Unit 4:

Requirements Engineering (3 Hrs.)

Compiled by : Madan Nath (B.Sc. CSIT, TU)

11
 Contents:
 Concept of User and System Requirements;
 Functional and Non-Functional Requirements;
 Requirements Engineering Process;
 Requirements Elicitation;
 Requirements Specification;
 Requirements Validation;
 Requirements Change

2 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements engineering (RE)

• Requirements engineering (RE) is 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.
• Requirements may range from a high-level abstract statement
of a service or of a system constraint to a detailed mathematical
functional specification.
• As much as possible, requirements should describe what the
system should do, but not how it should do it.
3 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements engineering (RE)…

Two kinds of requirements based on the intended

purpose and target audience:
1. User requirements:
2. System requirements:
• User requirements:
High-level abstract requirements written as 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.

4 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements engineering (RE)…

• System requirements:
Detailed description of what the system should do including
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.

5 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Three classes of 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.
3. Domain requirements: Constraints on the system from the
domain of operation.
6 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Functional requirements

Functional requirements describe functionality or system

services. They 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.
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by
developers and users. In principle, requirements should be both
Complete and Consistent.
7 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Functional requirements…

• Complete: they should include descriptions of all facilities

required, and
• Consistent: there should be no conflicts or contradictions in
the descriptions of the system facilities.
In practice, it is impossible to produce a complete and consistent
requirements document.

8 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 2. Non-functional requirements:

Non-functional requirements 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.
9 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 2. Non-functional requirements:…

Non-functional requirements may affect the overall architecture

of a system rather than the individual 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.

10 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 2. Non-functional requirements:…

11 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Three classes 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 organizational 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.
12 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 3. Domain requirements

The system's operational domain imposes requirements on the

system. Domain requirements may be new functional
requirements, constraints on existing requirements or define
specific computations. If domain requirements are not satisfied,
the system may be unworkable. Two main problems with domain
requirements:
Understandability: Requirements are expressed in the language
of the application domain, which is not always 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.
13 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements engineering process

Processes vary widely depending on the application domain, the

people involved and the organization developing the
requirements. In practice, requirements engineering is
an iterative process, in which the following generic activities are
interleaved:
• Requirements elicitation;
• Requirements analysis;
• Requirements validation;
• Requirements management.

14 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Spiral view of requirements engineering
process

15 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Requirements elicitation and analysis

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:

16 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Requirements elicitation and analysis…

17 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Requirements elicitation and analysis…

Requirements discovery: Interacting with stakeholders to

discover their requirements. Domain requirements are also
discovered at this stage.
Requirements classification and organization: Groups related
requirements and organizes them into coherent clusters.
Prioritization and negotiation: Prioritizing requirements and
resolving requirements conflicts.
Requirements specification: Requirements are documented and
input into the next round of the spiral.

18 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Requirements elicitation and analysis…

Closed (based on pre-determined list of questions) and

open interviews with stakeholders are a part of the RE
process. User stories and scenarios are real-life examples of how
a system can be used, which are usually easy for stakeholders to
understand. Scenarios should include descriptions of the starting
situation, normal flow of events, what can go wrong, other
concurrent activities, the state of the system when the scenario
finishes.
Use-cases are a scenario-based technique in the UML which
identify the actors in an interaction and which describe the
interaction itself. A set of use cases should describe all possible
19 interactions with the system. Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Requirements elicitation and analysis…

20 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 1. Requirements elicitation and analysis…

Problems to look for during requirements elicitation and

analysis:
• Stakeholders don't know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the
system requirements.
• The requirements change during the analysis process.
• New stakeholders may emerge and the business
environment may change.

21 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 2. Requirements specification

Requirements specification is 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 and it is important that these
are as complete as possible.
In principle, requirements should state what the system should do
and the design should describe how it does this. In
practice, requirements and design are inseparable.
22 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 2. Requirements specification…

User requirements are almost always written in natural

language supplemented by appropriate diagrams and tables in the
requirements document. System requirements may also be
written in natural language but other notations based on forms,
graphical system models, or mathematical system models can
also be used. Natural language is expressive, intuitive and
universal. This means that the requirements can be understood by
users and customers.

23 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 2. Requirements specification…

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. This
approach maintains most of the expressiveness and understand-
ability of natural language but ensures that some uniformity is
imposed on the specification.

24 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 3. Requirements validation

Requirements validation is concerned with demonstrating that

the requirements define the system that the customer really
wants. Requirements error costs are high so validation is very
important.
What problems to look for:
• 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?

25 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 3. Requirements validation…

• Realism: can the requirements be implemented given

available budget and technology?
• Verifiability: can the requirements be checked?
Requirements validation techniques:
1. Requirements reviews:
Systematic manual analysis of the requirements. Regular reviews
should be held while the requirements definition is being
formulated. What to look for:
• Verifiability: is the requirement realistically testable?
• Comprehensibility: is the requirement properly
understood?
26 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 3. Requirements validation…

• Traceability: is the origin of the requirement clearly stated?

• Adaptability: can the requirement be changed without a
large impact on other requirements?
2. Prototyping:
Using an executable model of the system to check requirements.
3. Test-case generation:
Developing tests for requirements to check testability.

27 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 4. Requirements Management

Requirements management is the process of managing changing

requirements during the requirements engineering process and
system development.
New requirements emerge as a system is being developed and
after it has gone into use. Reasons why requirements change after
the system's deployment:
1. The business and technical environment of the system
always changes after installation.

28 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 4. Requirements Management…

2. The people who pay for a system and the users of that
system are rarely the same people.
3. Large systems usually have a diverse user community, with
many users having different requirements and priorities
that may be conflicting or contradictory.

29 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements management planning

Planning is an essential first stage in the requirements

management process. The planning stage establishes the level of
requirements management detail that is required. During the
requirements management stage, you have to decide on:
1. Requirements identification
Each requirement must be uniquely identified.
2. A change management process
set of activities that assess the impact and cost of changes.

30 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements management planning…

3. Traceability policies
define the relationships between each requirement and
between the requirements and the system design that should
be recorded.
4. Tool support
Requirements management involves the processing of large
amounts of information about the requirements. Tools that
may be used range from specialist requirements management
systems to spreadsheets and simple database systems.

31 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements change management

Three principal stages to a change management process:

1. Problem analysis and change specification
The process starts with an identified requirements problem or,
sometimes, with a specific change proposal. During this stage,
the problem or the change proposal is analyzed to check that it is
32 valid. Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 Requirements change management

2. Change analysis and costing

The cost of making the change is estimated both in terms of
modifications to the requirements document and to the system
design and implementation. Once this analysis is completed, a
decision is made whether or not to proceed with the requirements
change.
3. Change implementation
The requirements document and, where necessary, the system
design and implementation, are modified

33 Compiled by : Madan
Nath (B.Sc. CSIT, TU)
 ~ END ~

34 Compiled by : Madan
Nath (B.Sc. CSIT, TU)