SRS is a complete specification and description of requirements of the software that need to be fulfilled for the successful development of the software system.

requirements can be functional as well as nonfunctional depending upon the type of requirement.

Features of a good SRS:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
   SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: SRS is complete if it includes:
   - All essential requirements
   - Definition of their responses
   - Full labels and references to all figurines, tables and diagrams.

3. Consistency: Consistent if, no subset of individual requirements described in its conflict.

4. Unambiguous: Unambiguous, when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted.

5. Modifiability: SRS should be made as modifiable and quickly obtain changes to the system to some extent.

6. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final software meets those requirements.

7. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition in future development or enhancement documentation.

8. Design Independence: should be an option to select from multiple design alternatives for the final system. the SRS should not contain any implementation details.

9. Testability: should be written in a way, it is simple to generate test cases and test plans from the report.

10. Understandable by the customer: the purpose of formal notations and symbols should be avoided too as much extent as possible. The language should be kept simple and clear.

Properties of a good SRS:

• Concise: SRS report should be concise and at the same time, unambiguous, consistent, and complete. Verbose and irrelevant descriptions decrease readability and also increase error possibilities.

• Structured: It should be well-structured. A well-structured document is simple to understand and modify. SRS document undergoes several revisions and user requirements evolve over time. To make the modifications to the SRS document easy, it is vital to make the report well-structured.

• Black-Box View: It should only define what the system should do and not stating how to do these. The SRS document should define the external behavior of the system and not discuss the implementation issues. The SRS report is also known as the black-box specification of a system.

• Conceptual Integrity: It should show conceptual integrity so that the reader can merely understand it.

  Response to undesired events: It should characterize acceptable responses to unwanted events. These are called system response to exceptional conditions.

• Verifiable: All requirements of the system, as documented in the SRS document, should be correct. i.e, it should be possible to decide whether or not requirements have been met in an implementation.