Change Record:
|
Date |
Version |
Changes/Additions |
Responsible Person |
|
|
|
|
|
For every modification to this document (including the first time it was handed in), an entry must be made in this field. This way, others reading the document can tell what modifications have been made, and when. Document modifications must be indicated within the document using some form of highlighting, such as change bars.
A listing of the contents of the document. It must be detailed enough to show the organization of requirements in the requirements specification section.
A high-level overview of your system. It should describe the project, as well as its purpose. This section provides the reader with a broad understanding of the project, which is then filled-in by the more detailed requirements in later sections.
Documents and Web sites that are useful in understanding the current document. Provide full bibliographic citations. It is not sufficient to just provide the URL of a Web site - the title of the site, and a brief description of its contents is also necessary.
Definitions of important and specialized terms and acronyms used throughout the remainer of the specification.
A detailed specification of the requirements for your chosen project. Requirements need to be organized into meaningful groupings. A brief introduction to the organization of the requirements, at the beginning of the section, might be useful.
Requirements specification are often (but not always) written as "musts" or "shalls". For example, "the system must provide a mechanism for immediately exiting the system, without data loss."
A series of diagrams describing all of the major menus, screens, behaviors, and dialog boxes of the project. Screenshots of a coded user interface prototype will be taken as a strong indicator that the project scope is too small, and may result in an Engineering Change Request to increase the scope of the project.