How do we use storyboards to gather requirements?
There a number of techniques which will help you discover requirements. Storyboards are just one. Effective requirements gathering should include more than one technique. With this said, let's investigate where storyboards fit in requirements gathering. Bear with me for a moment though, since my curiosity led me to do a little informal research on Wikipedia about the origin of storyboards. It appears that as early as the 1920s storyboards surfaced at Walt Disney Studios. The technique of illustrated cartoons for short subjects (1920s) was then leveraged to storyboard Gone with the Wind (1939). What a grand idea for articulating a story line in an embraceable way!
Having proved itself in another industry, storyboarding is now being applied to system development, Web development and instructional design. After all, if you are focused on the user there must be a "story" to tell. It is important though to know what you can expect from a storyboard and when it is appropriate to use this technique. I will highlight a few salient points from the two articles below and encourage you to read them for yourself:
- Form Feeds Function: The Role of Storyboards in Requirement Elicitation by Jochen Krebs
- Use cases and storyboards each have their purpose
- "Are storyboards necessary? ...depends on the audience and goals. There is little question that use cases have a bigger impact on software engineering than storyboards.
Use Case Foundational "Use cases are the origin and basis for a well-defined object model that not only manages the functionality and business rules of a system, but also serves more than one HCI,…" Storyboard Experiential "But storyboards can serve a niche in software engineering that I believe is often overlooked. Within this niche, they can be extremely powerful when applied in the right context. Storyboards, like HCIs and GUIs, communicate design notions more clearly to users than use cases alone can. They give users real content that is easy to digest."
- A storyboard may be focused on the user, but the primary beneficiary is the developer
"In a sense, the primary beneficiary of the storyboard document is not the users, but we the software engineers."
Sample user interface
- Storyboards are well-liked by the customer thus offering an opportunity to discover new functional requirements early.
"Storyboards are fun to create and well-liked by the most important participant in the software engineering process, the customer. Using storyboards as a requirements elicitation technique is often underestimated. They provide a vital opportunity to discover potential new functional requirements much earlier."
- Storyboarding for Design: An Overview of the Process by Dan Gruen
- Know the reason you are creating your storyboard
"Reasons for using stories and storyboards include:
- Anchoring design in end use
- Promoting innovation by capturing the problems people face in a real world domain;
- Conveying functionality of a proposed solution, product or service
- Convincing people of the value of a proposed product in a real-world domain, and, by analogy, that it would be valuable in their own settings
- Collecting requirements and generating feedback on how the events and functionalities depicted in the story map to the intended domain
- Helping people understand how they could incorporate a new technology in their own work practice and recognize the value of doing so
- Promoting 'Due Diligence' by insuring that the factors required for a successful KM solution and user experience have been considered."
- Use your story in a variety of ways
For Initial "Because stories reveal the end value that a system will provide, they can be effective sales tools." For Requirements Gathering Storyboards can be highly effective tools for generating requirements. Hearing a story reminds people of similar situations they have experienced in the past. Show the storyboard to potential users of the system you are useing. Ask for:
- General feedback and reactions to the story and the system it depicts. Could they see themselves using such a system? Why or why not?
- Situations the story brings to mind that they have encountered in the past.
- Situations in which they could imagine using the depicted system. How well would the system fit their needs? What would have to be changed? Probe for detailed descriptions of these situations, as they can form the basis for additional stories that capture more aspects of the target setting.
For Design "The process of creating a storyboard helps designers put themselves in the shoes and setting of the people for whom they are designing. It often prompts invention and ingenuity as problems end users encounter are recognized and opportunities to solve them are devised." For System Rollout "It is often hard for users to understand how and why they should use a new system. ...Seeing a story showing the system used in a detailed real-world setting helps..."
A number of personal experiences have emphasized to me the importance of the visual, but this next story is a favorite. Many years ago I managed a group of requirements analysts, and our team was developing a loan origination and maintenance system. One day our administrative assistant asked me if there was any way she could help. Since we were working on use cases, sequence diagrams, object models and the like, I was initially wondering what I could give her to do. Not wanting to turn away any willing hands, I asked her to print off the prototype screens, glue them to a long expanse of brown paper and indicate where each button would take you. Anyway, several days went by and this is what some of our cube walls looked like.
Summary The power of the visual is evident even in my rather unorthodox storyboard example. (I failed to mention that Loan Origination (flow) was "strung" together with yarn and Loan Maintenance (starburst) had spokes of Popsicle sticks!) Did you notice that it was done by a novice? Did you notice that it was done without a tool? There are very good storyboarding tools available, but look at what can be done with just a piece of brown wrapping paper. Did you notice that our team got valuable navigation and functionality input without even asking? Did you notice that the beneficiary of this feedback was the development team? Did you notice that our "storyboard" was not the only requirement analysis technique being used?
Storyboards provide a very embraceable approach that needs little explanation. When used with other complementary analysis techniques (use cases, data/object model and so forth), storyboards provide not only valuable requirement information, but design insights as well.
Dig deeper on Software Requirements Gathering Techniques
Related Q&A from Betty Luedke
Expert tackles the daunting task of searching through requirements documentation to discover the most important parts of the documentation while she ...continue reading
Using defect tracking tools to manage requirements assumes the wrong idea about what requirements really do. Expert Betty Luedke explains how to ...continue reading
Software requirements are often subject to change; using a sound estimation process helps greatly to manage change. Requirements expert Betty Luedke ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.