How to write a good SRS

In the process of development, we may be assign to write the SRS. first of all, we will follow the template in respective company, then we find it's not all we need to do here. because the complex of each template, it's difficult to be applicable to our varous projects, we shoshould know how to tailor it according the situation in that project. even though, we still have some general tips can be found below that is experience in my past projects.

In my opinion, there will be five categories as follows:

1. Scenarios

2. User Interfaces

3. system interfaces

4. A traceability Matrix

5. General Business Rules

 

Scenarios

In URS, some use cases are addressed there. here in SRS, In my point of view, one integral scenario based is to be written here without any design requirements, some other system requirements are stored as well. here, I explain a little bit the diference between system requirement and software requirement.

System Requirement

• Define the functions of the system
• Define the hardware/software functional partitioning
• Define the performance specification
• Define the hardware/software performance partitioning
• Define safety requirements
• Define the user interface (a good user's manual is often an overlooked part of the system specification. snapshot of our MERs haven' t even considered that this is the right time to write the user's manual .)
• Provide installation drawings/instructions.
• Provide interface control drawings (ICD's, external I/O)

Software Requirement

•  Functional requirements
• Non-functional requirements

From above, we find that the scope of system requirment includes des the latter one. how many scenarios we will describe on one user case depends on the complexity of that its priority, one important princile is the major and successful must be addressed.

User Interfaces

If there is no corresponding interfaces described in URS, it must be described here. In order to understand it easily, some screeshots can be posted directly.

System interfaces

In our application, frequently we have some interfaces with other applications. here by which way our application has contact with others shocould be addressed. the details may include the data format, the manners, and so on.

A traceability Matrix

For each requirement point, you shoshould give them a unique key to trace it in your whole development process. another advantage is to make your requirement in your control so that the situation can be handled when some conflicts occur. on the other hand, you can easily trace the whole path on one specific requirement, that is to say, once it's change from the client, you can find its influencing scope.

General Business Rules

In our document, some words which are ambiguous or uncertain shocould be pay attention to use. some words you must know the implicit meaning. about this part, you can see the reference doc (writing software requirements specifications ).

 

In conclusion, writting a professional document is not easy, hope this summary helpful for you.

 

Reference:

How to Write a software requirements specification

writing software requirements specifications