This template is a modified version of the IEEE 830-1998 standard. Please read that document for a general discussion of how to prepare a requirements specification.

Cover Page

Credits Page

Table of Contents (if necessary)

1.0 Vision and Scope

1.1 Business Requirements

1.2 Vision of the Solution

1.3 Scope and Limitations

1.4 Business Context

2.0 Functional Requirements

This is the most important section of the SRS.  List all the required functionality of the software in complete detail.  Number and organize the requirements carefully.

Two common notations for stating requirements are "atomic sentences" or "Use Cases."  Atomic sentences are appropriate where the system functioning is primarily computational or processing oriented. Use Cases are often preferred where the system is primarily interactive or event driven.

Be sure to follow the quality criteria for writing good requirements.

3.0 Quality Attributes (Nonfunctional Requirements)

This section describes any desired attributes or characteristics required of the system that don't provide a function or capability. Another way of saying it, is that this section specifies how much quality is required.

One way to distinguish a functional requirement is that you can point to the source code that implements it, but nonfunctional requirements can't be isolated in the code.  The best example is performance requirements, e.g., "the executable module must fit on a 1.4MB floppy disk."

These requirements are subject to the same criteria as the previous section.  Special attention must be given to stating the requirements in a manner that is objective and quantifiable; there must be some measurable way to assess whether the requirement has been met.

Consult this online reference as well as your textbook.  Also refer to section 5.3.6 of the IEEE template.

4.0 Behavioral Requirements

This section describes the manner in which the software behaves or operates.  In a typical end-user application this section describes the human-user interface.  For some products this section is a separate document that is simply referenced here, ideally with a hyperlink.

5.0 Informational Requirements

This section describes the information requirements from an external perspective only. Only data that is visible by the end user is described.

5.1 Data Model

Include one or more visual depictions of the data and relationships in the problem domain using some standard notation such as Entity-Relationship Model, Data Flow Diagram, State Transition Diagram, etc.

5.2 Data Dictionary

Provide an organized, alphabetical listing of all data elements that are pertinent to the system, with precise, rigorous definitions.  Each item must follow the Data dictionary notation. Refer to this sample Data Dictionary.

6.0 Appendices

6.1 External Interfaces

6.1.1 Hardware interfaces

Describe all interfaces between the software and any hardware components in the system (e.g. touch tablet).

6.1.2 Software interfaces

Describe the way in which the software will interact with any other required software (e.g. database, legacy system, web service, etc).  It is not necessary to detail any well-documented interface (e.g., SQL).

6.1.3 Communcations interfaces

Describe any communication protocols to other devices or networks. It is not necessary to detail any well-documented interface (e.g., HTTP).

6.1.4 I/O formats

Specify the format for all data input to or output from the system.  This includes any external file formats and the layout of any printed reports. View sample

6.2 Rationale (Issues and Tradeoffs - Engineering Analysis)

Give an engineering analysis explaining your rationale for all significant decisions you made during Analysis.  Issues such as platform choice, user interface style, and tradeoffs between usability and efficiency, are examples.  Do not include design issues.


Recommended Format

Issue #N: Describe the issue in a sentence. State it as a question or a tradeoff. For example,
"Should units be in meters or feet?"
"Should the application be portable to mobile devices?"
"Should we provide a way to customize the date output format?"
"Should we use a drop down menu or check boxes to select desired timezone?"
Alternative A: Brief description of the solution
    Advantages:  list advantage of this solution.
    Disadvantages: list drawbacks of this solution.
Alternative B: Brief description of the solution
    Advantages:  list advantage of this solution.
    Disadvantages: list drawbacks of this solution.
(Repeat for all alternatives you considered).
Decision:  Explain which alternative you chose and give your rationale. You need to justify your choice, and why it is superior to the other alternatives. Don't just simply restate it's advantages.


6.3 FTR Review Summary report, signed by your reviewing group
 
6.4 QA Checklist, (with items checked off), signed by your QA person. You must provide an explanation for any items not checked off.As a general rule, checklists with more than five unchecked items are not ready for submission. If an item is missing or obviously unsatisfactory that has been checked off, the entire document will be returned for correction and a late penalty will accrue.