What is Requirement Engineering?

o The requirements for a system are the descriptions of what the system
should do-the services that it provides and the constraints on its operation.
These requirements reflect the needs of customers for a system that serves a
certain purpose such as controlling a device, placing an order, or finding
information.

o The process of finding out, analyzing, documenting and checking these

services and constraints is called requirements engineering (RE).
What is Requirement Engineering?

o In some cases, a requirement is simply a high-level, abstract statement of

a service that a system should provide or a constraint on a system.

o At the other extreme, it is a detailed, formal definition of a system

function.
What is Requirement Engineering?

o The process to collect the software requirements from customers, analyze

and document them is referred to as requirement engineering.

o The primary purpose of requirement engineering is to develop and

maintain the delicate and descriptive 'System Requirements Specification'
document.
Requirement Engineering Process:

It is a four-step process, which includes –

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.
Requirement Engineering Process:

Feasibility Study:

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current

technologies, which are needed to accomplish customer requirements within
the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an organization.
Requirement Engineering Process:

2. Requirement Gathering:

After the feasibility study, the report of the feasibility study is positive
towards the project then, next phase starts with collect requirements from the
customers.

In this phase, the analyst and engineer interact with a client and end-users to
know their demands on what the project should provide and what features
they want the software to include.
Requirement Engineering Process:

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software

analyst after the requirements collected from the various sources - the requirement received
by the customer written in ordinary language.

It is the job of the analyst to write the requirement in technical language so that they can be
understood and beneficial by the development team.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
Requirement Engineering Process:

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in

this document are validated. The user might demand illegal, impossible
solution or experts may misinterpret the needs. Requirements can be the
check against the following conditions –

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
User requirements and System requirements

1. User requirements are statements, in a natural language plus diagrams, of

what services the system is expected to provide to system users and the
constraints under which it must operate.

2. System requirements are more detailed descriptions of the software

system’s functions, services, and operational constraints. The system
requirements document (sometimes called a functional specification) should
define exactly what is to be implemented. It may be part of the contract
between the system buyer and the software developers.
This example from a mental health care patient management system
(MHC-PMS) shows how a user requirement may be expanded into
several system requirements.

You can see from Figure 4.1 that the user requirement is quite general.
The system requirements provide more specific information about the
services and functions of the system that is to be implemented.
Functional and non-functional requirements

1. Functional requirements These are statements of services the system

should provide, how the system should react to particular inputs, and how
the system should behave in particular situations. In some cases, the
functional requirements may also explicitly state what the system should not
do.

2. Non-functional requirements These are constraints on the services or

functions offered by the system. They include timing constraints, constraints
on the development process, and constraints imposed by standards.
Non-functional requirements often apply to the system as a whole, rather
than individual system features or services.
Functional requirements

The functional requirements for a system describe what the system should do. These
requirements depend on the type of software being developed, the expected users of the
software, and the general approach taken by the organization when writing requirements.

Example of functional requirements for the MHC-PMS system, used to maintain

information about patients receiving treatment for mental health problems:

1. A user shall be able to search the appointments lists for all clinics.

2. The system shall generate each day, for each clinic, a list of patients who are expected to
attend appointments that day.

3. Each staff member using the system shall be uniquely identified by his or her eight-digit
employee number.

These functional user requirements define specific facilities to be provided by the system.
Non-Functional requirements

Non-functional requirements, as the name suggests, are requirements that

are not directly concerned with the specific services delivered by the system
to its users. They may relate to emergent system properties such as
reliability, response time, and store occupancy.

Non-functional requirements, such as 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.
Non-Functional requirements

Although it is often possible to identify which system components implement specific

functional requirements (e.g., there may be formatting components that implement reporting
requirements), it is often more difficult to relate components to non-functional requirements.
The implementation of these requirements may be diffused throughout the system. There are
two reasons for this:

1. 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.
2. A single non-functional requirement, such as a security requirement, may generate a
number of related functional requirements that define new system services that are
required. In addition, it may also generate requirements that restrict existing
requirements.
Fig: Types of non-functional requirement
1. Product requirements These requirements specify or constrain the behavior of the software.
Examples include performance requirements on how fast the system must execute and how much
memory it requires, reliability requirements that set out the acceptable failure rate, security
requirements, and usability requirements.

2. Organizational requirements These requirements are broad system requirements derived from
policies and procedures in the customer’s and developer’s organization. Examples include operational
process requirements that define how the system will be used, development process requirements that
specify the programming language, the development environment or process standards to be used, and
environmental requirements that specify the operating environment of the system.

3. External requirements This broad heading covers all requirements that are derived from factors
external to the system and its development process. These may include regulatory requirements that
set out what must be done for the system to be approved for use by a regulator, such as a central bank;
legislative requirements that must be followed to ensure that the system operates within the law; and
ethical requirements that ensure that the system will be acceptable to its users and the general public.
Fig: Metrics for specifying non-functional requirements
Fig: The structure of a requirements document
Fig: Ways of writing a system requirements specification
1. Requirements discovery This is the process of interacting with
stakeholders of the system to discover their requirements. Domain
requirements from stakeholders and documentation are also discovered
during this activity. There are several complementary techniques that can be
used for requirements discovery, which I discuss later in this section.

2. Requirements classification and organization This activity takes the

unstructured collection of requirements, groups related requirements, and
organizes them into coherent clusters. The most common way of grouping
requirements is to use a model of the system architecture to identify
sub-systems and to associate requirements with each sub-system. In practice,
requirements engineering and architectural design cannot be completely
separate activities.
3. Requirements prioritization and negotiation Inevitably, when multiple
stakeholders are involved, requirements will conflict. This activity is
concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiation. Usually, stakeholders have to
meet to resolve differences and agree on compromise requirements

4. Requirements specification The requirements are documented and input

into the next round of the spiral. Formal or informal requirements documents
may be produced.
Interviewing
Formal or informal interviews with system stakeholders are part of most
requirements engineering processes. In these interviews, the requirements
engineering team puts questions to stakeholders about the system that they
currently use and the system to be developed. Requirements are derived
from the answers to these questions. Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a pre-defined set of

questions.

2. Open interviews, in which there is no pre-defined agenda. The

requirements engineering team explores a range of issues with system
stakeholders and hence develop a better understanding of their needs.
Ethnography

Ethnography is an observational technique that can be used to understand

operational processes and help derive support requirements for these
processes.
Requirements Validation

During the requirements validation process, different types of checks should be carried out on
the requirements in the requirements document. These checks include:
Fig: Requirements change management