Scenario based methods

SCENARIO-BASED
METHODS
UNIT-II
OCTOBER
2021

CONTENTS
Requirements Analysis
Overall Objectives and Philosophy
Analysis Rules of Thumb
Domain Analysis
Requirements Modeling Approaches
Scenario-Based Modeling
Creating a Preliminary Use Case
Refining a Preliminary Use Case
Writing a Formal Use Case
UML Models That Supplements the Use Case
Developing an Activity Diagram
Swimlane Diagrams 2

3
Requirements analysis results in the specification of software’s operational
characteristics, indicates software’s interface with other system elements,
and establishes constraints that software must meet.
“Any one ‘view’ of requirements is insufficient to understand or describe the desired behavior of a
complex system.”
Alan M. Davis
QUOT
E:
REQUIRMENTS ANALYSIS

4
The requirements modeling action results in one or more of the following
types of models :
• Scenario-based models of requirements from the point of view of
various system “actors”
• Data models that depict the information domain for the problem
The analysis model and requirements specification provide a means for assessing quality once the
software is built.
Key Point:

5
The requirements modeling action results in one or more of the following
types of models :
• Class-oriented models that represent object-oriented classes
(attributes and operations) and the manner in which classes collaborate
to achieve system requirements
• Flow-oriented models that represent the functional elements of the
system and how they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a
consequence of external “events”

6
The requirements model must achieve three primary objectives:
• to describe what the customer requires
• to establish a basis for the creation of a software design
• to define a set of requirements that can be validated once the software
is built.
REQUIRMENTS ANALYSIS :
“Requirements are not architecture. Requirements are not design, nor are they the user interface.
Requirements are need.”
- Andrew Hunt and David Thomas
Quote:

7
The analysis model bridges the gap between a system-level description that
describes overall system or business functionality as it is achieved by
applying software, hardware, data, human, and other system elements and a
software design that describes the software’s application architecture, user
interface, and component-level structure.
The analysis model should describe what the customer wants, establish a basis for design, and
establish a target for validation.
Key Point:

8
Fig: The requirements model as a bridge between the system description
and the design model

9
• It is important to note that all elements of the requirements model will be directly
traceable to parts of the design model.
• A clear division of analysis and design tasks between these two important
modeling activities is not always possible.
• Some design invariably occurs as part of analysis, and some analysis will be
Conducted during design.

10
Arlow and Neustadt [Arl02] suggest a number of worthwhile rules of thumb that
should be followed when creating the analysis model:
• The model should focus on requirements that are visible within the problem or
business domain. The level of abstraction should be relatively high.
• Each element of the requirements model should add to an overall
Understanding of software requirements and provide insight into the information
domain, function, and behavior of the system.
• Delay consideration of infrastructure and other nonfunctional models until
design.

11
Arlow and Neustadt [Arl02] suggest a number of worthwhile rules of thumb that
should be followed when creating the analysis model:
• Minimize coupling throughout the system.
• Be certain that the requirements model provides value to all stakeholders.
• Keep the model as simple as it can be.
“Problems worthy of attack, prove their worth by hitting back.”
- Piet Hein
Quote:

12
Domain Analysis
Firesmith [Fir93] describes domain analysis in the following way:
Software domain analysis is the identification, analysis, and specification of common
Requirements from a specific application domain, typically for reuse on multiple
Projects within that application domain.
Domain analysis doesn’t look at a specific application, but rather at the domain in which the application
resides. The intent is to identify common problem solving elements that are
applicable to all applications within the domain.
Key point:

13
Domain Analysis
Firesmith [Fir93] describes domain analysis in the following way:
[Object-oriented domain analysis is] the identification, analysis, and specification
of common, reusable capabilities within a specific application domain, in terms of
common objects, classes, subassemblies, and frameworks.

14
Domain Analysis
The “specific application domain” can range from avionics to banking, from
Multimedia video games to software embedded within medical devices.
The goal of domain analysis is straightforward: to find or create those analysis
classes and/or analysis patterns that are broadly applicable so that they may be
reused.

15
Domain Analysis
Input and output for domain analysis

16
• One view of requirements modeling, called structured analysis, considers data and
the processes that transform the data as separate entities.
• Data objects are modeled in a way that defines their attributes and relationships.
• Processes that manipulate data objects are modeled in a manner that shows
how they transform data as data objects flow through the system.
“…analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult. In a word, it
is fascinating. Once you’re hooked, the old easy pleasures of system building are
never again enough to satisfy you.” - Tom DeMarco
Quote:

17
Elements of the analysis model

18
SCENARIO-BASED MODELING:
Alistair Cockburn characterizes a use case as a “contract for behavior”
[Coc01b].
The “contract” defines the way in which an actor uses a computer-based
system to accomplish some goal.
In essence, a use case captures the interactions that occur between
producers and consumers of information and the system itself.
“[Usecases] are simply an aid to defining what exists outside the system(actors) and what should be
performed by the system (Use cases)- Ivar Jacobson
Quote:

19
What to Write About ?
Requirements-gathering meetings, quality function deployment (QFD),
and other requirements engineering mechanisms are used to identify
stakeholders, define the scope of the problem, specify overall operational
goals, establish priorities, outline all known functional requirements and
describe the things (objects) that will be manipulated by the system.
“[Usecases] are simply an aid to defining what exists outside the system(actors) and what should be
performed by the system (Use cases)- Ivar Jacobson
Quote:

20
What to Write About ?
To begin developing a set of use cases, list the functions or activities
performed by a specific actor. You can obtain these from a list of required
system functions, through conversations with stakeholders, or by an
evaluation of activity diagrams developed as part of requirements
modeling.
In some situations, use cases become the dominant requirements engineering mechanism. However,
this does not mean that you should discard other modeling methods when they are appropriate.
Advice:

21
The SafeHome home surveillance function (subsystem) discussed in the
sidebar
identifies the following functions (an abbreviated list) that are performed
by the
homeowner actor:
• Select camera to view.
• Request thumbnails from all cameras.
• Display camera views in a PC window.
• Control pan and zoom for a specific camera.
• Selectively record camera output.
• Replay camera output.
• Access camera surveillance via the Internet.
Example
:

22
Use case: Access camera surveillance via the Internet—display camera
views
(ACS-DCV)
Actor: homeowner
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight
characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function
buttons.
Example
:

23
Use case: Access camera surveillance via the Internet—display camera
views
(ACS-DCV)
Actor: homeowner
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the
camera ID.
11. The system displays video output within the viewing window at one
frame per second.
Example
:

24
A description of alternative interactions is essential for a complete
understanding of the function that is being described by a use case.
Therefore, each step in the primary scenario is evaluated by asking the
following questions [Sch98a]:
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at this
point? If so, what might it be?
• Is it possible that the actor will encounter some other behavior at this
point (e.g., behavior that is invoked by some event outside the actor’s
control)? If so, what might it be?

25
Cockburn [Coc01b] recommends using a “brainstorming” session to derive
a
reasonably complete set of exceptions for each use case. In addition to the
three generic questions suggested earlier in this section, the following
issues should also be explored:
• Are there cases in which some “validation function” occurs during this
use case?
• Are there cases in which a supporting function (or actor) will fail to
respond appropriately?
• Can poor system performance result in unexpected or improper user
actions?

26
The list of extensions developed as a consequence of asking and
answering these questions should be “rationalized” [Co01b] using the
following criteria:
• an exception should be noted within the use case if the software can
detect the condition described and then handle the condition once it
has been detected.
• In some cases, an exception will precipitate the development of
another use case (to handle the condition noted).

27
Every modeling notation has limitations, and the use case is no exception.
Like any other form of written description, a use case is only as good as its
author(s). If the description is unclear, the use case can be misleading.
A use case focuses on functional and behavioral requirements and is
generally inappropriate for nonfunctional requirements.

28
Example
:

29
UML MODEL THAT SUPPLEMENT THE
USE CASE: Developing an Activity Diagram
The UML activity diagram supplements the use case by providing a
graphical representation of the flow of interaction within a specific scenario.
Similar to the flowchart, an activity diagram uses rounded rectangles to
imply a specific system function, arrows to represent flow through the
system, decision diamonds to depict a branching decision (each arrow
emanating from the diamond is labeled), and solid horizontal lines to
indicate that parallel activities are occurring.
A UML activity diagram represents the actions and decisions that occur as some function
is performed.
Key
Point:

30
USE CASE: Developing an Activity Diagram
Example
:

31
USE CASE: Swimlane Diagrams
The UML swimlane diagram is a useful variation of the activity diagram and
allows us to represent the flow of activities described by the use case and at
the same time indicate which actor (if there are multiple actors involved in a
specific use case) or analysis class has responsibility for the action
described
by an activity rectangle.
Responsibilities are represented as parallel segments that divide the
diagram vertically, like the lanes in a swimming pool.
A UML swimlane diagram represents the flow of actions and decisions and indicates
which actors perform each.
Key
Point:

32
USE CASE: Swimlane Diagrams
Example
:

33
REFRENCES
Software Engineering A Practioner’s Approach by Roger S Pressmen

THANK
YOU!
JOSHUA
Medium
https://medium.com/@joshuaudayagiri
Email
Joshua537.nit@gmail.com

Scenario based methods

More Related Content

What's hot (20)

Similar to Scenario based methods (20)

Recently uploaded (20)

Scenario based methods