HIGH LEVEL DESIGN 
QUALITY ASSURANCE CHECKLIST

Mechanics

[ ] 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 4)?

DESIGN OVERVIEW

1. [ ] Is the design overview included as HTML comments in the javadoc overview section?
2. [ ] Does the design overview contain all the sections required in the document format guidelines?
3. [ ] Has the design overview been proofread for clarity by a technical person not familiar with your project?
4. [ ] Are all significant design tradeoffs documented in the design issues section?
   
5. [ ] Do all design tradeoffs favor maintenance over performance (unless pre-approved by the instructor)?
   

1. [ ] Does the diagram conform to standard class diagraming notation (e.g. UML)?
2. [ ] Is the diagram neat and easy to read?
3. [ ] Is the diagram free from duplicate association lines?
4. [ ] Do the names and relationships match the class definitions (below) exactly?
5. [ ] Are the classes, attributes, and methods consistent with the Data Dictionary and Data Model from the Specification?
6. [ ] Are all Data Dictionary items included in the diagram?
7. [ ] Has the Data Dictionary been updated to show new items that were added during design?

1. [ ] Does the diagram conform to standard structure chart notation?
   
2. [ ] Is the diagram neat and easy to read?
3. [ ] Do the module names match the method definitions in the class skeletons (below) exactly?
4. [ ] Does the vertical dimension in the chart show decreasing levels of abstraction?
5. [ ] Does the chart show proper decomposition? Is each module "part of" its parent module?
6. [ ] 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.
7. [ ] Does each block contain a verb phrase, e.g. "Validate Username."

1. [ ] Does each class in the class diagram have an associated definition file that compiles?
2. [ ] Does each class header include the documentation required in the document format guidelines (especially an @author tag and a well written descriptive header)?
3. [ ] Does each method header include the documentation required in the document format guidelines?
4. [ ] Is each method name a verb phrase in active voice?
5. [ ] (DBC teams) Does each method have documented pre/post conditions that are clear, complete, and correct? (Exception: accessor methods normally don't required pre/post conditions).
6. [ ] Does the name for each abstraction and its description use terms from the problem domain? E.g., GameBoard, not Grid. CustomerList, not CustomerArray
7. [ ] Are meaningful names chosen for parameters and data attributes? See coding standard.
8. [ ] Are the data attributes consistent with the Data Dictionary?
9. [ ] Has the range of data values been constrained so as to not allow values 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 Natural class.
10. [ ] Do collection classes handle their own persistent data?
11. [ ] Are all instance variables private or protected?
12. [ ] Is there a comment included for each design element that traces it back to the SRS?

1. [ ] The diagrams conform to standard diagraming notation (e.g. UML)?
2. [ ] A diagram is provided for each use-case or functional requirement (that has more than two objects involved, or has more than four steps)?
3. [ ] Each diagram has a title.
4. [ ] The diagram is consistent with the other design documents?  All the class and method names match exactly?

1. [ ] There is a javadoc comment explaining the structure of each composite data structure in your solution.
2. [ ] Your implementation choice for each data structure has been explained in "Design Issues."
3. [ ] javadoc uses the -private flag.
4. [ ] The format and content for each external file is shown in detail.

1. [ ] A complete FTR Review Summary report is included.
2. [ ] The requirements traceability matrix.
   
3. [ ] Listings are included of the compilation script showing compilation of all classes, and all javadoc.
4. [ ] Listings use a non-proportional font.
5. [ ] There are no compile errors or javadoc errors.

Conformance to Design Principles

1. [ ] Does the design make effective use of abstraction? Does the structure of the software design mimic the structure of the problem domain? Whenever 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.
2. [ ] Does the design isolate the data from higher level functions? E.g., no control processes that belong in the collection class should be included with the elemental data.
3. [ ] Are User Interface classes completely disjoint from other classes? Avoid embedding user interface features within the internal data representation.

1. [ ] Is the solution thoroughly decomposed? Is each method at the level of 'atomic' components? That is, it should perform just a single task that can be coded in less than 30 lines (approximately).
2. [ ] Is the design highly factored? Each task the system needs to perform should be implemented in only one place.
3. [ ] Does the design decomposition consist of interfaces that reduce the complexity of connections between modules and with the external environment (low coupling)? The operations shouldn't have hidden interdependencies. Minimize the number of associations between classes.
4. [ ] Is the design decomposed into methods that exhibit high cohesion? Number of methods that access one or more of the same instance variables should be small (or zero).
5. [ ] Does the design distribute the "intelligence" so that no single component has a disproportionate amount of responsibility?

1. [ ] Does the design respect encapsulation? Don't expose private class data with public get/set methods, unless absolutely necessary.
2. [ ] Do the abstractions successfully separate interface from implementation? That is, no implementation details should have public visibility.
3. [ ] Has an appropriate implementation been chosen for the data? For example,
   • 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 or  pre-JDK 1.5) to represent non-alphanumeric data
   • Never use float to represent monetary values.

General

1. [ ] Is the design complete? Have all functional requirements and problem 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?
2. [ ] Does the design exhibit an architectural structure that has been created using recognizable design patterns?
3. [ ] Does the design exhibit uniformity and integration? It should appear as though designed by a single individual.
4. [ ] Does the design anticipate and accomodate unusual circumstances, and if it must terminate, do so in a graceful manner?
5. [ ] Does the design lend itself to evolutionary implementation and testing (a.k.a. "staged delivery")?
6. [ ] Is the inheritance tree as shallow as possible? Deep inheritance trees are difficult to comprehend.  Consider object composition as an alternative.

• design overview
• design issues
• class descriptive headers