Software

Requirement
Analysis

AZMAN HOSSAIN
201-35-550
PC-A
DEPARTMENT OF SOFTWARE ENGINEERING
 Introduction 1

Submitted to:
Professor Dr. Touhid Bhuiyan

Professor & Head

Department of Software Engineering

Faculty of Science and Information Technology

Daffodil International University

AZMAN HOSSAIN 1
 Introduction 2

Contents
Introduction ............................................................................................................................................ 3
Requirement Analysis .............................................................................................................................. 4
Process ................................................................................................................................................ 5
Feasibility Study ...................................................................................................................................... 6
Requirement Elicitation And Analysis ...................................................................................................... 7
Process ................................................................................................................................................ 7
Requirement Elicitation Techniques..................................................................................................... 8
Interviews........................................................................................................................................ 8
Joint Requirements Development (JRD) Sessions ............................................................................. 8
Prototypes ....................................................................................................................................... 9
Use cases ......................................................................................................................................... 9
Requirement Specification..................................................................................................................... 10
Functional Requirements ................................................................................................................... 11
Non-functional Requirement ............................................................................................................. 12
Measurable ................................................................................................................................... 13
Dependent..................................................................................................................................... 13
Distinction between functional and non-functional requirements.................................................. 14
Requirement Validation......................................................................................................................... 15
Summary ............................................................................................................................................... 16

AZMAN HOSSAIN 2
 Introduction 3

Introduction

Software requirements are created for/by people who want to use the software, not the people who are
going to create the software. It’s not a technical task in the way that programming is a technical task. To
get started with making a software the creators should know what are they making. That’s why this step
is necessary. It is a description of features and functionalities of the target system.

In this process the requirements are gathered from the clients. Then they are analyzed and
documented. The goal of this process is to develop a Document for whole Software Development
process.

This Process confirms whether or not the project is going to be taken. Here it is seen if the software can
be developed within the current technologies, software hardware and budget.

AZMAN HOSSAIN 3
 Requirement Analysis 4

Requirement Analysis

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.

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. At the other extreme, it is a detailed, formal definition of a system function. Davis (1993) explains
why these differences exist:

IF A COMPANY WISHES TO LET A CONTRACT FOR A LARGE SOFTWARE DEVELOPMENT PROJECT, IT MUST DEFINE ITS 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 DETAIL 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.
(Davis 1993)

AZMAN HOSSAIN 4
 Requirement Analysis 5

Process
Requirements engineering processes ensures your software will meet the user expectations, and ending
up with a high quality software.

It’s a critical stage of the software process as errors at this stage will reflect later on the next stages,
which definitely will cause you a higher costs.

At the end of this stage, a requirements document that specifies the requirements will be produced and
validated with the stockholders.

There are four main activities (or sub-activities) of requirements engineering:

Feasibility Study
Requirement Requirement Elicitation and Analysis
Engineering Requirements Specification
Requirements Validation

AZMAN HOSSAIN 5
 Feasibility Study 6

Feasibility Study

An estimate is made of whether the identified can be achieved using the current software and hardware
technologies, under the current budget, etc. The feasibility study should be cheap and quick; it should
inform the decision of whether or not to go ahead with the project.

When the client approaches the organization for getting the desired product developed, it comes up with
rough idea about what all functions the software must perform and which all features are expected from
the software. Referencing to this information, the analysts does a detailed study about whether the
desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the software
product can be practically materialized in terms of implementation, contribution of project to
organization, cost constraints and as per values and objectives of the organization. It explores technical
aspects of the project and product such as usability, maintainability, productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate comments and
recommendations for management about whether or not the project should be undertaken.

The source for information may be the managers of departments where the system will be used, software
engineers who are familiar with the type of proposed system, technology experts, end-users of the
system, etc. Normally, we should try and complete a feasibility study in two or three weeks.

The results of the feasibility study should be a report that recommends whether to go forward to the next
process or you won’t be able to implement the software at all.

AZMAN HOSSAIN 6
 Requirement Elicitation And Analysis 7

Requirement Elicitation And Analysis

After an initial feasibility study, 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 is the process to find out the requirements for an intended software system by
communicating with client, end users, system users and others who have a stake in the software system
development.

Process

Requirements gathering/Discovery - The Gathering

developers discuss with the client and end users
and know their expectations from the software.
This is the process of interacting with stakeholders
of the system to discover their requirements.
Domain requirements from stakeholders and Specification Organization
documentation are also discovered during this
activity. There are several complementary
techniques that can be used for requirements
discovery, which I discuss later in this section. Prioritization
and
Negotiation
Requirement Organization - This activity takes the
unstructured collection of requirements, groups
related requirements, and organizes them into
coherent clusters. The most common way of grouping requirements is to use a model of the system
architecture to identify sub-systems and to associate requirements with each sub-system. In practice,
requirements engineering and architectural design cannot be completely separate activities.

Requirements prioritization and negotiation - Inevitably, when multiple stakeholders are involved,
requirements will conflict. This activity is concerned with prioritizing requirements and finding and
resolving requirements conflicts through negotiation. Usually, stakeholders have to meet to resolve
differences and agree on compromise requirements. If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.

The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are
discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.

Requirement Documentation/Specification - All formal & informal, functional and non-functional

requirements are documented and made available for next phase processing.

AZMAN HOSSAIN 7
 Requirement Elicitation And Analysis 8

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software system by
communicating with client, end users, system users and others who have a stake in the software system
development.

Interviews

Techniques Joint Requirements Development (JRD) Sessions

Prototypes

Use cases

Interviews
Stakeholder interviews are a common technique used in requirement analysis. Though they are generally
idiosyncratic in nature and focused upon the perspectives and perceived needs of the stakeholder, very
often without larger enterprise or system context, this perspective deficiency has the general advantage
of obtaining a much richer understanding of the stakeholder's unique business processes, decision-
relevant business rules, and perceived needs. Consequently, this technique can serve as a means of
obtaining the highly focused knowledge that is often not elicited in Joint Requirements Development
sessions, where the stakeholder's attention is compelled to assume a more cross-functional context.
Moreover, the in-person nature of the interviews provides a more relaxed environment where lines of
thought may be explored at length.

Joint Requirements Development (JRD) Sessions

Requirements often have cross-functional implications that are unknown to individual stakeholders and
often missed or incompletely defined during stakeholder interviews. These cross-functional implications
can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained
facilitator, wherein stakeholders participate in discussions to elicit requirements, analyze their details
and uncover cross-functional implications. A dedicated scribe and Business Analyst should be present to
document the discussion. Utilizing the skills of a trained facilitator to guide the discussion frees the
Business Analyst to focus on the requirements definition process.

JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit
requirements that guide design, whereas the latter elicit the specific design features to be implemented
in satisfaction of elicited requirements.

AZMAN HOSSAIN 8
 Requirement Elicitation And Analysis 9

Prototypes
In the mid-1980s, prototyping was seen as the best solution to the requirements analysis problem.
Prototypes are Mockups of an application. Mockups allow users to visualize an application that hasn't yet
been constructed. Prototypes help users get an idea of what the system will look like, and make it easier
for users to make design decisions without waiting for the system to be built. Major improvements in
communication between users and developers were often seen with the introduction of prototypes. Early
views of applications led to fewer changes later and hence reduced overall costs considerably.

Use cases
A use case is a technique for documenting the potential requirements of a new system or software
change. Each use case provides one or more scenarios that convey how the system should interact with
the end-user or another system to achieve a specific business goal. Use cases typically avoid technical
jargon, preferring instead the language of the end-user or domain expert. Use cases are often co-
authored by requirements engineers and stakeholders.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case
contains a textual description of all of the ways which the intended users could work with the software
or system. Use cases do not describe any internal workings of the system, nor do they explain how that
system will be implemented. They simply show the steps that a user follows to perform a task. All the
ways that users interact with a system can be described in this manner.

AZMAN HOSSAIN 9
 Requirement Specification 10

Requirement Specification
We should try to understand what sort of requirements may arise in the requirement elicitation phase
and what kinds of requirements are expected from the software system.

A software requirements specification (SRS) is a complete description of the behavior of the system to
be developed. It includes a set of use cases that describe all of the interactions that the users will have
with the software. Use cases are also known as functional requirements. In addition to use cases, the
SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are
requirements which impose constraints on the design or implementation (such as performance
requirements, quality standards, or design constraints).

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 nonfunctional requirements so
that they are understandable by system users who don’t have detailed technical knowledge. Ideally, they
should specify only the external behavior of the system. The requirements document should not include
details of the system architecture or design.

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 should therefore be a complete and detailed specification of the whole
system.

AZMAN HOSSAIN 10
 Requirement Specification 11

Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.They define
functions and functionality within and from the software system.

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.

Examples –

• Search option given to user to search from various invoices.

• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.

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.

AZMAN HOSSAIN 11
 Requirement Specification 12

Non-functional Requirement
Requirements, which are not related to functional aspect of software, fall into this category. They are
implicit or expected characteristics of software, which users make assumption of.

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 the capabilities of I/O devices or the data
representations used in interfaces with other systems.

Non-functional requirements are often critical than individual functional requirements. Users can
usually find ways to work around a system function that doesn’t really meet their needs. However,
failing to meet a non-functional requirement can mean that the whole system is unusable.

For example, if an aircraft doesn’t mean meet its reliability requirements, it won’t be safe for operation,
or if an embedded control system fails to meet its performance requirements, the control functions
won’t operate correctly.

AZMAN HOSSAIN 12
 Requirement Specification 13

Measurable
Whenever possible, we should write non-functional requirements quantitatively, so that they can be
tested. You can measure them when the system being tested to check whether the system meet it’s
non-functional requirements.

Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM 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

In practice, customers for a system often find it difficult to translate their goals into measurable
requirements. They don’t understand what some number defining the required speed or reliability. For
some goals, such as maintainability, there’re no metrics that can be used.

The cost of verifying measurable non-functional requirements can be very high and the customers may
not think that these costs are justified.

Dependent
Non-functional requirements often conflict, interact, or even generate other functional or non-
functional requirements.

A user requirement concerned with security, such as limiting access to authorized users, may generate
other requirements that are functional, such as the need to include user authentication facilities in the
system.

AZMAN HOSSAIN 13
 Requirement Specification 14

Distinction between functional and non-functional requirements

In practice, it’s difficult to separate functional and non-functional requirements. The distinction is not
clear as their definitions suggest.

Separate between functional and non-functional requirements

If the non-functional requirements are stated separately from the functional requirements, the
relationship between them may be hard to understand.

However, we should explicitly highlight requirements that are clearly related to emergent system
properties such as performance or reliability.

AZMAN HOSSAIN 14
 Requirement Validation 15

Requirement Validation
Software validation or, more generally, verification and validation (V&V) is intended to show that a
system both conforms to its specification and that it meets the expectations of the customer.

Validation may also involve checking processes, such as inspections or reviews at each stage of the
software process, from defining the requirements till the software development.

Testing, where the system is executed using simulated test data, is an important validation technique.
It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with
finding problems with the requirements.

These problems can lead to extensive rework costs when these they are discovered in the later stages,
or after the system is in service.

The cost of fixing a requirements problem by making a system change is usually much greater than
repairing design or code errors. Because a change to the requirements usually means the design and
implementation must also be changed, and re-tested.

AZMAN HOSSAIN 15
 Summary 16

Summary
Software engineering practices are the most important practices for the success of software. Requirement
engineering is the first and crucial phase in the development of software.

The whole development process of the software is depended on this phase. It involves set of activities like
system feasibility study, elicitation analysis, validation and management of the requirements.

AZMAN HOSSAIN 16