CHAPTER -3

Requirement and Specifications

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).

The term ‘requirement’ is not used consistently in the software industry. In some cases, a
requirement is simply a high-level, abstract statement of a service that a system should
provide or a constraint on a system.
Types of requirement
1. User requirements: Statements in natural language plus diagrams of the services the
system provides to users and the constraints under which it must operate.
2. System requirements: A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. The system requirements document
(sometimes called a functional specification) should define exactly what is to be
implemented.
3. Software specification: A detailed software description which can serve as a basis for a
design or implementation. Written for developers
Functional and non-functional requirements
Software system requirements are often classified as functional requirements or non-
functional 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.
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.
3. Domain requirements: Requirements that come from the application domain of the
system and that reflect characteristics of that domain.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 1

 CHAPTER -3

1. 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.
However, more specific functional system requirements describe the system functions, its
inputs and outputs, exceptions, etc., in detail.
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. For example, here are examples of functional requirements for the MHC-
PMS system, used to maintain information about patients receiving treatment for mental
health problems:
1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are expected to
attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her eight-digit
employee number.
Problems arise when functional requirements are not precisely (Accurately) stated.
Ambiguous requirements may be interpreted in different ways by developers and users.
Consider the term ‘search’ in requirement 1
 User intention – search for a patient name across all appointments in all clinics;
 Developer interpretation – search for a patient name in an individual clinic. User
chooses clinic then search.
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.
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

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 2

 CHAPTER -3

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
characteristics of the system as a whole. Non-functional requirements may be more critical
than functional requirements. If these are not met, the system is useless. For example, if an
aircraft 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.
The implementation of these requirements may be diffused (Spread Over) 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.
Types of non-functional requirement

 Product requirements
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements, etc.
 External requirements

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 3

 CHAPTER -3

 Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative
requirements, etc.
Domain requirements
 Derived from the application domain and describe system characteristics and features
that reflect the domain
 May be new functional requirements, constraints on existing requirements or define
specific computations
 If domain requirements are not satisfied, the system may be unworkable

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. 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 a large number of
requirements, the detailed system requirements may be presented in a separate document.
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 fig shows possible users of the document and how they use it.

Naturally, the information that is included in a requirements document depends on the type of
software being developed and the approach to development that is to be used.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 4

 CHAPTER -3

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.
However, when the software is part of a large system project that includes interacting
hardware and software systems, it is usually necessary to define the requirements to a fine
level of detail.

Requirements specification
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.
The user requirements for a system should describe the functional and non-functional
requirements so that they are understandable by system users who don’t have detailed
technical knowledge. Ideally, they should specify only the external behaviour of the system.
The requirements document should not include details of the system architecture or design.
Consequently, if you are writing user requirements, you should not use software jargon,
structured notations, or formal notations. You should write user requirements in natural
language, with simple tables, forms, and intuitive diagrams.
System requirements are expanded versions of the user requirements that are used by
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 therefore it should be a complete and
detailed 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. Ways of writing
system requirements specification.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 5

 CHAPTER -3

To minimize misunderstandings when writing natural language user requirements, that

you follow some simple guidelines:
1. Invent a standard format and ensure that all requirement definitions adhere to that
format.
2. Use language consistently to distinguish between mandatory and desirable
requirements. 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’.
3. Use text highlighting (bold, italic, or color) to pick out key parts of the requirement.
4. Do not assume that readers understand technical software engineering language. It is
easy for words like ‘architecture’ and ‘module’ to be misunderstood. You should,
therefore, avoid the use of jargon, abbreviations, and acronyms.

Requirements engineering processes

Requirement engineering is process that involves all the activities required to create and
maintain a system requirements document. Processes used to discover, analyse and validate
system requirements.
Requirements engineering processes may include four high-level activities.
1. Feasibility Study
2. Requirements elicitation and analysis

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 6

 CHAPTER -3

3. Requirements specification
4. Requirements validation
The processes used for RE widely depending on the application domain, the people involved
and the organisation developing the requirements.

Feasibility Study
For all new systems, the requirements engineering process should start with a feasibility
study. The input to the feasibility study is a set of preliminary business requirements, an
outline description of the system and how the system is intended to support business
processes. The results of the feasibility study should be a report that recommends whether or
not it is worth carrying on with the requirements engineering and system development
process. i.e A feasibility study decides whether or not the proposed system is worthwhile
It is a short and focused study that checks
 If the system contributes to organisational objectives
 If the system can be engineered using current technology and within budget
 If the system can be integrated with other systems that are used
Requirements elicitation and analysis
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 people in an organisation. It
may involve end-users, managers, engineers involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders. The term stakeholder is used to refer to any person
or group who will be affected by the system, directly or indirectly.
Elicitation and analysis of stakeholder requirements is difficult for several reasons:

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 7

 CHAPTER -3

 Stakeholders often don't know what they want from the computer system except in the
most general terms.
 Stakeholders naturally express requirements in their own terms and with implicit
knowledge of their own work.
 Different stakeholders have different requirements, which they may express in
different ways.
 Political factors may influence the requirements of the system. For example,
managers may demand specific system requirements that will increase their influence
in the organisation.
 The economic and business environment in which the analysis takes place is dynamic.
A very general process model of the elicitation and analysis process is shown in Figure.

The Process activities are:

1. Domain understanding: Analyst must develop the understanding of the application
domain.
2. For ex: If the system is required for supermarket then analyst must find out how the
supermarket operates.
3. Requirements collection: This is the process of interacting with stakeholders in the
system to collect their requirements.
4. Requirements classification and organisation: This activity takes the unstructured
collection of requirements, groups related requirements and organises them into
coherent clusters.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 8

 CHAPTER -3

5. Conflict resolution: As multiple stakeholders are involved, requirements will conflict.

This activity is concerned with finding and resolving these conflicts.
6. Requirements prioritisation: This activity is concerned with prioritising the
requirements by interacting with stakeholders.
7. Requirements checking: The requirements are checked for completeness and
consistency as per the stakeholder.

Viewpoint-oriented elicitation
Stakeholders represent different ways of looking at a problem or problem viewpoints. This
multi-perspective analysis is important as there is no single correct way to analyse system
requirements.
Viewpoint-oriented approaches to requirements engineering organise both the elicitation
process and the requirements themselves using viewpoints. A key strength of viewpoint-
oriented analysis is that it recognises multiple perspectives and provides a framework for
discovering conflicts in the requirements proposed by different stakeholders.
Types of viewpoint (Viewpoint can be considered as).
Data sources or sinks
• In this case Viewpoints are responsible for producing or consuming data. Analysis involves
checking that data is produced and consumed and that assumptions about the source and sink
of data are valid.
Representation frameworks
• Viewpoints represent particular types of system model. These may be compared to discover
requirements that would be missed using a single representation. Particularly suitable for
real-time systems.
Receivers of services
• Viewpoints are external to the system and receive services from it. Most suited to
interactive systems.

Method-based analysis
This is widely used approach to requirements analysis. It depends on the application of a
structured method to understand the system.
A viewpoint-oriented method (VORD) is used as an example here. This has been designed
for as a service oriented framework for requirement elicitation and analysis.
The stages of The VORD method are shown in below fig

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 9

 CHAPTER -3

1. Viewpoint identification
It involves discovering viewpoints which receive system services and identify the
services provided to each viewpoint.
2. Viewpoint structuring
It involves grouping of related viewpoints into a hierarchy. Common services are
provided at higher-levels in the hierarchy.
3. Viewpoint documentation
It involves refining the description of the identified viewpoints and services.
4. Viewpoint-system mapping
Transform the analysis to an object-oriented design

Scenarios
People usually find it easier to relate to real-life examples than to abstract descriptions.
Scenarios are descriptions of how a system is used in practice. They are helpful in
requirements elicitation as people can relate to these more readily than abstract statement of
what they require from a system.
Scenarios are particularly useful for adding details to summarize the requirements
description. The scenario starts with a summary of the interaction, and, during elicitation,
details are added to create a complete description of that interaction.
Most general, a scenario may include:
I. A description of what the system and users expect when the scenario starts
2. A description of the normal flow of events in the scenario
3. A description of what can go wrong and how this is handled
4. Information about other activities that might be going on at the same time
5. A description of the system state when the scenario finishes.
Event scenarios
Event scenarios may be used to describe how a system responds to the occurrence of some
particular event such as ‘start transaction’.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 10

 CHAPTER -3

Use cases
Use-cases are a scenario-based technique for requirements elicitation which were first
introduced in the Objectory method (Jacobsen, et al., 1993).
They have now become a fundamental feature of the UML notation for describing object
oriented system models. In their simplest form, a use-case identifies the type of interaction
and the actors involved. Use-cases identify the individual interactions with the system. They
can be documented with text or linked to UML models that develop the scenario in more
detail.
Actors in the process are represented as stick figures, and each class of interaction is
represented as a named ellipse.
Sequence diagrams may be used to add detail to use-cases by showing the sequence of event
processing in the system.

Use cases for the library system

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 11

 CHAPTER -3

System interactions for article printing

Requirements validation
Requirements validation is concerned with showing that the requirements actually define the
system that the customer wants. Requirements validation is important because errors in a
requirements document can lead to extensive rework and high costs when they are discovered
during development or after the system is in service.
The cost of fixing a requirements problem by making a system change is much greater than
repairing design or coding errors.
During the requirements validation process, checks should be carried out on the requirements
in the requirements document. These checks include:
 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. Does the system provide the functions which best support
the customer’s needs?
 Consistency checks: Requirements in the document should not conflict. That is, there
should be no contradictory constraints or descriptions of the same system function.
 Completeness checks: The requirements document should include requirements,
which define all functions, and constraints proposed by the system user.
 Realism checks: Using knowledge of existing technology, the requirements should be
checked to ensure that they could actually be implemented.
 Verifiability To reduce the potential for dispute between customer and contractor,
system requirements should always be written so that they are verifiable.
Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 12
 CHAPTER -3

System modelling
System modelling is the process of developing abstract models of a system, with each model
represents a different view or perspective of that system. System modelling generally meant
to represent the system using some kind of graphical notation, which is now almost always
based on notations in the Unified Modelling Language (UML).
System modelling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.
You may develop different models to represent the system from different perspectives. For
example:
1. An external perspective, where the context or environment of the system is modelled
2. A behavioural perspective, where the behaviour of the system is modelled
3. A structural perspective, where the architecture of the system or the structure of the data
processed by the system is modelled
Examples of the types of system models that you might create during the analysis process
are:
1. A data- flow model: Data-flow models show how data is processed at different stages in
the system.
2. A composition model: A composition or aggregation model shows how entities in the
system are composed of other entities. (Architectural models show the a system and its
relationship with other systems)
3. An architectural model: Architectural models show the principal sub-systems that make up
a system.
4. A classification model: Object class/inheritance diagrams show how entities have common
characteristics.
5. A stimulus-response model: A stimulus-response model, or state transition diagram, shows
how the system reacts to internal and external events.
Context models
At an early stage in the requirements elicitation and analysis process, you should decide on
the system boundaries. This involves working with system stakeholders to decide what
functionality should be included in the system and what is provided by the system’s
environment.
Context models are used to illustrate the boundaries of a system

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 13

 CHAPTER -3

Once some decisions on the boundaries of the system have been made, part of the analysis
activity is the definition of that context and the dependencies that a system has on its
environment. Normally, producing a simple architectural model is the first step in this
activity.

Above Figure is an architectural model that illustrates the structure of the information system
that includes a bank auto-teller network. High-level architectural models are usually
expressed as simple block diagrams where each sub-system is represented by a named
rectangle, and lines indicate associations between sub-systems.
Behavioural models
Behavioural models are used to describe the overall behaviour of a system
Two types of behavioural model are shown here
1. Data processing models that show how data is processed as it moves through the
system
2. State machine models that show the systems response to events
Both of these models are required for a description of the system’s behaviour

1. Data flow models

Data-flow models are an intuitive way of showing how data is processed by a system.
The notation used in these models represents functional processing (rounded rectangles), data
stores (rectangles) and data movements between functions (labelled arrows).
Data-flow models are used to show how data flows through a sequence of processing steps.
A data-flow model, which shows the steps involved in processing an order for goods (such as
computer equipment) in an organisation, is illustrated in Figure.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 14

 CHAPTER -3

Data-flow diagram of order processing

2 State machine models
A state machine model describes how a system responds to internal or external events. The
state machine model shows system states and events that cause transitions from one state to
another. It does not show the flow of data within the system. This type of model is often used
for modelling real-time systems.
A state machine model of a system assumes that, at any time, the system is in one of a
number of possible states. When a stimulus is received, this may trigger a transition to a
different state. For example, a system controlling a valve may move from a state 'Valve open'
to a state 'Valve closed' when an operator command (the stimulus) is received.
To simplify the model, I have assumed that the sequence of actions in using the microwave
is:
1. Select the power level (either half-power or full-power).
2. Input the cooking time.
3. Press Start, and the food is cooked for the given time.
State machine model of a simple microwave oven

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 15

 CHAPTER -3

Data models
Most large software systems make use of a large database. In some cases, this database is
independent of the software system. In others, it is created for the system being developed.
An important point of systems modelling is defining the logical form of the data processed by
the system. These are sometimes called semantic data models.
Used to describe the logical structure of data processed by the system.
The most widely used data modelling technique is Entity-Relation-Attribute modelling (ERA
modelling), which shows the data entities, their associated attributes and the relations
between these entities. This approach to modelling was first proposed in the mid-1970s by
Chen (Chen, 1976).
The UML does not include a specific notation for this database modelling, as it assumes an
object-oriented development process and models data using objects and their relationships.
However, you can use the UML to represent a semantic data model. You can think of entities
in an ERA model as simplified object classes (they have no operations), attributes as class
attributes and named associations between the classes as relations.

Semantic data model for the L1BSYS system.

Object models
An object-oriented approach to the whole software development process is now commonly
used, particularly for interactive systems development. This means expressing the systems

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 16

 CHAPTER -3

requirements using an object model, designing using objects and developing the system in an
object-oriented programming language such as Java or C++.
An object class is an abstraction over a set of objects that identifies common attributes (as in
a semantic data model) and the services or operations that are provided by each object.
Objects are executable entities with the attributes and services of the object class.

Prepared by: Chandrashekhar K, Asst. Prof, Dept. of BCA Page 17