3. Software Requirements Analysis and Specification

IEEE defines a requirement as “(1) A condition of capability needed by a user to solve a problem or achieve an objective; (2) A condition or a capability that must be met or possessed by a system ... to satisfy a contract, standard, specification, or other formally imposed document” [53]. Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capabilities that the system, which is yet to be developed, should have.

As we have seen, all development models require requirements to be specified. Approaches like agile require only high-level requirements to be specified in written form—detailed requirements are elicited through interaction with the customer in the iteration the requirement is to be implemented and directly reflected in software. Other approaches prefer that the requirements are specified precisely. In such situations, the goal of the requirements activity is to produce the Software Requirements Specification (SRS) that describes what the proposed software should do without describing how the software will do it.
In this chapter we will discuss:

• The role of the SRS in a project and the value a good SRS brings to it.
• The different activities in the process for producing the desired SRS.
• The desired characteristics of an SRS, the structure of an SRS document, and its key components.
• The use case approach for analyzing and specifying functional requirements, and how use cases can be developed.
• Some other approaches for analyzing requirements like the data flow diagram.
• How requirements are validated.