Results for category "communicating requirements"

Create wireframe designs for SAP using PowerPoint / PowerStory

With SAP release of SAP UI5, their  HTML5 Toolkit for Quickly Building Lightweight Business UIs on Multiple Platforms, this really does provide tremendous opportunity for building amazing applications based on SAP but even more integrated with the world outside of SAP.

Use PowerStory SAP UI5 Library to design your SAP Applications

PowerStory has added about 200 UI SAP UI5 controls, based on the controls defined on SAP’s SAP UI5 site found here, to its library of now almost 700 UI Controls.  This first version is focused on the web based SAP UI5 controls, with a future set of libraries being planned for the Mobile SAP UI5 controls.

If you already have the PowerStory for PowerPoint plugin, and want to import this SAP UI5 library into PowerStory, you can download the library here. This library is only available on this page.  Here is a quick video showing you how to import the SAP UI5 Shapes library.

If you don’t yet have the PowerStory for PowerPoint plugin, you can get a free trial here and then download and import the SAP Library

Here is an example of a sample UI Mockup created using the PowerStory SAP UI5 library.  (Click on the image to see a bigger version of it)

sample sap ui built using PowerStory


There are too many UI Controls in the library to show you them all, but here are some samples…









Forms and ValueFields













Overlays with DialogsSAP UI5 SAMPLE OVERLAY




Avoiding conflicting requirements across your different requirements artifacts?

One issue I hear from developers, testers and stakeholders when reviewing requirements specs, is that sometimes the different requirements artifacts such as use cases, stories, wireframes and storyboards will often have “conflicting information” about the requirements, leading to confusion.

For example:
You might start with a user story, which is then expanded into a one or more use cases, which define the flow of steps between the system and the end user. Then there might be a number of wireframes defined and put together in the form of a storyboard to essentially bring the use case to life. I have often seen the situation where as the storyboard evolves and by its nature uncovers incremental requirements, the storyboard may have some steps in it that are not defined in the use case or worse in fact contradict what is in the use case. Then the test cases get created which again define a series of steps between the system and the end user.

The key thing being duplicated here across use cases, storyboards and test cases, is the series of steps between the system and the end user. This leads to confusion as to what the requirements are. 

Essentially what is happening here is that as we add more details about the requirements by adding new requirements artifacts, even with full traceability, we run the risk of duplicating requirements information which can get out of sync, or providing new conflicting requirements information.

Traceability to the rescue? Kind-of, but not fully!

One strategy to help reduce this issue, is to not to duplicate specific requirements details across the different requirements artifact types, and use traceability to link everything together. This traceability strategy is good to a point but does not fully address the issues I raised above. With this traceability strategy you still won’t avoid the duplication of the steps / flow describing how the user interacts with the system across your use cases, storyboards and test cases. 

We also need to combine artifact types! 

By combining the concepts of use cases, wireframes, storyboards and test cases into one integrated requirements artifact type that only defines the flow of steps between the user and the system once, you will avoid this duplication.

I refer to the combining of these different deliverable types as a “Use Case Storyboard“. The concept is to start with a use case and then as you create your wireframes, you associate them with each step in the use case, so that you can easily see the step information and the wireframe together. When you “walk through” the steps you are essentially seeing something similar to a storyboard, but this storyboard is not linear like traditional storyboards. In other words this storyboard supports main flows and alternate flows.

This notion of having storyboards that support main flow and alternate flows just like use cases do, further reduces duplication beyond just what was stated above. For example if you were to translate a use case with just one alternate flow into a storyboard you would need to create two storyboards, and these two storyboards would need to duplicate the steps in the main flow that are common. 

Now let’s talk about testing! 

You could perhaps just use the “use case storyboards” as your test scripts, or you could have some software automate the creation of your test cases by scanning the “use case storyboard” and creating a test case for each unique path through the combination of main flow and alternate flow steps. This does create a duplicate of the steps information, but it can always be re-generated when the “use case storyboard” needs to reflect a change in requirements.


Stop the insanity of multiple copies of your requirements specifications floating around in eMail inboxes

If you are like most people I talk to, you hate all the versions and copies of requirements documents that fly around within emails. The good news is that the advancements in cloud based solutions for office in the form of skydrive and office 365, really provide you with the opportunity to eliminate this pain point.

  • With SkyDrive, everyone has access to the same version of the requirements documents you produce!
  • Pass around the links…not the documents!
  • Edit the Documents at the same time! Yes Really!
  • You can even view and edit these documents directly in your browser, but you still have the option of working offline using your desktop version of office.
  • When you create links between documents (e.g for traceability) those links won’t get broken even if you move the document to another folder in skydrive.

The one thing skydrive does not really offer is what I would refer to as “requirements management” capabilities. By this I mean the ability to sort and organize your requirements/features lists by additional data such as “priority”, “status”, “owner” etc.


Developers keep telling me there is not enough detail in the requirements spec!

Developers keep telling me there is not enough detail in the requirements spec! …or they are having a hard time understanding the requirements


  • BAs might say…
    • Developers seem to want every last detail defined…can’t they think for themselves.
    • Or they just make a lot of assumptions. That are clearly wrong!  what were they thinking?
  • Developers might say…
    • The requirements are not clear…there are so many details that are left out.
    • It is difficult to see the big picture and overall flow from a user perspective

potential reasons for this

  • the spec document is not very clear or well organized
  • the spec document was written in a form that was easy to create…instead of easy to understand…
    • for example if you write requirements just as a collection of statements that are “traced or linked to each other”, this can be hard for a developer to consume and understand.
  • you rely on the developer to read the spec and understand it


  • walk through the requirements with the developer
  • get the developer involved early and often in the review of the requirements
  • make sure the requirements are written in a form that is easy to understand – e.g. from a user point of view such as use cases, storyboards etc.
  • don’t duplicate requirements, as they can get out of sync and confuse the team.
  • ensure your requirements don’t conflict each other


Nobody seems to read my requirements spec document! &#*#!

  • why
    • too much volume
    • hard to follow
    • all the details are referenced to somewhere else
    • don’t know what it will look like
  • do it differently
    • describe from user point of view
      • user scenarios
      • user stories
      • use cases
      • storyboards
      • use case storyboards
    • de-normalize
      • don’t duplicate things….but combine them.
      • Combine your use cases, storyboards and wireframes into one deliverable
    • don’t duplicate the story flow
      • scenario, use case, storyboard and test cases all duplicate the same story flow…stop it
    • walk them through the requirements


Design for Simplicity

My presentation from a workshop I lead at work on design for simplicity. Below are the notes for each slide: 2. Simplicity can be divine. When done right. When done right, you will find people usin…

PowerStory‘s insight:

some good rules of thumb about designing for simplicity in this presentation.

See on