Guidelines for Documents

Submission: softcopy in pdf on your project web site

1. 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]
2. 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 interface (methods)
• 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]

Suggestions

• 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:
  1. the Requirement Document based on the initial meeting before you submitted your project plan.
  2. 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:
  1. discuss the draft Requirement Document
  2. discuss the mock-up of the user interface to indicate how to access different features/functionalities of the system
  3. ask:
     1. if the requirements are reasonable
     2. which requirements need to be updated, added, or removed
     3. how the requirements should be prioritized