|| '''Category''' || '''Element''' || '''Check/Plus/Minus''' ||
   || Requirements   || Use Cases cover core gameplay   ||  || 
   ||    || Use Cases are reasonable (not overly ambitious for Alpha   ||  || 
   ||    || Use Cases provide clear, concise descriptions of gameplay scenarios   ||  || 
   ||    || Non-functional requirements that impact architecture are clearly articulated    ||  || 
   || Domain Diagrams   || Domain diagram identifies key domain concepts found in Use Cases   ||  || 
   ||    || Domain diagram identifies key relationships found in Use Cases   ||  || 
   || Class Diagrams   || Simple and Intuitive;   ||  || 
   ||    || Uses real game objects.    ||  || 
   ||    || Clearly articulates important aspects of interface.    ||  || 
   ||    || Identifies major collaborations between classes.    ||  || 
   ||    || Obeys single responsibility principle.    ||  || 
   ||    || Favors composition over inheritence.    ||  || 
   ||    || Obeys Law of Demeter.    ||  || 
   ||    || Encapsulates variation.    ||  || 
   ||    || Diagrams are clear and well drawn.    ||  || 
   || Sequence Diagrams   || Realize Use Cases   ||  || 
   ||    || Illustrate Low Coupling   ||  || 
   ||    || Avoids unnecessary details    ||  || 
   ||    || Diagrams are clear and well drawn.    ||  || 
   || Other Models   || Scoring models are clearly described, responsibilities      for maintaining and updated these models are clear in class       and sequence diagrams    ||  || 
   ||    || Simulation models are clearly described, responsibilities      for maintaining and updated these models are clear in class       and sequence diagrams    ||  || 
   ||    || Data models ncluding data structures and input/output specs are described,      responsibilities for maintaining data is clear in class       and sequence diagrams    ||  || 
   ||    || Important algorithms are clearly described,      responsibilities for implementing these algorithms are clear in class      and sequence diagrams    ||  || 
   || Feasibility;   || The team can build the architecture within Phase 2   ||  || 
   || Testability   || No obvious problems in testing an implementation of this architecture   ||  || 
   || Extensibility   || Design sufficiently flexible that extending for final game is reasonable   ||  || 
   ||    || Follows open-closed principle   ||  || 
   ||    || Design sufficiently intuitive and flexible so that others could extend   ||  || 
   || Design Patternsl   || Used as appropriate   ||  || 
   || Critique   || Problems in architecture are identified   ||  || 
   ||    || Reasons for not addressing problems are discussed   ||  || 
   || Response to Design Review   || Discusses how the design was reviewd in response to review issues   ||  || 
   ||    || Discusses issues raised in the review that were not addressed   ||  || 


'''Grade(10, 7, 3, 0):''' 
[[BR]]'''Comments:'''[[BR]] 
 Plus = +[[BR]]
 Check = V[[BR]]
 Minus = -[[BR]]
 WTF = ?[[BR]]