CS 3610: Software Engineering
Fall 2009
<<Project Title>>
Software Requirements Specification Document
<<Team Members>>
<<Date>>
Software Requirements Specification
1. Introduction
[The introduction of the SRS should provide an overview of the entire SRS. It should include the purpose,
scope, definitions, acronyms, abbreviations, references and overview of the SRS.]
1.1 Purpose
[Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or
subsystem identified. It also describes nonfunctional requirements, design constraints and other factors
necessary to provide a complete and comprehensive description of the requirements for the software.]
1.2 Scope
[A brief description of the software application that the SRS applies to; the feature or other subsystem
grouping; what Use Case model(s) it is associated with, and anything else that is affected or influenced by
this document.]
1.3 Definitions, Acronyms and Abbreviations
[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to
interpret properly the SRS. This information may be provided by reference to the project Glossary.]
1.4 References
[This subsection should provide a complete list of all documents referenced elsewhere in the SRS. Each
document should be identified by title, report number (if applicable), date, and publishing organization.
Specify the sources from which the references can be obtained. This information may be provided by
reference to an appendix or to another document.]
1.5 Overview
[This subsection should describe what the rest of the SRS contains and explain how the SRS is organized.]
2. Overall Project Description
[This section of the SRS should describe the general factors that affect the product and its requirements.
This section does not state specific requirements. Instead, it provides a background for those requirements,
which are defined in detail in section 3, and makes them easier to understand. Include such items as
product perspective, product functions, user characteristics, constraints, assumptions and dependencies,
and requirements subsets.]
2.1 Use-Case Model Survey
[If using use-case modeling, this section contains an overview of the use-case model or the subset of the
use-case model that is applicable for this subsystem or feature. This includes a list of names and brief
descriptions of all use cases and actors, along with applicable diagrams and relationships. Refer to the
use-case model survey report, which may be used as an enclosure at this point.]
Insert use-case diagram(s) here.
Use the following table template to describe each use- case defined for your software
application. Use one table for each use-case. Make sure NO blue text in the final tables.
(This table is adopted from “Systems Analysis and Design”, by Whitten, Bentley, and Dittman)
Use case name:
ID:
Priority:
Use-case name should represent the goal that the
Unique identifier
Level of importance
use-case is trying to accomplish. The name should
for the use-case.
(high, medium, low).
begin with a verb (e.g., Enter Login Info).
Primary actor:
Source:
Use case type:
The primary
This identifies the entity that
Use-case type can be Business or
stakeholder that
triggered the use-case. This
Technical type, depending on what
benefit from the
could be a requirement, a
the use-case represents (business
execution of the usespecific document, or a
requirements or technical
case.
stakeholder.
requirements).
Interested Stakeholders:
A stakeholder is anyone who has a stake in the development and operations of the system to be
developed. An interested stakeholder is a person (other than the primary actor) who has an
interest in the goal of the use-case.
Brief description:
Couple sentences outlining the purpose of the use-case and its activities.
Precondition:
A constraint on the state of the system before the use-case can be executed. Usually this is another
use-case that must be previously executed.
Trigger:
This is an event that initiates the execution of the use-case.
Relationships: Relationships with other use-cases.
Include:
Names of use-cases that this use-case includes (uses).
Extend:
Names of use-cases that this use-case extends.
Typical flow of events:
Sequence of activities performed by the actor(s) and the system in order to satisfy the goals of the
use-case. This includes the interactions between the system and the actors and the activities the
system performs in response to the interactions.
Assumptions
Any assumptions that were made when defining the use-case.
Implementation Constraints and Specifications:
Any non-functional requirements that may impact the implementation of the use-case.
2.2 Assumptions and Dependencies
[This section describes any key technical feasibility, subsystem or component availability, or other project
related assumptions on which the viability of the software described by this SRS may be based.] [Here,
please include any limitations, constraints, restrictions identified for the system]
3. Specific Requirements
[This section of the SRS should contain all the software requirements to a level of detail sufficient to enable
designers to design a system to satisfy those requirements, and testers to test that the system satisfies those
requirements. When using use-case modeling, these requirements are captured in the use cases and the
applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary
specifications may be inserted directly into this section.]
3.1 Classes/Objects
Here, insert conceptual UML class inheritance diagram.
Use the following table format to describe classes similar to the following table
Class name: The class name
Brief description: Brief description of the class
Attributes (fields)
Attribute 1
Attribute 2
...
Methods (operations)
Method 1
Method 2
...
Attribute Description
Brief description of attribute 1
Brief description of attribute2
...
Method Description
Brief description of method1 1
Brief description of method 2
...
3.2 Object Collaboration Diagrams
Draw a UML object relationship (collaboration) diagram(s)
3.3 Sequence Diagrams
Draw a UML sequence diagram for each use-case. The diagram is derived from the event flow section of
the use-case table.
3.4 Object Behavior Diagrams
Draw a UML state transition diagrams for the system (event flow diagram)
3.5 Performance Requirements
List any performance requirements specific to the project.
3.6 Other Requirements
List nay other requirements that may not be included in the use cases.
4. Supporting Information
[The supporting information makes the SRS easier to use. It includes: a) Table of contents, b) Index, c)
Appendices. These may include use-case storyboards or user-interface prototypes. When appendices are
included, the SRS should explicitly state whether or not the appendices are to be considered part of the
requirements.]