Project Name
??/??/04,
Version major.minor
This is a design and planning document template for CS169. Please fill out this template carefully. Items in italics are information that you are to fill in, beginning with the project name, date, and version number above. See below for an explanation of version numbers. If any sections is not applicable, put N/A in the body of the section (do not delete the section). Also, if the information has already been given in another document, refer to that document.
Each team must send a copy of this completed document to cs169@cory.eecs.berkeley.edu by 5pm on the due date. The subject line of the email message must contain only the word “proj4”.
Document Revision History:
Your first version of this document is version 1.0. After that minor changes increment the minor version number (e.g., 1.1, 1.2, …) and major changes increment the major version number and set the minor number to zero (e.g., 2.0, 3.0, …). We will follow this convention with other documents as well.
Rev. 1.0 YYYY-MM-DD - initial version
System Architecture
Here you should describe the high-level
architecture of your system: the major pieces and how they fit together. Use graphical notations as much as possible
in preference to English sentences. For
example, you could describe the architecture using UML, or a finite automaton,
if your system lends itself to these descriptions. Try to use standard
architectural elements (e.g., pipe-and-filter, client-server, event-based). Make
sure to describe the major interfaces between components.
Design Details
In this section go those important facets that
are not at the level of “architecture,” such as descriptions of critical
algorithms, protocols, and key invariants.
Also, wherever possible items should be linked back to your
specification. Ideally, you can match up
everything in the specification with where it is implemented in the design.
Testing plan
In this section goes a brief description of how
you plan to test the system. Thought
should be given to how mostly automatic testing
can be carried out, so as to maximize the limited number of human hours you
will have for testing your system. The
purpose of this section is a reality check that your design will in fact be
testable with a reasonable effort. You
should specifically discuss design decisions that affect testing, and describe
any test interfaces built into the system in this section. You must discuss
here your plans for unit testing (approach, when are they created, when are
they run), integration testing (what order), system testing (what kind), regression
testing (how are you going to organize and run them)
Plan
From your design you should prepare a plan. In particular, you should list all of
the tasks to be done, a preliminary assignment of tasks to people in the group, estimates of the time for each task, dependencies between tasks, and a
preliminary division into builds (e.g., which features are implemented in the first build, second build, and so on).
The plan should be designed to get some prototype system running as quickly as possible and then growing towards to the full project over a
sequence of builds. Please pay extra attention to the dependency relationships between tasks; you will almost certainly run into the situation where
one bit isn't done but everything else is waiting for it. In that case, you want to know exactly where resources need to go, and how urgent each bit is
(hint: NOT proportional to its size or importance in the whole system).
The
following checklist is provided to help the reviewers (and author) prepare for
the review by providing a set of questions for the reviewer to answer about the
design document. If the answer to any
question is "no", that item should be identified as an issue at the
review. The checklist is only a
guideline; it should not be solely relied upon for a complete review. Reviewers
may want to add their own questions to the checklist.
Y N CONTENT
___ ___ Are
all the interfaces to the system specified in detail?
___ ___ Are
acceptable solution alternatives and their trade-offs specified?
___ ___ Are
you satisfied with all parts of the document?
___ ___ Do
you believe all parts are possible to implement?
___ ___ Are
all parts of the document in agreement with the product
requirements?
___ ___ Is there risk associated with the proposed design? Is it
discussed in the document?
___ ___ Will
the goal for each type of testing be met with the testing that is described?
___ ___ Are
the testing activities scheduled at the appropriate times?
___ ___ Is each part of the document in agreement with all other
parts?
COMPLETENESS
___ ___ Have
alternative designs been considered and documented?
___ ___ Are
the limitations of the specified implementation sufficiently documented?
___ ___ Are
dependencies and assumptions thoroughly documented?
___ ___ Where information isn't available before review, are the
areas of incompleteness specified?
___ ___ Are
all the testing stages covered?
___ ___ Is the regression test strategy covered?
___ ___ Are
there high-level validation tests necessary and covered (performance, security,
etc.)?
CLARITY
___ ___ Is the solution at a fairly consistent and appropriate level
of
detail?
___ ___ Is the solution clear enough to be turned over to an
independent
group for implementation and
still be understood?
___ ___ Is the control flow and the data flow clear?
___ ___ Is each requirement (or feature list item) measurable (will
it be possible for independent
testing to determine whether each
requirement has been satisfied)?
___ ___ Is the test strategy for each type of testing clearly
described?
___ ___ Are
the test report requirements clearly described?
___ ___ Are
all items clear and not ambiguous? (Minor document
readability issues should be handled off-line, not in the
review,