Guidelines for Documents
Submission: softcopy in pdf on your project web site
Guidelines for Requirement Document and Test Plan
- Requirement Document ("What the system should do?")
- at least teamSize * 2 pages (single-spaced, 12-pt font, 1-in margins) [for example, at least 6 pages for a team with 3 members]
- specify required/expected features/behaviors
- for each required/expected feature/behavior, state sample input and output
of correct (and incorrect) behavior
- [e.g. IEEE Recommended Practice for Software Requirements Specifications]
- Test Plan ("How to verify that the system does what it should do?")
- at least teamSize * 1 page (single-spaced, 12-pt font, 1-in margins) [for example, at least 3 pages for a team with 3 members]
- for each required feature/behavior
in the Requirement Document, discuss test cases to verify the feature/behavior.
- Generally, test cases are designed to find bugs. Hence, besides the
"usual" input values, "ununsal" input values should be consdiered as well.
- [e.g. IEEE Standard for Software Test Documentation]
Guidelines for Design Document ("How to design a system that satisfies the required features/behaviors?")
- at least teamSize * 2 pages (single-spaced, 12-pt font, 1-in margins)
- system architecture diagram (e.g. UML diagram, sample tool)
- for each module (class), discuss its functionality and
- if you plan to have GUI for your system, a sketch (mock-up)
of the different screens to help illustrate the key
functionalities of your system
- additional design could include: algorithm (pseudocode), database (ER diagram, tables, keys), communication over networks (protocol)
- [e.g. IEEE Standard for Information Technology -- Systems Design -- Software Design Descriptions]
- I strongly suggest you to meet with the "client/customer" to gain a mutual understanding of what your system should do ("requirements").
- Before the meeting, I suggest you to have a draft of:
- the Requirement Document based on the initial meeting before you submitted your project plan.
- a mock-up of the user interface (part of the Design Document) that allows access to the different features/functionalities of the system--this is a visual summary of your understanding of the required features from the "client/customer."
- During the meeting, I suggest you to:
- discuss the draft Requirement Document
- discuss the mock-up of the user interface to indicate how to access different features/functionalities of the system
- if the requirements are reasonable
- which requirements need to be updated, added, or removed
- how the requirements should be prioritized
Last modified: Wed Sep 12 12:07:44 EDT 2014