System Requirements Specification (SRS) Document Format
COMP 413W Semester Project
PennStateHarrisburg Fall 2007
Title Page
Contains the name of project, date, and document version number.
Abstract
A one-to-three paragraph summary of the problem solved by this project.
Document History
List the various revisions of this document along with a brief summary of they changes. It is often helpful to state why the revisions were made if those revisions were for some other reason than accuracy or refinement.
Approvals
Provide a signature block for each of the key stakeholders who have signatory approval for the project. These roles will be spelled out in the project charter.
Project Team
List project team members and their roles.
Table of Contents
Provide major headings and page numbers. The page footer should contain the page number ("Page x of y,")
1.0 Introduction
This section provides an overview of the entire design document. This document describes all data, architectural, interface and component-level design for the software.
1.1. Goals and Objectives
Describe overall goals and business objectives to be realized by the software. If relevant to the problem area, include a list and description of the major classes of stakeholders.
1.2. Scope of Solution
Describe the boundaries of the solution here. State what functionality is included and what is excluded. This statement is given in terms of business functions. A rationale for which parts are excluded should also be included.
2.0 Overall Description
This section provides a high level overview of the system, how it will be used, and by whom.
2.1. Product Context
Indicate whether this system is part of a larger system, whether it encompasses other, smaller systems, or whether it is one of several products in a product line.
2.2. Product Features
Summarize the significant features of the product from a.high level perspective. Graphical depictions such as top-level data flow, UML architecture, or use case diagrams may be included here if they are helpful.
Note: This section should include the features that were not included in this product at this time with an explanation as to why they were not included and whether they will be included in a future version of the product.
2.3. User Classes, Roles, and Characteristics
Describe the organizational roles of people who are expected to use the system. It may also be helpful to mention the assumed level of sophistication of the users if it is relevant to the design of the product. Indicate which system features will be employed by each class of users. These user roles appear as actors in the use case diagrams below. A tabular format is helpful when there are a large number of roles involved.
2.4. Operating Environment
Provide a general description of the hardware and software environment(s) within which the product will operate. Be sure to list anything unusual, such as whether the product is expected to operate in a harsh physical environment.
2.5. Constraints
List any unusual factors that may impede the expedient implementation of full functionality of the product. There is no need to include the obvious constraints of staying within budget or on time unless one or both of these constrains is unusual in its severity. (For example, Y2K was an immovable deadline!)
2.6. Assumptions and Dependencies
Provide information concerning any unusual conditions that are assumed to hold to assure a successful implementation or to allow the product to operate correctly.
3.0. Detailed Requirements
Describe the system functionality in plain language that is understandable by the customer and the technical team.
3.1. Use Cases
Supply a use case description and diagram that encompasses the functional requirements of the entire system. More than one diagram may be required.
Figure 3.xx: Overview System Use Case: [Title]
Use Case #1 (Name)
General Description: (Provide a few sentences about the general purpose of this use case.)
Precondition:
Postcondition:
Basic Flow:A use case describes what an actor does and how the system responds. (Recall, an actor does not have to be a person.) A use case starts when an actor takes an action. The use case description tells what happens inside the system, but not how or why. Actions should be phrased in the form of a dialog between the actor and the system. If information is exchanged, provide details about what information is exchanged. Simple alternatives (say a few sentences or less) may be presented in the text of the use case. A more complex alternative should be described in an alternative use case.
U1.1. Use Case Step 1
U1.2. Use Case Step 2
U1.n. Use Case Step n
Alternative Flow
U1.1.a Use Case Step 1 Alternate Step a
Figure 3.xx: Use Case Diagram for Use Case #1
Use Case #2 (Name)
General Description:
Precondition:
Postcondition:
Basic Flow …
U2.1. Use Case Step 1
U2.2. Use Case Step 2
U2.n. Use Case Step n
Alternative Flow …
U2.1.a Use Case Step 1 Alternate Step a
Figure 3.xx: Use Case Diagram for Use Case #1
Use Case #n (Name)
General Description
Precondition:
Postcondition:
Basic Flow
Alternative Flow
3.2. Other Functional Requirements
Provide a detailed description of any functional requirements that are not included in the use case diagrams. Use cases have their limitations, and sometimes they cannot express important aspects of the systems' proposed behavior. If the system behavior is highly state-dependent, provide state transition diagrams, if the system requires a great deal of complex decision making, include a suitable flowchart. Sometimes a simple narrative will make things clear. Explain or briefly describe each component in any diagrams supplied in this section. Provide a number for each step, component, or state for cross-referencing purposes.
Other Functional Requirement #1 (OF1)
Other Functional Requirement #2 (OF2)
Other Functional Requirement #n (OFn)
3.3. Non-Functional Requirements
Clearly state each non-functional requirement of this system. Each requirement must be numbered for cross-referencing purposes.
Non-Functional Requirement #1 (NF1)
Non-Functional Requirement #2 (NF2)
Non-Functional Requirement #n (NFn)
3.4. External system interfaces
List all interfaces to other systems, products, or networks if any. Note: At this point we just say what the interfaces are and what purpose they serve.
4.0 Quality Assurance
This section presents the test strategy, preliminary test case specifications, and any other means by which the quality of the product may be evaluated. An introductory paragraph, placed here, outlines the basic approach to the testing. The paragraphs below should answer the question, "How will I know when each major component of the system is delivering what is required of it?"
Appendices
Include any documents that support, clarify, or elaborate upon other sections of this document. Most requirements documents will need a glossary and business process description here (Appendix A and Appendix B.).
Page 1 of 4