Lecture Three

Requirements engineering

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.
The process of finding out, analyzing, documenting and checking these services and
constraints is called requirements engineering (RE).

There are four main activities in the requirements engineering process:

Feasibility study An estimate is made of whether the identified user needs may be
satisfied using current software and hardware technologies. The study considers whether
the proposed system will be cost-effective from a business point of view and if it can be
developed within existing budgetary constraints. A feasibility study should be relatively
cheap and quick. The result should inform the decision
of whether or not to go ahead with a more detailed analysis.

Requirements elicitation and analysis This is the process of deriving the system
requirements through observation of existing systems, discussions with potential users and
procurers, task analysis, and so on. This may involve the development of one or more
system models and prototypes. These help you understand the system to be specified.

Requirements specification Requirements specification is the activity of translating the

information gathered during the analysis activity into a document that defines a set of
requirements. Two types of requirements may be included in this document. User
requirements are abstract statements of the system requirements for the customer and
end-user of the system; system requirements are a more detailed description of the
functionality to be provided.

Requirements validation This activity checks the requirements for realism, consistency,
and completeness. During this process, errors in the requirements document are inevitably
discovered. It must then be modified to correct these problems. Of course, the activities in
the requirements process are not simply carried out in a strict sequence. Requirements
analysis continues during definition and specification and new requirements come to light
throughout the process. Therefore, the activities of analysis, definition, and specification
are interleaved. In agile methods, such as extreme programming, requirements are
developed incrementally according to user priorities and the elicitation of requirements
comes from users who are part of the development team.

COMP 212 REQUIREMENT ENGINEERING Page 1

Fig: Requirement Engineering Process

The requirements engineering process aims to produce an agreed requirements document

that specifies a system satisfying stakeholder requirements. Requirements are usually
presented at two levels of detail.

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.

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.

Example

User Requirement Definition – Library Management System

Users should be able to search for books by title, author, genre, or ISBN to easily find the
desired book in the library's catalog.

System Requirement specification – Library Management System

1.1 The system shall provide a search bar where users can input search terms (title, author,
genre, or ISBN).
1.2 The system must query the database and return results matching the search criteria within 2
seconds.
1.3 Search results should display the book title, author, availability status, and cover image.
1.4 The system shall support filters and sorting options (e.g., by relevance, publication date).
1.5 The search functionality must process and display results for up to 10,000 books within 2
seconds.

COMP 212 REQUIREMENT ENGINEERING Page 2

Different levels of requirements are useful because they communicate information about
the system to different types of reader.

User Requirement System Requirements

Client Managers System End-Users
System End-Users Client Engineers
Client Engineers System Architects
Contractor Managers Software Developers
System Architects

Functional and non-functional requirements

Software system requirements are often classified as functional requirements or
nonfunctional 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 and 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 (from Library Management)

Functional Requirements
1.1 The system shall provide a search bar where users can input search terms (title, author,
genre, or ISBN).
1.3 Search results should display the book title, author, availability status, and cover image.

These functional requirements define specific facilities to be provided by the system.

Imprecision in the requirements specification is the cause of many software engineering
problems.

In principle, the functional requirements specification of a system should be both complete

and consistent. Completeness means that all services required by the user should be
defined. Consistency means that requirements should not have contradictory definition.

Non-functional requirements
Non-functional requirements 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.

COMP 212 REQUIREMENT ENGINEERING Page 3

They may define constraints on the system implementation such as the capabilities of I/O
devices or the data representations used in interfaces with other systems.
System users can usually find ways to work around a system function that doesn’t really
meet their needs. However, failing to meet a non-functional requirement can mean that the
whole system is unusable.

Example (from Library Management)

1.2 The system must query the database and return results matching the search criteria
within 2 seconds.
1.5 The search functionality must process and display results for up to 10,000 books within
2 seconds.

The implementation of the non-functional 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.

A common problem with non-functional requirements is that users or customers often

propose these requirements as general goals, such as ease of use, the ability of the system
to recover from failure, or rapid user response.

The software requirements document

The software requirements document (sometimes called the software requirements

specification or SRS) is an official statement of what the system developers should
implement. It should include both the user requirements for a system and a detailed
specification of the system requirements.
Requirements documents are essential when an outside contractor is developing the
software system.
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.
The level of detail that you should include in a requirements document depends on the
type of system that is being developed and the development process used
A possible organization for a requirements document that is based on an IEEE standard for
requirements documents (IEEE, 1998). This standard is a generic standard that can be
adapted to specific uses.

COMP 212 REQUIREMENT ENGINEERING Page 4

Chapter Description
Preface This should define the expected readership of the document and
describe its
version history, including a rationale for the creation of a new version
and a
summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe
the
system’s functions and explain how it will work with other systems. It
should
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should
not
make assumptions about the experience or expertise of the reader.
User Here, you describe the services provided for the user. The non-functional
requirement system requirements should also be described in this section. This
s description may use natural language, diagrams, or other notations that
definition are
understandable to customers. Product and process standards that must
be
followed should be specified.
System This chapter should present a high-level overview of the anticipated
architecture system
architecture, showing the distribution of functions across system
modules.
Architectural components that are reused should be highlighted.
System This should describe the functional and non-functional requirements in
requirement more
s detail. If necessary, further detail may also be added to the non-
specification functional
requirements. Interfaces to other systems may be defined.
System This might include graphical system models showing the relationships
models between
the system components, the system, and its environment. Examples of
possible
models are object models, data-flow models, or semantic data models.
System This should describe the fundamental assumptions on which the system
evolution is
based, and any anticipated changes due to hardware evolution,
changing
user needs, and so on. This section is useful for system designers as it
may
help them avoid design decisions that would constrain likely future
changes
to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database

COMP 212 REQUIREMENT ENGINEERING Page 5

 descriptions.
Hardware requirements define the minimal and optimal configurations
for the
system. Database requirements define the logical organization of the
data used
by the system and the relationships between data.
Index Several indexes to the document may be included. As well as a normal
alphabetic index, there may be an index of diagrams, an index of
functions,
and so on.

Fig: The structure of a requirements document

Requirements specification
Requirements specification is the process of writing down the user and system
requirements in a requirements document.
The user and system requirements should be clear, unambiguous, easy to understand,
complete, and consistent.
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.
System requirements are expanded versions of the user requirements that are used by
software engineers as the starting point for the system design.

Ways of writing system requirements specification

Natural language sentences: The requirements are written using numbered sentences
in natural language. Each sentence should express one requirement.

Design description languages: This approach uses a language like a programming

language, but with more abstract features to specify the requirements by defining an
operational model of the system. This approach is now rarely used although it can be useful
for interface specifications.

Graphical notations: Graphical models, supplemented by text annotations, are used to

define the functional requirements for the system; UML use case and sequence diagrams
are commonly used.

Mathematical specifications: These notations are based on mathematical concepts such

as finite-state machines or sets. Although these unambiguous specifications can reduce the
ambiguity in a requirements document, most customers don’t understand a formal
specification. They cannot check that it represents what they want and are reluctant to
accept it as a system contract.

COMP 212 REQUIREMENT ENGINEERING Page 6

Some of the problems it may be encountered without a SRS document
The important problems that an organization would face if it does not develop a SRS
document may include
- The system would not be implemented according to customer needs.
- Software developers would not know whether what they are developing is what
exactly required by the customer.
- It will be very much difficult for the maintenance engineers to understand the
functionality of the system.
- It will be very much difficult for user document writers to write the users’ manuals
properly without understanding the SRS document.

Requirements engineering processes

As earlier indicated, 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), and checking that the requirements actually define
the system that the customer wants (validation).
These activities can be organized as an iterative process around a spiral, with the output
being a system requirements document.

Fig: Spiral View of requirement Engineering Process

Requirements elicitation and analysis

COMP 212 REQUIREMENT ENGINEERING Page 7
After an initial feasibility study, the next stage of the requirements engineering process is
requirements elicitation and analysis. In this activity, 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,
and so on.
Requirements elicitation and analysis may involve a variety of different kinds of people in
an organization. A system stakeholder is anyone who should have some direct or indirect
influence on the system requirements e.g end users, engineers, business managers,
domain experts and others.

The activities in the elicitation and analysis process include:

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.

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.
Requirements prioritization and negotiation 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.
Requirements specification The requirements are documented and input into the next
round of the spiral

Fig: The requirements elicitation and analysis process

COMP 212 REQUIREMENT ENGINEERING Page 8

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; they may find it difficult to articulate what they want the system
to do; they may make unrealistic demands because they don’t know what is and isn’t
feasible.
- Stakeholders in a system naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers, without experience in
the customer’s domain, may not understand these requirements.
- Different stakeholders have different requirements and they may express these in
different ways. Requirements engineers have to discover all potential sources of
requirements and discover commonalities and conflict.
- Political factors may influence the requirements of a system. Managers may demand
specific system requirements because these will allow them to increase their
influence in the organization.
- The economic and business environment in which the analysis takes place is
dynamic. It inevitably changes during the analysis process. The importance of
particular requirements may change. New requirements may emerge from new
stakeholders who were not originally consulted.

Requirements discovery
Requirements discovery (sometime called requirements elicitation) is the process of
gathering information about the required system and existing systems, and distilling the
user and system requirements from this information.
Sources of information during the requirements discovery phase include documentation,
system stakeholders, and specifications of similar systems.

Requirement Discovery Techniques

i. Interviews - the requirements engineering team puts questions to stakeholders
about the system that they currently use and the system to be developed.
Requirements
i. Viewpoints - A viewpoint is way of collecting and organizing a set of
requirements from a group of stakeholders who have something in common. Each
viewpoint therefore includes a set of system requirements. Viewpoints might come
from end-users, managers, etc. They help identify the people who can provide
information about their requirements and structure the requirements for analysis.
i. Scenarios - People usually find it easier to relate to real-life examples rather than
abstract descriptions. They can understand and criticize a scenario of how they
might interact with a software system. Requirements engineers can use the
information gained from this discussion to formulate the actual system
requirements. Particularly useful for adding details to an outline requirement
i. Use cases - Use cases are a requirements discovery technique that were first
introduced in the Objectory method (Jacobson et al., 1993). Use cases are
documented using a high-level use case diagram. The set of use cases represents
all of the possible interactions that will be described in the system requirements.
Actors in the process, who may be human or other systems, are represented as

COMP 212 REQUIREMENT ENGINEERING Page 9

 stick figures. Each class of interaction is represented as a named ellipse. Lines link
the actors with the interaction
i. Ethnography is an observational technique that can be used to understand
operational processes and help derive support requirements for these processes.
An analyst immerses himself or herself in the working environment where the
system will be used. The day-to-day work is observed and notes made of the
actual tasks in which participants are involved

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 when these problems are discovered during development or after
the system is in service.
During the requirements validation process, different types of checks should be carried out
on the requirements in the requirements document. These checks include:
1. Validity checks A user may think that a system is needed to perform certain
functions. However, further thought and analysis may identify additional or different
functions that are required.
2. Consistency checks Requirements in the document should not conflict. That is, there
should not be contradictory constraints or different descriptions of the same system
function.
3. Completeness checks the requirements document should include requirements that
define all functions and the constraints intended by the system user.
4. Realism checks Using knowledge of existing technology, the requirements should be
checked to ensure that they can actually be implemented.
5. Verifiability To reduce the potential for dispute between customer and contractor,
system requirements should always be written so that they are verifiable. This means
that you should be able to write a set of tests that can demonstrate that the
delivered system meets each specified requirement.

Validation techniques include:

i. Requirements reviews The requirements are analyzed systematically by a team of

reviewers who check for errors and inconsistencies.
ii. Prototyping In this approach to validation, an executable model of the system in
question is demonstrated to end-users and customers. They can experiment with
this model to see if it meets their real needs.
iii. Test-case generation Requirements should be testable. If the tests for the
requirements are devised as part of the validation process, this often reveals
requirements problems.

NB: 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

COMP 212 REQUIREMENT ENGINEERING Page 10