Software Requirements Document (SRD)

As noted in our project overview document, "the Software Requirements Document [is] a detailed description of the problem to be solved:  its purpose, context, scope, capabilities and functions, performance characteristics, interfaces including the user interface."  Also, as indicated in our discussion on Analysis Modeling the diagrams in the SRD are to provide a cognitive model of the application (i.e., what the system is or does) rather than a implementation design (how it accomplishes the task.  With these thoughts in mind, here are a few principles to apply and suggestions for content as your develop your documents.

SRD Principles:

bulletEstablish the system's or application's context:  e.g., business environment, place within an existing process, relationship to other hardware or software, etc.
bullet Concentrate on functionality (what does the system do) rather then on implementation (how the function is accomplished).
bulletConcentrate on user visible features and components of the application.
bulletDescribe the application's capability and behavior from the user's perspective.
bulletDescribe a notional user interface.
bulletUse user stories or scenarios.  For example, describe different ways in which the customer will use the application. 
bulletNOTE:  Be sure to describe all capabilities, not just those that are most common.  Remember the SRD is a "contract" identifying what is to be built.  If there are "minor" capabilities not reflected in the SRD, then the work for these capabilities is not likely to be reflected in the planning.
bulletUse modeling techniques from our textbook to present the application from different viewpoints, emphasizing perhaps data, processes, behavior, interactions, state changes, etc.

SRD Content:  Please include as a minimum the following in your document:

bulletIntroduction:  Identifies team, project purpose, application overview (e.g., short description of scope and capability), application context, customer(s).
bulletRequirements*
bulletArchitectural model - indicates the user-visible components of the application and their relationships with one another.
bulletBehavioral description of the application - how does the user interact with the system.  May include a notional user interface diagram or screen shot of a prototype.  Often includes examples of how the system operates using user stories.
bulletFunctional description of the application - describe the functions and capabilities of the system.  Notes any constraints or performance requirements. 
bulletInformational description of the application - indicates what data will be produced, modified, or used by the application.  Indicates data relationships.
bulletValidation Criteria:  This section identifies how the requirements will be validated.  In some cases it will be by merely exercising the capability, in other cases the application my need to pass a specific battery of tests.  Note that this section need not be separated from the listing of the requirements, but could be integrated, e.g., by giving the requirement and following it immediately with the manner in which the requirement will be validated.

*Note:  Requirements should be specified in a manner that facilitates verification.  For example, when describing application features it is better to collect features into functional groupings and list specific capabilities within each group rather than use a paragraph description, because a bulleted list allows easier verification.