3.7 Summary

• The main goal of the requirements process is to produce the software requirements specification (SRS) which accurately captures the client’s requirements and which forms the basis of software development and validation.
• There are three basic activities in the requirements process—problem analysis, specification, and validation. The goal of analysis is to understand the different aspects of the problem, its context, and how it fits within the client’s organization. In requirements specification the understood problem is specified or written, producing the SRS. Requirements validation is done to ensure that the requirements specified in the SRS are indeed what are desired.
• The key desirable characteristics of an SRS are: correctness, completeness, consistency, unambiguousness, verifiability, and ranked for importance.
• A good SRS should specify all the functions the software needs to support, performance requirements of the system, the design constraints that exist, and all the external interfaces.
• Use cases are a popular approach for specifying functional requirements.
• Each use case specifies the interaction of the system with the primary actor, who initiates the use case for achieving some goal.
• A use case has a precondition, a normal scenario, as well as many exceptional scenarios, thereby providing the complete behavior of the system. 
• For developing use cases, first the actors and goal should be identified, then the main success scenarios, then the failure conditions, and finally the failure handling.
• With data flow diagrams, a system is analyzed from the point of view of how data flows through the system. A DFD consists of processes and data flows through the processes.
• Omission, incorrect fact, inconsistency, and ambiguity are the most common errors in an SRS. For validation, the most commonly used method is doing a structured group review of the requirements.