UNIT II SOFTWARE REQUIREMENTS

CHAPTER 4: SOFTWARE REQUIREMENTS

--------------------------------------------------------------------------------------------
OBJECTIVES:
The objectives of this chapter are to introduce software system
requirements and to explain different ways of expressing software requirements.
When you have read the chapter, you will:
 Understand the concepts of user requirements and system.
 Requirements and why these requirements should be written in different
ways
 Understand the differences between functional and non-functional
software requirements;
 Understand how requirements may be organized in a software
requirements document

CONTENTS:
4.1 Functional and non-functional requirements
4.2 User requirements
4.3 System requirements
4.4 Interface specification
4.5 The software requirements document
4.6 Summary
4.7 Exercises

Prepared by: Dept. of CSE, RGMCET (Autonomous), Nandyal Page 1

UNIT II SOFTWARE REQUIREMENTS

Introduction
The requirements for a system are “the descriptions of the services provided by the
system and it’s operational constraints”. These requirements reflect the needs of customers for a
system that helps to solve some problems 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.
The term requirement is not used in the software industry in a consistent way. In some
cases, a requirement is simply a high-level abstract statement of a service that the system should
provide or a constraint on them. At the other extreme, “it is a detailed, formal definition of a
system function”.

Davis (1983) explains why these differences exist:

If a company wishes to let a contract for a large software project, it must define it’s needs
in a sufficiently abstract way that a solution is not predefined. The requirements must be written
so that several contractors can bid for the contract, offering, perhaps, different ways of meeting
the client organization’s needs. Once a contract has been awarded, the contractor must write a
system definition for the client in more details so that the client understands and can validate
what the software will do. Both of these documents may be called the requirements document for
the system.
Some of the problems that arise during the requirements engineering process are a result
of failing to make a clear separation between these different levels of description. We can
distinguish between them by using the term user requirements to mean the high-level abstract
requirements and system requirements to mean the detailed description of what the system
should do.

i) User requirements: These are the statements in a natural language plus diagrams, of what
services the system is expected to provide and the constraints under which it must operate.

ii) System requirements: system requirements specify the system’s functions, services and
operational constraints in detail. The system requirements document (i.e. Functional
specification) should be precise. It should define exactly what is to be implemented.
UNIT II SOFTWARE REQUIREMENTS

Different levels of system specification are useful because they communicate information
about the system to different types of readers. Figure 4.1 illustrates the distinction between user
and system requirements. This example from a library system shows how a user requirement
may be expanded into several system requirements. You can see from Figure 4.1 that the user
requirement is more abstract, and the system requirements add detail, explaining the services and
functions that should be provided by the system to be developed.
Fig 6.1 User and System Requirements
User requirement definition

1. LIBSYS shall keep track of all data required by copyright licensing agencies in the UK and
elsewhere.

System requirements specification

1.1 On making a request for a document from LIBSYS, the requestor shall be presented with
a form that records details of the user and the request made.
1.2 LIBSYS request forms shall be stored on the system for five years from the date of
the request.
1.3 All LIBSYS request forms must be indexed by user, by the name of the material
requested and by the supplier of the request.
1.4 LlBSYS shall maintain a log of all requests that have been made to the system.
1.5 For material where authors' lending rights apply, loan details shall be sent monthly
to copyright licensing agencies that have registered with LIBSYS.

You need to write requirements at different levels of details because different types of
readers use them in different ways. Figure 4.2 shows the different types of readers for the user
and system requirements. The readers of the user requirements are not usually concerned with
how the system will be implemented. The readers of system requirements need to know more
precisely what the system will do because they are concerned with how it will support the
business process or because they are involved in the system implementation.
UNIT II SOFTWARE REQUIREMENTS

Fig 4.2 Readers of different types of specifications

4.1 Functional and non-functional requirements

Software requirements are often classified into three categories:
i) Functional requirements
ii) Non-functional requirements
iii) Domain requirements.
i) Functional requirements: These are the 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.

ii) Non-functional requirements: These are the constraints on the services or functions offered
by the systems. They include timing constraints, constraints on the development process and
standards. Non–functional requirements often apply to the system as a whole. They do not
apply to the individual system features or services.

iii)Domain requirements: These are requirements that come from the application domain of the
system and that reflect characteristics and constraints on that domain. They may be
functional or non-functional.
UNIT II SOFTWARE REQUIREMENTS

In reality, the distinction between different types of requirements is not as clear-cut as

these simple definitions suggest. A user requirement concerned with security, say, may appear to
be a non-functional requirement. However, when developed in more detail, this requirement may
generate other requirements that are clearly functional, such as the need to include user
authentication facilities in the system.

4.1.1 Functional requirements

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, the requirements are usually described in a fairly abstract way. However,
the functional system requirements describe the system functions in detail, it’s inputs and
outputs, exceptions and so on. Functional requirements for a software system may be expressed
in number of ways.

Example: Functional requirements for a university library system called LIBSYS, used
by students and faculty to order books and documents from other libraries.
1) The user shall be able to search either all of the initial set of databases or select a
subset from it.
2) The system shall provide appropriate viewers for the user to read documents in the
document store.
3) Every order shall be allocated a unique identifier (ORDER_ID), which the user shall
be able to copy to the accounts permanent storage area.

These functional user requirements define specific facilities to be provided by the system.
These have been taken from the user requirements document, and they illustrate that functional
requirements may be written at different levels of detail.
Imprecision in the requirements specification is the cause of many software engineering
problems. It is natural for a system developer to interpret an ambiguous requirement to simplify
it’s implementation. New requirements have to be established and changes made to the system.
Of course, this delays system delivery and increases costs.
UNIT II SOFTWARE REQUIREMENTS

Consider the second example requirement for the library system that refers to
'appropriate viewers' provided by the system. The library system can deliver documents in a
range of formats; the intention of this requirement is that viewers for all of these formats should
be available. However, the requirement is worded ambiguously; it does not make clear that
viewers for each document format should be provided. A developer under schedule pressure
might simply provide a text viewer and claim that the requirement had been met.
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.
Note: In practice, for large, complex systems, it is practically impossible to achieve
requirements consistency and completeness.

4.1.2 Non-functional requirements

Non-functional requirements, as the name suggests, are the requirements that are not
directly concerned with the specific functions delivered by the system. They may relate to
emergent properties such as reliability, response time and store occupancy etc.
Non-functional requirements are rarely associated with individual system features.
Rather, they may specify system performance, security and other emerging properties. This
means that they are often more critical than individual functional requirements.
However, failing to meet a non-functional requirement can mean that the whole
system is unusable.
Examples:
i) If an aircraft system does not meet it’s reliability requirements, it will not
be certified as safe for operation;
ii) If a real-time control system fails to meet it’s performance requirements,
the control function will not operate correctly.
Non-functional requirements are not just concerned with the software system to be
developed. Some nonfunctional requirements may constrain the process that should be used to
develop the system. Examples of process requirements include a specification of the quality
standards that should be used in the process.
UNIT II SOFTWARE REQUIREMENTS

Non-functional requirements arise through user needs, because of budget constraints,

because of organizational policies, because of the need for interoperability with other software or
hardware systems, or because of external factors such as safety regulations or privacy legislation.
Figure 4.3 illustrates about the classification of non-functional requirements. You can see
from this diagram that the non-functional requirements may come from required characteristics
of the software (product requirements), the organization developing the software (organizational
requirements) or from external sources.

Fig 4.3 Types of Non-functional requirements

Fig 4.4 Examples of Non-functional requirements

UNIT II SOFTWARE REQUIREMENTS

[Link] Types of Non-functional requirements:

1) Product requirements:
These requirements specify product behavior. Examples include
i) Performance requirements on how fast the system must execute and how much
memory it requires;
ii) Reliability requirements that set out the acceptable failure rate;
iii) Portability requirements;
iv) Usability requirements.

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

3) External requirements:
This road category covers all requirements that are derived from factors external
to the system and it’ development process. These may include the following:
i) Interoperability requirements that define how the system interacts with the systems
in other organizations;
ii) Legislative requirements that must be fallowed to ensure that the system operates
with in the law.
iii) Ethical requirements are requirements placed on a system to ensure that it will be
acceptable to it’s users and the general public.
UNIT II SOFTWARE REQUIREMENTS

Figure 4.4 shows examples of product, organizational and external requirements taken
from the library system LIBSYS whose user requirements were discussed in Section 4.1.1.
The product requirement restricts the freedom of the LIBSYS designers in the
implementation of the system user interface. The organizational requirement specifies that the
system must be developed according to a company standard process defined as XYZCo-SP-
STAN-95. The external requirement is derived from the need for the system to conform to
privacy legislation. It specifies that library staff should not be allowed access to data, such as the
addresses of system users, which they do not need to do their job.
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 goals cause problems
for system developers as they leave scope for interpretation and subsequent dispute once the
system is delivered.
Non-functional requirements often conflict and interact with other functional or non-
functional requirements. For example, it may be a requirement that the maximum memory used
by a system should be no more than 4 Mbytes. Memory constraints are common for embedded
systems where space or weight is limited and the number of ROM chips storing the system
software must be minimized. Another requirement might be that the system should be written
using Ada, a programming language for critical, real-time software development. However, it
may not be possible to compile an Ada program with the required functionality into less that 4
Mbytes. There has to be a trade-off between these requirements: an alternative development
language or increased memory added to the system.
Non-functional requirements such as safety and security requirements are particularly
important for critical systems.
UNIT II SOFTWARE REQUIREMENTS

4.2 User requirements

The user requirements for a system should describe the functional and non functional
requirements so that they are understandable by system users without detailed technical
knowledge. They should only specify the external behavior of the system and should avoid, as
for as possible, system design characteristics.
If you are writing user requirements, you should not use software jargon, structured
notations or formal notations, or describe the requirement by describing the system
implementation. You should write user requirements in simple language, with simple tables and
forms and diagrams.
Below mentioned problems can arise, when requirements are written in natural language
sentences in a text document:
i) Lack of clarity: it is sometimes ‘difficult to use language in a precise and
unambiguous way without making the document wordy’ and ‘difficult to read’.
ii) Requirement confusion: functional and non-functional requirements and design
information may not be clearly distinguished.
iii) Requirements amalgamation: several different requirements may be expressed
together as a single requirement.
As an illustration of some of these problems, consider one of the requirements for the
library shown in Figure 4.5.
Figure 4.5 A user requirement for an accounting system in LIBSYS

LIBSYS shall provide a financial accounting system that maintains records of all accounting
system payments made by users of the system. System managers may configure this system.
So that regular users may receive discounted rates.

This requirement includes both conceptual and detailed information. It expresses the
concept that there should be an accounting system as an inherent part of LIBSYS. However, it
also includes the detail that the accounting system should support discounts for regular LIBSYS
users.

Prepared by: Dept. of CSE, RGMCET (Autonomous), Nandyal Page 10

UNIT II SOFTWARE REQUIREMENTS

4.2.1 Guidelines to minimize misunderstandings when writing user requirements:

1) Invent a standard format and ensure that all requirements definitions should be in
that format. Standardizing the format makes omissions less likely and requirements
easier to check.
2) Use language consistently. You should always distinguish between mandatory and
desirable requirements.
i) Mandatory requirements are requirements that the system must support and
are usually written using “shall”.
ii) Desirable requirements are not essential and are written using “should”.
3) Use text highlighting (i.e., bold, italic, color etc.) to pick out key parts of the
requirement.
4) Avoid, as far as possible, the use of Computer jargon.
Note:
Jargon € Words or Expressions that are used by a particular profession (or)
group of people, and are difficult for others to understand.

4.3 System requirements

System requirements are the expanded versions of the user requirements that are used by
the software engineers as the starting point for the system design. System requirements add
detailed information about how the user requirements should be provided by the system.
Ideally, the system requirements should simply describe the external behavior of the
system and it’s 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. You may have 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. This architectural definition is essential if you want to reuse software
components when implementing the system.
UNIT II SOFTWARE REQUIREMENTS

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 that the system is safe may specify that an
architectural design that has already been certified be used.

Natural language is often used to write system requirements specification as well as user
requirements. However, system requirements are more detailed than user requirements, natural
language specifications can be confusing and hard to understand:

1) Natural language understanding relies on the specification 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 specifications is over flexible. You can say the same
thing in completely different ways.
3) There is no way to modularize natural language requirements. It may be difficult to find all
related requirements. To discover the consequence of the change, you may have 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. It is essential to write the user requirements in a language that, even
a non-specialist can understand. However, you can write system requirements in more
sophisticated notations as shown below. These include stylished, structured natural language, and
graphical models of the requirements such as use-cases to formal mathematical specifications.
Notation Description
i) Structured natural This approach depends on defining
Language standard forms or templates to express
the requirements specification.

ii) Design description This approach uses a language like a

Language. Programming language but with more
abstract features to specify the requirements
by defining an operational model of the system.
UNIT II SOFTWARE REQUIREMENTS

iii) Graphical notations A graphical language, supplemented by text

annotation is used to define the functional
requirements for the system.
iv) Mathematical notations These are notations based on mathematical
concepts such as finite state machines or sets etc.

4.3.1 Structured language specifications

Structured natural language is a way of writing system requirements where the freedom
of the writer is limited and all the requirements are written in a standard format. The advantage
of this approach is that it maintains most of the expressiveness and understandability of natural
language, but it ensures that some degree of uniformity is imposed on the specification.
Structured language notations limit the terminology that can be used and use the templates to
specify the requirements.

[Link] Form-based approach to specifying the system requirements

An early project that used structured natural language for specifying system requirements
is described by Heninger (1980). Special-purpose forms were designed to describe the input,
output and functions of an aircraft software system. The system requirements were specified
using these forms.
UNIT II SOFTWARE REQUIREMENTS

Fig 4.6: System requirements indication using a standard form

To use these, you must define one or more standard forms or templates to express the
requirements. The specifications may be structured around the objects manipulated by the
system, the functions performed by the system or events processed by the system. An example of
such a form-based specification is shown in Figure 4.6.
When a standard form is used for specifying functional requirements, the fallowing
information should be included:
 Description of the function or entity being specified.
 Description of inputs and from where these inputs are coming.
 Description of it’s outputs and where these to go.
 Indication of what other entities are used (the requires part).
UNIT II SOFTWARE REQUIREMENTS

 If a functional approach is used, a pre-condition setting out on what must be true before
the function is called and a post condition specifying what is true after the function
called.
 Description of the side effects (if any) of the operation.
Using the formatted specifications removes some of the problems of natural language
specification. Variability in the specification is reduced and requirements are organized in more
effectively.
However, it is difficult to write requirements in an unambiguous way, particularly when
complex computations are required. You can see this in the description shown in Figure 4.6.
where it isn't made clear what happens if the pre-condition is not satisfied.
To address this problem, you can add extra information to natural language requirements
using tables or graphical models of the system. These can show how computations proceed, how
the system state changes, how users interact with the system and how sequences of actions are
performed.
Graphical models are most useful when you need to show how state changes or where
you need to describe a sequence of actions. Figure 4.7 illustrates the sequence of actions when a
user wishes to withdraw cash from an automated teller machine (ATM).
You should read a sequence diagram from top to bottom to see the order of the actions
that take place. In Figure 4.7, there are three basic sub-sequences:

1. Validate card: The user's card is validated by checking the card number and user's PIN.

2. Handle request: The user's request is handled by the system. For a withdrawal, the database
must be queried to check the user's balance and to debit the amount withdrawn. Notice the
exception here if the requestor does not have enough money in their account.

3. Complete transaction: The user's card is returned and, when it is removed, the cash and
receipt are delivered.
UNIT II SOFTWARE REQUIREMENTS

Fig. 4.7 Sequence diagram of withdrawal operation

UNIT II SOFTWARE REQUIREMENTS

4.4 Interface Specification:

Almost all software systems must operate with existing systems that have already been
implemented and installed in an environment. If the new and existing systems must work
together, the interfaces of existing systems have to be precisely specified. These specifications
should be defined early in the process and included in the requirements document.
There are 3 types of interfaces that may have to be defined.

1) Procedural interfaces, Here, existing programs or sub-systems offer a range of services

that are accessed by calling interface procedures. These interfaces are sometimes called
Application Programming Interfaces (APIs).
2) Data structures, which are passed from one sub-system to another. Graphical data
models are the best notations for this type of descriptions. If necessary, program
descriptions in java or C++ can be generated automatically from these descriptions.
3) Representations of data that have been established for an existing sub-system. These
interfaces are most common in embedded, real-time system. However, the best way to
describe these is probably to use a diagram of the structure with annotations explaining the
function of each group of bits.
UNIT II SOFTWARE REQUIREMENTS

4.5 The software requirements document

The software requirements document (sometimes called as 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. In other cases, the user requirements are defined in an introduction to the system
requirements specification. 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 that is paying for the system to the engineers responsible for
developing the software. Figure 4.8, illustrates possible users of the document and how they use
it.

Fig 4.8 Users of a requirements document

UNIT II SOFTWARE REQUIREMENTS

The diversity of possible users means that the requirements document has to be a
compromise between communicating the requirements to customers, defining the requirements
in precise detail for developers and testers, and including information about possible system
evolution.
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. When the system will
be developed by an external contractor, critical system specifications need to be precise and very
detailed. When there is more flexibility in the requirements and where an in-house, iterative
development process is used, the requirements document can be much less detailed and any
ambiguities resolved during development of the system.
A number of large organizations, such as the US Department of Defense and the IEEE,
have defined standards for requirements documents. Davis discusses some of these standards and
compares their contents. The most widely known standard is IEEE/ANSI 830- 1998. This IEEE
standard suggests the following structure for requirements documents:
1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations 1.4 References
1.5 Overview of the remainder of the document
Note: Abbreviations =>form a word or phrase that is shorter than it’s full form.
Acronym => formation of word or phrase with first letter. BSE is an acronym for
Bombay Stock Exchange.

2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
UNIT II SOFTWARE REQUIREMENTS

3. Specific requirements cover functional, non-functional and interface requirements.

This is obviously the most substantial part of the document but because of the wide variability
in organizational practice, it is not appropriate to define a standard structure for this section.
The requirements may document external interfaces, describe system functionality and
performance, specify logical database requirements, design constraints, emergent system
properties and quality characteristics.

4. Appendices

5. Index
Although the IEEE standard is not ideal, it contains a great deal of good advice on how to
write requirements and how to avoid problems. It is a general framework that can be tailored and
adapted to define a standard geared to the needs of a particular organization.
The information that is included in a requirements document must depend on the type of
software being developed and the approach to development that is used. If an evolutionary
approach is adopted for a software product (say), the requirements document will leave out many
of detailed chapters suggested above. The focus will be on defining the user requirements and
high-level, non-functional system requirements. In this case, the designers and programmers use
their judgment to decide how to meet the outline user requirements for the system.
By contrast, when the software is part of a large system engineering project that includes
interacting hardware and software systems, it is often essential to define the requirements to a
fine level of detail. This means that the requirements documents are likely to be very long and
should include most if not all of the chapters shown in Figure 4.9. For long documents, it is
particularly important to include a comprehensive table of contents and document index so that
readers can find the information that they need.

Prepared by: Dept. of CSE, RGMCET (Autonomous), Nandyal Page 20

UNIT II SOFTWARE REQUIREMENTS

Figure 4.9 illustrates a possible organization for a requirements document that is based on
the IEEE standard.
Fig 4.9 The structure of a requirements document
UNIT II SOFTWARE REQUIREMENTS

4.6 Summary
 Requirements for a software system set out what the system should do and define
constraints on its operation and implementation.
 Functional requirements are statements of the services that the system must provide or
are descriptions of how some computations must be carried out. Domain requirements are
functional requirements that are derived from characteristics of the application domain.
 Non-functional requirements constrain the system being developed and the development
process that should be used. They may be product requirements, organizational
requirements or external requirements. They often relate to the emergent properties of the
system and therefore apply to the system as a whole.
 User requirements are intended for use by people involved in using and procuring the
system. They should be written using in natural language, with tables and diagrams
that are easily understood.
 System requirements are intended to communicate, in a precise way, the functions that
the system must provide. To reduce ambiguity, they may be written in a structured form
of natural language supplemented by tables and system models.
 The software requirements document is the agreed statement of the system requirements.
It should be organized so that both system customers and software developers can use it.
 The IEEE standard for requirements documents is a useful starting point for more
specific requirements specification standards.
UNIT II SOFTWARE REQUIREMENTS

Exercises

1. Discover ambiguities or omissions in the following statement of requirements for part of

a ticket-issuing system.
An automated ticket-issuing system sells rail tickets. Users select their destination and
input a credit card and a personal identification number. The rail ticket is issued and their
credit card account charged. When the user presses the start button, a menu display of
potential destinations is activated, along with a message to the user to select a destination.
Once a destination has been selected, users are requested to input their credit card. Its
validity is checked and the user is then requested to input a personal identifier. When the
credit transaction has been validated, the ticket is issued.

2. Describe four types of non-functional requirements that may be placed on a system. Give
examples of each of these types of requirement.

3. Write a set of non-functional requirements for the ticket-issuing system, setting out its
expected reliability and its response time.

4. You have taken a job with a software user who has contracted your previous employer to
develop a system for them. You discover that your company's interpretation of the
requirements is different from the interpretation taken by your previous employer. Discuss
what you should do in such a situation. You know that the costs to your current employer
will increase if the ambiguities are not resolved. You have also a responsibility of
confidentiality to your previous employer.

XXXXXXXXXXXXXXXXXXXXXX COMPLETED XXXXXXXXXXXXXXXXXXXXXX