Unit Ii
Unit Ii
• Concise: The 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. In practice, the SRS document undergoes several
revisions to cope up with the user requirements. Often, user requirements evolve
over a period of time. Therefore, 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 refrain from
stating how to do these. This means that the SRS document should define the
external behavior of the system and not discuss the implementation issues. The
SRS report should view the system to be developed as a black box and should
define the externally visible behavior of the system. For this reason, 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. This means that it should be possible to decide
whether or not requirements have been met in an implementation.