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
|