This template is a modified version of the IEEE 830-1998 standard. 

Credits Page

1.0 Vision and Scope

1.1 Business Requirements

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.   Discuss advantages of this product over other solutions.
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 Vision

Write a concise vision statement that summarizes the purpose and intent of the new product and describes what the world will be like when it includes the product. The vision statement should reflect a balanced view that will satisfy the needs of diverse customers as well as those of the developing organization.

1.3 Product Features

Give a brief summary or bullet list of the major features that the software will perform. emphasizing those features that distinguish it from previous or competing products.

1.4 Project Priorities

Describe the priorities among project schedule, budget, scope, and quality.   Give a rationale for the tradeoffs you've made in light of the business requirements above.

1.5 User characteristics

Describe general characteristics of the intended user of the product, including age, education level, specific experience, and technical expertise.   Describe their primary motivations for using the product.

1.6 Constraints

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

1.7 Assumptions and dependencies

List any factors or dependencies that the developers may assume will exist that may affect the software product, such as specific technologies, third-party vendors, or other business relationships.

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 key mapping be configured inside the application or externally?
"How will the user 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.