How to create complete and Traceable SRS – Software Requirements Specification Document

Posted by : Khurram Shahzad on 04 Dec, 2011

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.

Types of software requirements traceability

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.

Share with your friends

0 Resonses to "How to create complete and Traceable SRS – Software Requirements Specification Document"

Leave a Reply

Name (Required)
Email (Required)