What are some sources of “REWORK”
- Misunderstanding of Requirements => Translation Errors
- Test Cases that are inconsistent with the Requirements
Changes to Requirements
- 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
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”.
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.