Are you tired of REWORK to requirement and test cases when requirements change?

Current approach – too many hand-offs and deliverables

Many organizations approach to defining software requirements involve too many hand-offs and deliverables. This can lead to requirements translations errors between the different hand-offs and deliverables. In addition, the collective details of the requirements are spread across so many different deliverables it makes it harder for the developers and testers to properly interpret and understand the requirements.

For example, many organizations will take this approach…

  • BA / Product Manager
    • The BA or Product owner elicits requirements from a customer…
    • …and writes them down perhaps as a high level feature list…
    • …then further elicits and documents requirements details using use cases and/or user stories and perhaps
  • UI / UX Team
    • These use cases or stories are then interpreted by the UI/UX team…
    • …to develop UI Mockups
    • …and perhaps UI Storyboards
    • …or even full blow interactive UI Prototypes to bring these use cases to life.
  • QA and Development
    • Then the development team and the testing team need to interpret these UI Storyboards, UI Mockups and Use Cases to develop the code and Test Cases.

The result of this approach includes a lot of re-work and project costs due combinations of the following. Perhaps some of this sounds familiar to you.

  • Use Cases, UI Mockups, UI Storyboards and test cases often get out of sync with each other, which makes it difficult for the developers and testers to know what real requirements are.
    • For example the use case steps may now communicate something different than steps outlined in the ui storyboard or test cases.
  • UI Storyboards and/or prototypes forget to implement all of the flows outlined in the use cases, leading to a scenario where features get missed.
  • Test cases are incorrect, causing false bugs to be found, wasting further time and budget.
  • Missed test cases, causing bugs not to be uncovered, leading to costly production issues.
  • Developers building features that are different than what the customer is looking for, leading to unsatisfied customers or additional rework.
  • Another related issue is that often during the UI Storyboarding phase new requirements come up that are added to the UI Storyboard but also should be in the original use case. A lot of good intentioned teams will not spend the time to update the use cases and feature lists, furthering the confusion for the developers and testers.

What can we do to reduce this confusion and rework


The good news is that there are some reasonably simple changes we can make in our processes and deliverables that will decrease the “broken telephone effect”. The theme shared by these ideas is to reduce the hand-offs and translations.

Get the Entire Team Involved in the Requirements Early


One technique is to involve the BA, UI/UX and QA resources directly in the elicitation process with the customer. Some may even argue to include the lead developer for that domain as well. By having all disciplines represented during the interviewing process, they will all hear requirements directly from the customer, helping reduce the reliance on just what the BA documents. Another equally important side benefit is that each discipline brings a different perspective which can lead the interview process down different paths of conversation and requirements gathering.

For example the QA resource may tend to ask more questions about the requirements that related to edge conditions, or error conditions, than perhaps the BA or UI/UX resource would. In addition putting the UI/UX resource in front of the customer, will give them a chance to better understand what kinds of features are more frequently used, which is important when trying to manage the cognitive load of the end user, by ensuring the more frequently used functionality is more easily found through good UI/UX design.

This may seem like a waste of time and budget, but at least considering the benefits of doing this on the more complex portions of your application could be a good start.

My personal approach is to include the developers and QA team during the requirements walkthroughs early and well before they are done, so that they have the opportunity to provide feedback and also gain a deeper semantic understanding of the requirements and what is driving them.

Combine and evolve your Use Cases, UI Mockups and UI Storyboards into the same physical deliverable


One approach to addressing this is to combine your Use Cases, UI mockups and UI storyboards into one integrated deliverable called a “Use Case Storyboard”. A “Use Case Storyboard” is simply a use case where each step in the use case is associated with a UI Mockup.

This approach has the benefit of automatically keeping what you traditionally would have documented as a separate use case, UI mockups and UI storyboards in sync. In addition to keeping everything in sync, it turns out to be far easier to communicate the requirements during walkthroughs of “use case storyboards”, because they combine the details of a use case text along with the informative UI Mockups into one deliverable that is easy to walk through from the end user point of view. This not only helps your end customer confirm the requirements are correct, but also importantly helps reduce confusion with the developers and testers

In addition it strongly encourages the collaborative and combined review of use cases and UI/UX design by your BA and UI/UX teams, which will result in more accurately defined and understood requirements.

Adopting this approach would involve starting as we normally do by having the BA define the use case without any mention of UI specific requirements, just to capture the objective of the user in the use case and any key steps and alternate flows (or exception flows, depending on which terminology you use). Then the UI/UX team would start to attach UI Mockups to each of the steps in the Use Case to start to bring to life the UI/UX design.

Since the “Use Case Storyboard” is expressed in terms of a main flow and alternate it has the additional benefit of reducing the number of traditional storyboards, which are linear and don’t include alternate flows. For example if we took the sample “use case storyboard” above and represented it as two separate linear storyboards, the first and last steps and their UI mockups would be duplicated, leading to requirements maintenance and rework costs.

So to summarize, the “use case storyboard” reduces rework by helping you communicate requirements more clearly. In addition this approach also reduces requirements translation errors typically caused by hand-offs between deliverables and teams.


Generate Your Test Cases Automatically from Use Case Storyboards.


Instead of having your QA team manually create test cases, why not Generating test cases directly from your “Use Case Storyboards”. This has the following major benefits.

  • Dramatically reduce the time it takes to create your functional test case set.
  • Your test cases are 100% consistent with your requirements
  • You have complete functional test case coverage
  • As requirements change, you can update your test case set quickly

For example if we were to take the “Use Case Storyboard” outlined above, it would generate the following two test cases, including the UI Mockups.

Test Cases are typically written in a format of a “user action” followed by an “expected” result. If you spend a little more time up front when creating “Use Case Storyboards”, defining which steps are “user actions” and which steps are “expected results” this can used in the test case generation engine to determine which steps should be assembled into test cases as “user actions” or “expected results”.




As an industry we are always evolving how we do things. In this article I present an approach that helps reduce project costs and increase the likelihood that you will develop what your customers need. I talked about how to get your collective team involved earlier in the requirements definition process which is not really a new idea, but certainly a valuable one. However I do present the concept of a “Use Case Storyboard” that combines Use Cases, UI Mockups and UI Storyboards, into one integrated deliverable that promotes collaboration and also makes it easier to communicate requirements to your customer, developers and testers. Lastly I talked about the idea of generating your functional test cases directly from these “Use Case Storyboards” which generates some significant project savings.

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>