Are you tired of REWORK caused by software requirements changes & misunderstandings?

Causes of Rework = duplication + translation errors

sources of rework

Too many hand-offs,  Translation Errors & Duplication

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.

When Requirements Change => You have to update too many documents with often duplicate information

For example…

  • Updating the user interaction flow and step details that are duplicated across your Use Cases and Storyboards and Test Cases
  • Updating your Wireframes, which are duplicated across multiple storyboards and test cases
  • etc

How do “Use Case Storyboards” eliminate this REWORK

“Use Case Storyboards” COMBINE your “use cases”, “wireframes” and “storyboards” into one integrated deliverable

A “Use Case Storyboard” as shown below, is simply a “Use Case” where each step in the use case is associated with a UI Wireframe/Mockup. This of course includes the main flow and alternate flow steps of the use case which is very different than traditional “Storyboards”, which are only a series of linear steps. This sounds simple, but the benefits are profound.

This approach allows you to walk through, or essentially simulate your “use case”.

Sample Use Case Storyboard where you associate Wireframes with each step  in a use case.

So what are the benefits of this approach and how does it reduce REWORK

    • Communicates Requirements more clearly resulting in less software development iterations
      • No longer does the reader have to review a use case and then manually correlate the steps in the use case to a storyboard or even worse just a collection of wireframes not put into a storyboard.
      • Instead the reader has the context of the details outlined in the use case step right beside and in context of the Wireframe associated with that step.
      • 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.
    • The “user interaction flow” is shared between the use case and the storyboard eliminating duplication
      • As the flow changes you no longer have to update the flow definition in multiple places (ie. Use Case, Storyboard, Test Cases), reducing rework.
      • It also ensures your storyboards cover all of the alternate flows defined within the use case helping ensure requirements are not overlooked
      • Your storyboards will have less duplicate UI Wireframes, because common wireframes that used to be duplicated across multiple storyboards are now defined in the mainflow or parent flows of nested alternate flows.
    • You could even generate your test cases from your Use Case Storyboards
      • The interaction flow and wireframes defined in the Use Case Storybaord are identical to what you will want for functional test cases. So using some creative algorithms you can actually automatically generate your functional test cases and they will be 100% in sync with your requirements.

powerSTORYBOARD allows you to create Use Case Storyboards in something you are already familiar with -> PowerPoint

Create “Use Case Storyboards” in PowerPoint with powerSTORYBOARD

Learn More…