Chapter 8

Analysis Engineering
Software Engineering: A Practitioner’s Approach
Elements of Requirements Analysis

These slides are designed to accompany

Software Engineering: A Practitioner’s
2
Approach, 7/e (McGraw-Hill, 2009). Slides
Scenario-Based Modeling
“[Use-cases] are simply an aid to defining what exists outside
the system (actors) and what should be performed by the
system (use-cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?

These slides are designed to accompany

Software Engineering: A Practitioner’s
3
Approach, 7/e (McGraw-Hill, 2009). Slides
•
What to Write About?
Elicitation—provide you with the information you’ll need to begin
writing use cases.
• Requirements gathering meetings 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.
• To begin developing a set of use cases, list the functions or activities
performed by a specific actor.

These slides are designed to accompany

Software Engineering: A Practitioner’s
4
Approach, 7/e (McGraw-Hill, 2009). Slides
 How Much to Write About?
• As further conversations with the
stakeholders progress, the requirements
gathering team develops use cases for
each of the functions noted.
• In general, use cases are written first in an
informal narrative fashion.
• If more formality is required, the same use
case is rewritten using a structured format
similar to the one proposed.
These slides are designed to accompany
Software Engineering: A Practitioner’s
5
Approach, 7/e (McGraw-Hill, 2009). Slides
 Use cases
• Use Cases
– Scenario that describes a thread of usage
– Actors: represent roles people or devices as
system function
– Users: can play different roles in a scenario
SafeHome home surveillance
SafeHome home surveillance
 SafeHome home surveillance
• Functions performed by homeowner
– Select camera to view
– Request thumbnails for all cameras
– Display camera view in PC window
– Control pan and zoom for specific camera
– Selectively record camera output
– Replay camera output
– Access camera surveillance via the internet
 SafeHome home surveillance
• Further conversation with stakeholders RE
team develops use cases for each function
• Formal method
– Structured format
• Example access camera surveillance via the
internet display camera views ACS-DCV
 ACS-DCV Scenario
• If I’m at a remote location, I can use any PC with appropriate
browser software to log on to the SafeHome Products website. I
enter my user ID and two levels of passwords and once I’m
validated, I have access to all functionality for my installed
SafeHome system. To access a specific camera view, I select
“surveillance” from the major function buttons displayed. I then
select “pick a camera” and the floor plan of the house is
displayed. I then select the camera that I’m interested in.
Alternatively, I can look at thumbnail snapshots from all cameras
simultaneously by selecting “all cameras” as my viewing choice.
Once I choose a camera, I select “view” and a one-frame-per-
second view appears in a viewing window that is identified by the
camera ID. If I want to switch cameras, I select “pick a camera”
and the original viewing window disappears and the floor plan of
the house is displayed again. I then select the camera that I’m
interested in. A new viewing window appears
 ACS-DCV Scenario
• Narrative use case
• Interaction as an ordered sequence of user
actions
• Each action as declarative sentence
 Use case: Access camera surveillance
via the Internet—display camera views
Actor: homeowner
(ACS-DCV)
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.
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.
 Refining a Preliminary Use Case
• Description of alternative interactions
• Each step in the primary scenario is evaluated by
asking questions
– Can the actor take some other action at this point ?
– Is it possible that actor will encounter some error
condition at this point? If so, what it might 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?
 Refining a Preliminary Use Case
• Consider steps 6 and 7
– 6. The homeowner selects “pick a camera.”
– 7. The system displays the floor plan of the house.
• Can the actor take some other action at this
point ?
– YES
– Actor may chose view thumbnail of all cameras
– Secondary scenario “View thumbnail snap shots
for all cameras”
 Refining a Preliminary Use Case
• Consider steps 6 and 7
– 6. The homeowner selects “pick a camera.”
– 7. The system displays the floor plan of the house.
• Is it possible that the actor will encounter
some error condition at this point?
– YES
– Floor pan not configured
– This error condition becomes second scenario
 Refining a Preliminary Use Case
• Consider steps 6 and 7
– 6. The homeowner selects “pick a camera.”
– 7. The system displays the floor plan of the house.
• Is it possible that the actor will encounter
some other behavior at this point ?
– YES
– System may encounter alarm condition
– Alarm condition encountered
 Formal use-Case
• The goal in context identifies the overall scope of the
use case. The
• The Precondition describes what is known to be true
before the use case is initiated.
• The Trigger identifies the event or condition that “gets
the use case started”
• The Scenario lists the specific actions that are required
by the actor and the appropriate
• system responses.
• The Exceptions identify the situations uncovered as
the preliminary use case is refined
 USE CASE: ACS - DCV
• Page 160
 Use-case Diagram

Use-case diagram for surveillance function

 Activity diagram
• Activity diagram supplements the use case by
providing a graphical representation of the flow
of interaction within a specific scenario.
• 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.
Activity diagram for
Access camera
surveillance—display
camera views function
 Swim-lane diagrams
• The UML swimlane diagram is a useful variation of the
activity diagram.
• Allows to represent the flow of activities described by
the use case.
• It also indicates 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.
Swimlane
diagram
Flow-Oriented Modeling
 Guidelines

• Depict the system as single bubble in level 0.

• Carefully note primary input and output.
• Refine by isolating candidate processes and their
associated data objects and data stores.
• Label all elements with meaningful names.
• Maintain information conformity between levels.
• Refine one bubble at a time.
 Data Flow Diagram

Context-level DFD for SafeHome security function

 DFD Naming Guidelines

• External Entity  Noun

• Data Flow  Names of data
• Process  verb phrase
– a system name
– a subsystem name
• Data Store  Noun
Analysis classes: Grammatical Parse
Level 2 DFD that refines the monitor sensors process
 Control Flow Diagram

State diagram for SafeHome security function

Class-Based Modeling
 Identifying Analysis Classes
• External entities that produce or consume
information
• Things that are part of the information domain
• Occurrences or events
• Roles played by people who interact with the system
• Organizational units
• Places that establish context
• Structures that define a class of objects
Class Selection Criteria

1. Retained information
2. Needed services
3. Multiple attributes
4. Common attributes
5. Common operations
6. Essential requirements
 Identifying Classes
Potential class Classification Accept / Reject
homeowner role; external entity reject: 1, 2 fail
sensor external entity accept
control panel external entity accept
installation occurrence reject
(security) system thing accept
number, type not objects, attributes reject: 3 fails
master password thing reject: 3 fails
telephone number thing reject: 3 fails
sensor event occurrence accept
audible alarm external entity accept: 1 fails
monitoring service organizational unit; ee reject: 1, 2 fail
 Class Diagram

Class diagram for the system class

 Class Diagram

Class diagram for FloorPlan

 Class Responsibilities

• Distribute system intelligence across classes.

• State each responsibility as generally as possible.
• Put information and the behavior related to it in the
same class.
• Localize information about one thing rather than
distributing it across multiple classes.
• Share responsibilities among related classes, when
appropriate.
 Class Collaborations

• Relationships between classes:

– is-part-of — used when classes are part of an
aggregate class.
– has-knowledge-of — used when one class must
acquire information from another class.
– depends-on — used in all other cases.
Class Diagrams

Top: Multiplicity
Bottom: Dependencies
Behavioral Modeling
 Identifying Events

• A use-case is examined for points of

information exchange.
• The homeowner uses the keypad to key in a
four-digit password. The password is
compared with the valid password stored in the
system. If the password in incorrect, the
control panel will beep once and reset itself for
additional input. If the password is correct, the
control panel awaits further action.
 State Diagram

State diagram for the ControlPanel class

 Sequence Diagram

Sequence diagram (partial) for the SafeHome security function