JNTUA College of Engineering (Autonomous)

Ananthapuramu
Department of Computer Science and Engineering
MCA (R20)
Software Engineering
SEMESTER - II L-T-P-C: 3-0-0-3

UNIT–II:
Requirements: Importance of Requirement Analysis, User Needs, Software
Features and Software Requirements. Classes of User Requirements :
Enduring and Volatile, Sub phases of Requirement Analysis, Functional and
Non-functional requirements, Barriers to Eliciting User requirements, The
software requirements document and SRS standards, Requirements
Engineering, Case Study of SRS for a Real Time System. Tools for
Requirements Gathering: Document Flow Chart, Decision Table, Decision
Tree, Introduction to non-traditional Requirements.

Requirements
The software requirements are description of features and
functionalities of the target system. Requirements convey the expectations
of users from the software product. The requirements can be obvious or
hidden, known or unknown, expected or unexpected from client’s point of
view.

Requirement Engineering
The process to gather the software requirements from client, analyze
and document them is known as requirement engineering. The goal of
requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.

2.1 Requirement Analysis

Requirements Analysis is the process of defining the expectations of
the users for an application that is to be built or modified. It involves all the
tasks that are conducted to identify the needs of different stakeholders.
Therefore requirements analysis means to analyze, document, validate and
manage software or system requirements.

High-quality requirements are documented, actionable, measurable,

testable, traceable, helps to identify business opportunities, and are defined
to a facilitate system design.

Requirements Analysis Process

The software requirements analysis process involves the following
steps/phases:
1. Eliciting requirements
 2. Analyzing requirements
3. Requirements modeling
4. Review and retrospective
1- Eliciting requirements
The process of gathering requirements by communicating with the
customers is known as eliciting requirements.
2- Analyzing requirements
This step helps to determine the quality of the requirements. It involves
identifying whether the requirements are unclear, incomplete, ambiguous,
and contradictory. These issues resolved before moving to the next step.
3- Requirements modeling
In Requirements modeling, the requirements are usually documented in
different formats such as use cases, user stories, natural-language
documents, or process specification.
4- Review and retrospective
This step is conducted to reflect on the previous iterations of requirements
gathering in a bid to make improvements in the process going forward.

User Needs:
Customers have needs and requirements. A customer need establishes
the relationship between the organization and the customer (example: I need
(or want) an iPad). Requirements are those characteristics that determine
whether or not the customer is happy. (Examples: a requirement is that the
iPad is user-friendly, has to be fast in data storage and retrieval, etc.)

Software Requirement:
Requirement is a condition or capability possessed by the software or
system component in order to solve a real world problem. The problems can
be to automate a part of a system, to correct shortcomings of an existing
system, to control a device, and so on.

IEEE defines requirement as (1) A condition or capability needed by a

user to solve a problem or achieve an objective. (2) A condition or capability
that must be met or possessed by a system or system component to satisfy
a contract, standard, specification, or other formally imposed documents. (3)
A documented representation of a condition or capability as in (1) or (2).’

Requirements describe how a system should act, appear or perform.

For this, when users request for software, they provide an approximation of
what the new system should be capable of doing. Requirements differ from
one user to another and from one business process to another.

Enduring and volatile requirements

 Enduring requirements. Stable requirements derived from the core
activity of the customer organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain models
 Volatile requirements. Requirements which change during development or
when the system is in use. In a hospital, requirements derived from
health-care policy
2.2 Types of Requirements:
Written for customers
User requirements
Statements in natural language plus diagrams of the services the
system provides and its operational constraints.
Written as a contract between client and contractor – System
requirements
A structured document setting out detailed descriptions of the system
services.
Written for developers – Software specification
A detailed software description which can serve as a basis for a design
or implementation.

User requirements readers

 Client managers
 System end-users
 Client engineers
 Contractor managers
 System architects

System requirements readers

 System end-users
 Client engineers
 System architects
 Software developers

Software specification readers

 Client engineers (maybe)
 System architects
 Software developers

2.2.a Functional requirements

 Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in
particular situations.
 Describe functionality or system services
 Depend on the type of software, expected users and the type of
system where the software is used
 Functional user requirements may be high-level statements of what
the system should do but functional system requirements should
describe the system services in detail

Examples of functional requirements

 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 account’s permanent storage area.

2.2.b Non-functional requirements

Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards, etc.
 Define system properties and constraints e.g. reliability, response time
and storage requirements. Constraints are I/ O device capability,
system representations, etc.
 Process requirements may also be specified mandating a particular
system, programming language or development method
 Non-functional requirements may be more critical than functional
requirements. If these are not met, the system is useless

Product requirements – Requirements which specify that the delivered

product must behave in a particular way e.g. execution speed, reliability, etc.
Organizational requirements – Requirements which are a consequence of
organizational policies and procedures e.g. process standards used,
implementation requirements, etc.
External requirements – Requirements which arise from factors which are
external to the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Goals and requirements
Non-functional requirements may be very difficult to state exactly and
imprecise requirements may be difficult to verify.
Goal – A general intention of the user such as ease of use
Verifiable non-functional requirement – A statement using some
measure that can be objectively tested

Goals are helpful to developers as they convey the intentions of the

system users

Examples
A system goal – The system should be easy to use by experienced
controllers and should be organized in such a way that user errors are
minimized.
A verifiable non-functional requirement – Experienced controllers shall
be able to use all the system functions after a total of two hours training.
After this training, the average number of errors made by experienced users
shall not exceed two per day.
Requirements measures

Requirements interaction
Conflicts between different nonfunctional requirements are common in
complex systems
Spacecraft system
 To minimize weight, the number of separate chips in the system should
be minimized
 To minimize power consumption, lower power chips should be used
 However, using low power chips may mean that more chips have to be
used. Which is the most critical requirement?
2.2.c Domain requirements
Requirements that come from the application domain of the system and
that reflect characteristics of that domain

 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
 Library system domain requirements
 There shall be a standard user interface to all databases which shall be
based on the Z39.50 standard.
 Because of copyright restrictions, some documents must be deleted
immediately on arrival. Depending on the user’s requirements, these
documents will either be printed locally on the system server for
manually forwarding to the user or routed to a network printer.

Domain requirements problems

 Understandability – Requirements are expressed in the language of the
application domain – This is often not understood by software
engineers developing the system
 Implicitness – Domain specialists understand the area so well that they
do not think of making the domain requirements explicit

2.3 Barriers to Eliciting User requirements

Eliciting requirements is the first step of Requirement Engineering process. It
helps the analyst to gain knowledge about the problem domain which in turn is
used to produce a formal specification of the software. There are a number of issues
and challenges encountered during this process. Some of them are as follows:

1. Understanding large and complex system requirements is

difficult
The word ‘large’ represents 2 aspects:
 (i) Large constraints in terms of security, etc. due to a large
number of users.
 (ii) Large number of functions to be implemented.

2. Undefined system boundaries –

There might be no defined set of implementation requirements.
The customer may go on to include several unrelated and unnecessary
functions besides the important ones, resulting in an extremely large
implementation cost which may exceed the decided budget.

3. Customers/Stakeholders are not clear about their needs.

Sometimes, the customers themselves maybe unsure about the
exhaustive list of functionalities they wish to see in the software. This
might happen when they have a very basic idea about their needs but
haven’t planned much about the implementation part.

4. Conflicting requirements are there

There is a possibility that two different stakeholders of the
project express demands which contradict each other’s
implementation. Also, a single stakeholder might also sometimes
express two incompatible requirements.
 5. Changing requirements is another issue
In case of successive interviews or reviews from the customer,
there is a possibility that the customer expresses a change in the initial
set of specified requirements. While it is easy to accommodate some of
the requirements, it is often difficult to deal with such changing
requirements.

6. Partitioning the system suitably to reduce complexity

The projects can sometimes be broken down into small modules
or functionalities which are then handled by separate teams. Often,
more complex and large projects require more partitioning. It needs to
be ensured that the partitions are non-overlapping and independent of
each other.

7. Validating and Tracing requirements

Cross-checking the listed requirements before starting the
implementation part is very important. Also, there should be forward
as well as backward traceability. For eg, all the entity names should be
the same everywhere, i.e., there shouldn’t be a case where ‘STUDENT’
and ‘STUDENTS’ are used at separate places to refer to the same
entity.

8. Identifying critical requirements

Identifying the set of requirements which have to be
implemented at any cost is very important. The requirements should
be prioritized so that crucial ones can be implemented first with the
highest priority.

9. Resolving the “to be determined” part of the requirements

The TBD set of requirements include those requirements which
are yet to be resolved in the future. The number of such requirements
should be kept as low as possible.

10. Proper documentation, proper meeting time and budget

constraints
Ensuring a proper documentation is an inherent challenge,
especially in case of changing requirements. The time and budget
constraints too need to be handled carefully and systematically.

2.4 The software requirements document and SRS standards

In order to form a good SRS, here you will see some points which can be
used and should be considered to form a structure of good SRS. These are as
follows:
1. Introduction
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
Software Requirement Specification (SRS) Format as name suggests,
is complete specification and description of requirements of software that
needs to be fulfilled for successful development of software system. These
requirements can be functional as well as non-requirements depending upon
type of requirement. The interaction between different customers and
contractor is done because it’s necessary to fully understand needs of
customers.

Depending upon information gathered after interaction, SRS is

developed which describes requirements of software that may include
changes and modifications that is needed to be done to increase quality of
product and to satisfy customer’s demand.

1. Introduction:
 (i) Purpose of this Document: At first, main aim of why this
document is necessary and what’s purpose of document is explained
and described.
 (ii) Scope of this document: In this, overall working and main
objective of document and what value it will provide to customer is
described and explained. It also includes a description of development
cost and time required.
 (iii) Overview: In this, description of product is explained. It’s simply
summary or overall review of product.

2. General description: In this, general functions of product which includes

objective of user, a user characteristic, features, benefits, about why its
importance is mentioned. It also describes features of user community.

3. Functional Requirements: In this, possible outcome of software system

which includes effects due to operation of program is fully explained. All
functional requirements which may include calculations, data processing,
etc. are placed in a ranked order.

4. Interface Requirements: In this, software interfaces which mean how

software program communicates with each other or users either in form
 of any language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.

5. Performance Requirements: In this, how a software system performs

desired functions under specific condition is explained. It also explains
required time, required memory, maximum error rate, etc.

6. Design Constraints: In this, constraints which simply means limitation

or restriction are specified and explained for design team. Examples may
include use of a particular algorithm, hardware and software limitations,
etc.

7. Non-Functional Attributes: In this, non-functional attributes are

explained that are required by software system for better performance.
An example may include Security, Portability, Reliability, Reusability,
Application compatibility, Data integrity, Scalability capacity, etc.

8. Preliminary Schedule and Budget: In this, initial version and budget of

project plan are explained which include overall time duration required
and overall cost required for development of project.

9. Appendices: In this, additional information like references from where

information is gathered, definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained.

IEEE requirements standard

Introduction
General description
Specific requirements
Appendices
Index
This is a generic structure that must be instantiated for specific systems
2.4 Requirements Engineering
Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining
service provided by the system. Requirements Engineering Process consists
of the following main activities:
 Requirements elicitation
 Requirements specification
 Requirements verification and validation
 Requirements management

Requirements Elicitation:
It is related to the various ways used to gain knowledge about the
project domain and requirements. The various sources of domain knowledge
include customers, business manuals, and the existing software of same
type, standards and other stakeholders of the project.

The techniques used for requirements elicitation include interviews,

brainstorming, task analysis, prototyping, etc. Some of these are
discussed here. Elicitation does not produce formal models of the
requirements understood. Instead, it widens the domain knowledge of the
analyst and thus helps in providing input to the next stage.

Requirements specification:
This activity is used to produce formal software requirement models.
All the requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
During specification, more knowledge about the problem may be required
which can again trigger the elicitation process.

The models used at this stage include ER diagrams, data flow

diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries,
etc.

Requirements verification and validation:

Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.

Validation: It refers to a different set of tasks that ensures that the software
that has been built is traceable to customer requirements.

If requirements are not validated, errors in the requirement definitions would

propagate to the successive stages resulting in a lot of modification and
rework.
The main steps for this process include:
 The requirements should be consistent with all the other requirements
i.e no two requirements should conflict with each other.
 The requirements should be complete in every sense.
  The requirements should be practically achievable.

Requirements management:
Requirement management is the process of analysing, documenting,
tracking, prioritizing and agreeing on the requirement and controlling the
communication to relevant stakeholders. This stage takes care of the
changing nature of requirements. It should be ensured that the SRS is as
modifiable as possible so as to incorporate changes in requirements
specified by the end users at later stages too. Being able to modify the
software as per requirements in a systematic and controlled manner is an
extremely important part of the requirements engineering process.

2.5 Tools for Requirements Gathering:

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements
of system in a graphical form.
 It shows the flow of data between various functions of system and
specifies how the current system is implemented.
 It is an initial stage of design phase that functionally divides the
requirement specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user
and analyst and system designer.
 It gives an overview of what data a system processes, what
transformations are performed, what data are stored, what results are
produced and where they flow.
Basic Elements of DFD
DFD is easy to understand and quite effective when the required design is
not clear and the user wants a notational language for communication.
However, it requires a large number of iterations for obtaining the most
accurate and complete solution.
The following table shows the symbols used in designing a DFD and their
significance −

symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

 Open Rectangle Data Store

Context Diagram
A context diagram helps in understanding the entire system by one DFD
which gives the overview of a system. It starts with mentioning major
processes with little details and then goes onto giving more details of the
processes with the top-down approach.
The context diagram of mess management is shown below.

Decision Trees
Decision trees are a method for defining complex relationships by describing
decisions and avoiding the problems in communication. A decision tree is a
diagram that shows alternative actions and conditions within horizontal tree
framework. Thus, it depicts which conditions to consider first, second, and so
on.

Decision trees depict the relationship of each condition and their

permissible actions. A square node indicates an action and a circle indicates
a condition. It forces analysts to consider the sequence of decisions and
identifies the actual decision that must be made.
The major limitation of a decision tree is that it lacks information in its format
to describe what other combinations of conditions you can take for testing. It
is a single representation of the relationships between conditions and
actions.
For example, refer the following decision tree −

Decision Tables
Decision tables are a method of describing the complex logical
relationship in a precise manner which is easily understandable.
 It is useful in situations where the resulting actions depend on the
occurrence of one or several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the
actions.
Components of a Decision Table
 Condition Stub − It is in the upper left quadrant which lists all the
condition to be checked.
 Action Stub − It is in the lower left quadrant which outlines all the
action to be carried out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides
answers to questions asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the
appropriate action resulting from the answers to the conditions in the
condition entry quadrant.
The entries in decision table are given by Decision Rules which define the
relationships between combinations of conditions and courses of action. In
rules section,
 Y shows the existence of a condition.
 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −
CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X