How To Test Software Requirements Specification (SRS)?

Spec Review

How To Measure Functional SRS Documents?

Well, we need to define some standard tests to measure the requirements. Once each requirement is
passed through these tests you can evaluate and freeze the functional requirements.

Let's take an example, you are working on a web-based application. The requirement is as follows:
“Web application should be able to serve the user queries as early as possible”

How will you freeze the Requirement in this case?

What will be your Requirement Satisfaction criteria? To get the answer, ask this question to the
stakeholders: How much response time is ok for you? If they say, we will accept the response if it's
within 2 seconds, then this is your requirement measure. Freeze this requirement and carry the same
procedure for the next requirement too.

We just learned how to measure the requirements and freeze those in Design, Implementation and
Testing phases.

Now let's take another example: I was working on a Web-Based project. Client (stakeholders) specified
the project requirements at the initial phase of the project development. My manager circulated all the
requirements in the team for review. When we started the discussion on these requirements, we were
just shocked!

Everyone was having his or her own conception about the requirements. We found a lot of ambiguities
in the ‘terms’ specified in the requirement documents, which later on was sent to the client for
review/clarification.

The client used many ambiguous terms, which were having many different meanings, making it
difficult for us to analyze the exact meaning. The next version of the requirement doc from the client
was clear enough to freeze for the design phase.

From this example, we learned that “Requirements should be clear and consistent”

Next criteria for testing the requirements specification is “Discover missing requirements”, let's take a
look at it.

Discover Missing Requirements

Many times the project designers don't get a clear idea about each specific module and they simply
assume some requirements in the design phase. Any requirement should not be based on assumptions.
Requirements should be complete, covering each and every aspect of the system under development.

Specifications should state both types of the requirement i.e. what system should do and what it should
not.
Generally, I use my own method to uncover the unspecified requirements. When I read the Software
Requirements Specification document (SRS), I note down my own understanding of the requirements
that are specified, plus other requirements that the SRS document is supposed to cover.

This helps me to ask the questions about the unspecified requirements thereby making it clearer.

For checking the completeness of the requirements, divide requirements into three sections, ‘Must
implement' requirements, requirements that are not specified but are ‘assumed' and the third type is
‘imagination' type of requirements. Check if all the type of requirements is addressed before the
software design phase.

Check If The Requirements Are Related To The Project Goal

Sometimes stakeholders have their own expertise, which they expect to come in the system under
development. They don't even think whether that requirement would be relevant to the project in hand.
Make sure to identify such requirements. Try to avoid all irrelevant requirements during the first phase
of the project development cycle.

If not possible, then ask the questions to stakeholders like why do you want to implement this specific
requirement? This will describe the particular requirement in detail, thereby making it easier for
designing the system considering the future scope.

But how to decide whether the requirements are relevant or not?

Simple answer: Set the project goal and ask this question: If not implementing this requirement will
cause any problem achieving our specified goal? If not, then this is an irrelevant requirement. Ask the
stakeholders if they really want to implement these types of requirements.

In short, the Requirements Specification (SRS) doc should address the following:

Project functionality (What should be done and what should not be done).
Software, Hardware interfaces, and the user interface.
System Correctness, Security and performance criteria.
Implementation issues (risks) if any.

In short requirements specification (SRS) document should address following:

Project functionality (What should be done and what should not)

Software, Hardware interfaces and user interface
System Correctness, Security and performance criteria
Implementation issues (risks), if any

Conclusion
I have covered almost all aspects of requirement measurement. To be specific about requirements, I
will summarize requirement testing in one sentence:

“Requirements should be clear and specific with no uncertainty, requirements should be measurable in
terms of specific values, requirements should be testable having some evaluation criteria for each
requirement, and requirements should be complete, without any contradictions”
Testing should start at the requirement phase to avoid further requirement related bugs. Communicate
more and more with your stakeholders to clarify all the requirements before starting the project design
and implementation.

Do you have any experience in Testing Software Requirements?

In this article we have covered characteristics of requirement measurement. Here I am sum up the
requirement testing in simple statement:

Requirements should be clear and every point should specifically mention.

Requirements should be complete, without any inconsistency.
Requirements should be testable and every testable requirement should have some criteria to evaluate
the requirement.
Requirements should be measurable and it can be measured with specific standards/terms.

1. Correctness of SRS should be checked. Since the whole testing phase is dependent on SRS, it is very
important to check its correctness. There are some standards with which we can compare and verify.

2. Ambiguity should be avoided. Sometimes in SRS, some words have more than one meaning and this
might confused testers making it difficult to get the exact reference. It is advisable to check for such
ambiguous words and make the meaning clear for better understanding.

3. Requirements should be complete. When tester writes test cases, what exactly is required from the
application, is the first thing which needs to be clear. For e.g. if application needs to send the specific
data of some specific size then it should be clearly mentioned in SRS that how much data and what is
the size limit to send.

4. Consistent requirements.The SRS should be consistent within itself and consistent to its reference
documents. If you call an input “Start and Stop” in one place, don’t call it “Start/Stop” in another. This
sets the standard and should be followed throughout the testing phase.

5. Verification of expected result: SRS should not have statements like “Work as expected”, it should
be clearly stated that what is expected since different testers would have different thinking aspects and
may draw different results from this statement.

6. Testing environment: some applications need specific conditions to test and also a particular
environment for accurate result. SRS should have clear documentation on what type of environment is
needed to set up.

7. Pre-conditions defined clearly: one of the most important part of test cases is pre-conditions. If they
are not met properly then actual result will always be different expected result. Verify that in SRS, all
the pre-conditions are mentioned clearly.

8. Requirements ID: these are the base of test case template. Based on requirement Ids, test case ids are
written. Also, requirements ids make it easy to categorize modules so just by looking at them, tester
will know which module to refer. SRS must have them such as id defines a particular module.
9. Security and Performance criteria: security is priority when a software is tested especially when it is
built in such a way that it contains some crucial information when leaked can cause harm to business.
Tester should check that all the security related requirements are properly defined and are clear to him.
Also, when we talk about performance of a software, it plays a very important role in business so all
the requirements related to performance must be clear to the tester and he must also know when and
how much stress or load testing should be done to test the performance.

10. Assumption should be avoided: sometimes when requirement is not cleared to tester, he tends to
make some assumptions related to it, which is not a right way to do testing as assumptions could go
wrong and hence, test results may vary. It is better to avoid assumptions and ask clients about all the
“missing requirements” to have a better understanding of expected results.

11. Deletion of irrelevant requirements: there are more than one team who work on SRS so it might be
possible that some irrelevant requirements are included in SRS. Based on the understanding of the
software, tester can find out which are these requirements and remove them to avoid confusions and
reduce work load.

12. Freeze requirements: when an ambiguous or incomplete requirement is sent to client to analyze and
tester gets a reply, that requirement result will be updated in the next SRS version and client will freeze
that requirement. Freezing here means that result will not change again until and unless some major
addition or modification is introduced in the software.

What Is the Structure of SRS?

Introduction (purpose, scope, terms, references, overview).
Overall description (product perspective, functions, user characteristics, assumptions, etc.).
Specific requirements (for interface, performance, design, etc.).
SRS should be unambiguous, complete, correct, consistent, modifiable and verifiable. It captures a set
of various requirements types:

functional
performance
quality
safety
reliability
interface
maintainability
operational

What is Software Requirement Specification - [SRS]?

A software requirements specification (SRS) is a document that captures complete description about
how the system is expected to perform. It is usually signed off at the end of requirements engineering
phase.

Qualities of SRS:
Correct
Unambiguous
Complete
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable

Key components of an SRS

The main sections of a software requirements specification are:

Business drivers – this section describes the reasons the customer is looking to build the system,
including problems with the currently system and opportunities the new system will provide.
Business model – this section describes the business model of the customer that the system has to
support, including organizational, business context, main business functions and process flow
diagrams.
Business/functional and system requirements -- this section typically consists of requirements that are
organized in a hierarchical structure. The business/functional requirements are at the top level and the
detailed system requirements are listed as child items.
Business and system use cases -- this section consists of a Unified Modeling Language (UML) use case
diagram depicting the key external entities that will be interacting with the system and the different use
cases that they’ll have to perform.
Technical requirements -- this section lists the non-functional requirements that make up the technical
environment where software needs to operate and the technical restrictions under which it needs to
operate.
System qualities -- this section is used to describe the non-functional requirements that define the
quality attributes of the system, such as reliability, serviceability, security, scalability, availability and
maintainability.
Constraints and assumptions -- this section includes any constraints that the customer has imposed on
the system design. It also includes the requirements engineering team’s assumptions about what is
expected to happen during the project.
Acceptance criteria -- this section details the conditions that must be met for the customer to accept the
final system

RS Template
The following is a simple SRS template:

Table of Contents

1. Introduction
1.1 Purpose of this document
1.2 Scope of this document
1.3 Overview
1.4 Business Context

2. General Description
2.1 Product Functions
2.2 Similar System Information
2.3 User Characteristics
2.4 User Problem Statement
2.5 User Objectives
2.6 General Constraints
3. Functional Requirements

4. Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Communications Interfaces
4.4 Software Interfaces

5. Performance Requirements

6. Other non-functional attributes

6.1 Security
6.3 Reliability
6.4 Maintainability
6.5 Portability
6.6 Extensibility
6.7 Reusability
6.8 Application Affinity/Compatibility

7. Operational Scenarios

8. Preliminary Use Case Models and Sequence Diagrams

8.1 Use Case Model
8.2 Sequence Diagrams

9. Updated Schedule

10. Appendices
10.1 Definitions, Acronyms, Abbreviations
10.2 References

eatures of an SRS
An SRS should have following characteristics:

Correct -- should accurately reflect product functionality and specification at any point of time.
Unambiguous -- should not be any confusion regarding interpretation of the requirements.
Complete -- should contain all the features requested by a client.
Consistent -- same abbreviation and conventions must be followed throughout the document.
Ranked for importance and/or stability -- every requirement is important. But some are urgent and must
be fulfilled before other requirements and some could be delayed. It’s better to classify each
requirement according to its importance and stability.
Verifiable -- an SRS is verifiable only if every stated requirement can be verified. A requirement is
verifiable if there is some method to quantifiably measure whether the final software meets that
requirement.
Modifiable -- an SRS must clearly identify each and every requirement in a systematic manner. If there
are any changes, the specific requirements and the dependent ones can be modified accordingly without
impact the others.
Traceable – an SRS is traceable if the origin of each of its requirements is clear and if it makes it easy
to reference each requirement in future development.

Spec Review length

The Specification Review is conducted by two experienced developers at the client premises in close
consultation with the client. The time allocated for a Spec Review is generally 1 - 5 days depending on
initial expectations of the project. The rule of thumb is 1 - 2 days of Spec Review per estimated month
of project time.

The purpose is to understand the whole project but, if the project is greater than six months, focus
primarily on the first six months.

Talk about business requirements

Conduct Workshops: Conduct workshops with different groups of users (e.g. management, back office,
customer service) to build the "Product Backlog" which the business wants. This ensures that all users
get their say. Some "nice-to-haves" might actually be quite easy to implement. Product Backlog Items
can then be prioritized and fleshed out.
Review Documentation: Reviewing any documentation the client may already have. Remember clients
are mostly looking to software consultants to assist them in solving business problems.
Keep Technology discussions short: Unless they have a specific business purpose, detailed discussions
about technology with the client are unlikely to be useful. For example, most clients won't be interested
in a discussion about whether to use MVC or Angular at this stage.
Identify an MVP: Most client can't afford everything they want, so make sure you're keeping track of
the minimum we can do to deliver value.

Specification Review Deliverables?

Requirements Analysis
An architectural roadmap recommending technical solutions
A breakdown of the required software application into its core components, likely to include the
approximate number of main features (e.g. forms, reports, etc.)
An integration plan
A deployment strategy
An MVP (minimum viable product) will be identified, as well as a wish list - requiring the client to set
the priorities for the project through defining what is in and out of scope for the MVP
A detailed list of 'issues' associated with the existing system which impact future development and
maintenance
Hardware and licensed software recommendations
Mock-ups if required
Summary Product Backlog

A list of product backlog items (PBIs) will be broken down based on the Requirements Analysis and
the Architectural Design
These PBIs will then be estimated
Ballpark Estimates

The estimated number of sprints

Estimated cost of the project

General Project Costs

Management costs can change depending on how much management the client requires. You should
recommend a suitable level of management. 'Management, accountability and transparency' has a cost.

You should add general project costs as a % of the work items generally in line with the following (note
that these numbers are just best guesses):

Testing: 20%
Bug Fixes: 20%
Software Audit (if relevant): 4 hours per Release - usually conducted by two experienced Architects
Fixes from the Software Audit: 5%
DevOps: 10%
Project Management: 15% - this includes items like stand up meetings, timesheets, standard updates,
reviews, etc.
Unknowns (for risky projects): 10%. While this is arbitrary it raises awareness for everybody that 'there
are things we still don't know!'