Page 285 - Software and Systems Requirements Engineering in Practice

I
N
Q
U
P
T
H
A
T
H
N
ç
S
E
C
E
E
V
E
$
E
P
M
L
O
ç

R
ç
I
D
A
P
4
ç ç # # H A P T E R ç ç ç 2 2 A P I D ç $ E V E L O P M E N T ç 4E C H N I Q U E S ç ç
E
SEVERAL OTHER EVALUATION ASPECTS )F THE STORYBOARD CONTAINS SEVERAL
OPTIONAL WORKFLOWS IT CAN BE MARKED TO ILLUSTRATE THEIR START AND END
POINTS INCLUDING PRECONDITIONS AND POSTCONDITIONS 4HIS ALLOWS US TO
REPRESENT THESE MULTIPLE WORKFLOWS IN ONE ARTIFACT SIMPLIFYING
MAINTENANCE AND ANALYSIS !LSO STORYBOARDS CAN BE USED TO SHOW
DIFFERENT VARIATIONS OF THE PROPOSED SOLUTION "OTH THE SELECTED AND
DROPPED VARIATIONS CAN REMAIN IN THE DOCUMENT ALLOWING LATER
RECONSIDERATION OF THE CHOICES
6ISUAL PROTOTYPING IS MOST COMMONLY USED IN THE CONTEXT OF 5)
DESIGN 3TORYBOARDS PROVIDE USEFUL SUPPORT FOR THIS TYPE OF PROTOTYPING
)T IS VERY EASY TO IMPORT A SCREENSHOT OF AN EXISTING APPLICATION TO BE
USED AS AN INITIAL PLACEHOLDER FOR THE DESIRED FUNCTIONALITY )F EXECUTABLE
PROTOTYPES ARE INVOLVED SCREENSHOTS OF THE ACTUAL PROTOTYPE CAN BE
USED AS A FURTHER APPROXIMATION IN THE STORYBOARD DESCRIPTION !LSO
THIS TYPE OF PROTOTYPING COMMONLY GOES ON IN PARALLEL WITH 5) DESIGN
7HILE THE 5) DESIGN ITSELF IS UNLIKELY TO BE DONE USING 0OWER0OINT THE
SCREEN DESIGNS FROM ANY SPECIALIZED 5) DESIGN TOOLS CAN ALWAYS BE
IMPORTED INTO THE STORYBOARD TO IMPROVE THE REPRESENTATION OF THE
TARGET SYSTEM
3TORYBOARDS FOCUS THE DISCUSSION BETWEEN REQUIREMENTS ENGINEERS
AND VARIOUS STAKEHOLDERS ON THE SPECIFIC REQUIREMENTS OF AN AGREED
SCENARIO OF INTEREST 4HEY ENABLE THEM TO ELICIT ELABORATE AND ORGANIZE
THE SYSTEM REQUIREMENTS WITHIN A SINGLE ARTIFACT 4HE INTUITIVE NATURE
AND REPRESENTATION CAPABILITIES OF THE STORYBOARD GENERALLY ALLOW ANY
STAKEHOLDER TO CONTRIBUTE TO THE EVOLUTION OF THE REQUIREMENTS 4HEY
CAN DO THIS INDIVIDUALLY OR IN COACHED GROUPS BY SIMPLY ANNOTATING
THE RELEVANT PARTS OF THE DOCUMENT 7HILE WE DON T ADVOCATE A SPECIFIC
PROCESS FOR HANDLING STORYBOARDS THERE ARE SOME SPECIFIC ASPECTS OF
REQUIREMENTS THAT CAN AND SHOULD BE EXPLORED
v 4HE GRAPHICAL PART OF THE STORYBOARD SLIDE SHOULD DESCRIBE
THE VISUAL ASPECT OF THE APPLICATION AND ONLY THE MOST
IMPORTANT USER INTERACTIONS 5SER INTERACTIONS ARE DESCRIBED
BY HIGHLIGHTING THE VISUAL ELEMENTS THAT ENABLE THEM
(IGHLIGHTING AND CALLOUTS ARE ALSO USED TO EMPHASIZE THE
CONTENTS OR THE ROLE OF SPECIFIC AREAS OF THE DISPLAY
v .OTES ASSOCIATED WITH A STORYBOARD REPRESENT OTHER DETAILS
INCLUDING OPTIONAL INTERACTIONS UNAVAILABLE INTERACTIONS
FURTHER STAKEHOLDER REQUESTS NOT ASSOCIATED WITH THE PRIMARY
SCENARIO AND GENERAL NOTES ASSOCIATED WITH A SPECIFIC STEP
.OTES ALLOW MULTIPLE STAKEHOLDERS TO FORMULATE CONFLICTING
CHANGE REQUESTS AND TO KEEP TRACK OF THEM IN A WELL STRUCTURED
FORM ASSOCIATED TO THE CONTEXT WHERE THEY ARE RELEVANT
v %ACH STEP OF THE SYSTEM INTERACTION SHOULD BE REPRESENTED IN
THE STORYBOARD 4HIS COMPLETENESS OF THE SEQUENCE IS IMPORTANT
TO ENSURE THE UNAMBIGUOUS REPRESENTATION OF THE SYSTEM FOR
MULTIPLE STAKEHOLDERS )N GENERAL IT IS BETTER TO PUT SIMPLE