3.

Requirements amalgamation: Several different requirements may be expressed together

as a single requirement.
To minimize misunderstandings when writing user requirements, it is recommend to follow
some simple guidelines:
o Invent a standard format and ensure that all requirement definitions adhere to that
format. Standardizing the format makes omissions less likely and easier to check the
requirements.
o Include information about who proposed the requirement (the requirement source) so
that one knows whom to consult if the requirement has to be changed.
o Use language consistently. The mandatory and desirable requirements must always
be distinguished.
 Mandatory requirements are requirements that the system must support and
are usually written using ‗shall‘.
 Desirable requirements are not essential and are written using ‗should‘.
o Use text highlighting (bold, italic or colour) to pick out key parts of the requirement.
o Avoid, as far as possible, the use of computer terminologies.

SYSTEM REQUIREMENTS
System requirements are expanded versions of the user requirements that are used by the
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. They may be used as part of the contract for the
implementation of the system and should therefore be a complete and consistent specification of the
whole system.
Ideally, the system requirements should simply describe the external behaviour of the
system and its operational constraints. They should not be concerned with how the system should be
designed or implemented. However, at the level of detail required to completely specify a complex
software system, it is impossible, in practice, to exclude all design information.
 There are several reasons for this:
1. One has to design an initial architecture of the system to help structure the requirements
specification.
 The system requirements are organized according to the different sub-systems that
make up the system.
 The architectural definition is essential if software components are reused when
implementing the system.
2. In most cases, systems must interoperate with other existing systems.
 These constrain the design, and these constraints impose requirements on the new
system.
3. The use of a specific architecture to satisfy non-functional requirements may be
necessary.
 An external regulator who needs to certify whether the system is safe may utilize the
architectural design that has already been certified.
Natural language is often used to write system requirements specifications as well as user
requirements. However, because system requirements are more detailed than user requirements,
natural language specifications can be confusing and hard to understand for the following reasons:
1. Natural language understanding relies on the specification framed by the readers and writers
using the same words for the same concept.
 This leads to misunderstandings because of the ambiguity of natural language.
2. A natural language requirements specification is over flexible.
 One can say the same thing in completely different ways.
 It is up to the reader to find out when requirements are the same and when they are
distinct.
3. There is no easy way to modularize natural language requirements.
 It may be difficult to find all related requirements.
 To discover the consequence of a change, one has to look at every
requirement rather than at just a group of related requirements.
Because of these problems, requirements specifications written in natural language are
prone to misunderstandings. These are often not discovered until later phases of the software process
and may then be very expensive to resolve. Different levels of system specification are useful because
they communicate information about the system to different types of readers.
 SYSTEM REQUIREMENTS

Functional Requirements Non - Functional Requirements Domain Requirements

System requirements are often classified as functional requirements, nonfunctional

requirements or domain requirements:
1. Functional Requirements – that define the function of a software system or its component.
2. Non-functional Requirements – constraints on the services or functions offered by the entire
system
3. Domain Requirements – requirements of application domain of the system that reflect the
characteristics and constraints of that domain

1. FUNCTIONAL REQUIREMENTS
Functional Requirements are statements that define the function of a software system or its
components, its inputs, behavior, the outputs in detail. These are statements of the services provided by
the system, 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 do
and what the system should not do (do‘s & don‘ts of the system). These functional user requirements
define specific facilities to be provided by the system. These can be obtained from the User
Requirements Document (URD).
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 definitions.
In practice, for large, complex systems, it is practically impossible to achieve requirements
consistency and completeness.
 One reason for this is that it is easy to make mistakes and omissions when writing
specifications for large, complex systems.
 Another reason is that different system stakeholders have different needs.
These inconsistencies may not be obvious when the requirements are first specified, so
inconsistent requirements are included in the specification. The problems may only emerge after deeper
analysis or, sometimes, after development is complete and the system is delivered to the customer.

2. NON-FUNCTIONAL REQUIREMENTS
Non-functional Requirements are those requirements that are not directly concerned with the
specific functions delivered by the system. It describes the constraints on the services or functions
offered by the entire system. They include timing constraints, constraints on the development process
and standards.
Non-functional requirements are rarely associated with individual system features rather they may
specify system performance, security, availability, and other emergent properties. This means that they
are often more critical than individual functional requirements. 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.
 For example,
 o If an aircraft system does not meet its reliability requirements, it will not be certified as
safe for operation
o If a real-time control system fails to meet its performance requirements, the control
functions will not operate correctly.

Types of Non-Functional Requirements

 From the above diagram, it is obvious that the non-functional requirements may come from
o Required characteristics of the software (product requirements),
o The organization developing the software (organizational requirements) or
o From external sources (external requirements).
 The types of non-functional requirements are:
1. Product requirements
 Product requirements specify the behaviour of the product
 Examples include performance requirements on how fast the system must execute and
how much memory it requires;
i. Usability requirements.
ii. Reliability requirements that set out the acceptable failure rate and
iii. Portability requirements

2. Organizational requirements
 Organizational requirements are derived from policies and procedures in the
customer‘s and developer‘s organization.
 Examples include
i. Delivery requirements that specify when the product and its
documentation are to be delivered.
ii. Implementation requirements such as the programming language or
design method used and
iii. Process standards that must be used

3. External requirements
  External requirements cover all requirements that are derived from factors external to
the system and its development process.
 These may include
i. Interoperability requirements that define how the system interacts with
systems in other organizations;
ii. Legislative requirements that must be followed to ensure that the
system operates within the law; and ethical requirements.
iii. Ethical requirements are requirements placed on a system to ensure
that it will be acceptable to its users and the general public.

A common problem with non-functional requirements is that they can be difficult to verify.
Users or customers often state these requirements as general goals such as ease of use, the ability of
the system to recover from failure or rapid user response. These vague goals cause problems for
system developers which may lead to disagreement with the clients once the system is delivered. The
non-functional requirements must be written quantitatively so that they can be tested objectively.
However, customers for a system may find it practically impossible to translate their goals into
quantitative requirements.
o For some goals, such as maintainability, there are no metrics that can be used.
o In other cases, even when quantitative specification is possible, customers may not be able
to relate their needs to these specifications.
Therefore, Requirements Documents often include statements of goals mixed with
requirements. These goals may be useful to developers because they give indications of customer
priorities.
Metrics for Specifying Non-Functional Requirements

3. DOMAIN REQUIREMENTS
These are requirements that come from the application domain of the system that reflect the
characteristics and constraints of that domain. They usually include specialized domain terminology or
reference to domain concepts. They may be new functional requirements, constrain existing functional
requirements or it may be about how particular computations must be carried out. Because these
requirements are specialized, software engineers often find it difficult to understand how they are
related to other system requirements.
Domain requirements are important because they often reflect fundamentals of the application
domain. If these requirements are not satisfied, it may be impossible to make the system work
satisfactorily.
 The first requirement is a design constraint.
 The second requirement is the operational constraint.
The domain requirements specify how a computation has to be carried out, as taken from the
requirements specification specified in the requirements document

SOFTWARE REQUIREMENTS DOCUMENT (SRS)

The software requirements document (sometimes called the software requirements specification
or SRS) is the 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. In some
cases, the user and system requirements may be integrated into a single description.
If there are a large number of requirements, the detailed system requirements may be presented
in a separate document. The requirements document has a diverse set of users, ranging from the senior
management of the organization to the engineers responsible for developing the software. Figure
illustrates possible users of the document and how they use it.

A software requirements specification (SRS) is a document that captures complete description

about how the system is expected to perform. It is usually signed off at the end of requirements
engineering phase.

Qualities of SRS:
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable
How to write a requirements document:
1. Make an outline.
2. Define the purpose of your product.
3. Describe what you're building.
4. Detail the requirements.
5. Get it approved.

Types of Requirements:
The below diagram depicts the various types of requirements that are captured during SRS.
Goals
The Software Requirements Specification (SRS) is a communication tool between users and
software designers. The specific goals of the SRS are as follows:
 Facilitating reviews
 Describing the scope of work
 Providing a reference to software designers (i.e. navigation aids, document structure)
 Providing a framework for testing primary and secondary use cases
 Including features to customer requirements
 Providing a platform for ongoing refinement (via incomplete specs or questions)
Structure
An example organization of an SRS is as follows
1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces
2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory Constraints
2. Design constraints
1. Operations
2. Site Adaptation Requirements
3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Functional requirements
3. Performance requirements
4. Logical database requirement
5. Software System Attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
6. Functional requirements
1. functional partitioning
2. functional description
 3. control description
7. Environment characteristics
1. Hardware
2. peripherals
3. people
8. Appendices
9. Index
The structure of the requirements document includes the following chapters as described below,
Examples of SRS:
1. Library Management System
2. Coffee vending machine
3. Employee Payroll System
4. Student Information System
5. Supermarket Billing system
6. Student Result Analysis
7. Online Shopping system
8. So on.

REQUIREMENT ENGINEERING PROCESS

Requirements Engineering (RE) refers to the process of formulating, documenting and
maintaining requirements in the engineering design process. Requirement engineering provides the
appropriate mechanism to understand what the customer desires, analyzing the need, and assessing
feasibility, negotiating a reasonable solution, specifying the solution clearly, validating the specifications
and managing the requirements as they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and notation to describe a
proposed system's intended behavior and its associated constraints.
Requirement engineering tasks:
1. Inception - Inception is a task where the requirement engineering asks a set of questions to
establish a software process. In this task, it understands the problem and evaluates with the
proper solution. It collaborates with the relationship between the customer and the developer.
The developer and customer decide the overall scope and the nature of the question.
2. Elicitation - Elicitation means to find the requirements from anybody. The requirements are
difficult because the following problems occur in elicitation.
 Problem of scope: The customer give the unnecessary technical detail rather than
clarity of the overall system objective.
 Problem of understanding: Poor understanding between the customer and the
developer regarding various aspect of the project like capability, limitation of the
computing environment.
 Problem of volatility: In this problem, the requirements change from time to time and it
is difficult while developing the project.
3. Elaboration - In this task, the information taken from user during inception and elaboration and
are expanded and refined in elaboration. Its main task is developing pure model of software
using functions, feature and constraints of a software.
4. Negotiation - In negotiation task, a software engineer decides the how will the project be
achieved with limited business resources. To create rough guesses of development and access
the impact of the requirement on the project cost and delivery time.
5. Specification - In this task, the requirement engineer constructs a final work product. The work
product is in the form of software requirement specification. In this task, formalize the
requirement of the proposed software such as informative, functional and behavioral. The
requirement are formalize in both graphical and textual formats.
6. Validation - The work product is built as an output of the requirement engineering and that is
accessed for the quality through a validation step. The formal technical reviews from the
software engineer, customer and other stakeholders helps for the primary requirements
validation mechanism.
7. Management - It is a set of activities that help the project team to identify, control and track the
requirements and changes can be made to the requirements at any time of the ongoing project.
These tasks start with the identification and assign a unique identifier to each of the requirement.
After finalizing the requirement traceability table is developed. The examples of traceability table
are the features, sources, dependencies, subsystems and interface of the requirement.