CPE 308
Winter 2009
Turner
Software Requirements Specification (SRS) Content

IMPORTANT NOTES:

1. Your SRS is expected to look professional; imagine you are turning it in to your corporate boss.
   An unprofessional SRS submission will be returned, without review, marked with a very low grade.

2. Use present tense, active voice with transitive verbs, and 3rd person writing in this document. Keep all language in the problem domain. If you have questions about writing style, refer to a good standard style guide.

3. Passive voice writing is unacceptable.
   Use of words from the bad words list is against company rules.
   Use of words in Table 10-1 is against company policy.
   

4. Plain text is the least desirable medium.
   Whenever possible, use tables, lists, figures, diagrams and pictures.
   

Cover Page
Include logo and date.

Credits Page
What did everyone do? Think about the end of a movie.
Each credit must include one and only one name!

1. Introduction
   Write these sections so they can be separately understood by people unfamiliar with your project.
   Use the principle of abstraction; leave out detail.  
   Suggestion: do this part immediately and get it signed.

   Section 1.3: your audience is the students in this class.
   Section 1.4 can point to your Vision and Scope document.
   

   Section 1.5 includes material needed to develop your system (web URLs, vendor manuals, standards, ...). Use proper citation methods.
   Your team must possess a copy of each reference.

2. Overall Description
   You may omit sections 2.1; this information is in Section 1.1
   Section 2.2 must contain a top level data flow diagram with a short introduction to explain the overall system requirements.
   Section 2.3 (User Classes) must be a table.
   Section 2.4 must describe both your target platform and development platform.
   Section 2.5 must list all system-level constraints.
   Section 2.6 must state that user documentation will be built into the system (check with customer on this!)
   Section 2.7 - write system-level assumptions and dependencies.
   

3. System Features
   This section contains use cases, documented in the Use-Case document. 
   Use the Wiegers form for each use case.
   

4. External Interface Requirements
   Describe every interface to your system.
   List external hardware and software that your system uses or connects to.
   For example, if you import something from the WWW, that is a software interface.

5. Nonfunctional Requirements
   For Section 5.4, there are examples of good and bad quality attributes for your viewing pleasure.
   You must include at least 3 maintainability requirements; other quality attributes will be discussed in a team meeting.
   
   Be sure all of your nonfunctional requirements are measurable and testable.
   

6. Data Dictionary
   Our Data Dictionary replaces a vast amount of textual information commonly used to describe these requirements.
   Define every attribute in the problem domain. If it's mentioned in this document, it needs to be documented in the DD. Note that the dictionary dictionary is disjoint from the glossary; the audience for the data dictionary is the software developer.
   

Appendix A: Glossary
This audience for these terms is the reader of this document.
The glossary and data dictionary are disjoint.

Appendix B: Analysis Models
Team-specific. These will be discussed at a team meeting.

Appendix C: User Interface (Prototype)
Include high-quality story boards or a GUI prototype that shows the major user cases.
This need not be the actual user interface; its purpose is to illustrate the system requirements for the user interface.

Appendix D: Checklist
The checklist for this document with each item checked.