Lecture 3 Software Requirements Analysis I.pdf

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 1
Lecture 3 Software Requirements Analysis I
 Software Requirements Engineering
“How to find out what the customer wants?”

2
What Are Software
Requirements?
 What the customers want?
 How end users will interact with the software?
 What the software should be processing?
 What is the technical environment of the
software system?
 How the software fits into the business
processes?

3
What We Are Doing
ABC Software!

4
Requirements Engineering
is The First Task
Problem
Models
Solution
Analysis
Design
Development
Testing

 Inception—ask a set of questions that establish …
 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary communication and collaboration
between the customer and the developer
 Elicitation—elicit requirements from all stakeholders
 Elaboration—create an analysis model that identifies data,
function and behavioral requirements
 Negotiation—agree on a deliverable system that is realistic for
developers and customers

 Specification—can be any one (or more) of the following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Validation—a review mechanism that looks for
 errors in content or interpretation
 areas where clarification may be required
 missing information
 inconsistencies (a major problem when large products or systems
are engineered)
 conflicting or unrealistic (unachievable) requirements.
 Requirements management

Inception
 Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful
solution
 Is there another source for the solution that you
need?

Eliciting Requirements
 meetings are conducted and attended by both software
engineers and customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual
forum) is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

Elicitation Work Products
 a statement of need and feasibility.
 a bounded statement of scope for the system or product.
 a list of customers, users, and other stakeholders who
participated in requirements elicitation
 a description of the system’s technical environment.
 a list of requirements (preferably organized by function)
and the domain constraints that apply to each.
 a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.
 any prototypes developed to better define requirements.

Quality Function Deployment
 Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
 Information deployment identifies data objects
and events
 Task deployment examines the behavior of the
system
 Value analysis determines the relative priority
of requirements

Non-Functional Requirements
 Non-Functional Requirment (NFR) – quality attribute,
performance attribute, security attribute, or general
system constraint. A two phase process is used to
determine which NFR’s are compatible:
 The first phase is to create a matrix using each NFR
as a column heading and the system SE guidelines a
row labels
 The second phase is for the team to prioritize each
NFR using a set of decision rules to decide which to
implement by classifying each NFR and guideline
pair as complementary, overlapping, conflicting, or
independent

Use-Cases
 A collection of user scenarios that describe the thread of usage of a
system
 Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way
 Each scenario answers the following questions:
 Who is the primary actor, the secondary actor (s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external
environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?

Use-Case Diagram
homeowner
Arms/ disarms
system
Accesses system
via Internet
R
econfigures sensors
and related
system features
R
esponds to
alarm event
Encounters an
error condition
system
administrator
sensors

Building the Analysis Model
 Elements of the analysis model
 Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an
“actor” and the system
 Class-based elements
• Implied by scenarios
 Behavioral elements
• State diagram
 Flow-oriented elements
• Data flow diagram

Eliciting Requirements
Use QFD to
prioritize
requirements
informally
prioritize
requirements
formalprioritization?
Create Use-cases
yes no
Elicit requirement s
write scenario
define actors
complete template
draw use-case
diagram
Conduct FAST
meetings
Make lists of
functions, classes
Make lists of
constraints, etc.

Class Diagram
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure
()
From the SafeHome system …

State Diagram
Reading
Commands
System status = “ready”
Display msg = “enter cmd”
Display status = steady
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State name
State variables
State activities

Analysis Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address the
problem.
Forces and context: A description of external issues (forces) that can affect how
the pattern is used and also the external issues that will be resolved when the
pattern is applied.
Solution: A description of how the pattern is applied to solve the problem with an
emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and what
trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use of
known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related to the named
pattern because (1) it is commonly used with the named pattern; (2) it is structurally
similar to the named pattern; (3) it is a variation of the named pattern.

Negotiating Requirements
 Identify the key stakeholders
 These are the people who will be involved in the
negotiation
 Determine each of the stakeholders “win
conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that lead to “win-
win”

Requirements Monitoring
Especially needes in incremental development
 Distributed debugging – uncovers errors and
determines their cause.
 Run-time verification – determines whether software
matches its specification.
 Run-time validation – assesses whether evolving
software meets user goals.
 Business activity monitoring – evaluates whether a
system satisfies business goals.
 Evolution and codesign – provides information to
stakeholders as the system evolves.

Validating Requirements - I
 Is each requirement consistent with the overall objective for the
system/product?
 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-
on feature that may not be essential to the objective of the
system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
 Do any requirements conflict with other requirements?

Validating Requirements - II
 Is each requirement achievable in the technical environment
that will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information,
function and behavior of the system to be built.
 Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system.
 Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly
validated? Are all patterns consistent with customer
requirements?

Requirements Analysis
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet
 Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier
requirement engineering tasks
 build models that depict user scenarios, functional
activities, problem classes and their relationships, system
and class behavior, and the flow of data as it is
transformed.

Elements of Requirements Analysis

Requirements Modeling
 Scenario-based
 system from the user’s point of view
 Data
 shows how data are transformed inside the system
 Class-oriented
 defines objects, attributes, and relationships
 Flow-oriented
 shows how data are transformed inside the system
 Behavioral
 show the impact of events on the system states

A Bridge
system
description
analysis
model
design
model

Rules of Thumb
 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 analysis 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 non-
functional models until design.
 Minimize coupling throughout the system.
 Be certain that the analysis model provides value to all
stakeholders.
 Keep the model as simple as it can be.

Domain Analysis
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 . . .
[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 . . .
Donald Firesmith

Domain Analysis
 Define the domain to be investigated.
 Collect a representative sample of applications
in the domain.
 Analyze each application in the sample.
 Develop an analysis model for the objects.

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?

What to Write About?
 Inception and elicitation—provide you with the
information you’ll need to begin writing use cases.
 Requirements gathering meetings, 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.
 To begin developing a set of use cases, list the functions
or activities performed by a specific actor.

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.

Use-Cases
 a scenario that describes a “thread of usage” for
a system
 actors represent roles people or devices play as
the system functions
 users can play a number of different roles for a
given scenario

Developing a Use-Case
 What are the main tasks or functions that are performed by
the actor?
 What system information will the the actor acquire,
produce or change?
 Will the actor have to inform the system about changes in
the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected
changes?

Reviewing a Use-Case
 Use-cases are written first in narrative form and mapped to
a template if formality is needed
 Each primary scenario should be reviewed and refined to
see if alternative interactions are possible
 Can the actor take some other action at this point?
 Is it possible that the actor will encounter an error condition at
some point? If so, what?
 Is it possible that the actor will encounter some other
behavior at some point? If so, what?

Use-Case Diagram
homeowner
Access camera
surveillance viathe
Internet
ConfigureSafeHome
system parameters
Set alarm
cameras
SafeHome

Exceptions
 Describe situations (failures or user choices) that cause
the system to exhibit unusual behavior
 Brainstorming should be used to derive a reasonably
complete set of exceptions for each use case
 Are there cases where a validation function occurs for the
use case?
 Are there cases where a supporting function (actor) fails to respond
appropriately?
 Can poor system performance result in unexpected or improper use
actions?
 Handling exceptions may require the creation of additional
use cases

Activity Diagram
enter password
and user ID
select major function
validpasswords/ID
prompt for reentry
invalidpasswords/ ID
input t ries remain
noinput
t ries remain
select surveillance
ot her f unct ions
may alsobe
selected
t humbnail views select aspecif ic camera
select camera icon
prompt for
another view
select specific
camera - thumbnails
exit t his f unct ion
seeanot her camera
view camera output
in labelled window
Supplements the
use case by
providing a
graphical
representation of
the flow of
interaction within a
specific scenario

Swimlane Diagrams
Allows the modeler 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
enter password
and user ID
select major function
valid passwords/ ID
prompt for reentry
invalid
passwords/ ID
input tries
remain
no input
t ries remain
select surveillance
ot her f unctions
may also be
select ed
t humbnail views select aspecif ic camera
select camera icon
generate video
output
select specific
camera - thumbnails
exit t his
f unct ion
see
anot her
camera
hom e owne r c a m e ra i nt e rf a c e
prompt for
another view
view camera output
in labelled window

Lecture 3 Software Requirements Analysis I.pdf

More Related Content

Similar to Lecture 3 Software Requirements Analysis I.pdf (20)

Recently uploaded (20)

Lecture 3 Software Requirements Analysis I.pdf