Guideline: Discover and Clarify Requirements with Storyboarding
Take someone's vision of carrying out an activity and communicate that vision to developers who can create that vision.
Relationships
Related Elements
Main Description

The fundamental purpose of storyboarding is to take someone's vision of carrying out an activity and communicating that vision to developers who can create that vision.

Storyboarding is a technique, within requirements definition, that is used to both discover and to clarify requirements. This technique can be used at many points within a development lifecycle and is equally relevant for Systems development as it is for software development.

Storyboarding may take place as early as the Inception Phase to identify what capabilities (goals) the stakeholder may wish obtain. At this phase in development the 'System' (whether it includes hardware or just software) does not exist. Alternatively it could take place later in the development and would be used to clarify how something (user) may interact with the item being developed (User Interface). Therefore, the purposes for storyboarding will be different at various phases in the development.

Before storyboarding should take place it is essential that the problem to be solved is clearly identified. Once the problem has been identified then the purpose of the storyboard can be defined. The purpose should clearly 'bound' the area under investigation so providing the scope for the storyboarding. Within this 'bounding' any constraints that may be applicable for the storyboard should be identified.

Following the completion of a storyboard, checks should be made to verify that the purpose of the storyboard has been resolved. It is essential that the stakeholders involved in storyboarding take ownership of the developed storyboard, in effect, 'signing up' to the storyboard validating that it correctly expresses their thoughts. To enable ownership it is essential that the storyboard is developed using terms that they understand.

The end state of the item under investigation should be documented and any further potential related storyboards should also be identified (maybe because of dependencies). A list of assumptions made during the storyboard should be gathered (which can later be verified as being correct) plus any constraints discovered during the storyboarding.

Following the storyboard, requirements should be generated from the results of the storyboard with traceability (back to the specific element within the storyboard) and agreed with the stakeholder. These requirements would then be placed within the appropriate requirements set from which the need for the storyboard first emerged.

A typical template for creating a storyboard would include the pre and post conditions as detailed below:

Pre Conditions

1. Define the Problem
It is important to fully understand the problem to be addressed. If storyboarding is being employed during the Inception Phase, it is likely that the problem being addressed is to identify what 'capabilities' the stakeholder will obtain. This may be initiated from original stakeholder needs. If storyboarding is taking place later in the development lifecycle, then it is more likely that the problem being addressed will involve identification of some feature or behavior of something under development.

Inception Phase Example: The retail shopper statement of need - I wish to shop for items from retail outlets without leaving my home.
Elaboration Phase Example: Implementation centric need - How can the music enthusiast confirm whether he will enjoy the item he is purchasing?

2. Define the Purpose of Storyboarding
The storyboard to be developed should focus on the problem identified; however, the problem being resolved may need a number of stakeholder viewpoints to be considered. Therefore, it may be that several storyboards have to be created to fully address the problem under investigation. Stakeholders and analysts must understand the boundary of the storyboard. This is best defined by clearly stating the purpose for the specific storyboard.

Inception Phase Example: To identify how a classical music enthusiast may wish to purchase music from retail outlets while remaining at home
Elaboration Phase Example: To identify the location, appearance and occurrence of the 'Sample play' function within the on-line market GUI

3. Define Type of Storyboarding
There are fundamentally two types of storyboard. These are Requirements Discovery storyboards or Requirements Clarification storyboards. These storyboards would cover all examples of where storyboarding may be needed, for example, Capability Discovery, Use-case Development, User Interfacing, Requirements Clarifying, Prototyping.

Inception Phase Example: Capability Requirements Discovery
Elaboration Phase Example: Prototyping Requirements Clarification

4. Identify Development Lifecycle Phase
Clearly there is a relationship between the type of storyboard to be used and the phase of the development lifecycle. It is likely that during the Inception Phase that requirements are being 'discovered', while in the Elaboration Phase there may need to be a further understanding and clarification of the requirements.

5. Determine Level of Fidelity to be Used
When planning to use storyboarding, the level of fidelity (that is, how accurately must the storyboard reflect the theme under investigation) should be determined. It is likely that a low level of fidelity could be used when storyboarding during the Inception Phase, as it is unlikely to be clear what the 'end' product will be. When using storyboarding during the Elaboration Phase, it is likely that there will be considerable knowledge of what the end product will be and will appear like. The higher level of fidelity will be important to accurate reflect this appearance to enable the clarification of requirements to take place.

6. Identify Stakeholder Role
The role of the stakeholder to be questioned during storyboarding should be identified, particularly when there will be multiple storyboards.

Inception Phase Example: Retail shopper
Elaboration Phase Example: Music enthusiast

7. Identify Constraints
Before the storyboard begins, it is essential that any constraints applicable for the storyboard are identified. This will ensure that the development remains within any limiting circumstances such as legal constraints or domain standards.

Inception Phase Example: An audit trail of the order/purchase process must be available for scrutinizers
Elaboration Phase Example: The GUI should conform to Standard Windows conventions

Post Conditions

Following the completion of the storyboard it is essential that the validity of the developed storyboard is confirmed and any further follow-on work is identified.

1. Confirm original problem resolved
Has the storyboard fully resolved the original problem identified?
Yes/Partial/No

2. Confirm purpose of storyboard satisfied
Was the purpose of conducting the storyboard satisfied?
Yes/No

3. Storyboard agreed with Stakeholder
Has the stakeholder involved with the storyboard taken ownership for the storyboard yet?
Yes/Under review/No

4. Further storyboard themes identified
During the development of the storyboard were other storyboard themes identified. What were those themes and what stakeholder roles would be involved?

Inception Phase Example: How the retailers may keep track of deliveries
Elaboration Phase Example: The location, appearance, and occurrence of the album art feature

5. Related storyboards
Identifying where other storyboards have been or are planned to be developed. Typical where a sequence of actions, each fully discovered via separate storyboards.

6. Assumptions made
Identifying any assumptions that were made during the storyboard development. These assumptions will require follow-up action to confirm if correct

Example: only valid with UK legal jurisdiction

7. New Constraints
Identifying any constraints discovered during the storyboard development and not already defined in the pre-conditions

8. Requirements sources identified within the storyboard