Software Requirements

Document Guidelines

Section 1: Product Overview
From your system definition you should construct an overview of the product you intend to build. This summary should first summarize the problem context, complete with user characteristics, then present an overview of the intended operational capability of the system as it solves the problem. You should consider the comments made in to the system definition and during our meetings in revising the material you have.

Section 2: Processing Environment
You should describe the environment in which the system will operate. You should be specific regarding CPU type, with both internal and external memory requirements, and operating system. If there is a network involved then you should include details regarding transmission speed and connectivity. If reports are to be generated and printed then details regarding the hardware available should be included.

Section 3: System Model
You should develop a model using the appropriate representation for the system you are planning. The level of detail should be appropriate for the phase of the life-cycle in which you are working. You should construct a data dictionary that includes a finer level of detail regarding the data the moves from on process to another, the logical organization of data stores, data sources, and processes that appear in your system model. Your system model should be at the level of external, observable behavior!

Section 4: Requirements Specifications
The heart of the SRS (SRD) is the functional specification. Remember you are attempting to define the behavior of the system from the user's perspective. You should try to group these requirements in categories that make sense in the context of the system you are proposing. You should attempt to connect the requirements to the system model developed and displayed in section 3.

Section 5: User displays and report formats
You should give a first cut at the user interface for the software system and define any report formats that are required for the system. This should include displays, information layouts, and command summaries.

Section 6: Design Guidelines (hints and constraints)
This section is reserved for comments and ideas related to the actual design of the system. It is here to give you a place to put ideas, hints, and constraints that you may think of during the requirements phase but could not put them in the body of the document. If you foresee a particular problem, related to the system, then make the comment here.

Section 7: Sources of Information

Section 8: Glossary of Terms

The document should have a title page, a table of contents, and page numbers. The title page should include the title of the project and the team submitting the document. You should continue to stress clarity and coherence in your documents.


Comments to
Richard Upchurch
RUpchurch@umassd.edu

This document
Created: February 11, 1995
by RLU