How to Test Software Requirements Specification (SRS)?

Are you aware that “Most of the Bugs in software are due to incomplete or inaccurate functional requirements?” However well it is written, the software code does not matter and nothing can be done if there are any ambiguities in the requirements.

This tutorial on Software Requirements Specification (SRS) states that Requirements must be clear, specific, measurable and complete without contradictions.

It’s better to catch the requirement ambiguities and fix them in the early development life cycle itself. 

The cost of fixing the bug after completion of the development or product release is too high.  So it’s important to have requirement analysis and catch these incorrect requirements before design specifications and project implementation phases of SDLC.

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 that they 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 during the initial phase of the project development. My manager circulated all the requirements to 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 had many different meanings, thereby 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 the “Requirements should be clear and consistent”

The next criteria for testing the requirements specification is to “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. None of the requirements should be based on assumptions. Requirements should be complete, covering each and every aspect of the system under development.

Specifications should state both the types of requirements i.e., what the 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 will help me to ask questions about the unspecified requirements thereby making it clearer.

To check the completeness of the requirements, divide the 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 types of requirements are 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 into the system under development. They don’t even think about whether that requirement would be relevant to the project in hand. Make sure to identify such requirements.

Try avoiding 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 that particular requirement in detail, thereby making it easier to design 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 in 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.

Conclusion

We have covered almost all aspects of the requirement measurement. To be specific about the requirements, we will summarize the requirement testing shortly.

“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 during 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? Please feel free to share them in the comments below.