Software

Software Project Requirements

6 Project Requirements NOTES

Chapter Includes :
• Software Requirements
• Functional And Non-Functional Requirements
• User Requirements
• System Requirements
• Software Requirements Document

SOFTWARE REQUIREMENTS
It has been shown in various process models that a successful development process
involves several key activities. Every process model includes one such activity that
determines the product requirements. These requirements enable the software engi-
neer to understand the expectations of the customers from the proposed product. It
is a statement of services and constraints that the software product needs to satisfy.
IEEE defines requirement as “A condition or capability that must be met or possessed
by a system to satisfy a contract, standard, specification or other formally imposed
document”. The software requirements can be categorized as :
a) User requirements : The client provides the description of services required
and constraints under which the system must operate smoothly. The state-
ments of services and constraints are recorded in textual or graphical forms.
b) System requirements : It is also known as functional specification. It is an
elaboration of services and constraint statements. This document must be
prepared with preciseness as it may form a part of the contract.
c) Software design specification : It is a brief outline of the software design that
forms a basis for the detailed design and implementation.
The requirements phase finally leads to the Software Requirements Specification 87
(SRS). Thus, the basic goal of requirements phase is to produce the SRS.
Software Readers of different types of requirements specification
Engineering
User requirements Client managers, system end-users, client engineers,
contractor managers, system architects.
NOTES System requirements System end-users, system architects, client engineers,
software developers.
Software design specification Client engineers, system architects, software
developers.

Needs of Requirements
The requirements serve three important purposes:

➤ The requirements enable the software engineers to understand the customer’s

expectations from the system.

➤ The requirements convey to the developer, the functionality and character-

istics the resultant system shall have.

➤ The requirements help the test team in presenting the system to the client
in a convincing manner.

Characteristics of requirements
In order to ensure that the software engineers and customers understand and use
these requirements correctly, it is necessary that requirements should be of high
quality. To ensure the same, the requirements can be checked for the following
characteristics:
➤ Correctness : Customer and developer should ensure that requirements are stated
without error.
➤ Consistency : All requirements should be free from ambiguities.
➤ Completeness : It ensures that all possible conditions, input, products and con-
straints have been included.
➤ Realistic : All the requirements must be examined to ensure that they are pos-
sible.
➤ Verifiability : It must be possible for the software engineer to demonstrate that
the requirements have been met.

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

The system requirements can be classified as:
➤ Functional requirements
➤ Non-functional requirements
➤ Domain requirements
These are explained below :
Functional Requirements
The functional requirements describe an interaction between the system and its
environment. It is a statement expected from a system. These are statements of
services, behavior of system with particular input, in particular situations and output
88 of the system with different input. The software development group should ensure
that the functional requirements are correct, complete, consistent and unambiguous.
In large and complex systems, it is difficult to achieve consisted and complete Software
requirements. During reviews, more requirements may be discovered which should Project Requirements
be added to requirements document.
The functional requirements can be summarized as below :
NOTES
➤ Types of input and their constraints
➤ Types of output and their constraints
➤ Nature of computations
➤ Timing and synchronization of all of the above

Non-Functional Requirements
Non-functional requirements refer to the constraints or restrictions on the system.
These constraints may narrow the selection of language, platform, implementation
techniques and tools. The non-functional requirements may sometimes be more
critical than the functional requirements as they may relate to the total system rather
than to individual system features. The non-functional requirements can be built on
the basis of needs of the user, budget constraints, organizational policies, inter-
operability and external factors like safety and privacy considerations.
The non-functional requirements can be listed as follows:

➤ Response time
➤ Throughput
➤ Resource usage
➤ Reliability
➤ Availability
➤ Recovery from failure
➤ Ease for maintainability and enhancement
➤ Allowances for reusability
➤ Platform to be used
➤ Technology to be used
➤ Development process
➤ Cost and delivery data

The non-functional requirements can be classified as:

a) Product requirements : These requirements specify product behavior such as
reliability, portability, usability, performance, space requirements etc.
b) Organizational requirements : These requirements specify the process stan-
dards, design methods and programming languages used by the developer
organization. These also specify when the product and its documentation are
to be delivered.
c) External requirements : External requirements include all the requirements
that may arise from the external factors. These include interoperability re-
quirements that define the compatibility of proposed system with other
systems, legislative requirements to ensure that the product complies with
89
the state legislations, and ethical requirements to ensure social acceptability.
Software The non-functional requirements are difficult to verify and can be misinterpreted by
Engineering users. Each non-functional requirement should be attached with related system goal.
Thus, it can be verified by testing whether the system has met the customer’s goals
or not. These goals are useful for developers to understand the customers’ priorities.
NOTES For example,

➤ A System Goal : The system should be easy to use and users’ errors should
be minimized.
➤ A verifiable non-functional requirement : Two days of training should be
enough to use all the system functions and average number of errors made
by users shall not exceed two errors per day. Non-functional requirements
should be expressed and measured by using metrics. A number of possible
metrics to specify non-functional system properties is given in the following
Table. System requirements should be calculated quantitatively and measures
can be made during system testing.

Property Measure
Speed Processed transactions/second,
User/event-response time,
Screen refresh time.
Size Kbytes
Number of RAM Chips
Ease of use Training time, Number of help frames
Reliability Mean time to failure,
Probability of unavailability,
Rate of failure occurrence, Availability.
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure.
Portability Percentage of target-dependent statements
Number of target systems.

Table : Metrics for specifying non-functional requirements

Normally, functional and non-functional requirements should be differentiated in a

requirements document, but practically it is difficult. Developers should take care of
requirements as a whole and they should be able to balance both types of require-
ments.

Domain Requirements
These requirements are derived from the application domains employed in the de-
sign of the system. This may add a new set of functional requirements to the existing
fist. It may also pose new constraints on the system design. It is essential to satisfy
these requirements as they may affect the capability of the system.

USER REQUIREMENTS
User requirements are expressed in natural language and may be supported with
figures and diagrams. It must easily be understandable by the people who may not
have sound computer knowledge. Users’ requirements comprise of both functional
90 and non-functional requirements for a proposed system. These requirements should
specify only the external behavior of the system. Inclusion of system design charac- Software
teristics may be avoided. Project Requirements
The use of natural language in describing the users’ requirements has the following
drawbacks:
NOTES
a) Lack of clarity : The natural language may lack the technical clarity and
preciseness.
b) Requirements confusion : The user requirements description in natural lan-
guage may not present the functional and non-functional requirements and
system goals etc. in a distinct manner.
c) Requirements amalgamation : A set of requirements may sometime be amal-
gamated into a single requirement.
Guidelines for writing user requirements :

➤ Use standard format for describing all the requirements. It will minimize the
omission and simplifies the task of requirements verification.
➤ Impose consistency in language to distinguish between the mandatory and
desirable requirements.
➤ Distinguish the important parts of requirements using text highlighting.
➤ Use reader friendly language by avoiding complex terminologies and phrases.
➤ User requirements should be separated from more detailed system require-
ments in a requirements document to make it readable for nontechnical
readers.
Example : If a railway reservation system is to be developed, the following can be
the different types of requirements:
1. Functional requirements

➤ How information about trains, passengers, bookings are entered - Input.

➤ What information appears on tickets and reports - Output.
➤ How fares are calculated - Computation.
➤ What information must be stored in the database that travel agents and
other can access - Data storage.
2. Non-functional requirements

➤ The system must be available at all times. Downtime of only two minutes
a week is to be permitted - Availability.
➤ Response time should be short - Efficiency.
➤ System should not produce incorrect results - Reliability.
3. Domain requirements

➤ The system should be designed to be extended to handle any number of

trains and related information - Allowance for enhancement (non-functional).

➤ Any type of query about trains such as timings availability of reservation, 91

fares should be available - Output (functional).
Software 4. User-interface requirements
Engineering
➤ All query screens should have similar and consistent format.
➤ Users should be allowed to select the options instead of feeding more data
NOTES manually.

SYSTEM REQUIREMENTS
A detailed description of user requirements results in system requirements. They
serve as basis for starting the system design. System requirements must be complete
and consistent as they may form a part of the contract for system implementation.
System requirements only reveal the system’s functions that are supposed to be
performed and which can be shown by different models such as data flow model and
object model. These requirements do not state function’s implementation. But prac-
tically, it is not possible to separate requirements and design completely. The follow-
ing are the reasons for this:

➤ The initial architecture of the system is useful in framing the requirements

specifications of sub-systems.
➤ The proposed system must inter-operate with other existing systems and
such constraints result in additional requirement for the new system.
➤ The use of a specific design may be an external system requirement.
The system requirements specification is generally described in natural language.
However, the use of natural language may pose following difficulties:

➤ While using a natural language, it is assumed that there will not be any
deviation in interpretation of the words used in system requirements.
➤ Using natural language, a particular specification can be written in different
ways. Such descriptions may be misinterpreted.
➤ It is difficult to write the related requirements in form of groups.
Thus, requirements specifications written in natural language may lead to misunder-
standings. At later stage of the process, it is very expensive to resolve these misun-
derstandings. Following table shows various alternatives to natural language.
Notation Description
Structured natural language This relies on standard forms or templates to
describe the requirements specifications.
Design description language The requirements are specified by defining an
operational model of the system with more
abstract features by using PDL.
Graphical notation The functional requirements of the system are
defined by using a graphical language support
by text annotations (example SADT, usecase
description).
Mathematical specifications This approach uses a mathematical concept such
as finite state machines or sets, to define the
system specifications without any ambiguities,
but it is hard to be, understood by non-techni-
92
cal customers.
Table : Notations for requirements specifications
Structured Language Specifications Software
Project Requirements
The limitation of a natural language can be overcome by using structured natural
language. The use of structured natural language brings uniformity in description of
system requirements and minimizes the ambiguities. The language retains the salient NOTES
qualities of natural language such as expressiveness and understandability. The struc-
tured language may derive notation and format to specify the system requirements,
and certain features of programming languages may also be incorporated. This will
help uniting the use of various terminologies from the natural language.
While using the structured language, the software developers can design special
purpose forms to specify the system requirements. This approach requires more than
one form to describe the requirements. The specifications of the system may be
structured around the objects, functions or the events.
The standard form used for specifying functional requirements should contain de-
scription of following information:
➤ Functions specified
➤ Input and their sources
➤ Output and their destination
➤ Pre and post condition in a functional approach
➤ Side-effects of the operation

The formatted specification overcomes some of the drawbacks of the natural language
specification as the variability in specification is reduced and requirements are ex-
pressed more effectively.

Requirements Specification using a PDL

More structured notations such as Programme Description Language (PDL) can be
used to avoid ambiguities in specification fisting. PDL is derived from a program-
ming language like Java Ada, C++ etc. Following figure shows detailed specifications
for few modules (character counts) with the flavor of C++.

Void perform-char-count ()
{
string validated-file-name
int char-count;
If (get-input (validated-file-name) is false)
Print “error message: file does not exist”;
else
{
Set char-count equal to count-number-of -chars (validated-file-name);
if (char-count is equal to -1)
print “error message: file is not a text file”; Check Your Progress
else 1. What is requirment?
produce-output (char-count); 2. What re non-technical
requirements?
}
} 93
boolean get-input (string validated-file-name) {
Software string file-name;
Engineering file-name = read-file-name ();
if (validated-file-name (file-name) is true)
{
NOTES
set validated-file-name equal to file-name; return true;
}
else
return false;
}

Figure 6.1 : PDL representation

Advantages of using PDL

➤ PDL provides a detailed specification.
➤ It can be checked syntactically and semantically by software tools.
➤ Requirements omission and inconsistencies can be identified.
➤ Requirements specification is less ambiguous and easy to understand.
➤ Possibilities of misinterpretation are reduced.
➤ The transition from requirement to design is natural, as PDL is based on the
implementation language.
➤ It is useful when an operation is specified as an orderly sequence of actions,
nested conditionals and loops which cannot be described by natural lan-
guage.
➤ Interface between subsystems and interface between hardware and software
can easily be described by PDL.

Disadvantages of using PDL

➤ The language may lack expressiveness to describe system functionality.
➤ Non-specialists may find difficulties in understanding the notations.
➤ The requirements specification may be treated as design rather than the basis
of understanding the system.
The software developer can arrive at more effective approach by combining the
beneficial features of structural natural language with PDL. The developer can use
form based approach for specifying the overall system and PDL to define the control
sequence or interface in detail.

Interface Specification
Any new software system must be designed to work with the system that already
exists in the environment. This makes it necessary that the interfaces of existing
systems are precisely denned and included in requirements document early in the
development process.
There are three types of interfaces:
1. Procedure interfaces : When sub-systems offer various services and these
94
services are implemented by different procedures. The procedural interfaces
should be well denned.
 2. Data structure interfaces between subsystems : A Java based PDL or entity Software
relationship diagrams can be used to define the interface and passing the Project Requirements
data structure from one subsystem to another.
3. Representation of data : Data which is already established for an existing
subsystem should be represented for new system in a consistent way. NOTES

SOFTWARE REQUIREMENTS DOCUMENT

It is also referred as Software Requirements Specification (SRS). It is a technical
specification of the requirements for the software product. The objective of require-
ments document is to describe the technical requirements of the software product in
complete, consistent and unambiguous manner. Depending on the scale and com-
plexity of the software product, the size of software requirements document may vary
from few pages to several volumes.

Users of Requirements Document

The software requirements document serves the needs of various users as shown in
Table.
User Purpose

System customers To specify the requirements.

To check if they meet customer’s needs.
To suggest changes if necessary.

Development manager To bid for the system.

To plan the development process.

System engineers To understand the type of system to be developed.

Test engineers To develop the validation tests.

Maintenance engineers To understand the relations between the system and

its parts.
Table : Users of a requirements document

Characteristic Features of Software Requirements Document

There are seven characteristic properties of Software requirements document as iden-
tified by the IEEE. These are:
➤ A software requirements specification (SRS) is correct if every requirement of
the Requirements description and definition (RDD) is represented in it. It
is complete when it specifies fully all the responses required to deliver the
functions and features in RDD.
➤ The SRS is unambiguous, if it has one and only one interpretation.
➤ The SRS should be verifiable to ensure that software can deliver precisely Check Your Progress
what is stated in the RDD. 3. What is SPS?
➤ The SRS should be consistent vis-a-vis other specifications. The inconsistency 4. What is to included in
and conflict may occur due to ignorance of constraints and pre-conditions. requirement docu-
ments?
➤ The SRS should classify and rank the specifications according to their im-
portance. The categorization should be core and stable, critical and unstable,
95
non-critical and stable specifications.
Software ➤ The SRS should be easily modifiable, presenting consistency and complete-
Engineering ness. This could be done with cross-reference to the specifications, so that if
one is modified, the other also gets modified.
➤ The ACID test of a good SRS is in traceability to RDD.
NOTES Heninger has suggested that an ideal software requirements document should satisfy
six requirements.
➤ It should specify only external system behavior.
➤ It should specify constraints on the implementation.
➤ It should be easy to change.
➤ It should serve as a reference tool for system maintainers.
➤ It should record forethought about the life cycle of the system.
➤ It should characterize acceptable responses to undesired events.
Structure of a Requirements Document
The requirements document must include all the requirements of the system in a
clear and concise manner. This requires that the document is systematically orga-
nized as sections and subsections. Many methods and standards have been suggested
to structure a requirements document; Standardized format minimizes the possibility
of omissions and makes the document easily understandable. The general structure
of requirements document suggested by IEEE is given in the figure 6.2.
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
2.6 Requirements subsets
3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 User class 1
3.2.1.1 Functional requirements 1.1
3.2.1.2 Functional requirements 1.2
3.2.2 User class 2
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
4. Appendices
5. Index
96
Figure 6.2 : Structure of a requirements document
IEEE standard provides well structured guidelines to write the software require- Software
ments. Organizations can adopt these standards with suitable modifications, if nec- Project Requirements
essary. The information included in the document will depend on the type of
product being developed and the development approach adopted.
The requirements document for a product being developed using Evolutionary model NOTES
may skip some parts of the recommended format whereas software for large system
engineering project will require defining the requirements to their finest level.
The following table illustrates a typical organization for a requirements document
based on the IEEE standards.

Chapter Description
Preface This section should define the intended reader
ship. The history of the present version and
rationale for creating a new version should be
described. Summary of changes should be included.
Introduction This part should describe the need for the system.
The functions of the system should be briefly
described. It should describe how the new system
fits into the overall business objective of the
organization.
Glossary This should define all technical terms used in the
document.
User requirements In this section, users’ and non-functional require-
ments should be dedefinition scribed using natural
language and other notations. Product and process
standard must be specified.
System architecture This section provides a high-level view of the
anticipated system architecture. Distribution of
functions across system modules should be described
and reused components must be highlighted.
System requirements This part should contain detailed description of
functional and and specifications nonfunctional
requirements.
System models This section should include system models used
for representing relationship between the system
components and the system, and its environment.
The system models may be object model, data flow
model etc.
System evolution This part describes the fundamental assumptions
on which the system is based. It should also
include anticipated changes, changing user needs
etc.
Appendices This section provides detailed, specific information
related to the application being developed.
Appendices may be on topics like hardware
description, data base description, requirements for
system configurations etc.
Index It should include indexes of diagram, functions etc.
in alphabetical order.
97
Software SUMMARY
Engineering • Requirement is a condition or capability that must be met or possessed by
a system to satisfy a contract, standard, specification or other formally im-
posed document
NOTES • The functional requirements describe an interaction between the system and
its environment. It is a statement expected from a system. These are state-
ments of services, behavior of system with particular input, in particular
situations and output of the system with different input.
• Non-functional requirements refer to the constraints or restrictions on the
system. These constraints may narrow the selection of language, platform, imple-
mentation techniques and tools. The non-functional requirements may some-
times be more critical than the functional requirements as they may relate to the
total system rather than to individual system features.
• The non-functional requirements are difficult to verify and these can be misin-
terpreted by users.
• Domain requirements are derived from the application domains employed in the
design of the system.
• User requirements are expressed in natural language and may be supported with
figures and diagrams. It must easily be understandable by the people who may
not have sound computer knowledge.
• A detailed description of user requirements results in system requirements. They
serve as basis for starting the system design. System requirements must be
complete and consistent as they may form a part of the contract for system
implementation.
• SRS a technical specification of the requirements for the software product.
• The requirements document must include all the requirements of the system in
a clear and concise manner.
ANSWERS TO "CHECK YOUR PROGRESS"
1. Requirement is a condition or capability that must be met or possessed
by a system to satisfy a contract, standard, specification or other formally
imposed document.
2. The non-functional requirements are difficult to verify and these can be
misinterpreted by users.
3. SRS a technical specification of the requirements for the software
product.
4. The requirements document must include all the requirements of the
system in a clear and concise manner.
EXERCISES
1. What are the differences between requirements definition and requirements
specification?
2. What are the different levels of software requirements? Who are the users of these
requirements?
3. Describe different software requirements with examples.
4. Explain briefly different notations for requirements specifications.
5. How can requirements be specified using a PDL? Give an example.
98 6. Explain the characteristic features of a software requirements document.
7. Explain the structure of a software requirements document.