Description of Contents
·Preface: A paragraph describing the expected readers of the document.
·Introduction: "This should describe the need for the system, .. its functions and explain how it will work with other systems, .. how the system fits into the .. objectives of the [client's] organization" (p. 118)
·Glossary: "Define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader." (p. 118)
·User Requirements: High-level functional & non-functional user requirements as described in ch. 5.1-5.2. Document in written English using a standard format with sections/subsections, highlighting, etc. (e.g. Fig. 5.10-5.11).
·Domain Requirements: Describe functional & non-functional requirements that "are derived from the application domain of the system rather than from the specific needs of specific users" (p. 105) as discussed in ch. 5.1.3. Document in written English in the same format as User Requirements.
·Scenarios: Primary and secondary scenarios. (The number of scenarios to be written depends upon how many people are in the group and on how the task units are allocated.See the instructor.) Document in written English following example in Dr. Green's supplementary lecture notes.
·Use Case Analysis: Use cases covering all user-visible functionality. Document with both a Use Case Diagram (e.g. Fig. 6.12) and, for each Use Case, a written English description following example in Dr. Green's supplementary lecture notes.
·System Requirements: Describes the functional & non-functional requirements in more detail than the user requirements, as described in ch.5.1 and 5.3. Document in written English using a standard format with sections/subsections, highlighting, etc. (e.g. Fig. 5.10-5.11 or Fig. 5.13). (Do not use a PDL.)
·System Evolution: "This should describe .. assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs, etc." (p. 118)
·Prioritized List of User, Domain and System Requirements: List the requirements in each category: Critical, Important, or Optional.
·Release Plan: Outline which User, Domain, and System Requirements will be met by the product in three releases. Release 1 is defined as the first increment that could be released and should consist of the requirements that should be met in the earliest useful but incomplete version of the system. Release 2 is defined as the second increment and should consist of all requirements that are Critical or Important. Release 3 is defined as the final increment including all features. (Release 2 is due at the end of the semester.)
·Demo of Prototype: C++ source code used to implement the prototype, printed copies of any sample files used in the demo, printed copies of screen shots illustrating the program running. (This section of the Requirements Document should be done by the person who implemented the prototype, not the person who ran the prototype at the demo.)
·Feedback from Client on demo: a memo summarizing the client's questions and comments at the demo of the prototype and the author's recommendations for additions or changes in the Requirements due to this feedback. (This section should be written by the person who ran the prototype at the demo.)
·System Models: three types of diagrams:
·Data-flow Diagram showing main processing steps, data flow, data sources, data stores, and dotted line around system boundary as in Fig. 7.2-7.4
·State Machine (ex. Fig. 7.5) documenting interface shown at demo of prototype (showing the effect of user actions on the internal state of the system), and
·User Class Model: a class diagram with inheritance and aggregation links as shown in ch. 7.4. This diagram should show only classes that represent simple concepts from the user's perspective of the system, not all classes that would be required to implement the system.
Submission Instructions
All work should be submitted in two forms: on paper and on-line. Here are the specific instructions for each medium:
Paper: Each person should have done the work described as one task unit (see instructor). Turn in a paper copy of the work that you did for your task unit with a single cover page stating your name, project name, date, and the contents of your task unit. Fasten (stapled or paper clipped) all the sections of your task unit together. Turn in each person's work separately. It is important to follow these instructions so that you get proper credit for your work!
On-line: The on-line version of the requirements will be created by naming your files as specified in the links of the ReqTOC (Requirements Table of Contents) web page that the instructor created for each group. (Note that all the files containing written English, diagrams, or screen shots must be in PDF format.) The ReqTOC web page and all of your files to which it is linked should be kept in a folder on the UNCG Novell network that the instructor created for this purpose. (The name of the folder will be given to your group in class.) Do not modify the ReqTOC web page except to add links to the contents and the name of the author of each part; do not change the list of contents in any other way. Note that students can access the folder from off-campus using NetStorage. I will check the ReqTOC web page 30 minutes before the beginning of class on the due date.
Resources
The University Writing Center http://www.uncg.edu/eng/writingcenter/ offers all UNCG students free, individual assistance with planning, writing, or revising papers for any course.
Writing Reference Materials
·Yale University Web Style Guide
UML Reference Materials
·Bruegge and Dutoit handout p. 39-44