Requirements Engineering

Module 2 – Requirement Engineering
Name of Faculty: Manisha Kumari

Assistant professor
MCA Department
Requirements engineering 1
Topics
Functional and non-functional requirements

The software requirements document
Requirements specification
Requirements engineering processes
Requirements elicitation and analysis
Requirements validation
Requirements management
Manisha Kumari
Assistant Professor
Requirements engineering
PG Dept. MCA 2
Brindavan College, Bangalore
Requirements Engineering
The process of establishing the services that the

customer requires from a system and the constraints
under which it operates and is developed.
The requirements themselves are the descriptions of the

system services and constraints that are generated
during the requirements engineering process.
Manisha Kumari
Assistant Professor
PG Dept. MCA 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.
Manisha Kumari
Assistant Professor
PG Dept. MCA 4
Requirements engineering Brindavan College, Bangalore
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.”
Types of Requirements
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.
• Whom do you think these are written for?
• These are higher level than functional and non-functional
requirements, which these may subsume.
Manisha Kumari
Assistant Professor
PG Dept. MCA 6
User and System Requirements
Functional and Non-functional requirements
1. 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.
2. 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.
Manisha Kumari
Assistant Professor
Requirements engineering PG Dept. MCA 8
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.
• Essentially, these are the ‘what's’ of the system that we
often refer to. These are not ‘all that there is,’ but these
should describe the overall functionality of the system.
Manisha Kumari
Assistant Professor
PG Dept. MCA 9
Non-functional Requirements
• Requirements are not directly concerned with the specific

services.
• They relate to emergent system properties such as

reliability, response time and store occupancy.
• Performance, security or availability, usually specify or

constrain characteristics of the system as a whole.
• Non-functional requirements are often more critical than

individual functional requirements.
Manisha Kumari
Assistant Professor
Types of Nonfunctional Requirements
Manisha Kumari
Assistant Professor
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.
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 (MTTF)
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure (MTTR)
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Domain requirements problems
Understandability
• Requirements are expressed in the language of the application
domain;
• Application written for mortgage banking people need to
express functionality in terms of home loans, mortgage
balances, escrow, investor accounting, foreclosure, etc.
• This is often not understood by software engineers developing
the system.
Implicitness
• Domain specialists understand the area so well that they do not
think of making the domain requirements explicit.
And this is often a major problem in communications!!!
Manisha Kumari
Assistant Professor
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.
Manisha Kumari
Assistant Professor
Software Requirements Document
• The software requirements document (sometimes called the

software requirements specification or SRS).
• It should include both the user requirements for a system

and a detailed specification of the system requirements.
• The user requirements are defined in an introduction to the

system requirements specification.
• The requirements document has a diverse set of users,

ranging from the senior management of the organization
that is paying for the system to the engineers responsible
for developing the software.Manisha Kumari
Assistant Professor
PG Dept. MCA
Users of a requirements document
Manisha Kumari
Assistant Professor
The structure of a requirements
document
Manisha Kumari
Assistant Professor
Continue…
Manisha Kumari
Assistant Professor
Requirements specification
• Requirements specification is the process of writing down the user

and system requirements in a requirements document.
• The user requirements for a system should describe the functional

and nonfunctional requirements so that they are understandable by
system users who don’t have detailed technical knowledge.
• The requirements document should not include details of the system

architecture or design.
• by software engineers as the starting point for the system design.

They add detail and explain how the user requirements should be
provided by the system.
Manisha Kumari
Assistant Professor
There are several reasons
• You may have to design an initial architecture of the

system to help structure the requirements specification.
• Systems must interoperate with existing systems, which

constrain the design and impose requirements on the
new system.
• The use of a specific architecture to satisfy non-functional

requirements may be necessary.
Manisha Kumari
Assistant Professor
Natural language specification
• Natural language has been used to write requirements for software

since the beginning of software engineering.
simple guidelines:
• Invent a standard format and ensure that all requirement definitions
adhere to that format.
• Use language consistently to distinguish between mandatory and

desirable requirements
• Use text highlighting (bold, italic, or color) to pick out key parts of the
requirement.
• Do not assume that readers understand technical software

engineering language.
Manisha Kumari
Assistant Professor
Structured specifications
• Structured natural language is a way of writing system

requirements where the freedom of the requirements writer is
limited and all requirements are written in a standard way.
Manisha Kumari
Assistant Professor
Structured specifications
Manisha Kumari
Assistant Professor
The following information should be
included:
• A description of the function or entity being specified.
• A description of its inputs and where these come from.
• A description of its outputs and where these go to.
• Information about the information that is needed for the computation

or other entities in the system that are used (the ‘requires’ part).
• If a functional approach is used, a pre-condition setting out what

must be true before the function is called, and a post-condition
specifying what is true after the function is called.
• A description of the side effects (if any) of the operation.

Manisha Kumari
Assistant Professor
A spiral requirements process
Manisha Kumari
Assistant Professor
processes
Requirements engineering processes may include four
high-level activities
• These focus on assessing if the system is useful to
the business(feasibility study).
• Discovering requirements (elicitation and analysis).
• Converting these requirements into some standard

form (specification).
• Checking that the requirements actually define the

system that the customer wants (validation).
Manisha Kumari
Assistant Professor
Requirements elicitation and
analysis
• Software engineers work with customers and system

end-users to find out about the application domain,
what services the system should provide, the
required performance of the system hardware
constraints.
Manisha Kumari
Assistant Professor
The process activities are:
1. Requirements discovery
2. Requirements classification and organization
3. Requirements prioritization and negotiation Inevitably
4. Requirements specification
Manisha Kumari
Assistant Professor
Continue…
Eliciting and understanding requirements from system

stakeholders is a difficult process for several reasons:
• Stakeholders often don’t know what they want from a

computer system except in the most general terms.
• Stakeholders in a system naturally express requirements in

their own terms and with implicit knowledge of their own
work.
• Different stakeholders have different requirements and they

may express these in different ways .
Manisha Kumari
Assistant Professor
Continue…
• Political factors may influence the requirements of a

system.
• The economic and business environment in which the

analysis takes place is dynamic.
Manisha Kumari
Assistant Professor
Continue…
• Requirements discovery
• Interviewing
• Scenarios
• Use cases
• Ethnography
Manisha Kumari
Assistant Professor
Requirements validation
 Requirements validation is the process of

checking that requirements actually define the
system that the customer really wants.
 Requirements validation is important because

errors in a requirements document can lead to
extensive rework costs.
Manisha Kumari
Assistant Professor
Continue…
During the requirements validation process, different

types of checks should be carried out on the
requirements in the requirements document.
• Validity checks
• Consistency checks
• Completeness checks
• Realism checks
• Verifiability
Manisha Kumari
Assistant Professor
Requirements change management
Requirements change management should be applied to

all proposed changes to a system’s requirements after
the requirements document has been approved.
There are three principal stages to a change management

process:
– Problem analysis and change specification.
– Change analysis and costing
– Change implementation
Manisha Kumari
Assistant Professor

Requirements Engineering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Engineering

Uploaded by

Copyright:

Available Formats

Module 2 – Requirement Engineering

Name of Faculty: Manisha Kumari

Functional and non-functional requirements

The process of establishing the services that the

The requirements themselves are the descriptions of the

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

This is inevitable as requirements may serve a dual

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

Both of these documents may be called the requirements document for

• Describe functionality or system services.

• Requirements are not directly concerned with the specific

• They relate to emergent system properties such as

• Performance, security or availability, usually specify or

• Non-functional requirements are often more critical than

Non-functional requirements may affect the overall

Requirements for a software system set out what the

• The software requirements document (sometimes called the

• It should include both the user requirements for a system

• The user requirements are defined in an introduction to the

• The requirements document has a diverse set of users,

• Requirements specification is the process of writing down the user

• The user requirements for a system should describe the functional

• The requirements document should not include details of the system

• by software engineers as the starting point for the system design.

• You may have to design an initial architecture of the

• Systems must interoperate with existing systems, which

• The use of a specific architecture to satisfy non-functional

• Natural language has been used to write requirements for software

• Use language consistently to distinguish between mandatory and

• Do not assume that readers understand technical software

• Structured natural language is a way of writing system

• A description of its inputs and where these come from.

• A description of its outputs and where these go to.

• Information about the information that is needed for the computation

• If a functional approach is used, a pre-condition setting out what

• A description of the side effects (if any) of the operation.

• Discovering requirements (elicitation and analysis).

• Converting these requirements into some standard

• Checking that the requirements actually define the

• Software engineers work with customers and system

Eliciting and understanding requirements from system

• Stakeholders often don’t know what they want from a

• Stakeholders in a system naturally express requirements in

• Different stakeholders have different requirements and they

• Political factors may influence the requirements of a

• The economic and business environment in which the

 Requirements validation is the process of

 Requirements validation is important because

During the requirements validation process, different

Requirements change management should be applied to

There are three principal stages to a change management

You might also like