Requirement Engineering

Software Engineering – Requirements Engineering

“The hardest single part of building a software system

is deciding what to build.
No part of the work so cripples the resulting system if
done wrong.
No other part is more difficult to rectify later.” Fred
Brooks

2
 What Are the Real Problems?
the customer has only a vague idea of what is
required

the developer is willing to proceed with the

"vague idea" on the assumption that "we'll fill in
the details as we go"

the customer keeps changing requirements

the developer is "dragged" by these changes,

making errors in specifications and development

and so it goes ...

 Software Requirements
 knowledge area is concerned with the acquisition,
analysis, specification, validation and management of
software requirements.
 Its importance has led to the widespread use of the term
‘requirement engineering’ to denote the systematic
handling of requirement.
 Express the needs and constraints that are placed upon a
software product that contribute to the satisfaction of
some real world application [Kot00]
 Except where the problem is motivated by technology, it is
an artifact of the problem domain and is generally
technology-neutral.
 Software Requirements (2)
 One of the main objectives of RE is to discover how to partition the system; to
identify which requirements should be allocated to which components.
 In some systems, all the components will be implemented in software. Others will
comprise a mixture of technologies. Because of these,
 RE is fundamentally an activity of systems engineering. In this respect, the
term ‘software requirements engineering’ is misleading because it implies a
narrow scope.
 Req. engineer is required to possess technical skills, an understanding of the
application domain, and the inter-personal skills to help build consensus between
heterogeneous groups of stakeholders [Gog93].

System Engg. RE PABX

H/W Engg. SE Other Engg. S/W Modules H/W Modules

HRE SRE ??
 Requirements Engineering-Origin
Where does requirements engineering begin? Could be
many places, however we will use the following
definition:
The start of requirements engineering begins with it’s
stakeholders:
 managers
 customers
 end-users

This is where:
 business needs are defined
 user scenarios defined
 features delineated
 project constraints are defined
6
 Software Requirements Engg

Requirements Reqs Reqs Reqs Requireme Requireme

Engineering Elicitation Analysis Specification nts nts
Process Validation Managemen
t
Req Req.
Process Requireme Classificatio Definition Conduct of Change
Models nt Sources n Document Requireme Management
nts Reviews
Reqs
SW Reqs
Process Attributes
Conceptual Specificatio
Actors
Elicitation Modeling n (SRS)
Techniques Prototyping
Process Architectural Reqs
Structure Tracing
Support Design and Model
and
and Requirement Validation
Standards
Manageme s Allocation
nt
Acceptance
Document Tests
Process Req Quality
Quality and Negotiation
Improvement
 Informal Statement
Decision •User Needs of Requirements
Point: •Domain
Accept Information
Document or •Standard
Reenter Requirements
Spiral Requirements Analysis and
Elicitation Negotiation
Requirements
Document Start Agreed
and Requirements
Validation
Report Requirements
Requirements
Validation
Specification

Draft Requirements
Document
A spiral model of the requirements engineering process
 Requirements Elicitation
 Also termed as ‘requirements capture’, ‘requirements discovery’ or
‘requirements acquisition’.
 Concerned with where requirements come from and how they can be collected by
the requirements engineer.
Requirements Sources
 Goals: The term ‘Goal’ (sometimes called ‘business concern’ or ‘critical
success factor’) refers to the overall, high-level objectives of the system.
 Domain Knowledge: The requirements engineer needs knowledge about
the application domain. Sometimes to act as a ‘user’ champion.
 System Stakeholders:
 The Operational Environment: derived from the environment in which
the software will execute, e.g. timing constraints in a real-time system or
interoperability constraints in an office environment.
 The Organizational Environment: Many systems are required to support
a business process (may be conditioned by the structure, culture and
internal politics of the organization).
 Elicitation Techniques
 Interviews.
 Scenarios. Use cases.
 Prototypes.
 Facilitated Meetings. Brainstorm and refine ideas
that may be difficult to surface using (e.g.) interviews.
 Observation. Requirements engineer learns about
user’s tasks by immersing themselves in the
environment and observation how users interact
with their systems and each other.
10 Small Steps to Better Requirements

Ian Alexander, "10 Small Steps to Better

Requirements," IEEE Software, vol. 23, no.
2, pp. 19-21, Mar./Apr. 2006,
doi:10.1109/MS.2006.34
www. c o m p u t e r. o r g / s o f t w a r e
 Use-Cases
 A collection of 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:

 What are the main tasks or functions performed by the actor?

 What system information will the actor acquire, produce or
change?
 Will the actor inform the system about environmental
changes?
 What information does the actor require of the system?
 Does the actor wish to be informed about unexpected
changes
 Software Requirements Engg

Requirements Requireme Requireme Requireme Requireme Requireme

Engineering
Process
nts
Elicitation

nts Analysis

Requireme
nts
Specificatio
n
nts
Validation
nts
Managemen
t

Χ Process
Models Χ Requireme
nt Sources
nt
Classificatio
n
Requireme
nt
Definition
Document
Conduct of
Requireme
nts Reviews
Change
Management

Requireme
Process nts
Conceptual

Χ
Actors Attributes
Elicitation Modeling Software
Techniques Requirements Prototyping
Process Architectura Specification Requireme
Support l Design and (SRS) Model nts Tracing
and Requiremen Validation
Manageme ts Allocation Structure
nt and Acceptance
Standards Tests
Process Quality Requireme
and nt Document
Improvemen Negotiation Quality
t
Requirements Analysis
(1) Requirements Classification
 Functional or nonfunctional.
 Derived from one or more high-level requirements.
 Requirement is on the product.
 Requirement priority: Often classified on a fixed point
scale such as mandatory, highly desirable, desirable,
optional.
 Scope of the requirement: Some requirements (
particularly non-functional ones) have a global scope in
that their satisfaction cannot be allocated to a discrete
component.
Components of SW Requirements
Business
Requirement

Vision and Scope Document

User Quality
Requirement Attributes
Other
Use Case Document Non Functional
Requirement
System Functional
Requirement Requirement Constraints*

SW Requirement Spec (SRS)

(2) Conceptual Modeling
 Conceptual models comprise models of entities
from the problem domain configured to reflect
their real-world relationships and dependencies.
These include:
 data and control flows,
 state models,
 event traces,
 user interactions,
 object models and many others.
 The issue of modeling is tightly coupled with that
of methods. Methods and notations come and go in
fashion.
(3) Architectural Design and Requirements Allocation
In many cases, the requirements engineer
acts as system architect because the process of
analyzing and elaborating the requirements
demands that the subsystems and components
that will be responsible for satisfying the
requirements be identified.
This is requirements allocation – the assignment of
responsibility (for satisfying requirements) to
subsystems.
Structured Design Example:
Level 0 <Context> DFD
processing
user request requested
digital video
video signal
monitor
processor
video
source NTSC
video signal
The Data Flow Hierarchy

a b
x P y level 0

a c p2
p1
f

d p4 p5 b
p3 e g
level 1
 Hierarchy of DFDs
Shipment
Orders Advice
Sales
Customers Manag Warehouse
System Orders
Invoices
1.1
Context Diagram Check Credit
(Level 0) Limit
1 Verified Overlimit
Orders Verify Rejected Orders Orders
Order Orders 1.2
Revise/Auth
Verified Orders oris Order
2 Rejected
Accept Orders
Invoices Shipment Advice
Order Verify Order DFD
Sales Management DFD (Level 1) (Level 2 )
DFDs: A Look Ahead

analysis model

Maps onto
design model
Process/SW Specification (PSPEC)
bubble

PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
A Design Note

PSPEC one or more ”components"

in the software design
Creating Mini-Specs (SRS)

Software
Specification
(4) Requirements Negotiation
 Also known as ‘conflict resolution’. Where
conflicts occur; between two stakeholders’
requiring mutually incompatible features, or
between requirements and resources or
between capabilities and constraints.
 consult with the stakeholders to reach a
consensus on an appropriate trade-off. It is
often important for contractual reasons that
such decisions are traceable back to the
customer.
 Software Requirements Engg

Requirements
Engineering
Process
Requireme
nts
Elicitation
Requireme
nts Analysis

Requireme
nts
Specificatio
n
Requireme
nts
Validation
Requireme
nts
Managemen
t
Requireme

Χ Process
Models Χ Requireme
nt Sources Χ nt
Classificatio
n
Requireme
nt
Definition
Document
Conduct of
Requireme
nts Reviews
Change
Management

Requireme

Χ
Process nts
Conceptual

Χ
Actors Attributes
Elicitation Modeling Software
Techniques Requirements Prototyping
Process Architectura Specification Requireme

Χ
Support l Design and (SRS) Model nts Tracing
and Requiremen Validation
Manageme ts Allocation Structure
nt and Acceptance
Standards Tests

Χ
Process Quality Requireme
and nt Document
Improvemen Negotiation Quality
t
 Requirements specification
(1) The System Requirements Definition Document
A statement in a natural language of what user services the system is
expected to provide.
 sometimes known as the user requirements document (or concept
of operations) records the system requirements.
 defines the high-level system requirements from the domain
perspective.
 Must list the system requirements along with background information
about overall objectives for the system, its target environment and a
statement of the constraints, assumptions and non-functional
requirements.
 May include conceptual models designed to illustrate the system
context, usage scenarios, the principal domain entities, and data,
information and work-flows.
(2) Requirements specification (intermediate level)
A structured document which sets out the system
services in more detail.
It should be written such that understandable by
technical staff from both clients and developers.

Samples/Template
Preamble
Sample FUNCTIONAL
Table of Contents
Requirement Shell REQUIREMENTS: PROJECT ISSUES:
Requirement Numbering 7. The Scope of the Work 18. Open Issues
Definitions Used in this 8. The Scope of the 19. Off-the-shelf
Template Product Solutions
PROJECT DRIVERS: 9. Functional and Data 20. New Problems
1. The Purpose of the Requirements 21. Tasks
Product NON-FUNCTIONAL 22. Cutover
2. Client, Customer, REQUIREMENTS: 23. Risks
Stakeholders 10. Look and Feel 24. Costs
3. Users of the Product 11. Usability 25. User Documentation
PROJECT 12. Performance 26 Ideas for Solutions
CONSTRAINTS: 13. Operational
4. Mandated Constraints 14. Maintainability
5. Naming Conventions 15. Portability
and Definitions 16. Security
6. Relevant Facts and 17. Cultural and Political
Assumptions 18. Legal
A Common Approach
3.A. Functional Requirements
(RS)
3.A.i. Student Services
R-001 Students can add, drop, and change course.
R-002 Students can check which sections of a certain course are available.
R-003 Students can check the tuition fee.
3.A.ii. Teacher Services
R-009 The professors can set the limit of number of students in his or her class.
R-010 Any user can view any courses offered in the year.
R-011 The professors can let a student register a course but no overloading.
3.A.iii. System-Related Requirements
R-013 The system shall provide access through the web.
R-014 The system shall work with internet protocol.
3.B. Performance Requirements
R-020 The system shall allow 1000 users to connect simultaneously.
R-021 The system shall response the request in 15 seconds.
R-022 The system shall log out the user after 20 minutes of connection.
Non Functional Requirements (4)
Property Metric
Speed Process transaction/second,
must be testable, so user/event response time
should be expressed
quantitatively, using an Size Kilobytes, code, RAM chip
accepted metric or
especially design-one. Ease of Use Training time, of held frames

Reliability Mean time to failure, probability

of unavailability, Role of failure
occurrence, Availability.

Robustness Time to restart after failure,

%age of events causing failure,
Probability of data corruption on
failure
Portability %age of target dependent
statements, No. of target
systems
Requirement Shell/template
As a guide for writing each requirement.
 Example

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 34

 (3) Software Requirements Specification (SRS)
 Also called (Design Specification)
 An abstract description of the S/W, which is basis for its design and
implementation. There should be a clear and direct relationship between
this document and the requirement specification, but the reader of this
are S/W designers.
 Such a specification is included mostly as part of system contract and is the
basis for designing system acceptance tests.
 Inputs, Process, Output, pre-conditions, post-conditions are the minimum
required.
 SRS (2)
Structured Language Specification
 Natural Language is required because of understandability.

 Many notations have been developed which rely on natural language

in a controlled way using standard form and also use graphical
highlighting.

 The form structure will vary depending on the requirement

structuring technique (functional, data, object e.t.c).
 Functional oriented Specifications are most common.
 Form based approach fits well with formal mathematical
specification. A formal specification can be defined and paraphrased
in a set of forms or a formal specification can be defined from the
structured forms and used to refine the requirement specification.

 Other approaches (e.g. formal mathematical) tackle some problems of

specifications ambiguity but at the cost of perhaps, readability.
 SRS (3)
 ATM example of structured requirement specification (functional approach)
Function: Check-Card-Validity
Description: Must ensure the card input by the user, is in date, contains account information e.t.c.
Inputs: Bank-identifiers, account No. , Expiry date
Source: Input read from card magnetic strip
Output: Card-Status (OK, invalid)
Destination: AutoTeller (Status passed to other parts of S/W)
Requires: Bank list, account format, today’ date.
Pre-condition: Card has been input and strip data read.
Post-Condition: Bank-identifier is in bank list and account number matches Account format,
expiry-date, today-date and card-status = OK
Side effects: None

Exercise: Design a format for object oriented specification technique

A form based approach could obviously be automated.
 Pre and post conditions are used to specify the actions of the function.
 It is not an operational specification of what the function must do.
 The names used (in the form) must be defined elsewhere or if possible in data
dictionary.
Document Structure and Standards
Several recommended guides and standards
exist to help define the structure of
requirements documentation. These include
IEEE P1233/D3 guide, IEEE Std. 1233 guide,
IEEE Std. 830-1998, ISO/IEC 12119-1994.
IEEE Std 1362-1998 concept of operations
(ConOPs).
 Software Requirements Engg


Requirements Requireme Requireme Requireme Requireme Requireme
Engineering nts nts Analysis nts nts nts
Process Elicitation Specificatio Validation Managemen
n t
Requireme

Χ Process
Models Χ Requireme
nt Sources Χ nt
Classificatio
n Χ
Requireme
nt
Definition
Document
Conduct of
Requireme
nts Reviews
Change
Management

Requireme

Χ
Process nts
Conceptual

Χ
Actors Attributes
Elicitation Modeling Software

Process
Techniques
Architectura Χ
Requirements
Specification
Prototyping
Requireme

Χ
Support l Design and (SRS) Model nts Tracing
and Requiremen Validation

Χ
Manageme ts Allocation Structure
nt and Acceptance
Standards Tests

Χ
Process Quality Requireme

Χ
and nt Document
Improvemen Negotiation Quality
t
 Requirements Validation
 One or more formally scheduled points in the
requirements engineering process where the
requirements are validated.
 Concerned with the process of examining the
requirements document to ensure that it
defines the right system (i.e., the system that
the user expects).
 Requirements Validation (2)
(1) The Conduct of Requirements Reviews
Common means of validation is by inspection or formal reviews of
the requirements document (s).
(2) Prototyping
validating the req. engineer’s interpretation of the system
requirements, as well as for eliciting new requirements.
(3) Model Validation
Quality of the models developed during analysis should be validated.
(4) Acceptance Test
 Essential property of a requirement is that it should be possible to
validate that the finished product satisfies the requirement.
 Identifying and designing acceptance test may be difficult for
non-functional requirements. To be validated, they must first be
analysed to the point where they can be expressed quantitatively.
Requirements Validation (3)
There are seven criteria in the validation process:
1. Correctness
2. Consistency - no conflicting/ambiguous requirements
3. Completeness - describes all possible situations
4. Realistic - Requirements of the user environment and
practical
5. Needed - does each requirement describe something
needed by the customer
6. Verifiable - can tests be written to demonstrate meeting
the requirement
7. Traceable - trace requirement to system function
 Requirements Management
An activity that spans the whole software life cycle. Fundamentally about
change management and the maintenance of the requirements.
(1) Change Management
Procedures that need to be in place and the analysis that should be
applied to proposed changes. Strong links to the configuration
management.
(2) Requirements Tracing
 Tracing is fundamental to performing impact analysis when requirements change.
 A requirement should be traceable backwards to the requirements and
stakeholders that motivated it.
 Conversely, a requirement should be traceable forwards into SRS and design
entities that satisfy it (And into the code module that implement it).
 Requirements trace for a typical project will form a complex directed acyclic
graph (DAG) of requirements. Modern requirements management tools have
improved this situation and the importance of tracing (and requirements
management in general) is starting to make an impact in software quality.
 Software Requirements Engg

Requirements Requireme Requireme Requireme Requireme Requireme

Engineering nts nts Analysis nts nts nts
Process Elicitation Specificatio Validation Managemen
n t
Requireme

Χ Process
Models Χ Requireme
nt Sources Χ nt
Classificatio
n Χ
Requireme
nt
Definition Χ
Conduct of
Requireme
nts Reviews
Χ Change
Management

Requireme
Document

Χ
Process nts
Conceptual

Χ
Actors Attributes

Process
Elicitation
Techniques
Modeling

Architectura Χ
Software
Requirements
Specification Χ
Prototyping

Χ
Requireme

Χ Χ
Support l Design and (SRS) Model nts Tracing
and Requiremen Validation

Χ
Manageme ts Allocation Structure
nt and
Standards
ΧAcceptance
Tests

Χ
Process Quality Requireme

Χ
and nt Document
Improvemen Negotiation Quality
t
Requirement Engineering Roadmap
 Three radical ideas
 Modeling and analysis cannot be performed
adequately in isolation from the organizational
and social context in which the new system will
have to operate
 RE should not focus on specifying the
functionality of a new system, but instead
should concentrate on modeling indicative and
operative properties of the environment
 Attempt to build consistent and complete
requirement models is futile.
What's the Future ?
 New techniques for formally modeling and analyzing
properties of the environment
 Richer model for capturing and analyzing non-
functional requirements
 Bridging the gap between requirements elicitation
approaches.
 Better understanding of software architectural
choices
 Reuse of requirement models
 Multidisciplinary training of requirements practitioners