CS 305 Software Engineering

Course Documents

Document Version: 1.0.1, Jan. 27, 1998.

Document Maintained by: Darrah Chavey.

This document was modified by Kunal Mittal on Jan 21st. 2000 (to edit links only).

Changes from Previous Versions: V. 1.0.

Non-standard Terminology: etc, compilable.

Document purpose: This document provides links to the documents used in this course, the "general course documents", which define the standards for the course (processes, document standards, change standards, etc.), and the project documents (specifications, design, test plans, code, etc.).

General Course Documents:

• The Process Description (sorry link not available) document describes the overall procedures of how teams function, preparation for the weekly inspections, course evaluation, etc.
• The Waterfall Model (sorry link not available)document describes, for the purposes of this course, how the various phases of the software process are defined, and what is to be achieved at each stage of the process.
• The Document Standards (sorry link not available)specifies the formats required of the documents throughout the course.
• The Change Control Standards (sorry link not available)specifies how changes will be made to documents after their initial approval, who is responsible for the changes, how they are approved, who is informed of them, etc.

Project Specific Documents

For more details on the meanings of the documents below, see the Waterfall Model document mentioned earlier. For the list of who is on which team, and who has which responsibilities on these teams, see the Teams link. Note that the actual team assignments are subject to change in the event that someone drops the course. The documents that should be produced for our particular software project are:

• The Requirements Document, which describes in a general manner the goals and desirable functions of the software program to be produced. This is written for the eventual user of the product.
• The Specifications Document, which gives precise details of what the product is supposed to do. This is written for the programmers who have to implement the program. It specifies the functionality of the program, but not the interface details.
• The User Interface Specification, which gives detailed specifics for what the interface should look like and how it should behave. This includes sample screen shots, etc.
• The Systems Analysis (sorry link not available) document, which gives a visual description of how data flows through the program components.
• The Architectural Design document, which gives specifications for the objects in the program, how modules are decomposed, what methods are needed for each object, and how these objects will achieve the program functionality required.
• The Module Design documents, a collection of the interface specifications for each object module in the system. These are fully usable Java interface documents.
• The Module Testing documents, a collection of code units used to test each of the modules. These are compilable modules even in the absence of code from the module implementation phase.
• The Module Code (sorry link not available) document is a collection of links to the source code for each of the individual modules.
• The User Documentation is the final documentation for the client who will be using this program.
• The Integration Testing document includes both the plan for how modules will be combined and tested, i.e. in which order are they expected to be integrated, and the code units used to test these module combinations and the combined program.