Software requirement specification (SRS) ?

Software Requirements Specification (SRS) is complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Nonfunctional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, and design constraints).

1.      What Makes a Great Software Requirements Specification?

We have to keep in mind that the goal is not to create great specifications but to create great products and great software. Can you create a great product without a great specification? Absolutely! You can also make your first million through the lottery – but why take your chances? Systems and software these days are so complex that to embark on the design before knowing what you are going to build is foolish and risky.

2.      What are the benefits of a Great SRS?

·         Establish the basis for agreement between the customers and the suppliers on what the software product is to do.

·         Reduce the development effort.

·         Provide a basis for estimating costs and schedules.

·         Provide a baseline for validation and verification.

·         Facilitate transfer.

·         Serve as a basis for enhancement.

3.      What are the characteristics of a great SRS?

·         Correct

·          Unambiguous

·          Complete

·          Consistent

·          Ranked for importance and/or stability

·          Verifiable

·          Modifiable

·          Traceable

4.      Difference between a design requirement and software requirement?

The SRS should not include any design requirements. However, this is a difficult discipline. For example, because of the partitioning and the particular RTOS you are using, and the particular hardware you are using, you may require that no task use more than 1 ms of processing prior to releasing control back to the RTOS. Although that may be a true requirement and it involves software and should be tested – it is truly a design requirement and should be included in the Software Design Document or in the Source code.

Consider the target audience for each specification to identify what goes into what documents.

Marketing/Product Management

Creates a product specification and gives it to Systems. It should define everything Systems needs to specify the product

Systems

Creates a System Specification and gives it to Systems/Software and Mechanical and Electrical Design.

Systems/Software

Creates a Software Specification and gives it to Software. It should define everything Software needs to develop the software.

Thus, the SRS should define everything explicitly or (preferably) by reference that software needs to develop the software. References should include the version number of the target document. Also, consider using master document tools which allow you to include other documents and easily access the full requirements.