Are you aware that “Most of the bugs in software are due to incomplete or inaccurate functional requirements?” However well its written, the software code does not matter and nothing can be done if there are any ambiguities in requirements. This article 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.
Cost of fixing the bug after completion of the development or product release is too high. So it’s important to have a requirement analysis and catch these incorrect requirements before design specifications and project implementation phases of SDLC.
What You Will Learn:
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 to 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.
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 requirements completeness, 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.
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, 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.
I have covered almost all the 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?
Please feel free to share them in the comments below.