| CEN4020: Software Engineering I | up↑ |
Your SRS should be organized into the following sections. You may find a partially completed example at vrsSRSExample.html.
Identify the purpose of this SRS and its intended audience.
Describe the origin of the need for this system. Explain what the software product(s) will, and, if necessary, will not do. Describe the customer's goals for the proposed system.
Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to an appendix or other document(s).
List and describe any supporting documents that are not included in the SRS or its appendices.
Describe the rest of the SRS and how it is organized.
Describe the relationship of software to its environment (i.e., the software's interface). For example, if the product is independent and totally self-contained, it should be stated here. If the SRS defines a product that is a component of a larger system or project, describe how it interacts with rest of system.
Provide a summary of all the functions of the software. The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time.
Provide general characteristics of the classes of eventual users, such as their expected educational background and the amount of product training they are likely to require.
Express such things as host hardware limitations, interfaces, and implementation language requirements. Provide a general description of any other items that will limit the developer's options for designing the system.
List and describe each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but any changes to them can affect the requirements in the SRS. For example, an assumption might be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change.
State the functional requirements in sentences identified by numbers. Each requirement is something that the system shall do. Thus, it has a common name of a "shall list". You may provide a brief design rationale for any requirement which you feel requires explanation for how and/or why the requirement was derived.
Use the same format as the functional requirements for the non-functional requirements. You may provide a brief design rationale for any requirement which you feel requires explanation as to how and/or why the requirement was derived.
This section presents a high-level overview of the anticipated system architecture using a class diagram. It shows the fundamental objects/classes that must be modeled with the system to satisfy its requirements. Each class on the diagram must include the attributes related to the class. All the relationships between classes and their multiplicity must be shown on the class diagram. The classes specified in this document only are those directly derived from the application domain. The class diagram must be developed using the Jude software.
This section presents the use case diagram for the system under development. The use case diagram should be a complete version containing all the use cases needed to describe the functionality to be developed.
Provide completely defined entries for all of the actors in the use case diagram.
Provide completely defined entries for all of the use cases in the use case diagram.
Provide partially defined entries for all the classes in the class diagram. The fields for the name, description, attributes, and relationships must be completed on the data dictionary form of each class in the class diagram for the SRS document. (The data dictionary forms for the classes in the class diagram will be completed later, in the design document. That is, the fields for the methods will be completed.)
Attribute Descriptions
Provide completely defined entries for all of the attributes in the class diagram.
Provide the actor summary table used for the raw use case point analysis of the use case diagram.
Provide the use case summary table used for the raw use case point analysis of the use case diagram.
This appendix contains the scenario analysis table for each use case in the use case diagram. The template for scenario analysis table is provided.
This appendix contains the screens/reports list for all the use cases in the use case diagram. The template for the screens/reports list is provided.
Append anything else that is needed by the reader of this document for understanding or further explanation.
| ($Id: SRSTemplate.html,v 1.1 2010/09/11 23:20:30 baker Exp baker $) |