Module 2

Requirements
1. Importance of Requirement Analysis: Requirement Analysis, also known as
Requirement Engineering, is the process of defining user expectations for a new
software being built or modified. In software engineering, it is sometimes referred
to loosely by names such as requirements gathering or requirements capturing.
Requirements analysis encompasses those tasks that go into determining the
needs or conditions to meet for a new or altered product or project, taking
account of the possibly conflicting requirements of the various stakeholders,
analyzing, documenting, validating and managing software or system
requirements.
Objectives of Requirement Analysis: Successful completion of the Requirements
Analysis Phase should comprise:
i. Definition of approved requirements
ii. Creation of the Functional Requirements Document and Requirements
Traceability Matrix
iii. Development of planned test activities
iv. Performance of needed procurement activities
v. Approval to progress to the Design Phase
Goals of Requirement Analysis: The purpose of the Requirements Analysis Phase
is to transform the needs and high-level requirements specified in earlier phases
into unambiguous (measurable and testable), traceable, complete, consistent, and
stakeholder-approved requirements. During the Requirements Analysis Phase, the
agency will conduct any procurement needed for the project.

2. User Needs: These requirements describe the needs and expectations of the end-
users of the software system. They include information about the users’ tasks,
workflows, and preferences, and how the software should support them. It can be
a calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to perform. All
these functionalities need to be necessarily incorporated into the system as a part
of the contract. These are represented or stated in the form of input to be given to
the system, the operation performed and the output expected. They are basically
the requirements stated by the user which one can see directly in the final
product, unlike the non-functional requirements. Each high-level functional
requirement may involve several interactions or dialogues between the system
and the outside world. In order to accurately describe the functional requirements,
all scenarios must be enumerated. There are many ways of expressing user needs
e.g., natural language, a structured or formatted language with no rigorous syntax
and formal specification language with proper syntax. User needs in Software
Engineering are also called Functional Requirements.
3. Software Features and Software 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.
Software requirements are the subset of software feature. An incomplete set of
requirements is one in which some requirements have been overlooked. The lack
of these features would be felt by the customer much later, possibly while using
the software. Often, incompleteness is caused by the inability of the customer to
visualize the system that is to be developed and to anticipate all the features that
would be required. An experienced analyst can detect most of these missing
features and suggest them to the customer for his consideration and approval for
incorporation in the requirements.

4. Classes of User Requirements: Requirements evolution during the requirement

analysis and after a system has gone into service is inevitable. Developing software
requirements focuses attention on software capabilities, business objectives and
other business systems. As the requirements definition is developed, you normally
develop a better understanding of users’ needs. This feeds information back to the
user who may then propose a change to the requirements. Furthermore, it may
take several years to specify and develop a large system. Over that time, the
system’s environment and the business objectives change and the requirements
evolve to reflect this.
From an evolution perspective, requirements fall into two classes:
 Enduring requirements: These are relatively stable requirements that
derive from the core activity of the organization and which relate directly
to the domain of the system. For example, in a hospital there will always be
requirements concerned with patients, doctors, nurses, treatments, etc.
These requirements may be derived from domain models that show the
entities and relations which characterize an application domain.
 Volatile requirements: These are requirements that are likely to change
during the system development process or after the system has been
become operational. Examples of volatile requirements are requirements
resulting from government health-care policies or healthcare charging
mechanisms.
Volatile requirements fall into five classes:
i. Mutable requirements: Requirements that change because of
changes to the environment in which the organization is operating.
For example, in hospital systems, the funding of patient care may
change and thus require different treatment information to be
collected.
ii. Emergent requirements: Requirements that emerge as the
customer's understanding of the system develops during the system
 development. The design process may reveal new emergent
requirements.
iii. Consequential requirements: Requirements that result from the
introduction of the computer system. Introducing the computer
system may change the organizations processes and open up new
ways of working which generate new system requirements.
iv. Compatibility requirements: Requirements that depend on the
particular systems or business processes within an organization. As
these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.

5. Sub phases of Requirement Analysis

Software requirement analysis means complete study, analyzing, describing
software requirements so that requirements that are genuine and needed can be
fulfilled to solve problem. Requirements analysis is the first stage in the software
development process. It encompasses those tasks that go into determining the
needs or conditions to meet for a new or altered product, taking account of the
possibly conflicting requirements of the various stakeholders, such as beneficiaries
or users. Analysis of the requirement is critical to the success of a development
project. Requirements must be actionable, measurable, testable, related to
identified business needs or opportunities, and defined to a level of detail
sufficient for system design. Requirements can be functional and non-functional.
There are 6 phases of requirement analysis which is described below:
i. Requirement Initiation/Problem Recognition: The main aim of requirement
analysis is to fully understand main objective of requirement that includes
why it is needed, does it add value to product, will it be beneficial, does it
increase quality of the project, and does it will have any other effect. All
these points are fully recognized in problem recognition so that
requirements that are essential can be fulfilled to solve business problems.
ii. Requirement Elicitation: Eliciting requirements is the task of communicating
with customers and users to determine what their requirements are. This is
sometimes also called requirements gathering.
iii. Requirement Elaboration: This is the process of collecting the user's needs
and constraints. How the entities of the system will interact with each other.
iv. Requirement Negotiation: This is the process of negotiating with the client
about the software cost and other facilities that will be provided with the
system.
v. Requirement Specification: 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. In this stage, I specified the manpower
requirements, and technologies required for the deployment of the system.
vi. Requirement Verification: All the requirements of the user whether they
need any modification or not will be verified by myself.
6. Functional and Nonfunctional requirements
 Functional Requirements: The functional requirements capture the
functionalities required by the users from the system. We can consider a
software as offering a set of functions {f i} to the user. These functions can be
considered similar to a mathematical function f : I → O, meaning that a function
transforms an element (ii) in the input domain (I) to a value (o i) in the output
(O). Each function fi of the system can be considered as reading certain data i i,
and then transforming a set of input data (i i) to the corresponding set of output
data (oi). The functional requirements of the system, should clearly describe
each functionality that the system would support along with the corresponding
input and output data set.
These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be
necessarily incorporated into the system as a part of the contract. These are
represented or stated in the form of input to be given to the system, the
operation performed and the output expected. They are basically the
requirements stated by the user which one can see directly in the final product,
unlike the non-functional requirements.
 Non-Functional Requirements: The non-functional requirements are non-
negotiable obligations that must be supported by the software. The non-
functional requirements capture those requirements of the customer that
cannot be expressed as functions (i.e., accepting input data and producing
output data). Non-functional requirements usually address aspects concerning
external interfaces, user interfaces, maintainability, portability, usability,
maximum number of concurrent users, timing, and throughput (transactions
per second, etc.). The non-functional requirements can be critical in the sense
that any failure by the developed software to achieve some minimum defined
level in these requirements can be considered as a failure and make the
software unacceptable by the customer.
These are basically the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which these factors
are implemented varies from one project to other. They are also called non
behavioral requirements.

7. Barriers to Eliciting User requirements: Eliciting requirements is the first step of

the 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 barriers encountered during this process.
i. Understanding the user’s needs: Requirements are often poorly defined
and may change over time, making it difficult for engineers to understand
the user’s true needs.
ii. Managing stakeholders: There may be multiple stakeholders with different
goals and priorities, making it difficult to satisfy everyone’s requirements.
 iii. Identifying and mitigating risks: Engineers must identify and mitigate
potential risks associated with the requirements, such as security
vulnerabilities or scalability issues.
iv. Handling ambiguity: Requirements may be ambiguous, inconsistent, or
incomplete, making it difficult for engineers to understand what the system
should do.
v. Keeping up with changing technology: Requirements must be aligned with
the latest technology trends and innovations, which can be difficult to
predict and keep up with.
vi. Maintaining a balance between feasibility, cost and time: Engineers need
to balance the feasibility of implementing a requirement, the cost of
implementation, and the time required to implement it.
vii. Maintaining traceability: Engineers need to maintain traceability of
requirements throughout the development process to ensure that all
requirements are met and any changes are tracked.

8. The software requirements document and SRS standards: The requirements

document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the
system requirements. It is NOT a design document. As far as possible, it should set
of WHAT the system should do rather than HOW it should do it
The Software Requirements document suggests that there are 6 requirements that
requirement document should satisfy. It should
 Specify only external system behavior
 Specify constraints on the implementation.
 Be easy to change
 Serve as reference tool for system maintainers
 Record forethought about the life cycle of the system.
 Characterize acceptable responses to undesired events
Purpose of SRS
 Communication between the Customer, Analyst, system developers,
maintainers,
 firm foundation for the design phase
 support system testing activities
 Support project management and control
 controlling the evolution of the system
IEEE requirements standard: It defines a generic structure for a requirements
document that must be instantiated for each specific system.
- Introduction.
- General description.
- Specific requirements.
- Appendices.
- Index.
I. Introduction
  Purpose
 Scope
 Definitions
 Acronyms and Abbreviations
 References
 Overview
II. General description
 Product perspective
 Product function summary
 User characteristics
 General constraints
 Assumptions and dependencies
III. Specific Requirements
 Functional requirements
 External interface requirements
 Performance requirements
 Design constraints
 Attributes eg. security, availability, maintainability,
transferability/conversion
 Other requirements
IV. Appendices
V. Index

9. Requirements Engineering: The broad spectrum of tasks and techniques that lead
to an understanding of requirements is called requirements engineering. From a
software process perspective, requirements engineering is a major software
engineering action that begins during the communication activity and continues
into the modeling activity. It must be adapted to the needs of the process, the
project, the product, and the people doing the work.
Requirements engineering provides the appropriate mechanism for understanding
what the customer wants, analyzing need, assessing feasibility, negotiating a
reasonable solution, specifying the solution unambiguously, validating the
specification, and managing the requirements as they are transformed into an
operational system. It encompasses seven distinct tasks: inception, elicitation,
elaboration, negotiation, specification, validation, and management. It is
important to note that some of these tasks occur in parallel and all are adapted to
the needs of the project.
i. Inception: At project inception a basic understanding of the problem, the
people who want a solution, the nature of the solution that is desired, and
the effectiveness of preliminary communication and collaboration between
the other stakeholders and the software team is established.
ii. Elicitation: It certainly seems simple enough—ask the customer, the users,
and others what the objectives for the system or product are, what is to be
accomplished, how the system or product fits into the needs of the business,
 and finally, how the system or product is to be used on a day-to-day basis.
But it isn’t simple—it’s very hard. There are a number of problems that are
encountered as elicitation occurs.
a. Problems of scope: The boundary of the system is ill-defined or the
customers/users specify unnecessary technical detail that may
confuse, rather than clarify, overall system objectives.
b. Problems of understanding: The customers/ users are not completely
sure of what is needed, have a poor understanding of the capabilities
and limitations of their computing environment, don’t have a full
understanding of the problem domain, have trouble communicating
needs to the system engineer, omit information that is believed to be
“obvious,” specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or
untestable.
c. Problems of volatility: The requirements change over time.
To help overcome these problems, you must approach requirements
gathering in an organized manner.
iii. Elaboration: The information obtained from the customer during inception
and elicitation is expanded and refined during elaboration. This task focuses
on developing a refined requirements model that identifies various aspects
of software function, behavior, and information.
Elaboration is driven by the creation and refinement of user scenarios that
describe how the end user (and other actors) will interact with the system.
Each user scenario is parsed to extract analysis classes—business domain
entities that are visible to the end user. The attributes of each analysis class
are defined, and the services that are required by each class are identified.
The relationships and collaboration between classes are identified, and a
variety of supplementary diagrams are produced.
iv. Negotiation: It isn’t unusual for customers and users to ask for more than
can be achieved, given limited business resources. It’s also relatively
common for different customers or users to propose conflicting
requirements, arguing that their version is “essential for our special needs.”
You have to reconcile these conflicts through a process of negotiation.
Customers, users, and other stakeholders are asked to rank requirements
and then discuss conflicts in priority. Using an iterative approach that
prioritizes requirements, assesses their cost and risk, and addresses internal
conflicts, requirements are eliminated, combined, and/or modified so that
each party achieves some measure of satisfaction.
v. Specification: In the context of computer-based systems (and software), the
term specification means different things to different people. A specification
can be a written document, a set of graphical models, a formal mathematical
model, a collection of usage scenarios, a prototype, or any combination of
these.
 vi. Validation: The work products produced as a consequence of requirements
engineering are assessed for quality during a validation step. Requirements
validation examines the specification5 to ensure that all software
requirements have been stated unambiguously; that inconsistencies,
omissions, and errors have been detected and corrected; and that the work
products conform to the standards established for the process, the project,
and the product.
vii. Management: Requirements for computer-based systems change, and the
desire to change requirements persists throughout the life of the system.
Requirements management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at any
time as the project proceeds.

10. Case Study of SRS for a Real Time System: Covered through Assignment

11. Tools for Requirements Gathering:

Document Flow Chart: These “have the purpose of showing existing controls over
document-flow through the components of a system. The chart is read from left to
right and documents the flow of documents through the various business units.”

Example of document flow chart

Decision Table: A decision table shows the decision making logic and the
corresponding actions taken in a tabular or a matrix form. The upper rows of the
table specify the variables or conditions to be evaluated and the lower rows
specify the actions to be taken when an evaluation test is satisfied. A column in the
table is called a rule. A rule implies that if a certain condition combination is true,
then the corresponding action is executed.
Decision tables provide a notation that translates actions and conditions
(described in a processing narrative or a use case) into a tabular form. The table is
difficult to misinterpret and may even be used as a machine-readable input to a
table-driven algorithm.

Decision table nomenclature

Decision table organization is illustrated in above figure. Referring to the figure,
the table is divided into four sections. The upper left-hand quadrant contains a list
of all conditions. The lower left-hand quadrant contains a list of all actions that are
possible based on combinations of conditions. The right-hand quadrants form a
matrix that indicates condition combinations and the corresponding actions that
will occur for a specific combination. Therefore, each column of the matrix may be
interpreted as a processing rule. The following steps are applied to develop a
decision table:
i. List all actions that can be associated with a specific procedure (or
component).
ii. List all conditions (or decisions made) during execution of the
procedure.
iii. Associate specific sets of conditions with specific actions,
eliminating impossible combinations of conditions; alternatively,
develop every possible permutation of conditions.
 iv. Define rules by indicating what actions occur for a set of conditions.
To illustrate the use of a decision table, consider the following excerpt from an
informal use case that has been proposed for the print shop system:
Three types of customers are defined: a regular customer, a silver customer, and
a gold customer (these types are assigned by the amount of business the
customer does with the print shop over a 12 month period). A regular customer
receives normal print rates and delivery. A silver customer gets an 8 percent
discount on all quotes and is placed ahead of all regular customers in the job
queue. A gold customer gets a 15 percent reduction in quoted prices and is
placed ahead of both regular and silver customers in the job queue. A special
discount of x percent in addition to other discounts can be applied to any
customer’s quote at the discretion of management.
Above figure illustrates a decision table representation of the preceding informal
use case. Each of the six rules indicates one of six viable conditions. As a general
rule, the decision table can be used effectively to supplement other procedural
design notation.

Decision Tree: A decision tree gives a graphic view of the processing logic involved
in decision making and the corresponding actions taken. Decision tables specify
which variables are to be tested, and based on this what actions are to be taken
depending upon the outcome of the decision making logic, and the order in which
decision making is performed.
The edges of a decision tree represent conditions and the leaf nodes represent the
actions to be performed depending on the outcome of testing the conditions.
Instead of discussing how to draw a decision tree for a given processing logic, we
shall explain through a simple example how to represent the processing logic in
the form of a decision tree.
In many software application areas, it is often more cost effective to acquire rather
than develop computer software. Software engineering managers are faced with a
make/ buy decision that can be further complicated by a number of acquisition
options:
i. software may be purchased (or licensed) off-the-shelf
ii. “full-experience” or “partial-experience” software components may be
acquired and then modified and integrated to meet specific needs
iii. Software may be custom built by an outside contractor to meet the
purchaser’s specifications.

The steps involved in the acquisition of software are defined by the criticality of
the software to be purchased and the end cost. In some cases (e.g., low-cost PC
software), it is less expensive to purchase and experiment than to conduct a
lengthy evaluation of potential software packages. In the final analysis, the
make/buy decision is made based on the following conditions:
i. Will the delivery date of the software product be sooner than that for
internally developed software?
 ii. Will the cost of acquisition plus the cost of customization be less than the
cost of developing the software internally?
iii. Will the cost of outside support (e.g., a maintenance contract) be less than
the cost of internal support?
These conditions apply for each of the acquisition options.

Creating a Decision Tree: The steps just described can be augmented using
statistical techniques such as decision tree analysis. For example, Figure below
depicts a decision tree for a software based system X. In this case, the software
engineering organization can
i. Build system X from scratch
ii. reuse existing partial-experience components to construct the system
iii. buy an available software product and modify it to meet local needs
iv. Contract the software development to an outside vendor.

A decision tree to support the make/buy decision

If the system is to be built from scratch, there is a 70 percent probability that the
job will be difficult. Using the estimation techniques the project planner estimates
that a difficult development effort will cost $450,000. A “simple” development
effort is estimated to cost $380,000. The expected value for cost, computed along
any branch of the decision tree, is
Expected cost = ∑ (path probability)i ×(estimated path cost)I ; where i is the
decision tree path.
For the build path,
Expected costbuild = 0.30 ($380K) + 0.70 ($450K) = $429K
 Following other paths of the decision tree, the projected costs for reuse, purchase,
and contract, under a variety of circumstances, are also shown. The expected costs
for these paths are
Expected costreuse = 0.40 ($275K) + 0.60 [0.20 ($310K) + 0.80 ($490K)] = $382K
Expected costbuy = 0.70 ($210K) + 0.30 ($400K) = $267K
Expected costcontract = 0.60 ($350K) + 0.40 ($500K) = $410K
Based on the probability and projected costs that have been noted in above figure,
the lowest expected cost is the “buy” option.
It is important to note, however, that many criteria—not just cost— must be
considered during the decision-making process. Availability, experience of the
developer/ vendor/contractor, conformance to requirements, local “politics,” and
the likelihood of change are but a few of the criteria that may affect the ultimate
decision to build, reuse, buy, or contract.

12. Introduction to nontraditional Requirements: Nontraditional Requirements are

user stories which are short (a few sentences) descriptions of what scenarios the
customers and users would like the system to support. They are different from
traditional requirements specification primarily in details—user stories do not
contain detailed requirements which are to be uncovered only when the story is to
be implemented, therefore allowing the details to be decided as late as possible.
Each story is written on a separate card, so they can be flexibly grouped.