UNIT- 2 – Requirements Engineering

30/10/2014 Chapter 4 Requirements Engineering 1

Topics covered

 Functional and non-functional requirements

 Requirements engineering processes
 Requirements elicitation
 Requirements specification
 Requirements validation
 Requirements change

30/10/2014 Chapter 4 Requirements Engineering 2

Requirements engineering

 The process of establishing the services that a customer

requires from a system and the constraints under which
it operates and is developed.
 The system requirements are the descriptions of the
system services and constraints that are generated
during the requirements engineering process.

30/10/2014 Chapter 4 Requirements Engineering 3

What is a requirement?

 It may range from a high-level abstract statement of a

service or of a system constraint to a detailed
mathematical functional specification.
 This is inevitable as requirements may serve a dual
function
 May be the basis for a bid for a contract - therefore must be
open to interpretation;
 May be the basis for the contract itself - therefore must be
defined in detail;
 Both these statements may be called requirements.

30/10/2014 Chapter 4 Requirements Engineering 4

Requirements abstraction (Davis)

“If a company wishes to let a contract for a large software development

project, it must define its needs in a sufficiently abstract way that a
solution is not pre-defined.
The requirements must be written so that several contractors can bid for
the contract, offering, perhaps, different ways of meeting the client
organization’s needs.
Once a contract has been awarded, the contractor must write a system
definition for the client in more detail so that the client understands and
can validate what the software will do.
Both of these documents may be called the requirements document for
the system.”

30/10/2014 Chapter 4 Requirements Engineering 5

 Types of requirement

 User requirements
 Statements in natural language plus diagrams of the services
the system provides and its operational constraints. Written for
customers.
 System requirements
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.

30/10/2014 Chapter 4 Requirements Engineering 6

User and system requirements

30/10/2014 Chapter 4 Requirements Engineering 7

Readers of different types of requirements
specification

30/10/2014 Chapter 4 Requirements Engineering 8

System stakeholders

 Any person or organization who is affected by the

system in some way and so who has a legitimate interest
 Stakeholder types
 End users
 System managers
 System owners
 External stakeholders

30/10/2014 Chapter 4 Requirements Engineering 9

The problems in formulation of requirements
are

• Incomplete requirements
• Inconsistent requirements
• Ambiguous requirements
• Conflicting requirements
• Unrealistic or impractical requirements
• Gold plating (adding extra features that are not
required)
• Over-emphasis on ease of implementation
• Over-emphasis on ease of use

30/10/2014 Chapter 4 Requirements Engineering 10

 Functional and non-functional requirements

30/10/2014 Chapter 4 Requirements Engineering 11

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
30/10/2014 Chapter 4 Requirements Engineering 12
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.

30/10/2014 Chapter 4 Requirements Engineering 13

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, because of system and environmental
complexity, it is impossible to produce a complete and
consistent requirements document.

30/10/2014 Chapter 4 Requirements Engineering 14

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.

30/10/2014 Chapter 4 Requirements Engineering 15

Types of nonfunctional requirement

30/10/2014 Chapter 4 Requirements Engineering 16

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.

30/10/2014 Chapter 4 Requirements Engineering 17

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.

30/10/2014 Chapter 4 Requirements Engineering 18

Examples of nonfunctional requirements in the
Mentcare system

Product requirement
The Mentcare system 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 Mentcare 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.

30/10/2014 Chapter 4 Requirements Engineering 19

Goals and requirements

 Non-functional requirements may be very difficult to state

precisely and imprecise requirements may be difficult to
verify.
 Goal
 A general intention of the user such as ease of use.
 Verifiable non-functional requirement
 A statement using some measure that can be objectively tested.
 Goals are helpful to developers as they convey the
intentions of the system users.

30/10/2014 Chapter 4 Requirements Engineering 20

Usability requirements

 The system should be easy to use by medical staff and

should be organized in such a way that user errors are
minimized. (Goal)
 Medical staff shall be able to use all the system functions
after four hours of training. After this training, the
average number of errors made by experienced users
shall not exceed two per hour of system use. (Testable
non-functional requirement)

30/10/2014 Chapter 4 Requirements Engineering 21

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

30/10/2014 Chapter 4 Requirements Engineering 22

 Requirements engineering processes

30/10/2014 Chapter 4 Requirements Engineering 23

Requirements engineering processes

 The processes used for RE vary widely depending on

the application domain, the people involved and the
organisation developing the requirements.
 However, there are a number of generic activities
common to all processes
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.
 In practice, RE is an iterative activity in which these
processes are interleaved.

30/10/2014 Chapter 4 Requirements Engineering 24

A spiral view of the requirements engineering
process

30/10/2014 Chapter 4 Requirements Engineering 25

 Requirements elicitation

30/10/2014 Chapter 4 Requirements Engineering 26

Requirements elicitation and analysis

 Requirements elicitation is the process of

gathering and defining the requirements for a
software system.
 The goal of requirements elicitation is to ensure
that the software development process is based
on a clear and comprehensive understanding of
the customer needs and requirements.
 Requirements elicitation involves the
identification, collection, analysis, and refinement
of the requirements for a software system.
 It is a critical part of the software development
life cycle and is typically performed at the
30/10/2014 Chapter 4 Requirements Engineering 27
beginning of the project
Requirements elicitation

 Software engineers work with a range of system

stakeholders to find out about the application domain,
the services that the system should provide, the required
system performance, hardware constraints, other
systems, etc.
 Stages include:
 Requirements discovery,
 Requirements classification and organization,
 Requirements prioritization and negotiation,
 Requirements specification.

30/10/2014 Chapter 4 Requirements Engineering 28

Requirements elicitation has several key
benefits

 Establishes the precise scope of work and

the budget.
 Avoids confusion during development
 Adds business value
 Reveals hidden and assumed requirements.
 Allows for developing only relevant
functionality.

30/10/2014 Chapter 4 Requirements Engineering 29

The requirements elicitation and analysis
process

30/10/2014 Chapter 4 Requirements Engineering 30

30/10/2014 Chapter 4 Requirements Engineering 31
Process activities

 Requirements discovery
 Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
 Requirements classification and organisation
 Groups related requirements and organises them into coherent
clusters.
 Prioritisation and negotiation
 Prioritising requirements and resolving requirements conflicts.
 Requirements specification
 Requirements are documented and input into the next round of
the spiral.

30/10/2014 Chapter 4 Requirements Engineering 32

30/10/2014 Chapter 4 Requirements Engineering 33
Brainstorming Sessions:

• It is a group technique
• It is intended to generate lots of new ideas hence
providing a platform to share views
• A highly trained facilitator is required to handle
group bias and group conflicts.
• Every idea is documented so that everyone can
see it.
• Finally, a document is prepared which consists of
the list of requirements and their priority if
possible.

30/10/2014 Chapter 4 Requirements Engineering 34

Interviewing

 Interviews are one of the most common techniques used for

requirement elicitation.
 They involve one-on-one discussions with stakeholders to gather
information about their needs, expectations, and requirements.
 Interviews can be structured or unstructured and can be conducted
in person or remotely.
 Effective interviewing
 Be open-minded, avoid pre-conceived ideas about the requirements and
are willing to listen to stakeholders.
 Prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a
prototype system.

30/10/2014 Chapter 4 Requirements Engineering 35

Surveys:

 Surveys are yet another popular requirement

elicitation technique.
 They can be conducted in person, over the
phone, or online.
 They are an excellent way to gather information
from a large number of stakeholders and can
provide quantitative data.

30/10/2014 Chapter 4 Requirements Engineering 36

Prototyping:

 This technique involves creating a preliminary

version of the product or service.
 This can be a physical prototype or a digital
prototype.
 Prototyping is an excellent way to gather
feedback from stakeholders about the design and
functionality of the product or service.

30/10/2014 Chapter 4 Requirements Engineering 37

Observation:

 The observation technique involves observing

stakeholders in their work environment.
 Observation can be used in combination with
other requirement elicitation techniques to
provide a comprehensive understanding of
stakeholders’ needs.

30/10/2014 Chapter 4 Requirements Engineering 38

Stories and scenarios

 Scenarios and user stories are real-life examples of how

a system can be used.
 Stories and scenarios are a description of how a system
may be used for a particular task.
 Because they are based on a practical situation,
stakeholders can relate to them and can comment on
their situation with respect to the story.

30/10/2014 Chapter 4 Requirements Engineering 39

Advantages of Requirements Elicitation:

• Helps to clarify and refine the customer requirements.

• Improves communication and collaboration between
stakeholders.
• Increases the chances of developing a software system that
meets the customer needs.
• Avoids misunderstandings and helps to manage
expectations.
• Supports the identification of potential risks and problems
early in the development cycle.
• Facilitates the development of a comprehensive and
accurate project plan.
• Increases user and stakeholder confidence in the software
development process.
30/10/2014 40
30/10/2014 Chapter 4 Requirements Engineering 41
 Requirements specification

30/10/2014 Chapter 4 Requirements Engineering 42

Requirements specification

 The process of writing down the user and system

requirements in a requirements document.
 User requirements have to be understandable by end-
users and customers who do not have a technical
background.
 System requirements are more detailed requirements
and may include more technical information.
 The requirements may be part of a contract for the
system development
 It is therefore important that these are as complete as possible.

30/10/2014 Chapter 4 Requirements Engineering 43

The software requirements document

 The software requirements document is the official

statement of what is required of the system developers.
 Should include both a definition of user requirements and
a specification of the system requirements.
 It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather than
HOW it should do it.

30/10/2014 Chapter 4 Requirements Engineering 44

Software requirement specification (SRS)

 The production of the requirements stage of the

software development process is Software
Requirements Specifications (SRS) (also
called a requirements document).
 This report lays a foundation for software
engineering activities and is constructing when
entire requirements are elicited and analyzed.
 The basic goal of the requirement phase is to produce
the SRS, Which describes the complete behavior of the
proposed software.
 SRS is also helping the clients to understand their own
needs.
30/10/2014 Chapter 4 Requirements Engineering 45
 A software requirements specification (SRS) is a
document explaining how and what the
software/system will do. It defines the features
and functionality that the product requires to
satisfy all stakeholders’ (business, users) needs.
 A standard SRS includes:
• A goal/purpose
• A summary of the whole process
• Specific Requirements
 The best SRS documents describe how the
program communicates with the embedded
hardware or specific software with unique coding
culture. The chosen
30/10/2014
real-life users also account 46
Chapter 4 Requirements Engineering
 Need for SRS

 SRS establishes basis of agreement between the

user and the supplier.
 Users needs have to be satisfied, but user may not
understand software
 Developers will develop the system, but may not know about
problem domain
 SRS is the medium to bridge the commn. gap and specify
user needs in a manner both can understand

Requirements 47
Need for SRS…

 Helps user understand his needs.

 users do not always know their needs
 must analyze and understand the potential
 the goal is not just to automate a manual system,
but also to add value through IT
 The req process helps clarify needs
 SRS provides a reference for validation of the
final product
 Clear understanding about what is expected.
 Validation - “ SW satisfies the SRS “
Requirements 48
Need for SRS…

 High quality SRS essential for high Quality

SW
 Requirement errors get manifested in final sw
 to satisfy the quality objective, must begin with high
quality SRS
 Requirements defects are not few
• 25% of all defects in one case; 54% of all defects found
after UT
• 80 defects in A7 that resulted in change requests
• 500 / 250 defects in previously approved SRS.

Requirements 49
Need for SRS…

 Good SRS reduces the development cost

 SRS errors are expensive to fix later
 Req. changes can cost a lot (up to 40%)
 Good SRS can minimize changes and errors
 Substantial savings; extra effort spent during req. saves
multiple times that effort
 An Example
 Cost of fixing errors in req. , design , coding , acceptance
testing and operation are 2 , 5 , 15 , 50 , 150 person-months

Requirements 50
 Characteristics of an SRS
 What should be the characteristics of a good
SRS? Some key ones are
 Complete
 Unambiguous
 Consistent
 Verifiable
 Ranked for importance and/or stability

Requirements 51
30/10/2014 Chapter 4 Requirements Engineering 52
Characteristics…
 Correctness
 Each requirement accurately represents some
desired feature in the final system
 Completeness
 All desired features/characteristics specified
 Hardest to satisfy
 Completeness and correctness strongly related
 Unambiguous
 Each req has exactly one meaning
 Without this errors will creep in
 Important as natural languages often used
Requirements 53
Characteristics…

Requirements 54
 Components of an SRS
 What should an SRS contain ?
 Clarifying this will help ensure completeness
 An SRS must specify requirements on
 Functionality
 Performance
 Design constraints
 External interfaces

Requirements 55
Sample format od SRS

30/10/2014 Chapter 4 Requirements Engineering 56

Advantages


Software SRS establishes the basic for agreement between the client and
the supplier on what the software product will do.

• A SRS provides a reference for validation of the final product.

• A high-quality SRS is a prerequisite to high-quality software.
• A high-quality SRS reduces the development cost.

30/10/2014 Chapter 4 Requirements Engineering 57

 Requirements validation

30/10/2014 Chapter 4 Requirements Engineering 58

Requirements validation

 Validation answers the question, “Are we

building the right system?”
 Requirements validation is the process of
checking that the defined requirements are for
development, and defining the system that the
customer really wants.
 Requirements validation helps us detect errors at
an early stage of product development so that it
does not result in excessive rework when
detected later in the system development life
cycle

30/10/2014 Chapter 4 Requirements Engineering 59

1.Requirements validation: Have we got the requirements right?

2.Requirements analysis: Have we got the right requirements?

30/10/2014 Chapter 4 Requirements Engineering 60

Requirements checking

 Validity. Does the system provide the functions which

best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the
customer included?
 Realism. Can the requirements be implemented given
available budget and technology
 Verifiability. Can the requirements be checked?

30/10/2014 Chapter 4 Requirements Engineering 61

Requirements validation techniques

 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check requirements.
Covered in Chapter 2.
 Test-case generation
 Developing tests for requirements to check testability.

30/10/2014 Chapter 4 Requirements Engineering 62

Principles of Requirements Validation:

 considering the following four principles of

requirements validation increases the quality of
the validation results:
• Principle 1: Involvement of the correct stakeholders
• Principle 2: Separating the identification and the
correction of errors
• Principle 3: Validation from different views
• Principle 4: Repeated validation.

30/10/2014 Chapter 4 Requirements Engineering 63

Requirements reviews

 Regular reviews should be held while the requirements

definition is being formulated.
 Both client and contractor staff should be involved in
reviews.
 Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.

30/10/2014 Chapter 4 Requirements Engineering 64

Review checks

 Verifiability
 Is the requirement realistically testable?
 Comprehensibility
 Is the requirement properly understood?
 Traceability
 Is the origin of the requirement clearly stated?
 Adaptability
 Can the requirement be changed without a large impact on other
requirements?

30/10/2014 Chapter 4 Requirements Engineering 65

 Software Traceability

30/10/2014 Chapter 4 Requirements Engineering 66

What Is Traceability and Why Is It
Important?

 Traceability is the ability to trace something as it

moves through a process.
 In product development, it refers to the ability to
track and trace requirements to artifacts, test
runs, and anything else in the product lifecycle.

30/10/2014 Chapter 4 Requirements Engineering 67

 Traceability in software engineering describes the
extent to which documentation or code can be
traced back to its point of origin.
 The goal of traceability is to provide better quality
and consistency of product development.
 It brings the ability to verify the history, location,
and application of an item by means of
documented identification.

30/10/2014 Chapter 4 Requirements Engineering 68

30/10/2014 Chapter 4 Requirements Engineering 69
30/10/2014 Chapter 4 Requirements Engineering 70
30/10/2014 Chapter 4 Requirements Engineering 71
30/10/2014 Chapter 4 Requirements Engineering 72
30/10/2014 Chapter 4 Requirements Engineering 73
30/10/2014 Chapter 4 Requirements Engineering 74
30/10/2014 Chapter 4 Requirements Engineering 75
30/10/2014 Chapter 4 Requirements Engineering 76
30/10/2014 Chapter 4 Requirements Engineering 77
30/10/2014 Chapter 4 Requirements Engineering 78
30/10/2014 Chapter 4 Requirements Engineering 79
30/10/2014 Chapter 4 Requirements Engineering 80
30/10/2014 Chapter 4 Requirements Engineering 81
30/10/2014 Chapter 4 Requirements Engineering 82
Key points

 Requirements for a software system set out what the

system should do and define constraints on its operation
and implementation.
 Functional requirements are statements of the services
that the system must provide or are descriptions of how
some computations must be carried out.
 Non-functional requirements often constrain the system
being developed and the development process being
used.
 They often relate to the emergent properties of the
system and therefore apply to the system as a whole.
30/10/2014 Chapter 4 Requirements Engineering 83
Key points

 The requirements engineering process is an iterative

process that includes requirements elicitation,
specification and validation.
 Requirements elicitation is an iterative process that can
be represented as a spiral of activities – requirements
discovery, requirements classification and organization,
requirements negotiation and requirements
documentation.
 You can use a range of techniques for requirements
elicitation including interviews and ethnography. User
stories and scenarios may be used to facilitate
discussions.
30/10/2014 Chapter 4 Requirements Engineering 84
Key points

 Requirements specification is the process of formally

documenting the user and system requirements and
creating a software requirements document.
 The software requirements document is an agreed
statement of the system requirements. It should be
organized so that both system customers and software
developers can use it.

30/10/2014 Chapter 4 Requirements Engineering 85

Key points

 Requirements validation is the process of checking the

requirements for validity, consistency, completeness,
realism and verifiability.
 Business, organizational and technical changes
inevitably lead to changes to the requirements for a
software system. Requirements management is the
process of managing and controlling these changes.

30/10/2014 Chapter 4 Requirements Engineering 86

Explain why a software system that is used in a real world
environment must change or become progressively less useful

 A system that is used in a real-world environment

necessarily must change or become progressively less
useful in that environment. And remember that software
can’t be developed completely, as the requirement changes
software becomes useless or worth so that there is need to
update our system as per our requirements. As the
system’s environment changes, new requirements emerge
and the system must be modified. When the modified
system is re-introduced into the environment, this promotes
more environmental changes so the evolution process
recycles.
 There are certain reasons that makes software system
which is used in real-world environment must change
become progressively less useful as:

30/10/2014 Chapter 4 Requirements Engineering 87

1. Number of users may increases, and then the burden of the system
requiring is expanding to its hardware capability for handle several
connections.
2. The business model of the company may change so the system become
obsolete and need for a change to cope its requirements.
3. The law in the particular country may impose a particular standard which
also effect to software systems.
 Following figure shows Software reliability curve which means software
doesn’t ware-out but it becomes progressively less useful due to some real-
world environmental changes.

30/10/2014 Chapter 4 Requirements Engineering 88