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 Introduction

1.1 Scope

Give a one sentence explanation of what the product will do.
Explain why this product is needed. Discuss the specific problems that this product will attempt to solve.
Present any domain-specific background necessary to understand the problem.
Include a measurable statement of the intended benefits or objectives to be achieved by developing this product..

1.2 Product Features

Give a brief summary or bullet list of the major features that the software will perform.

1.3 User characteristics

Describe general characteristics of the intended user of the product, including age, education level, specific experience, and technical expertise.

1.4 Constraints

Describe any constraint that may limit the choices available to the developers, such as regulatory policies, intellectual property restrictions, high level language requirements, etc.

1.5 Assumptions and dependencies

List any factors or dependencies that the developers may assume will exist that may affect the software product.

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.

Winter 2004.  Using the ASCENT CASE tool you should write your functional requirements (or "mini-specs") as "Process Logic" within the CASE tool itself.  You then have several alternatives for how to submit it.

1. You may submit your ASCENT project itself in computer readable form (be sure to include all the ".cde" files that contain the mini-specs).
2. You may convert the content of all the ".cde" into HTML and include them in this section of the SRS.

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 server, 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.

6.2 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.
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.