Software Requirement Engineering

SE–3731w
IT-2102
SE-2102

Resource Person
Sehrish Munawar
Reference Books
• Software Requirements, Wiegers K. &Beatty J.,
3rd Ed. Microsoft Press, 2013
• Requirements Engineering, Elizabeth Hull, Ken
Jackson and Jeremy Dick. 3rd Ed, Springer-
Verlag London Limited, 2011.
• Requirements Engineering and Management
for Software Development Projects,
Chemuturi M., Springer New York, 2013.
Introduction
• Requirements form the basis for all
software products

• Requirements engineering is the process,

which enables us to systematically
determine the requirements for a software
product
What is requirement?
• Something required, something wanted or needed
– Webster’s dictionary
• Requirements are…a specification of what should
be implemented. They are descriptions of how the
system should behave, or of a system property or
attribute. They may be a constraint on the
development process of the system.
– Sommerville and Sawyer 1997
• There is a huge difference between wanted and
needed and it should be kept in mind all the time
Software Requirements - 1
• A complete description of what the software
system will do without describing how it will
do it is represented by the software
requirements

5
Software Requirements - 2
• Software requirements are complete
specification of the desired external behavior
of the software system to be built

• They also represent External behavior of the

system

6
Software Requirements - 3
• Software requirements may be:
– Abstract statements of services and/or constraints
– Detailed mathematical functions

7
Software Requirements - 4
• Software requirements may be:
– Part of the bid of contract
– The contract itself
– Part of the technical document, which describes a
product

8
IEEE Definition
• A condition or capability that must be met or
possessed by a system...to satisfy a contract,
standard, specification, or other formally
imposed document
– IEEE Std 729

9
The Requirement Engineering Process
• The process of establishing what services are required and the
constraints on the system’s operation and development
• Requirements engineering help software engineers to better
understand the problem they will work to solve. It encompasses the
set of tasks that lead to an understanding of what the business
impact of the software will be, what the customer wants and how
end-users will interact with the software.

• Requirement Engineering Process

– Feasibility Study
– Requirements elicitation and analysis
– Requirements Specification
– Requirements Validation
The Requirements Engineering Process

Feasibility Require ments

study elicitation and
analy sis
Require ments
specification
Feasibility Require ments
report validation

System
models
User and system
requirements

Require ments
document
Sources of Requirements
• Stakeholders
– People affected in some way by the system
• Documents
• Organization standards
• Existing systems
• Domain/business area
• Regulations etc.
Levels of Requirements
• Stakeholders describe requirements at different levels of
details
• Business Requirements
– Why the software product is being developed
– Vision and Scope document
– Project Chartered
• User Requirements
– Look at the functionality of the software product from the
user’s perspective
– Use Case Document
• Product Requirements
– Functional Requirements
– Non-Functional Requirements
– Software Requirement Specification(SRS)
Levels of requirements
Example: Levels of requirements
Business Requirement:
To allow the customer to pay for gas at the pump
User Requirement:
• Swipe credit or debit card
• Enter a security PIN number
• Request a receipt at the pump
Product Requirement:
• Prompt the customer to put his or her card into the reader
• Detect that the card has been swiped
• Determine if the card was incorrectly read and prompt the
customer to swipe the card again
• Parse the information from the magnetic strip on the card
Importance of Software Requirements

• The hardest single part of building a software system

is deciding what to build...No other part of the work
so cripples the resulting system if done wrong. No
other part is difficult to rectify later
– Fred Brooks
• Examples
– The system shall maintain records of all payments made
to employees on accounts of salaries, bonuses,
travel/daily allowances, medical allowances, etc.
– The system shall interface with the central computer to
send daily sales and inventory data from every retail store
– The system shall support at least twenty transactions per
second
Requirement Engineering
Characteristics of good requirements
• Complete
– Each requirement must fully describe the functionality to be delivered
• Correct
– Each requirement must accurately describe the functionality to be built
• Feasible
– It must be possible to implement each requirement within the known
capabilities and limitations of the system and its operating environment
• Necessary
– Each requirement should document a capability that the customers
really need
• Prioritize
– Assign an implementation priority to each functional requirement
Characteristics of good requirements
• Unambiguous
– All readers of a requirement statement should arrive at a single,
consistent interpretation of it

• Verifiable
– See whether you can devise a few tests or use other verification
approaches, such as inspection, reviews etc

• Traceable etc.
– A traceable requirement can be linked backward to its origin and
forward to the design elements and source code that implement it
Examples of Requirements - 1
• The system shall maintain records of all
payments made to employees on accounts of
salaries, bonuses, travel/daily allowances,
medical allowances, etc.

20
Examples of Requirements - 2
• The system shall interface with the central
computer to send daily sales and inventory
data from every retail store

21
Examples of Requirements - 3
• The system shall maintain records of all library
materials including books, serials, newspapers
and magazines, video and audio tapes,
reports, collections of transparencies, CD-
ROMs, DVDs, etc.

22
Examples of Requirements - 4
• The system shall allow users to search for an
item by title, author, or by International
Standard Book Number

• The system’s user interface shall be

implemented using a web browser

23
Examples of Requirements - 5
• The system shall support at least twenty
transactions per second

• The system facilities which are available to

public users shall be demonstrable in ten
minutes or less

24
Types of Software Requirements
• Functional requirements
• Non-functional requirements
• Domain requirements
• Inverse requirements
• Design and implementation constraints
Functional Requirements
• Statements describing what the system does
• A requirement that specifies a function that a
system or system component must be able to
perform.
• Statements of services the system should
provide
– Reaction to particular inputs
– Behavior in particular situations
• Functional requirements are supported by
non-functional requirements
•
Examples of Functional requirements
• A library system that provides a single interface
to a number of databases of articles in different
libraries.
• The user shall be able to search either the entire
database of patients or select a subset from it
(admitted patients, or patients with asthma, etc.)
• The system shall solve a quadratic equation
using the following formula

x = (-b+sqrt(b2 – 4*a*c))/(2*a)
Non-Functional Requirements
• Most non-functional requirements relate to the system
as a whole. They include constraints on timing,
performance, reliability, security, maintainability,
accuracy, the development process, standards, etc.
• They are often more critical than individual functional
requirements
• Capture the emergent behavior of the system, that is they
relate to system as a whole
• Must be built into the framework of the software product
• Failure to meet a non-functional system requirement may
make the whole system unusable
Non-Functional Requirements
• For example, if an aircraft system does not meet
reliability requirements, it will not be certified as ‘safe’
• If a real-time control system fails to meet its
performance requirements, the control functions will
not operate correctly
• Non-functional requirements arise through user needs,
because of budget constraints, because of
organizational policies, because of the need of
interoperability with other software and hardware
systems, or because of external factors such as safety
regulations, privacy legislation, etc
Types of non-Functional Requirements

• Product Requirements
– Requirements which specify that the delivered product
must behave in a particular way e.g. execution speed,
reliability, etc
• Organizational 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.
Product Requirements

Product
requirements

Usability Efficiency Reliability Portability

requirements requirements requirements requirements

Performance Space
requirements requirements
Product Requirement Examples

• The system shall allow one hundred thousand

hits per minute on the website
• The system shall not have down time of more
than one second for continuous execution of
one thousand hours
Organizational Requirements
• Standards Requirements
• Implementation Requirements
• Delivery Requirements
• Examples
– The system development process and deliverable
documents shall conform to the MIL-STD-2167A
– Any development work sub-contracted by the
development organization shall be carried out in
accordance with Capability Maturity Model
External Requirements

External
requirements

Interoperability Ethical Legislative

requirements requirements requirements

Privacy Safety
requirements requirements
External Requirements Examples
• The system shall not disclose any personal information about
members of the library system to other members except
system administrators
• The system shall comply with the local and national laws
regarding the use of software tools
Observations on non-Functional Reqs
• Non-functional requirements can be written to reflect
general goals for the system. Examples include:
– Ease of use
– Recovery from failure
– Rapid user response
Others
• Ergonomy, Configurability, Customizability, Dependability,
Durability, Extensibility, Evolvability, Installability,
Modularity, Reausbility, Scalability, Testability,
Understandability
Observations on non-functional
Requirements
• Goals are open to misinterpretation
• Objective verification is difficult
• Non-functional requirements should be written in a
quantitative manner as much as possible, which is not
always easy for customers
– Example: For some goals, there are no quantitative
measures, e.g., maintainability
– Chances of conflicts within non-functional requirements
are fairly high, because information is coming from
different stakeholders.
• Non-functional requirements should be
highlighted in the requirements document
How to measure non-functional Reqs
• NFRs should be expressed quantitatively using
metrics (measures) that can be objectively tested
Property Measure

Speed 1. Processed transactions/second

2. Response time
3. Screen refresh time
Size 1. K bytes
2. Number of function points
Ease of use 1. Training time
2. Number of help frames

Robustness 1. Time to restart after failure

2. Percentage of events causing failure
3. Probability of data corruption on failure
Metrics for non-functional Reqs
Property Measure

Reliability 1. Mean time to failure

2. Probability of unavailability
3. Rate of failure occurrence
4. Availability

Portability 1. Percentage of target-dependent statements

2. Number of target systems
Domain Requirements
• Requirements that come from the application
domain and reflect fundamental characteristics of
that application domain
• These can be both the functional or non-
functional requirements
• These requirements, sometimes, are not
explicitly mentioned
• Domain experts find it difficult to convey domain
requirements
• Domain requirements can impose strict constraints
on solutions. This is particularly true for scientific
and engineering domains.
Domain Requirement Examples
• In a commission-based sales businesses, there is no
concept of negative commission. However, if care is
not taken novice developers can be lured into
developing systems, which calculate negative
commission
• Banking domain has its own specific constraints, for
example, most banks do not allow over-draw on
most accounts, however, most banks allow some
accounts to be over-drawn
Inverse Requirements
• They explain what the system shall not do.
Many people find it convenient to describe
their needs in this manner
• These requirements indicate the indecisive
nature of customers about certain aspects of a
new software product
• Example:
The system shall not use red color in the user
interface, whenever it is asking for inputs from
the end-user
Design and Implementation Constraints
• They are development guidelines within which
the designer must work
• These requirements can seriously limit design
and implementation options
• Can also have impact on human resources
• Examples
 The system shall be developed using the Microsoft .Net
platform
 The system shall be developed using open source tools and
shall run on Linux operating system
Comments on Examples
• Notice the level of detail in different
requirements described above. Some are very
detailed compared to others

44
Comments on Examples
• Notice the ambiguity in the requirement,
which uses the term ‘appropriate viewers’

• This requirement does not mention the

formats of documents and types of viewers,
which can be used

45
Comments on Examples
• Notice the ambiguity in the requirement for
solving the quadratic equation. The
requirement does not speak about the
possibility when the value of ‘a’ is zero

x = (-b+sqrt(b2 – 4*a*c))/2*a

46
Comments on Examples
• Incomplete and ambiguous requirements are
open to multiple interpretations and
assumptions

• This can lead to the development of poor

quality, or faulty, software products

47
Requirement Problems
• The requirements don’t reflect the real needs of the
customer for the system
• Requirements are inconsistent and/or incomplete
• It is expensive to make changes to requirements after
they have been agreed upon
• There are misunderstandings between customers, those
developing the system requirements, and software
engineers developing or maintaining the system
• Requirement specification in natural language pose
some problems which include
 Lack of clarity
 Requirements confusion
 Requirements amalgamation
Problems with Natural Language
• Natural language understanding relies on the
specification readers and writers using the same
words for same concept
• A natural language requirements specification is
over-flexible.
“You can say the same thing in completely
different ways”
• It is not possible to modularize natural language
requirements. It may be difficult to find all
related requirements
Impact of Wrong Requirements
• Requirements errors account for 70 percent to
85 percent of the rework costs on a software
project (Wiegers 2003).
• When requirements are wrong, systems are
late, unreliable and don’t meet customers
needs
• Requirement errors results in enormous loss
of time, revenue, market share, and trust of
customers
What a Requirement Looks Like

• Unique Requirements ID
• Document Structure
• Relations
• Description
• Rationale
• Origin
• Validation / Test-Case
• Customer Satisfaction
References
• Software Engineering 6th Edition, by I.
Sommerville, 2000
• Software Engineering 5th Edition, by R.
Pressman
• Software Requirements, Second Edition by
Karl E. Wiegers