Lecture 4

 Requirement And Specification Part 1

 What is software requirement and software
specification?
 Functional and Non Functional requirements
 Types of requirements – user, system, interface

1
Modeling Principles
 In software engineering work, two classes of
models can be created:
 Requirements models (also called analysis models)
represent the customer requirements by depicting the
software in three different domains: the information
domain, the functional domain, and the behavioral
domain.
 Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2
Requirements Modeling Principles
 Principle #1. The information domain of a problem
must be represented and understood.
 Principle #2. The functions that the software
performs must be defined.
 Principle #3. The behavior of the software (as a
consequence of external events) must be
represented.
 Principle #4. The models that depict information,
function, and behavior must be partitioned in a
manner that uncovers detail in a layered (or
hierarchical) fashion.
 Principle #5. The analysis task should move from
essential information toward implementation detail.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3
 …from essential --- to details description
Domain Function Behaviour
The information domain encompasses the Software functions provide direct benefit The behavior of computer software is
data that flow into the system, out of the to end users and also provide internal driven by its interaction with the external
system, and the data stores. support for those features that are user environment.
visible.
Example: Example: Example:
Into system - from end users, other Some functions transform
systems, or external devices), data that flow into the system. Input provided by end users, control data
provided by an external system, or
out of the system - via the user interface, Functions can be described at many monitoring data collected over a network
network interfaces, reports,Graphics different levels of abstraction, ranging all cause the software to behave in a
from a general statement of purpose to a specific way.
data stores - collect and organize detailed description of the processing
persistent data objects (i.e., data that are elements that must be invoked.
maintained permanently)

Student Enroll
University
Generate Assign
Enroll Terminate Graduated …. Input IC ….
SID Course
Student Staff Registrar …..

…from essential --- to details description

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
 Requirements Engineering-I
 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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
Requirements Engineering-II
 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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
 ANYONE who benefits in a
Inception direct or indirect way from the
system which is being
developed
 Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
Create a list
of people who  The first questions
will contribute  Who is behind the request for this work?
input as  Who will use the solution?
requirements
 What will be the economic benefit of a successful
are elicited
solution
 Is there another source for the solution that you
need?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
Eliciting Requirements
 The goal is :
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution 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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
Eliciting Requirements (…cont)
Attendees are required to reflect each person’s perception of
the system by doing this list :
 Objects
 Objects that are part of the environment that surrounds the system
 Objects that are to be produced by the system
 Objects that are used by the system to perform its functions.
 Services
 Any processes or functions that manipulate or interact with the
objects
 Constraints
 Any restriction (e.g., cost, size, business rules) and performance
criteria or quality (e.g., speed, accuracy)

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9
Eliciting Requirements :
Case Study

SafeHome Project

Our research indicates that the market for home management systems is
growing at a rate of 40 percent per year. The first SafeHome function we
bring to market should be the home security function. Most people are
familiar with “alarm systems” so this would be an easy sell.
The home security function would protect against and/or recognize a
variety of undesirable “situations” such as illegal entry, fire, flooding,
carbon monoxide levels, and others. It’ll use our wireless sensors to
detect each situation. It can be programmed by the homeowner, and will
automatically telephone a monitoring agency when a situation is
detected.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Eliciting Requirements
Steps:
1. List objects, services, constraints
2. Combined and produce consensus list
3. Create mini-specification for objects or services
4. Give priority to the requirements (Possible tool:
QFD)
5. Create usage scenarios (Possible tool: use
case)
6. Create report of eliciting requirements or work
product

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11
 Eliciting Requirements:
Example of SafeHome
1) List objects, services, constraints
Constraints
Objects Services & Criteria

Objects might include : Services might include: Constraints:

the control panel, smoke configuring the system, the system must recognize
detectors, window and setting the alarm, when sensors are not
door sensors, motion monitoring the sensors, operating,
detectors, an alarm, an dialing the phone, must be user-friendly, must
event (a sensor has been programming the control interface directly to a
activated), a display, a PC, panel, and reading the standard phone line
telephone numbers, a display (note that services
telephone call, and so on. act on objects). Performance criteria:

a sensor event should be

recognized within one
second, and an event priority
scheme should be
implemented.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
Eliciting Requirements:
Example of SafeHome
2) Create Combined List

Next, creates a combined list by eliminating redundant entries,

adding any new ideas that come up during the discussion, but not
deleting anything.

The combined list is then shortened, lengthened, or reworded to

properly reflect the product/system to be developed.

The objective is to develop a consensus list of objects, services,

constraints, and performance for the system to be built.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
 Eliciting Requirements:
Example of SafeHome
3) Create mini-specification

An object or service described on a list will require further

explanation. To accomplish this, stakeholders develop mini-
specifications for entries on the lists.
Each mini-specification is an elaboration of an object or service.
For example, the mini-spec for the SafeHome object Control
In some cases, Panel might be:
the development of
mini-specs will
uncover new
objects, services,
 The control panel is a wall-mounted unit that is approximately 9 5
constraints, or inches in size. The control panel has wireless connectivity to sensors
performance
requirements that
and a PC. User interaction occurs through a keypad containing 12
will be added to the keys. A 3 3 inch LCD color display provides user feedback.
original lists.
 Software provides interactive prompts, echo, and similar functions.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
Eliciting Requirements:
Example of SafeHome
4) Give priority

 The list of customer needs must be translated to technical

requirements.
 Technical requirements are the one that to be implemented in
the system.
 A technique to use is Quality Functional Deployment (QFD).
 QFD “concentrates on maximizing customer satisfaction from
the software engineering process” using these elements:
 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
 And these elements are used to prioritize the technical
requirements into three types of requirements:
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
 Eliciting Requirements:
Example of SafeHome
4) Give priority (…cont)
 Normal requirements.
The objectives and goals that are stated for a product or system during meetings
with the customer. If these requirements are present, the customer is satisfied.
Examples: requested types of graphical displays, specific system functions, and
defined levels of performance.
 Expected requirements.
These requirements are implicit to the product
or system and may be so fundamental that the customer does not explicitly state
them. Their absence will be a cause for significant dissatisfaction.
Examples: ease of human/machine interaction, overall operational correctness and
reliability, and ease of software installation.
 Exciting requirements.
These features go beyond the customer’s expectations
and prove to be very satisfying when present.
Example, software for a new mobile phone comes with standard features, but is
coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice
mail) that delight every user of the product.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
 Eliciting Requirements:
Example of SafeHome
5) Create usage scenario

Create scenarios:

As requirements are gathered, an overall vision of system

functions and features begins to materialize.
The scenarios, often
However, it is difficult to move into more technical software
called use cases, engineering activities until you understand how these functions
provide a description and features will be used by different classes of end users.
of how the system
will be used.

To accomplish this, developers and users can create a set of scenarios

that identify a thread of usage for the system to be constructed.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Eliciting Requirements:
Example of SafeHome
6) Create Work Product

The work products produced as a consequence of requirements

elicitation.
For most systems, the work products include:
 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Eliciting Requirements : Summary
Conduct FA ST
m eet ings

Make list s of
f unct ions, classes

Make list s of
const raint s, et c.

f orm al priorit izat ion?

Eli c i t req ui rem e nt s
yes no

Use QFD t o inf orm ally def ine act ors

priorit ize priorit ize
requirem ent s requirem ent s

draw use-case
writ e scenario
diagram

Creat e Use-cases
com plet e t em plat e

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
 Building the Analysis Model
The intent of
analysis model is to
 Elements of the analysis model
provide a
description of the
 Scenario-based elements
required • Functional—processing narratives for software functions
informational,
functional, and • Use-case—descriptions of the interaction between an
behavioral domains
for a computer-
“actor” and the system
based system. It
has dynamic
 Class-based elements
perspectives. • Implied by scenarios
 Behavioral elements
For that reason,
the analysis model • State diagram
is a snapshot of
requirements at
 Flow-oriented elements
any given time.
You should expect
• Data flow diagram
it to change.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20
Scenario-base elements: 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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 21
Scenario-base elements: Use-Cases
Arms/ disarms
syst em

Accesses syst em sensors

via Int ernet

homeow ner

Responds t o
alarm event

Encount ers an
error condit ion

syst em Reconf igures sensors

administ rat or and relat ed
syst em f eat ures

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 22
 Use-Cases: Example
In SafeHome requirements, we define four actors: homeowner (a user), setup
manager (likely the same person as homeowner, but playing a different role),
sensors (devices attached to the system), and the monitoring and response
subsystem (the central station that monitors the SafeHome home security
function).

Considering the homeowner actor. The homeowner actor interacts with the home
security function in a number of different ways using either the alarm control panel
or a PC:
 Enters a password to allow all other interactions.
 Inquires about the status of a security zone.
 Inquires about the status of a sensor.
 Presses the panic button in an emergency.
 Activates/deactivates the security system.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23
 Use-Cases: Example

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 24
 Use-Cases: Example
Therefore, basic use case for homeowner actor :
UC1.The homeowner observes the SafeHome control panel (in Figure 5.1), to determine if the
system is ready for input. If the system is not ready, a not ready message is displayed on the
LCD display, and the homeowner must physically close windows or doors so that the not ready
message disappears. [A not ready message implies that a sensor is open; i.e., that a door or
window is open.]

UC2. 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 is incorrect, the control
panel will beep once and reset itself for additional input. If the password is correct, the control
panel awaits further action.

UC3. The homeowner selects and keys in stay or away to activate the system.
Stay activates only perimeter sensors (inside motion detecting sensors are deactivated).
Away activates all sensors.

UC4. When activation occurs, a red alarm light can be observed by the homeowner.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25
 Use-Cases: Example
Next, use a basic template for detailed descriptions of use cases:

Use case: InitiateMonitoring Use case ID : UC1

Primary actor: Homeowner.
Goal in context: To set the system to monitor sensors when the homeowner
leaves the house or remains inside.
Preconditions: System has been programmed for a password and to recognize
various sensors.
Trigger: The homeowner decides to “set” the system, i.e., to turn on the
alarm functions.

Scenario:
1. Homeowner: observes control panel
2. Homeowner: enters password
3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that SafeHome has been armed

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 26
 Use-Cases: Example
(..cont.)
Exceptions:
1. Control panel is not ready: homeowner checks all sensors to determine which are
open; closes them.
2. Password is incorrect (control panel beeps once): homeowner reenters correct password.
3. Password not recognized: monitoring and response subsystem must be contacted to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated.
5. Away is selected: control panel beeps three times and an away light is lit; all sensors
are activated.

Priority: Essential, must be implemented

Next, draw the use case using correct notation

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 27
Class-based Elements: Class Diagram

Each usage scenario implies a set of objects that are manipulated as

an actor interacts with the system.

These objects are categorized into classes—a collection of things that

have similar attributes and common behaviors.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 28
 Class Diagram : Example

From the SafeHome system …

Attributes
Sensor
of class
nam e/id
type
location
area
characteristics

identify()
enable()
disable() Operation
reconfigure () that can
change the
attributes

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 29
Behavioral-based Elements: State Diagram
 State diagram is one of modeling elements that
depict behavior.
 The behavior of a computer-based system can
have a profound effect on the design that is
chosen and the implementation approach that is
applied.
A state is any A state diagram indicates
externally observable actions - a consequence of
mode of behavior a particular event.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 30
 State Diagram : Example
Condition Reading
Commands
State name
[ power on ] System status = “ready”
Display msg = “enter cmd”
Display status = steady
State attributes/variables
Transition
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities

[ condition ]

[ next state ]

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 31
 Flow oriented elements: DFD
 Information is transformed as it flows through a computer-based system.
 The system accepts input in a variety of forms, applies functions to
transform it, and produces output in a variety of forms.
 Example of input:
 a control signal transmitted by a transducer,
 a series of numbers typed by a human operator,
 a packet of information transmitted on a network link, or
 a voluminous data file retrieved from secondary storage.
 Example of transformation function:
 a single logical comparison,
 a complex numerical algorithm
 Example of output:
 a light by LED
 a summary report

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 32
 • Certain problems reoccur
across all projects
• These analysis patterns
suggest solutions within the
application domain that can be

Analysis Patterns
reused

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.
• Information Solution: A description of how the pattern is applied to solve the problem with an
about an
emphasis on structural and behavioral issues.
analysis pattern
is presented in Consequences: Addresses what happens when the pattern is applied and what
a standard trade-offs exist during its application.
template Design: Discusses how the analysis pattern can be achieved through the use of
• The templates
known design patterns.
are stored in
repository for Known uses: Examples of uses within actual systems.
other Related patterns: On e or more analysis patterns that are related to the named
programmers to
pattern because (1) it is commonly used with the named pattern; (2) it is structurally
search and use
similar to the named pattern; (3) it is a variation of the named pattern.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 33
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”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 34
 Validating Requirements - I
 Is each requirement consistent with the overall objective for the
system/product?
During review,
always check for:
 Have all requirements been specified at the proper level of
 Inconsistency abstraction? That is, do some requirements provide a level of
 Omissions technical detail that is inappropriate at this stage?
 Ambiguity  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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 35
 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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 36
 Self-review Q
1) Why do we say that the requirements model represents a
snapshot of a system in time?

2) What do use case “exceptions” represent?

3) What do you think happens when requirement validation

uncovers an error? Who is involved in correcting the error?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 37