Scribd
Upload
2 views

Lecture-1 (1)

Requirements engineering (RE) involves identifying, analyzing, documenting, and validating the requirements of a system, which include both functional and non-functional requirements. Functional requirements specify what the system should do, while non-functional requirements address system properties like performance and security. The software requirements document (SRS) serves as an official statement of the requirements, aiming for clarity and consistency despite the challenges posed by stakeholder interpretations.

Uploaded by

vitaliswafula211
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

Lecture-1 (1)

Requirements engineering (RE) involves identifying, analyzing, documenting, and validating the requirements of a system, which include both functional and non-functional requirements. Functional requirements specify what the system should do, while non-functional requirements address system properties like performance and security. The software requirements document (SRS) serves as an official statement of the requirements, aiming for clarity and consistency despite the challenges posed by stakeholder interpretations.

Uploaded by

vitaliswafula211
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

SCS104

REQUIREMENTS ENGINEERING
Introduction
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, analysing, documenting and checking
these services and constraints is called requirements engineering (RE).

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

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. When
expressed as user requirements, functional requirements are usually described in an abstract
way that can be understood by system users.

Functional system requirements vary from general requirements covering what the system
should do to very specific requirements reflecting local ways of working or an organization’s
existing systems.

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.
Alternatively, 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.

Non-functional requirements, such as performance, security, or availability, usually specify or


constrain characteristics of the system. Non-functional requirements are often more critical than
individual functional requirements. Not meeting a non-functional requirement can mean that
the whole system is unusable. For example, if a plane system does not meet its reliability
requirements, it will not be certified as safe for operation; if an embedded control system fails
to meet its performance requirements, the control functions will not operate correctly.

Types of non-functional requirements


1. Product requirements These requirements specify or constrain the behaviour 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.

Metrics for specifying non-functional requirements


It is difficult, in practice, to separate functional and non-functional requirements in the
requirements document. If the non-functional requirements are stated separately from the
functional requirements, the relationships between them may be hard to understand.

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. Sometimes, the user and system requirements are integrated into a single
description. In other cases, the user requirements are defined in an introduction to the system
requirements specification. If there are many requirements, the detailed system requirements
may be presented in a separate document.

Requirements specifications
Requirements specification is the process of writing down the user and system requirements in
a requirements document. Ideally, the user and system requirements should be clear,
unambiguous, easy to understand, complete, and consistent. In practice, this is difficult to
achieve as stakeholders interpret the requirements in different ways and there are often inherent
conflicts and inconsistencies in the requirements.

You might also like