HIGH LEVEL DESIGN
QUALITY ASSURANCE CHECKLIST
[ ] Design document
format guidelines are followed?
[ ] Are there less than three errors in spelling, punctuation, and
grammar per page?
[ ] Are all components of the design consistent with each other and
with the SRS?
[ ] All narrative text meets the class writing standards (WPE level
- [ ] Is the design overview included as HTML comments in the
- [ ] Does the design overview contain all the sections required in
- [ ] Has the design overview been proofread for clarity by a
technical person not familiar with your project?
- [ ] Are all significant design tradeoffs documented in the design
- [ ] Do all design tradeoffs favor maintenance over performance
(unless pre-approved by the instructor)?
- [ ] Does the diagram conform to standard class diagraming
- [ ] Is the diagram neat and easy to read?
- [ ] Is the diagram free from duplicate association lines?
- [ ] Do the names and relationships match the class definitions
- [ ] Are the classes, attributes, and methods consistent with the
Dictionary and Data Model from the Specification?
- [ ] Are all Data Dictionary items included in the diagram?
- [ ] Has the Data Dictionary been updated to show new items that
CLASS DEFINITIONS (a.k.a. CLASS SKELETONS, ADT HEADERS)
- [ ] Does the diagram conform to standard structure chart notation?
- [ ] Is the diagram neat and easy to read?
- [ ] Do the module names match the method definitions in the class
- [ ] Does the vertical dimension in the chart show decreasing
levels of abstraction?
- [ ] Does the chart show proper decomposition? Is each module
"part of" its parent module?
- [ ] Does the chart show only decomposition and NOT procedural
information? It does NOT show the order in which tasks are
performed. It does NOT illustrate an algorithm.
- [ ] Does each block contain
a verb phrase, e.g. "Validate Username."
- [ ] Does each class in the class diagram have an associated
file that compiles?
- [ ] Does each class header include the documentation required in
format guidelines (especially an @author tag and a well
- [ ] Does each method header include the documentation required in
- [ ] Is each method name a verb phrase in active voice?
- [ ] (DBC teams) Does each method have documented pre/post
that are clear,
complete, and correct? (Exception: accessor methods normally don't
- [ ] Does the name for each abstraction and its description use
the problem domain? E.g., GameBoard, not Grid. CustomerList, not
- [ ] Are meaningful names chosen for parameters and data
attributes? See coding
- [ ] Are the data attributes consistent with the Data Dictionary?
- [ ] Has the range of data values been constrained so as to not
which are meaningless in the problem domain? E.g., don't use int for data that can never be negative.
Instead, use something like this
- [ ] Do collection classes handle their own persistent data?
- [ ] Are all instance variables private or protected?
- [ ] Is there a comment included for each design element that
back to the SRS?
- [ ] The diagrams conform to standard diagraming notation (e.g.
- [ ] A diagram is provided for each use-case or functional
has more than two objects involved, or has more than four steps)?
- [ ] Each diagram has a title.
- [ ] The diagram is consistent with the other design
the class and method names match exactly?
- [ ] There is a javadoc comment explaining the structure of each
composite data structure
- [ ] Your implementation choice for each data structure has been
explained in "Design
- [ ] javadoc uses the -private flag.
- [ ] The format and content for each external file is shown in
- [ ] A complete FTR Review Summary report is included.
- [ ] The requirements
- [ ] Listings are included of the compilation script showing
of all classes, and all javadoc.
- [ ] Listings use a non-proportional font.
- [ ] There are no compile errors or javadoc errors.
Conformance to Design Principles
- [ ] Does the design make effective use of abstraction? Does the
of the software design mimic the structure of the problem domain?
possible, the elements of the solution domain should map directly onto
elements of the problem domain. E.g., People waiting in line for a
bank teller should be represnted by a queue, not an array or vector.
The bank teller never needs to see the 3rd person in line.
- [ ] Does the design isolate the data from higher level functions?
no control processes that belong in the collection class should be
with the elemental data.
- [ ] Are User Interface classes completely disjoint from other
Avoid embedding user interface features within the internal data
- [ ] Is the solution thoroughly decomposed? Is each method at the
level of 'atomic' components?
is, it should perform just a single task that can be coded in less
30 lines (approximately).
- [ ] Is the design highly factored? Each task the system needs to
should be implemented in only one place.
- [ ] Does the design decomposition consist of interfaces that
complexity of connections between modules and with the external
The operations shouldn't have hidden interdependencies. Minimize the
of associations between classes.
- [ ] Is the design decomposed into methods that exhibit high cohesion?
Number of methods that access one or more of the same instance
should be small (or zero).
- [ ] Does the design distribute the "intelligence" so that no
has a disproportionate amount of responsibility?
- [ ] Does the design respect encapsulation? Don't expose private
with public get/set methods, unless absolutely necessary.
- [ ] Do the abstractions successfully separate interface from
That is, no implementation details should have public visibility.
- [ ] Has an appropriate implementation been chosen for the data?
- Don't use a record for a
collection of homogenous data
items, use an array.
- Don't use integers to 'encode' non-integer data items. Use
enumerated types (JDK1.5
1.5) to represent non-alphanumeric data
- Never use float
to represent monetary values.
- [ ] Is the design complete? Have all functional requirements and
data from the system specification been included? Can you prove it? Can
you trace each requirement into the design element which includes it?
Did you complete the requirements
traceability matrix and include it in the appendix?
- [ ] Does the design exhibit an architectural structure that has
using recognizable design patterns?
- [ ] Does the design exhibit uniformity and integration? It should
as though designed by a single individual.
- [ ] Does the design anticipate and accomodate unusual
if it must terminate, do so in a graceful manner?
- [ ] Does the design lend itself to evolutionary implementation
testing (a.k.a. "staged delivery")?
- [ ] Is the inheritance tree as shallow as possible? Deep
are difficult to comprehend. Consider object composition as an alternative.
If there are any items not checked,
provide an explanation on an attached page.
As a general rule, checklists with more than five unchecked items are
not ready for submission.
Tip: When Dr. Dalbey evaluates
your deliverable, in order to begin comprehending your design he will
read these three sections first:
The quality of writing in these sections is paramount. These
sections deserve your absolute best effort at crystal clear
writing. If these sections are poorly written it is impossible to
get a good grade.
- design overview
- design issues
- class descriptive headers
|Added writing tip
|Added requirements traceability
|Major reorganization into
categories of design principles.
||Reworked data implementation examples
||Added Explanation section
||Reworked to separate General issues from Mechanics
||Removed PSP forms
||Variable declarations must be commented.
Defect Logs must be included.
||Revised for Fall 2000