Chapter Four

Requirements Specification
Requirement Specification
• a collection of the set of all requirements that are
to be imposed on the design and verification of the
product.
• Fully describes what the software will do and how
it is expected to perform.
• Defines the software product to be built
• A manual of a project provided; it is prepared
before you kick-start a project/application.
• Contains both the definition of user requirements
and the specification of system requirements.
Different Types of Requirements

These examples that requirements are of different types.

1.Very general requirements, which set out in broad terms
what the system should do.
2.Functional requirements, which define part of the
system’s functionality.
3.Implementation requirements, which state how the
system must be implemented.
4.Performance requirements, which specify a minimum
acceptable performance for the system.
5.Usability requirements, which specify the maximum
acceptable time to demonstrate the use of the system.
Common Requirements problems

• The requirements don’t reflect the real needs of the customer

for the system.

• Requirements are inconsistent and/or incomplete.

• It is expensive to make changes to requirements after they

have been agreed.

• There are misunderstandings between customers, those

developing the system requirements and software engineers
developing or maintaining the system.
Wrong Requirements
• There are number of penalties which arise when the system
requirements are wrong.
• 1. the system may be delivered late and cost more than
originally expected.
• 2. the customer and end-user are not satisfied with the
system. They may not use its facilities or may even decide to
scrap it altogether.
• 3. the system may be unreliable in use, with regular system
errors and crashes disrupting normal operation.
• 4. if the system continuous in use, the costs of maintaining
and evolving the system are usually very high.
Requirements management

• Requirement management is the process of managing

changes to the system requirements.
• Requirements for a system always change to reflect the
changing needs of system stakeholders, changes in the
environment in which the system is to be installed, changes
in the business which plans to install the system, changes in
laws and regulations, etc.
Software Requirement document
• Also called software requirement specification
• An official statement of the system requirements for
customers, end-users, and software developers.
• There is no standard name for this document.
• Depending on the organization, the requirements document
may have different names such as the ‘functional
specification’, ‘the requirement definition’, ‘the software
requirements specification(SRS)’, etc.
• an official document of what should be implemented.
• developed based on the agreement between customer and
contractors.
The Requirements document
• The requirements document describes:
• The services and functions which the system should provide.
• The constraints under which the system must operate.
• Overall properties of the system i.e.. constraints on the
system’s emergent properties.
• Definitions of other systems which the system must integrate
with.
• Information about the application domain of the system e.g.
how to carry out particular types of computation.
• Constraints on the processes used to develop the system.
• The requirements document should always include an
introductory chapter which provides an overview of the
system, business needs supported by the system and a
glossary which explains the terminology used.
A requirement document includes:

• The purpose of the software being developed

• An overall description of the software
• The functionality of the software or what it is supposed
to do
• Performance of the software in a production situation
• Non-functional requirements
• External interfaces or how the software will interact
with hardware or other software it must connect to
• Design constraints or the limitations of the environment
that the software will run in
Different system stakeholders from different backgrounds will read
the requirements document and use it in different ways.
Specify the requirements and
System read them to check that they
customers meet their needs. They specify
changes to the requirements.
Use the requirements
Project document to plan a bid for the
Managers system and to plan the system
development process.
Use the requirements to
System engineers understand the system being
developed.
Use the requirements to
System test
develop validation tests for the
engineers
system.

System Use the requirements to help

maintenance understand the system and the
engineers relationships between its parts.
Requirements document structure
• The first step in the process is to create an outline for SRS
document. Here is a most commonly used outline:
1. Introduction
• Purpose
• Intended Audience
• Intended Use
• Scope
• Definitions
2. Overall Description
• User Needs
• Assumptions and Dependencies
3. System Features and Requirements
• Functional Requirements
• External Interface Requirements
• System Features
• Non-functional Requirements
Steps- Define the Purpose

• Start with defining the purpose of the product in the

introduction of your SRS. Here, the intended audience and
how they will use the product will be described. Here’s the
structure of the purpose:
• Define the product’s scope
• Describe the value it will deliver
• Show who will use the software
• Detail how it will help with the intended users’ job
Steps- Give an Overview

• After defining the product’s purpose, summarize how it will

work. The general description of the software’s features and
how they fit the user’s needs will be provided.
• The assumptions made about the product’s functionality and
anything it depends on in the current tech ecosystem will be
described.
Steps- Describe Functional and Non-functional
Requirements

• This detailed description of the system’s requirements is the

most essential component of an SRS document. Describe the
functional requirements in enough detail so developers can
get to work and the non-functional requirements like security
specifications and performance will be mentioned.
• Here, use cases to vividly describe how a user will interact
with your system will be added. It is where the project’s
objectives are detailed and how the project is progressing
during development are measured.`
Use Cases in an SRS

• A use case describes how a user will interact with the

system.
• It will describe the product from the end user’s point of view
in a simple story format.
• Writing out use cases forces you to think through what users
will do with the software and how it will respond.
• It is the real-life visualization of the functional requirements.
Use Cases in an SRS - steps

Steps to follow in writing a use case:

1. Describe your product’s end users.
2. Focus on one of these users.
3. Break this user’s interactions down into use cases. Each
interaction is a use case.
4. Describe the sequence of events for each use case.
5. Write a detailed description of the user’s actions and how
the system should respond.
6. Expand each use case with alternate user actions and
system responses.
7. Repeat 1-6 for each type of end-user
Writing requirements
• Requirements are usually written as paragraphs of natural
language text, supplemented by diagrams and equations.
Common Problems with requirements:
1.The requirements are written using complex conditional
clauses(if A then if B then If C…) which are confusing.
2.Terminology is used in a disordered and inconsistent way.
3.The writers of the requirement assume that the reader has
specific knowledge of the domain or the system and they leave
essential information out of the requirement.

• These problems make it difficult to check the set of

requirements for errors and omissions.
Three essential things to bear in mind when writing requirements

1.Requirements are read more often than they are written. You
should invest time to write readable and understandable
requirements.

2.Do not assume that all readers of the requirements have the
same background and use the same terminology as you.

3.Allow time for review, revision and re-drafting of the

requirements document.
Characteristics of a requirement document
Explicit
• An SRS document should be easy to understand. Nothing should
be vague, so there are no misunderstandings between
stakeholders.
Measurable
• The requirements in your SRS document need to be measurable,
so the finished product can be validated and verified against the
specifications.
Complete
• An SRS document should have enough information for
the development team to finish the product and for testers to
validate that the product meets the user’s need without bugs.
Viable
• The requirements should fit the reality of the current
environment, including the budget, timeline, and technology.
They shouldn’t depend on upcoming technological
breakthroughs.
Characteristics of a requirement document
Flexible
• Because things could change in the working environment,
your SRS document should be flexible enough to allow for
updates. Don’t add redundant information to multiple
sections that have to be updated with each change.
Verifiable
• Everyone on the development team should have access to the
document so they can reference it as frequently as necessary.
Requirements need to be precise so that team members do
not have to ask for more details. They should all be available
in the SRS document.
Consistent
• The requirements should fit each other. One section should
not conflict with another. The document should be formatted
consistently and used the same terminology throughout.
Characteristics of a requirement document
No Implementation Constraints
• An SRS document should be detailed enough to finish the
job, but should not be overly specific, because that might
restrict development. A lot of development depends on third-
party services that developers have no control over.
Accurate
• Goals in a requirements document should be precise to avoid
confusion.
What to avoid in a requirement document

• Loopholes
• Ambiguity
• Subjectivity
• Superlatives
• Comparative
Writing guidelines
• Define standard templates for describing requirements:
• You should define a set of standard format for different types of requirements
and always express requirements using that format. This makes is less likely that
important information will be missed out and makes it easier for the reader to
understand the different parts of the requirement.
• Use language simply, consistently and briefly:
• Don’t write requirements using complex language but follow good writing
practice such as using short sentences and paragraphs, using lists and tables and
avoiding jargon whenever possible.
• Use diagrams appropriately:
• You should not develop complex diagrams but should use diagrams to present
broad overviews and to show relationships between entities.
• Supplement natural language with other description of requirements:
• Don’t try to write everything in natural language. If readers of the requirements
document are likely to be familiar with other types of notation (e.g. equations),
you should not hesitate to use these.
• Specify requirements quantitatively.
• Whenever possible, you should specify your requirements quantitatively, this is
often possible when you are specifying the properties of a system such as
reliability, usability or performance.