Requirement Engineering

Software Engineering 1
Topic - 6

1
Requirements Engineering
 Requirement: A function, constraint or
other property that the system must
provide to fill the needs of the system’s
intended user(s)
 Engineering: implies that systematic and
repeatable techniques should be used
 Requirement Engineering means that
requirements for a product are defined,
managed and tested systematically
Characteristics of a Good
Requirement
 Clear and Unambiguous
 standard structure
 has only one possible interpretation
 Not more than one requirement in one sentence
 Correct
 A requirement contributes to a real need
 Understandable
 A reader can easily understand the meaning of the
requirement
 Verifiable
 A requirement can be tested
 Complete
 Consistent
 Traceable
 Why is Getting Good Requirements
Hard?

 Stakeholders don’t know what they really want.

 Stakeholders express requirements in their own
terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may influence
the system requirements.
 The requirements change during the RE process.
New stakeholders may emerge and the business
environment change.
 Requirements Engineering-
Tasks
 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- Tasks
 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
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?

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
 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

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
Conduct FA ST
m eet ings

Make lis t s of
f unct ions, classes

Make list s of
const raint s, et c.

f orm al priorit izat ion?

El ic it req ui re m e nt s
yes no

Use QFD t o inf orm ally def ine act ors

priorit iz e 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. 9
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
• Sequence Diagrams
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Functional and non-functional
requirements
 Functional requirements
 Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
 May state what the system should not do.
 Non-functional requirements
 Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
 Often apply to the system as a whole rather than individual
features or services.
 Domain requirements
 Constraints on the system from the domain of operation
Chapter 4
Requirements
11
engineering
Functional requirements
 Describe functionality or system services.
 Depend on the type of software, expected
users and the type of system where the
software is used.
 Functional user requirements may be high-level
statements of what the system should do.
 Functional system requirements should
describe the system services in detail.

Chapter 4
Requirements
12
engineering
Functional requirements for
the MHC-PMS
 A user shall be able to search the
appointments lists for all clinics.
 The system shall generate each day, for each
clinic, a list of patients who are expected to
attend appointments that day.
 Each staff member using the system shall be
uniquely identified by his or her 8-digit
employee number.

Chapter 4
Requirements
13
engineering
Requirements imprecision
 Problems arise when requirements are not
precisely stated.
 Ambiguous requirements may be interpreted in
different ways by developers and users.
 Consider the term ‘search’ in requirement 1
 User intention – search for a patient name across all
appointments in all clinics;
 Developer interpretation – search for a patient name
in an individual clinic. User chooses clinic then
search.

Chapter 4
Requirements
14
engineering
Requirements completeness
and consistency
 In principle, requirements should be both
complete and consistent.
 Complete
 They should include descriptions of all facilities
required.
 Consistent
 There should be no conflicts or contradictions in the
descriptions of the system facilities.
 In practice, it is impossible to produce a
complete and consistent requirements
document.
Chapter 4
Requirements
15
engineering
Non-functional requirements
 These define system properties and constraints
e.g. reliability, response time and storage
requirements. Constraints are I/O device
capability, system representations, etc.
 Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
 Non-functional requirements may be more
critical than functional requirements. If these
are not met, the system may be useless.

Chapter 4
Requirements
16
engineering
Types of nonfunctional
requirement

Chapter 4
Requirements
17
engineering
Non-functional requirements
implementation
 Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
 For example, to ensure that performance requirements
are met, you may have to organize the system to
minimize communications between components.
 A single non-functional requirement, such as a
security requirement, may generate a number of
related functional requirements that define system
services that are required.
 It may also generate requirements that restrict existing
requirements.
Chapter 4
Requirements
18
engineering
Non-functional
classifications
 Product requirements
 Requirements which specify that the delivered product
must behave in a particular way e.g. execution speed,
reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
 Requirements which arise from factors which are external
to the system and its development process e.g.
interoperability requirements, legislative requirements, etc.

Chapter 4
Requirements
19
engineering
Examples of nonfunctional
requirements in the MHC-PMS
Product requirement
The MHC-PMS shall be available to all clinics during normal
working hours (Mon–Fri, 0830–17.30). Downtime within normal
working hours shall not exceed five seconds in any one day.

Organizational requirement
Users of the MHC-PMS system shall authenticate themselves
using their health authority identity card.

External requirement
The system shall implement patient privacy provisions as set out
in HStan-03-2006-priv.

Chapter 4
Requirements
20
engineering
 Metrics for specifying
nonfunctional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems Chapter 4
Requirements
21
engineering
Domain requirements
 The system’s operational domain imposes
requirements on the system.
 For example, a train control system has to take into
account the braking characteristics in different
weather conditions.
 Domain requirements be new functional
requirements, constraints on existing
requirements or define specific computations.
 If domain requirements are not satisfied, the
system may be unworkable.

Chapter 4
Requirements
22
engineering
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. 23
Use-Case Diagram
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. 24
Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure()

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 26
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 27
State Diagram
Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables

Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities

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

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

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

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?
 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?

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