How to test software requirements specification (SRS)?
转自: http://space.itpub.net/?uid-11379785-action-viewspace-itemid-660907
Do you know “Most of the bugs in software are due to incomplete or
inaccurate functional requirements?” The software code, doesn’t matter
how well it’s written, can’t do anything if there are ambiguities in
requirements.
It’s better to catch the requirement ambiguities
and fix them in early development life cycle. Cost of fixing the bug
after completion of 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 software requirement specification (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. 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 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 next requirement.
We just learned how to measure the requirements and freeze those in design, implementation and testing phases.
Now
let’s take other example. I was working on a web based project. Client
(stakeholders) specified the project requirements for initial phase of
the project development. My manager circulated all the requirements in
the team for review. When we started discussion on these requirements,
we were just shocked! Everyone was having his or her own conception
about the requirements. We found lot of ambiguities in the ‘terms’
specified in requirement documents, which later on sent to client for
review/clarification.
Client used many ambiguous terms, which
were having many different meanings, making it difficult to analyze the
exact meaning. The next version of the requirement doc from client was
clear enough to freeze for design phase.
From this example we learned “Requirements should be clear and consistent”
Next criteria for testing the requirements specification is “Discover missing requirements”
Many
times project designers don’t get clear idea about specific modules and
they simply assume some requirements while 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 type of requirements i.e. what system should do and what 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 SRS document should supposed to cover. This helps me to
ask the questions about unspecified requirements making it clearer.
For
checking the requirements completeness, divide requirements in three
sections, ‘Must implement’ requirements, requirements those are not
specified but are ‘assumed’ and third type is ‘imagination’ type of
requirements. Check if all type of requirements are addressed before
software design phase.
Check if the requirements are related to the project goal.
Some
times stakeholders have their own expertise, which they expect to come
in system under development. They don’t think if that requirement is
relevant to project in hand. Make sure to identify such requirements.
Try to avoid the irrelevant requirements in first phase of the project
development cycle. If not possible ask the questions to stakeholders:
why you want to implement this specific requirement? This will describe
the particular requirement in detail making it easier for designing the
system considering the future scope.
But how to decide 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 irrelevant requirement. Ask the stakeholders if
they really want to implement these types of requirements.
In short requirements specification (SRS) doc 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 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 requirement phase to
avoid further requirement related bugs. Communicate more and more with
your stakeholder to clarify all the requirements before starting project
design and implementation.
Do you have any experience testing software requirements?