Software Requirements Engineering

Lecture # 7

Team Skill 2: Understanding User and

Stakeholder Needs

Requirements Elicitation Techniques - III

ALI JAVED

Lecturer

SOFTWARE ENGINEERING DEPARTMENT

U.E.T TAXILA

Email:: [email protected]

Office Room #:: 7

 Presentation Outline

 Storyboarding
 Benefits of Storyboarding
 Limits of Storyboarding
 Types of Storyboarding

 Passive Storyboarding
 Active Storyboarding
 Interactive Storyboarding

 What Storyboards Do
 Tools for Storyboarding
 Tips for Storyboarding
 Role Playing
 How to Role Play
 Scripted Walkthroughs
 CRC Cards
 Requirements Elicitation Techniques
 Interviews

 Questionnaires

 Background Reading

 Introspection

 Social Analysis

 Requirements Workshops

 Brainstorming and Idea Reduction

 Story Boarding

 Role Playing

 Prototyping

 Requirements Reuse covered in previous lectures

Covered in this lecture Will be covered in future lectures

 Storyboard
 A Storyboard is a logical and conceptual description of system
functionality for a specific scenario, including the interaction required
between the system users and the system

 A Storyboard "tells a specific story“

 The goal in all techniques is to interact with the user

 Helps to Bridge the gap between the user and the developer

 Nonetheless, most of these interpretations agree that the purpose of

storyboarding is to gain an early reaction from the users on the concepts
proposed for the application.

 With storyboarding, the user's reaction can be observed very early in

the lifecycle. In so doing, storyboards offer an effective technique for
addressing the "Yes, But" syndrome.

 Storyboarding is also very effective for “Blank page” Syndrome

 Storyboarding
 Often used in conjunction with another technique

 Capture ideas via brainstorming or interviewing

 Document in a storyboard to show user what is understood

 Human factors experts have promoted storyboarding for years

 This technique is used heavily in the movie industry

 Benefits of Storyboard
 A storyboard serves multiple purposes

 Helps understand how requirements impact implementation and test

 Provides an early review of the User Interface of the system (Describe

s how a system or part of a system is intended to work “before the fact”)

 documents system functionality

 Is extremely inexpensive

 Is user friendly, informal, and interactive

 Is easy to create and easy to modify

 Limitations of Storyboard
 One of the biggest problems with storyboards is that they can
become outdated very quickly. User interfaces originally defined
often change over time, and that creates a maintenance burden.
 Types of Storyboards
 Passive Storyboards

 Active Storyboards

 Interactive Storyboards
 Passive Storyboards
 Passive storyboards tell a story to the user.

 They can consist of sketches, pictures, screen shots, PowerPoint

presentations, or sample application outputs.

 In a passive storyboard, the analyst plays the role of the system

and simply walks the user through the storyboard, with a "When
you do this, this happens" explanation.
 Active Storyboards
 Active storyboards try to make the user see "a movie that hasn't
actually been produced yet."

 Active storyboards are animated or automated, perhaps by an

automatically sequencing slide presentation, an animation tool, a
recorded computer script or simulation, or even a homemade movie

 Active storyboards provide an automated description of the way

the system behaves in a typical usage or operational scenario.
 Interactive Storyboards
 Interactive storyboards let the user experience the system in as
realistic a manner as practical.

 They require participation by the user.

 Interactive storyboards can be simulations or mock-ups or can be

advanced to the point of throwaway code.

 An advanced, interactive storyboard built out of throwaway code

can be very close to a throwaway prototype.
 Types of Storyboards
 As Figure 1 shows, these three storyboarding techniques offer a continuum
of possibilities ranging from sample outputs to live interactive demos.

 Indeed, the boundary between advanced storyboards and early product

prototypes is a fuzzy one.
 What Storyboards Do
 In software, storyboards are used most often to work through the
details of the human-to-machine interface.

 In this area, generally one of high volatility, each user is likely to

have a different opinion of how the interface should work.

 Storyboards for user-based systems deal with the three essential

elements of any activity:

 Who the players are

 What happens to them

 How it happens
 What Storyboards Do
 The who element defines the players, or the users of the system.

 In a software system, the who are such players as users, other

systems, or devices—in other words they are the actors that interact
with the solution system we are defining.

 For users, the interaction is typically described via user input

screens or data entry forms, outputs such as data or reports, or
other types of input and output devices, such as buttons, switches,
displays, and monitors.

 The what element represents the behavior of the users as they

interact with the system as well as the behavior of the system as it
interacts with the user.

 The how element provides descriptions of how this interaction h

appens, showing events, states, and state transitions.
 What Storyboards Do

For example, a storyboard for an automated-vehicle amusement park ride i

ncludes the following things.

 The who represented the guests who ride on the vehicle.

 The what represented the behavior of the vehicle as it provided

various events for the guests.

 The how provided further descriptions of how this interaction

happens—events, state transitions—and described both the guest states
(surprised, scared) and the vehicle states (accelerating, braking,
unloading).
What Storyboards Do
 Tools for Storyboarding
 The tools and techniques for storyboarding can be as varied as the
team members' and users' imaginations will allow.

 Passive-storyboarding constructs have been made out of tools as

simple as paper and pencil or Post-it notes.
 Tools for Storyboarding
 More advanced storyboards can be built with presentation
managers such as PowerPoint.

 Passive, active, and user-interactive storyboards have been built

with various packages that allow fast development of user screens
and output reports.

 Interactive storyboards can be built with a variety of specialty

software packages for interactive prototyping, and tools such as
Macromedia's Director and Cinemation from Vividus Corporation and
Xara’s Graphics maker can be used to create more complex a
nimations and simulations.
 Tips for Storyboarding
 Here are some tips to keep in mind as you practice your
storyboarding technique.

 Don't invest too much in a storyboard.

 If you don't change anything, you don't learn anything.

 Don't make the storyboard too functional.

 Whenever possible, make the storyboard interactive.

 Who uses Storyboards
 The following people use the Storyboards:

 system analysts, to explore, clarify, and capture the behavioral

interaction envisioned by the user as part of requirements elicitation.

 user-interface designers, to design the user interface and to build a

prototype of the user interface;

 designers of the classes that provide the user interface functionality.

They use this information to understand the system's interactions with
the user, so they can properly design the classes that will implement the
user interface.

 those who test to test the system's features.

 the manager to plan and follow up the analysis & design work.
 Examples

 Imagine that in reviewing this visual storyboard, our end-user

accountant says, "Well, actually, billing numbers are divided into t
wo parts, the year and a unique number.

 This drawing shows only one field for the account number." Then
he adds: "And by the way, I don't want to enter the year all the time
, so please initialize this value with the current year, which I can
overwrite if necessary."
 Role Playing
 Role playing allows the development team to experience the user
world from the user’s perspective by playing the role of the user

 Role playing can be effective to address the following causes:

 Many users cannot articulate the procedures they follow or the needs
that must be addressed

 Many users do not have the freedom to admit that they do not follow
prescribed procedures; therefore what they tell you may or may not be
what they actually do

 Individual users may have patterns of work activity that are deeply in
grained and apply workarounds or unique paths of implementation that
may mask real problems from the observer

 It is impossible for any developer to anticipate every question that

must be asked or for users to know “what questions the developer
should be asking”
 How to Role Play
 In the simplest form of Role playing, the developer, the analyst,
and potentially every member of the development team simply take
the place of the user and execute the customers work activity

 There are two ways to get at the root causes:

 Use the Fish bone diagram, together with user’s input to analyze the
existing system and finds the root cause

 The developer/analyst can experience the problem and inaccuracies

inherent in the existing system by simply sitting down and execute the
system by himself

 By Playing the role of the user and using the system, the
developer or analyst can gain a better understanding of the
problem of existing system
 Scripted Walkthroughs
 In scripted walkthrough each participant follows a script that
defines a specific role in the “play”

 The walkthrough will demonstrates any misunderstanding in the

roles, lack of information available to an actor or lack of specific
behavior needed for the actors to succeed

 For example consider the case of an automated digital whiteboard

connected with several computers used in the class room and we are
interested to view how students and teacher would interact with an
automated digital whiteboard

 A prototype of the device can be used and had team members and
customer representatives play the roles of student and teacher

 The walkthrough contained multiple scenes, such as “students

accessing digital whiteboard through their computers and performing
the tasks assigned by the teacher to them and “teacher using the white
board for lectures”

 The scripted walkthrough was very useful way to get the feel for the
class room environment and the team learned a few new things in the
process
 Scripted Walkthroughs

 One of the advantages of

the scripted walkthrough is
that a script can be
modified and rerun as
many times as necessary
until the actors get it right

 The script can also be

reused to educate new
team members

 The script may be

modified and reused when
the behavior of the
system needs to be
changed
CRC (Class-Responsibility-Collaboration) Cards
 A derivative of Role playing is often applied as part of an object
oriented analysis effort

 In a special case of a Role play, each participant is given a set of

index cards describing the class or object; the responsibilities, or
behavior; and collaborations, or who the object communicates with,
of each entity being modeled
CRC (Class-Responsibility-Collaboration) Cards
 These collaborations may represent entities from the problem
domain, or objects that live in the solution domain

 When an indicator actor starts a specific behavior, all participants

follow the behaviors defined on their cards

 When the process breaks down due to a lack of information or

when one entity talks to another and the collaboration is not
defined, the cards can be modified and rerun again
 QUIZ # 3
1. ________ activity involves the organization of requirements
gathered from different sources

a) Requirements Organization
b) Requirements Classification
c) Requirements Conflicts
d) Requirements Prioritization

2. _________ is a cheaper way to get feedback from the users,

because it can reach to a large no of users in a short period of
time

a) Background Reading
b) Interviews
c) Questionnaires
d) Introspection
 QUIZ # 3
3. ________ technique is used when users are not available, don’t
want to answer your questions or shows lack of feedback or
input

a) Background Reading
b) Interviews
c) Questionnaires
d) Introspection

4. _________ technique is appropriate when you are not familiar

with the organization being investigated.

a) Background Reading
b) Interviews
c) Questionnaires
d) Introspection
 QUIZ # 3
5. ________ technique of Social analysis is carried out without
the direct involvement of the observer in the society

a) Passive Observation
b) Active Observation
c) Interactive Observation
d) Explanatory Observation

6. How we can reduce the “Undiscovered Ruins” Syndrome?

7. Why there exists high possibility for bias in Interviews?

8. Why Background reading cannot be solely used for Requirements

Elicitation?

9. List the major drawback of Introspection technique?

10. Differentiate between Passive and Active observation

Any question