Tuesday, 20 April 2010 00:00

Beyond Use Cases with Storyboarding

Written by 
Rate this item
(6 votes)

BeyondUse4The use case is now widely known as a technique to capture functional requirements. As long as we focus on core requirements in the early phase of software development, it works very well. However, once we have captured our business goals and want to see more details, especially user interface, we have to find other techniques and describe the detailed specifications in other documents separately. It makes our engineering process time-consuming when we get change requests. Also, use cases without UI information are not so easy for business users to understand. This article proposes a new approach for gathering requirements with storyboards. It's an approach that visualizes the use cases and enables business to walk through conceptual screens so that they can easily understand the proposed system.

Problems

In the whole software development process, we repeatedly have discussions with business about their needs and constraints and so on, We define the functional requirements in use cases, which are used as starting points for other stakeholders. For example, UI designers can start screen designs, architect can start architectural design for implementations, and QA team can start creating a test plan based on the use cases.

However, we need to spend a lot more time to refine the use cases due to a lack of details. In general, use case techniques are used in capturing core requirements, so we should avoid refining too many use cases. Hundreds of use cases make it difficult to understand and maintain consistency. Having said that, what if we don't describe the details? Developers and testers may choose easier ways that are not acceptable to business. Or they may simply ignore the cases; no implementation and no testing.

To avoid the problem, we normally describe the details in separate documents. But it also has some problems. One of the biggest problems is that the use case descriptions defined in the early phase are not updated. This is because our concerns have moved to details, which are not described in the use case document. As a result, even though we spend lots of time on them, no one, not even the business case users, sees the use cases. But the use cases are still important in and after the development, including in the maintenance phase, to clarify and remind what and why we implemented as we did.

In addition, we have one more problem: Business users often get more ideas when they

see prototypes or mock-up screens, and ask us to change the requirements.That is good for refining and making requirements better, but we have already started designing (and implementing testing sometimes), so it can definitely have a big impact. We need to find another approach that will allow us to easily manage such details in use cases, and also make it understandable to business.

Solution

Business users often ask me how the screen looks, even in the early phase, to understand the system we propose. So, I explain by drawing some simple wireframes on white board. Some elements and text messages are enough to express the system's behavior. This sort of visualization lets them get on the same page, and you can get more feedback from them.

Similar effects can be seen in a storyboard technique that visualizes interactions between system and user. The storyboard was originally developed in the film industry in which a series of pictures that represent each cut scene are organized in sequence. It pre-visualizes the script so that team members can easily understand what they have to do. The technique can also be applied to solving this problem. Here, I introduce a free storyboard tool, ezStory (http://www5f.biglobe.ne.jp/~webtest/ezstory/), developed with JavaScript. It allows you to draw a conceptual screen on a HTML page and define some actions that the system and/or user make take place as shown in Figure 1.

BeyondUse1
Figure 1. Conceptual Screen and Actions defined on ezStory

The screens can be linked to each other based on your requirements, and business can go through the pages just like they were accessing the final developed system.

There is one more important feature in the ezStory, which generates a storyboard document from the screens with use case description style. As you can see in figure 2, it looks like an ordinary use case description, but you can also see the conceptual screens defined in the HTMLs, which help readers understand where each action takes place and where it navigates if it's performed.

BeyondUse2
Figure 2. Conceptual Screen in Generated Use Case Description

In Figure 1, we defined two actions, a success case and an exception case (invalid ID or password). So, the ezStory generates a Main Flow and an Exception Flow in the document. If you add one more success case to the action list, an Alternative Flow will appear after the Main Flow. Since the screens and document are generated as HTML files, you can simply email or publish on web server so that business can also access the storyboard on their PCs.

Conclusion

Use case techniques have some problems that require us to describe and manage detail specifications and UI information separately, and maintenance of the documents can be difficult. In order to go beyond the constraints, I recommend using the storyboard tool, ezStory, which helps us visualize use cases and add more details in the use case descriptions. However, I don't recommend skipping the creation of use cases in your process. We should focus on core requirements first to find what business users want, then start storyboarding to refine the use cases. If you start storyboarding from the beginning, your business may be confused due to too much information, unless your application is small.

BeyondUse3
Figure 3. Vision, Use Case and Storyboard

I hope I have encouraged you to storyboard in your requirements gathering, and that it helps you capture all requirements in a use case document and in the entire development process.

Resources: ezStory homepage: http://www5f.biglobe.ne.jp/~webtest/ezstory/

Don't forget to leave your comments below


Masayuki Otoshi develops Web applications for a manufacturing company as a senior developer, and a developer of ezStory. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it.">This email address is being protected from spambots. You need JavaScript enabled to view it..

Read 37518 times Last modified on Tuesday, 03 April 2012 11:43

Comments  

0 # Andrew Midkiff 2010-04-21 05:21
For web applications, or applications with significant user interfaces, story boards are a great step between conceptual business needs and concrete design, especially if you can iterate through the storyboards from paper prototyping through wireframes and into finished mockups. For those applications without user interfaces, you can still use other kinds of modeling that still derive from use cases but show instead of screens, key moments in the process. An common example is a transactional system, such as an insurance adjudication system. Claims come in automatically, they get processed and come out the other end with a resolution, all without a single person looking at the claim. For something like this, it might make sense to diagram the state of the claim as it passes through the system. You might also indicate the transformations and processes happening to the claim in between each state. You can do this as formally as state diagrams, or as informally as a set of power point slide, or drawings on a sheet of paper. Storyboarding is really just a visual means of showing progression and change through time. You can use it for screens, states, transformations , etc... As long as you don't lose track of the details of behavior, constraints (rules), and data, storyboards can be a powerful way to allow your users to give more accurate feedback.
Reply | Reply with quote | Quote
0 # Mimi Sur 2010-04-21 08:43
This is a pretty useful, invaluable technique that information architects have been using for years and common in workshops when presenting to stakeholders who want to know how the application is going to work. Wireframes alone are not always enough. Usually, I use some sort of blended technique where the wireframes represent more than just the functionality (give some indication of look and feel) and are linked together. Sometimes using Visio, if I have the time and it's not a brand new app); more often using Powerpoint as it's easier to put together. Have been using this for years.
Reply | Reply with quote | Quote
0 # Kristofer Lundin 2010-04-22 18:38
I will definitely have a look on this tool. Like the proposed relation UC-story:) Doe s anyone have experience of above approach?
Reply | Reply with quote | Quote
0 # Mr Analyst 2010-04-23 00:15
ezStory looks like a cool tool. However a simple example is used for demo. Does someone have experience using this tool for complex use cases (with many alternate flows and extension points)? I kindda have a feeling the audience will loose the track of the flow if you introduce to many visuals. I therefore use Activity Diagrams with swimlanes to review most of my use cases. I also generate prototypes using Axure Pro (has a freel trial for 30 days) and keep it handy on the sides. Still I should be looking into new techniques. Nice article..
Reply | Reply with quote | Quote
0 # Tess 2010-12-21 06:40
Very valuable -
Reply | Reply with quote | Quote
+1 # Sunil Dhingra 2011-02-13 16:59
I came to this article when I was facing difficulty creating story boards from use cases and found this to be exceedingly wonderful.
Reply | Reply with quote | Quote
+1 # Aaron Sherman 2012-09-10 20:34
You can combine both the use case (or user story) and a very basic mockup in a storyboard using http://www.storyboardthat.com
Reply | Reply with quote | Quote
+1 # Humzah Al-Kindi 2012-10-25 09:45
The biggest confusion that I found in story boarding so far is that it means different for different people. There is no standard template for story boarding that is shared across the developer community.
To state my case here one link discribing story boarding that is very different from what you proposed:
http://answers.oreilly.com/topic/2485-storyboard-technique-for-software-projects/
Reply | Reply with quote | Quote
0 # Martin Crisp 2012-11-20 18:06
Hi

I have been a huge fan of "use case storyboards" for the past 5 years now, by associating UI Mockups / Wireframes with each use case step in the main and alternate flows.

KEY BENEFITS:

* better communicates requirements in an integrated manner
* better ensures that your use cases don't get out of sync with your storyboards or wireframes, compared with keeping all three in separate documents.
* Opens up opportunities for generating test cases automatically, as we do in our product "PowerStory".

PowerStory (a PowerPoint Plugin)

* allows you to create use case storyboards within powerpoint
* powerpoint is a very flexible UI Mockup / Wireframing tool, and very strong at 'communicating'.
* PowerStory also will generate test cases for each unique flow through the main flow and alternate flow steps.
* these test cases can be exported to TFS, Word and excel.

check it out at http://www.power-story.com

Martin Crisp
CEO PowerStory
Reply | Reply with quote | Quote
0 # Alan Maxwell 2012-11-20 19:14
I have found developing use cases is often an interative process, with at least two levels of Use Case.
The first is the High Level/Business Use case and is focussed on balancing the scope of each of many related Use Cases. Any graphics are around how the collection of all related Use Cases interact with each other and how the flow between them should work. Use case specific UI's are not relevant at this stage.
Eventually there is a final detailed versionof the use case with detailed system type info including data sources, business rules and indicative UI's etc.
The question of how soon to add indicative UI info into the use case, for me is as early as possible. E.g. Not the first iteration but soon after as makes things easier to communicate with business users, developers and others.
And always highlight that any included UI is indicative and may change before final version in application.
Note: A view of the overall UI navigation is also required and that is not inside any specific Use Case. For me that is separate and often an extension of the diagram that shows how all use cases interact.
Reply | Reply with quote | Quote
0 # Ian McGregor 2013-02-22 13:16
Masayuki,
Thanks for starting the conversation, I think the use of storyboarding resonates with many IT professionals. From my own experience introducing storyboarding early does not confuse the project stakeholders but helps to keep them engaged.
Reply | Reply with quote | Quote
0 # Carlos 2013-11-28 12:02
Masayuki, I liked the post, please email privately to me I want your OK to post your article in my blog, thanks, Carlos
Reply | Reply with quote | Quote
0 # Hari 2014-07-03 09:00
Can't agree with you more. Visual methodologies are treated as next upcoming avenues in consulting. More we resort to Visual based solution more we have same level understanding with our counter parts.
Reply | Reply with quote | Quote

Add comment


Security code
Refresh