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:
- 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."|
"In a sense, the primary beneficiary of the storyboard document is not the users, but we the software engineers."
"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."
- 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."
|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:
|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.
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.
This was first published in June 2008