Software Requirements

Management
Dr.V.S.R.Krishnaiah

Outline

Why to Focus on Requirements?

Definition of Sw Requirements
Requirements engineering Process
Types of Requirements
Requirements Development Process
Requirement Development Tasks
Software Requirements- Practical Strategy
Dr.V.S.R.Krishnaiah

Why to Focus on Requirements?

Software requirement development and
management is one area where the project
team needs to do a lot of work. Requirements
are one of the most important parts of the
software project. After all, the software
application or product is to be built based on
these requirements.

Dr.V.S.R.Krishnaiah

Why to Focus on Requirements?

What are customer requirements?
How are customer requirements gathered?
How are customer requirements managed?
What is the role of the configuration
management system in requirement
management?
How is quality assurance done during
software requirements management?

Dr.V.S.R.Krishnaiah

Requirements Study is done by

software engineering folks
Developing the requirement is done by software
engineering folks. Even if detailed requirements
come from a customer, analysis of these details
must be done. Some of the requirements may
need to be elaborated further. Some of the
requirements may not be feasible. In those cases,
some alternative solution has to be suggested to
the customer and approval obtained from him.
Once most of the requirements are made clear
and approved, then software design processes
can begin.
Dr.V.S.R.Krishnaiah

Software Requirements
Descriptions and specifications of what
a system must do and what a system
should be.

Dr.V.S.R.Krishnaiah

Requirements engineering:
The process of establishing the services the system
should provide and the constraints under which it
must operate is called requirements engineering.
This process is the set of activities that lead to the
production of the requirements definition and
requirements specification. Principal stages in this
process are:
Requirements Analysis
Requirements Definition
Requirements Specification
Dr.V.S.R.Krishnaiah

Requirements Analysis
This is the process of deriving the system
requirements through observation of
existing systems, discussions with potential
users and procurers, task analysis and so on.
This may involve the development of one or
more different system models. These help the
analyst understand the system to be specified.
System prototypes may also be developed to
help understand the requirements.
Dr.V.S.R.Krishnaiah

Requirements Definition
Requirements definition is the activity of
translating the information gathered during
the analysis activity into a document that
defines a set of requirements. These should
accurately reflect what the customer wants.
This document must be written so that it can
be understood by the end user and by the
system customer.
Dr.V.S.R.Krishnaiah

Requirements Specification
It should include all necessary information about what the
system must do and all constraints on its operation. A
detailed and precise description of the system requirements
is setout to act as a basis for a contract between client and
software developer. The creation of this document is usually
carried out in parallel with some high level design. The
design and requirements activities influence each other as
they develop. During the creation of this document, errors in
the requirements definition are inevitably discovered. It
must be modified to correct these problems.
The activities in the requirements process are not simply
carried out in sequence but
are iterated.
Dr.V.S.R.Krishnaiah

10

Requirements Abstraction (Davis)

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 pre-defined.
The requirements must be written so that several
contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organisations 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.
Dr.V.S.R.Krishnaiah

11

The Requirements Process

Why Are Requirements Important?

Top factors that caused project to fail

Incomplete requirements
Lack of user involvement
Unrealistic expectations
Lack of executive support
Changing requirements and specifications
Lack of planning
System no longer needed

Some part of the requirements process is involved in almost

all of these causes
Requirements error can be expensive if not detected early

12

The Requirements Process

Process for Capturing Requirements

Performed by the req. analyst or system analyst

The final outcome is a Software Requirements Specification
(SRS) document

13

The Requirements Process

Agile Requirements Modeling

If requirements are tighly coupled and complex, we may be

better off with a heavy process that empasizes up-front
modeling
If the requirements are uncertain, agile methods are an
alternative approach
Agile methods gather and implement the requirements in
increments
Extreme Programming (XP) is an agile process
The requirements are defined as we build the system
No planning or designing for possible future requirements
Encodes the requirements as test cases that eventually
implementation must pass
14

Requirements Elicitation
Customers do not always undertand what
their needs and problems are
It is important to discuss the requirements
with everyone who has a stake in the system
Come up with agreement on what the
requirements are
If we can not agree on what the requirements are,
then the project is doomed to fail
15

Requirements Elicitation
Stakeholders

Clients: pay for the software to be developed

Customers: buy the software after it is developed
Users: use the system
Domain experts: familiar with the problem that the software
must automate
Market Researchers: conduct surveys to determine future
trends and potential customers
Lawyers or auditors: familiar with government, safety, or legal
requirements
Software engineers or other technology experts

16

Requirements Elicitation
Using Viewpoints to Manage Inconsistency

No need to resolve inconsitencies early in the

requirements process (Easterbrook and Nuseibah, 1996)
Stakeholders' views documented and maintained as
separate Viewpoints through the software development
process
The requirements analyst defines consistency rules that should
apply between Viewpoints
The Viewpoints are analyzed to see if they conform to the
consistency requirements

Inconsistencies are highlighted but not adressed until

there is sufficient information to make informed decision
17

Requirements Elicitation
Means of Eliciting Requirements

Interviewing stake holders

Reviewing available documentations
Observing the current system (if one exists)
Apprenticing with users to learn about user's
task in more details
Interviewing user or stakeholders in groups
Using domain specific strategies, such as Joint
Application Design, or PIECES
Brainstorming with current and potential users

18

Requirements Elicitation

Means of Eliciting Requirements (continued)

The Volere requirements process model suggests some
additional sources for requirements

19

Types of Requirements
User requirements
Statements in natural language plus diagrams of the services
the system provides and its operational constraints. Written for
customers

System requirements
A structured document setting out detailed descriptions of the
system services. Written as a contract between client and
contractor

Software specifications
A detailed software description which can serve as a basis for a
design or implementation. Written for developers
Dr.V.S.R.Krishnaiah

20

Requirements Definitions and

specifications

Requirements definition

1. The software must provide a means of repr esenting and

1. accessing external files created by other tools.
Requirements specification
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the users display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
Dr.V.S.R.Krishnaiah

21

Requirements audience
User requirements

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

System requirements

System end-users
Client engineers
System architects
Software developers

Software design
specification

Client engineers (perhaps)

System architects
Software developers
Dr.V.S.R.Krishnaiah

22

Types of Software Requirements

Requirements can be broadly grouped into
two categories: functional requirements and
nonfunctional requirements .

Dr.V.S.R.Krishnaiah

23

Functional and non-functional

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

Non-functional requirements

constraints on the services or functions offered by the

system such as timing constraints, constraints on the
development process, standards, etc.

Domain requirements

Requirements that come from the application domain of the

system and that reflect characteristics of that domain
Dr.V.S.R.Krishnaiah

24

Functional requirements
Functional requirements pertain to those
requirements that state the functionality
required in the software system that the
customer is looking for.
A functional requirement could be, for
instance, to have a transaction ability so that
the user can purchase certain goods from the
Web site using a credit card.
Dr.V.S.R.Krishnaiah

25

Functional requirements
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

Dr.V.S.R.Krishnaiah

26

Examples of functional requirements

The user shall be able to search either all of the
initial set of databases or select a subset from it.
The system shall provide appropriate viewers for
the user to read documents in the document store.
Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to
the accounts permanent storage area.

Dr.V.S.R.Krishnaiah

27

Requirements imprecision
Problems arise when requirements are not precisely
stated
Ambiguous requirements may be interpreted in
different ways by developers and users
Consider the term appropriate viewers
User intention - special purpose viewer for each different
document type
Developer interpretation - Provide a text viewer that shows
the contents of the document

Dr.V.S.R.Krishnaiah

28

Requirements completeness and consistency

In principle requirements should be both complete
and consistent
Complete
They should include descriptions of all facilities required

Consistent
There should be no conflicts or contradictions in the
descriptions of the system facilities

In practice, it is impossible to produce a complete and

consistent requirements document

Dr.V.S.R.Krishnaiah

29

Non-functional requirements
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 CASE 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
Dr.V.S.R.Krishnaiah

30

Non-functional classifications
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.
Dr.V.S.R.Krishnaiah

31

Non-functional requirement types

Non-functional
requir ements

Product
requir ements

Ef ficiency
requir ements

Reliability
requir ements

Usability
requirements

Performance
requirements

Or ganizational
requir ements

Portability
requirements

Delivery
requirements

Interoperability
requirements

Implementation
requir ements

Space
requir ements
Dr.V.S.R.Krishnaiah

External
requirements

Ethical
requirements

Standards
requirements

Legislative
requirements

Privacy
requirements

Safety
requirements
32

Non-functional requirements examples

Product requirement
It shall be possible for all necessary communication
between the APSE and the user to be expressed in the
standard Ada character set

Organisational requirement
The system development process and deliverable
documents shall conform to the process and deliverables
defined in XYZCo-SP-STAN-95

External requirement
The system shall not disclose any personal information
about customers apart from their name and reference
number to the operators of the system
Dr.V.S.R.Krishnaiah

33

Requirements Development Process

Requirement development process flow
entails gathering requirements, formatting
requirement data, aggregating requirements,
maintaining hierarchy and relationship of
requirements to each other, and, finally,
prioritizing requirements.

Dr.V.S.R.Krishnaiah

34

Sources of software requirements

Standards
Business environmental requirements (e.g., laboratories, testing
and other facilities, and information technology infrastructure)
Technology
Business policies
Legacy products or product components (reuse product
components)

Dr.V.S.R.Krishnaiah

35

Techniques employed to elicit

requirements
Some of them include interface control working
groups, interim project reviews, operational
walkthroughs and end-user task analysis, technical
control working groups, technology demonstrations,
prototypes and models, brainstorming, customer
satisfaction surveys, quality function deployment,
market surveys, questionnaires, interviews, and
operational scenarios obtained from end users, beta
testing, extraction from sources such as documents,
standards, or specifications, observation of existing
products, environments, and workflow patterns, use
cases, business case analysis, and reverse engineering
Dr.V.S.R.Krishnaiah

36

Prioritizing Requirements for Staged Delivery

Must-have: A must-requirement is one that is essential to the
release; you cannot release the product without it. Must-have
features are implemented and tested as early as possible. They
command the full attention and resources of the project.
Should-have: A should-have requirement is one that is highly
desirable, you could, with proper justification, back the
requirement out of the release, but it is very important that you
deliver these features. Should-have requirements are
implemented and tested immediately after must-have
requirements.
Could-have: A could-have requirement is one that is desirable
but will be one of the last to be implemented and the first to be
reviewed for exclusion, should scheduling problems surface.
Dr.V.S.R.Krishnaiah

37

Requirement Development Tasks

Customer requirements are refined and elaborated to
develop product and product component
requirements.
Establish and maintain product and product
component requirements that are based on customer
requirements.
Allocate the requirements for each product
component.
Identify interface requirements.
The requirements are analyzed and validated, and a
definition of required functionality is developed.
Dr.V.S.R.Krishnaiah

38

Requirement Development Tasks

Establish and maintain operational concepts and
associated scenarios.
Establish and maintain a definition of required
functionality.
Analyze requirements to ensure that they are
necessary and sufficient.
Analyze requirements to balance stakeholder
needs and constraints.
Validate requirements to ensure that the
resulting product will perform as intended in the
user's environment.
Dr.V.S.R.Krishnaiah

39

Software Requirements Quality

Control
Software requirements can be checked or tested for
defects. Found defects can subsequently be removed,
and, thus, quality of the software requirements can be
improved. Some kinds of defects in the requirements
may include incoherent specification, wrong
specification, wrong assumption, incomplete
specification, and wrong relationship between
requirements. Through a thorough check, these defects
from requirement specifications can be removed.
The requirement development team itself can do these
tests, or a test team can perform these tests.
Dr.V.S.R.Krishnaiah

40

Software Requirements- Practical Strategy

1.

2.
3.
4.
5.
6.

7.

Requirements come in many forms (e-mail, chats, customer request,

meetings, reviews, etc.). So initial form varies. Use a standard template
to get all requirements so that requirement format is consistent and
that it is easy when they are to be incorporated in design. Capturing all
requirements is also possible this way.
Requirements should be verified with the source so that there is no
communication gap and requirements are captured as accurately as
possible.
Requirements should be complete, and no requirement should be
incomplete. Also, delivery dates should also be captured.
Requirements should be prioritized based on urgency, ROI, etc.
Communicate requirements as early as possible across all teams
especially to distributed teams.
Trace dependency among requirements so that if one requirement is
important but is dependent on another requirement that is not a
priority, then it has to be made sure that both requirements are
delivered.
Track requirement changes.
Dr.V.S.R.Krishnaiah

41

Conclusion
During requirement development, a lot of quality
aspects need to be checked. The relationship between
requirements, dependency of requirements, hierarchy
of requirements, etc., need to be checked. Formatting
of requirements also need to be checked. Apart from
correctness, other aspects like maintainability,
testability, and reliability also need to be checked.
During requirement management, the most critical
aspect to be checked is to assess the impact of change
on the entire development cycle. At the same time, the
right version of the requirement also needs to be
checked to ensure that no processes downstream use
wrong version of the requirement specifications.
Dr.V.S.R.Krishnaiah

42

Format of a software requirements

specifications
1. Product Overview and Summary
2. Development, Operating, and Maintenance Environments
3. External Interfaces and Data Flow
4. Functional Requirements
5. Performance Requirements
6. Exceptional Handling
7. Early subsets and Implementation Priorities
8. Foreseeable Modifications and Enhancements
9. Acceptance Criteria
10. Design Hints and Guidelines
11. Cross-reference Index
12. Glossary of Terms

Dr.V.S.R.Krishnaiah

43

software requirements specifications

Sections 1 and 2 of the requirements document present
an overview of product features and summarizes the
processing environments for development, operation,
and maintenance of the product.
Sections 3 specifies externally observable characteristics
of the software product. This include user displays and
report formats, a summary of user commands and
report options, data flow diagrams, and a data
dictionary. High level data flow diagrams and a data
dictionary are derived at the time this section is written.

Dr.V.S.R.Krishnaiah

44

software requirements specifications

Section 4 of a SRS specifies the functional requirements
for the software product. Functional requirements are
typically expressed in relational and state-oriented
notations that specify relationships among inputs,
action, and outputs.
Section 5 of requirements document specifies
performance characteristics such as response time for
various activities, processing time for various process,
throughput, primary and secondary memory
constraints, required telecommunication bandwidth,
and special items such as extraordinary security
constraints or unusual reliability requirements.
Dr.V.S.R.Krishnaiah

45

SRS
Section 6 of SRS describes exception handling,
including the actions to be taken and the messages
to be displayed in response to undesired situations
or events. A table of exception conditions and
exception responses should be prepared.

Categories of possible exceptions include temporary

resource failure, permanent resource failure,
incorrect, inconsistent, or out of range input data,
internal values, and parameters; violation of capacity
limits; and violations of restrictions on operators
Dr.V.S.R.Krishnaiah

46

Section 7 of the software requirements specification

specifies early subsets and implementation priorities for
the system under development. It is important to specify
implementation priorities for various system capabilities.
Essential features, desirable features, and nice if features
must be identified to provide guidance to the designers
and implementers.
Foreseeable modifications and enhancements that may
be incorporated into the product following initial product
release are specified in section 8 of the SRS. Foreseeable
product modifications might occur as a result of
anticipated changes in project budget or project mission,
as a result of new hardware acquisition, or as a result of
experience gained from an
initial release of the product.47
Dr.V.S.R.Krishnaiah

The software product acceptance criteria are specified in

section 9 of the requirements document. Acceptance
criteria specify functional and performance tests that
must be performed, and the standards to be applied to
source code, internal documentation, and external
documents such as the design specifications, the test
plan, the users manual the principles of operation, and
the installation and maintenance procedures.

Dr.V.S.R.Krishnaiah

48

Section 10 of the software requirements

specification contains design hints and guidelines.
The requirements specification is primarily
concerned with functional and performance
aspects of a software product, and emphasis is
placed on specifying product characteristics
without implying how the product will provide
those characteristics.

Dr.V.S.R.Krishnaiah

49

Section 11 relates product requirements to the sources of

information used in deriving requirements. A crossreference directory should be provided to index specific
paragraph numbers in the software requirements
specification to specific paragraphs in the system
definition and the preliminary user's manual, and to
other sources of information. Knowing the sources of
specific requirements permits verification and reexamination of requirements, constraints, and
assumptions.

Dr.V.S.R.Krishnaiah

50

Section 12 of the software requirements

specification provides definitions of terms that may
be unfamiliar to the customer and the product
developers. In particular, care should be taken to
define standard terms that are used in nonstandard ways.

Dr.V.S.R.Krishnaiah

51

Thanks

Dr.V.S.R.Krishnaiah

52