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.

Leave a reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>