Most of the project failures are the result of poor SRS or no SRS at all. The SRS should be complete enough to be understood by the technical and non-technical personals involved in the project.
During the development, tracing each requirement in the SRS document with the application being developed assure the creditability and shows the progress.
Attributes of the complete SRS
To make sure that the SRS is up to the mark of completion, some attributes must be validated.
Agile Requirement Engineering
The SRS document should possess all the significant requirements whether related to functionality, design constraints, behavior constraints, performance and about the external interfaces. All these requirements should be listed and acknowledged.
The SRS should list the responses against the realizable set of input. The input set includes all the data flowing into the application and list all the procedure and validation that the application will perform on the input data.
Number every figure and Page in SRS
The SRS should be numbered from all perspectives i.e. all the figures, Tables, Charts, all the unit of measures and terms, all the referenced material, and the sections. This not only increases the SRS modification very easy and helps to understand the requirements in supportive way. This way you help the non-technical persons to understand, what to build actually in transparent manner.
Eliminate, To Be Determined Sections
No part of the SRS document should be marked as, “To be Determined.” This makes the SRS document in complete. However, if there is anything, has to be declared, then it should be accompanied by the description, as what situation is causing this part to be delayed. The person name, which is responsible for the completion for TBD section. TBD section must mention the expected time of completion.
Traceability of the Software requirement Specification-SRS
Traceability of the SRS ensures the complete track of every requirement that is being fulfilled by a specific module and it mentions the future development or enhancements to documentation. Traceability is high priority task, and is very effective for a complex projects. To keep track of every requirement for complex and the lengthy projects, where the requirements are being updated most of the time is very difficult. For this purpose SRS provides the complete track of the requirement, which module is completing the specific requirement and what are the possible updates to made, becomes very easy with proper maintained Software requirement specification. SRS ensures this by the use of traceability technique.
Techniques of traceability for Software Requirement Specification – SRS
To maintain the up-to-date and locate the each requirement is an indexed manner, involves some rules to be implemented. These are the best concluded by the software professionals in the industry.
Number every paragraph hierarchically
This technique is a standardized set of styles that renumber Parts, paragraphs and sub-paragraphs when they are added or removed. By following this technique, you will get the related paragraphs, requirements, and information in organized manner.
State only the solo requirement in each Paragraph
Numbering each paragraph involves to number each every related requirement, and this rule enforces that no more than one requirement should be stated in the single paragraph. This shortens the locating time for every requirement and also increases the readability and modifiability.
Number every requirement
Once you have specified the requirement in the SRS, immediately place the number in the parentheses for reference, e.g., [1], [1.2], [2.3.4] etc. [1] shows the requirement number is starting where as the [1.2] that the requirement number is 2 and this is the sub requirement of the earlier stated requirement [1].
Convention for indicating a Requirement
This technique enforces the rule with the readability point of view. For example, the common approach is to use the shall statement for every requirement. This is as such not a defined; you may use your custom convention as well.
Types for Traceability for Software Requirements Specifications
There are four types of traceability techniques for SRS, defined as follows.
Backward from requirements
This traceability type implies that why every requirement in the SRS exists. State the reasons and the evidences to proof the existence for the requirement. This explores the description of the requirement and helps understand everyone the reason behind every requirement.
Forward from requirements
This traceability helps to know, which part of the software fulfills the specific requirement.
Backward to requirements
Backward to requirements implies that every module or component of the software should explicitly reference each requirement that it helps satisfy. For example, on every screen of the software, we can mention the operations that the user may perform.
Forward to Requirements
Forward to requirements implies that every document that is created after the SRS document, must mention the requirement number that the document satisfies. For an example, the use- case diagram, ERD diagram or others that are created after the SRS, should mention what specific requirement is being satisfied in this current document.
Read more about how to make Software Requirements Specification Complete
This article explains the general techniques for creating the effective SRS. More technical details may be explored by visiting the links below.