Testing the requirement specification document.


Testing the requirement specification document.

The requirement specification document is the official requirements document for what needs to be done by the software development team. It includes all definitions of user requirements and system requirements specification, not system design documents.

As we know, "Most bugs in software are caused by incomplete or inaccurate function." How the software code is written is not important, we would not be able to do anything if there were ambiguities in the requirement.

The ambiguities about requirements and fixing them early in the software development life cycle are best. The cost of fixing bugs after the software has completed or has been released is quite high. Therefore, it is important to have requirements analysis and capture requirements correctly before designing and implementing a project.


  • How to be sure of the proper understanding of the requirement specification document? 


We need to define some test standards and make sure of the proper understanding of the software requirements.


  • So how to understand the requirements in the design, implementation and testing phases. 


The client specifies the project requirements for the early phase of project development. When starting to discuss these requirements, everyone has their own opinion of the requirements, seeing a lot of ambiguity about the requirements in the requirements documents, which need to be sent to clients for review / clarify. Clients use many vague terms, which have so many different meanings, it is difficult to analyze the meaning accurately.

After clarifying the requirements with the client, the next version of the client requirement was clear enough to be understood during the design phase.

 “The requirement must be clear and suitable."

Many project designers have no clear idea about specific modules and they simply think of acknowledging some requirements during the design phase. Any requirement should not be based on assumptions. The requirement must be fulfilled, covered every part and all aspects of the system being developed.

The specifications should include both: What should the system do and what should not do?

To test the requirements towards fulfilment, the requirement should be divided into three parts:

  • 'Must do' requirement.
  • These requirements are not specified but need to make assumptions for verification.
  • The third type is the ‘image’ type of requirement.



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


The simple answer: Set project goals and ask questions for related issues: What would this problem be if not fulfilling this requirement in achieving the goal? If not, then this is an unrelated request.

In the short requirement specification (SRS), the following should be handled:

  • Project functions (What to do and what not to do).
  • Software, hardware interface and user interface.
  • The correctness of the system, security and performance criteria.
  • Implementation issues (risks)