Northern Arizona University
CS 486:
Capstone Design Project Notebook Format

Overall Notebook Format

  1. 3" or larger 3-ring binder with cover window for inserting title page
  2. Tagboard dividers with enough tabs
  3. All entries must be professional in quality and computer generated whenever possible.
  4. Each section must have a table of contents that is updated as new documents are added.
  5. Entries should be in reverse chronological order. The most recent documents appear first.
  6. You may add additional sections you believe are relevant to the effort and place them where you believe appropriate.
  7. IMPORTANT:  The very FIRST ITEM in your notebook should be any previous notebook review grading sheets you have received back from me --- the inside front cover jacket pocket is a good place to stash them. This allows me to track notebook improvements more easily...

Notebook Contents (suggested -- you may adapt as necessary)

Master table of contents - This TOC lists the number of each section and the title of that section.
Project Intro/Problem Statement - This is the general project intro. Should basically consist of your polished problem statement where you intro the problem, client, statement of the business issue and the value to the business of a technology solution, sketched requirements --- and perhaps even sketch out your solution. Should provide a solid intro/overview of the project in no more than 1-2 pages. Follow this with the formal project description the client posted to start with.
Project Requirements - List of functional and performance requirements that are extracted from problem statement and customer interviews. Statements of the customer needs, wants, feasibility.
Project Specifications - List of functional and performance specifications that also include metrics (e.g., operating temperature), their value or range of values (e.g., 100-120), and unit of measure (e.g., degrees Celsius). Environmental and other constraints are also described.

Project Development Plan. Extracted from the plan developed earlier in the term.
Team member info, Coding Standards, other "organizational info" - Team members, roles, filenames, structure, comments, documentation. Should appear somewhere near the front of the notebook.

Project Schedule - This section should always be kept up-to-date!. Provide a textual bulleted list showing major milestones --- this gives a rough feel for project progress/activities. Follow this with a Gannt chart (and perhaps PERT chart) showing schedule details.

Project Communications - status and information exchanges between client and team.

9.0 Your communications log showing every communication with the client: date/time/place/kind (in person, conf call, etc), who attended, and topics discussed. You can leave out emails and status memos because you'll have archived that below.
9.1. Archive of the weekly status memos you sent to the client.
9.2. E-mail exchanges with the client.
9.3. Archive of weekly task and progress reports that we work through in our team meetings.
Project Presentations - Presentations to the class and the client.
Architecture, Analysis, and Rough Design- This section begins with initial software models and descriptions of any prototype developments (including outcomes/conclusions). Later design is documented with things like system block diagrams and necessary descriptive text for control and data flow.
Detailed Design - This section contains the detailed design documentation. Interfaces: user, data, other systems; module descriptions, logic flow. Could be combined with Architecture docs, above.
Test Plan - This section contains a description of your testing goals and your test regime, i.e., test plans for unit test, system test, usability testing, acceptance testing --- anything you did for assuring the quality and correctness of your solution. Testing materials, e.g., the "lab manuals" developed for usability tests should appear in an appendix.
Testing Results - The collected results from the testing regime. Includes outcomes from expert reviews, usability tests, and so on. Generally test results start with the facts of the test: what kind of test, what date, testing goals, participants. Then results are presented. Finally, a conclusion section discusses what was learned and planned modifications to the design.
FINAL Report - This is the final project report that is submitted to your client. It should serve as a "post-mortem" for the entire project: it should contain a summary of every major phase of the project: The usual intro with problem statement, solution overview, etc, then small (!!) summaries of design process, requirements and specs, architecture, implementation milestones, testing regime and results, and conclusion summarizing (hopefully very positive) outcomes. The final report should include an as-built report; this can either placed as a major section in the final report or (preferred) as an addendum/appendix to the final report. It is basically a revision of your design document updated to reflect any design changes that happened during the actual implementation process (things rarely work out as planned!). So this document detailed exactly the design of the code that was actually delivered to the client; add a closing section giving thoughts on overall design outcomes and recommended future modifications to the design, if any.
Software Documentation - This section contains the documentation for the as-built software, including: install procedures, user manual OR user interface description, …

Appendix - This section contains any material that is relevant to the project but does not fit into one of the previous sections or best belongs at the end of the documentation.