Design Review Checklist

1. Are the following attributes well-defined for each design entity?

a. Identification (unique name)
b. Type (describing what kind of design entity it is)
c. Purpose (describing why it was introduced, in terms of the requirements)
d. Function (summarizing what the comonent does)
e. Dependencies (ossibly !none"# describing the requires or uses
relationshi)
f. Interface (provided by the design entity)
g. Processing (including autonomous acti$ities)
h. Data (information !hidden" inside)
%. &s the relationshi to the requirements clearly moti$ated? &s it clear why the
roosed architecture realizes the requirements?
'. &s the software architecture as simple as ossible (but no simler)?
o (o more than ) loosely-couled coherent high-le$el comonents.
o *ower-le$el comonents ossibly clustered into high-le$el comonents
(hierarchy).
o +sing standard(ized) comonents.
o &s de$iation from intuiti$ely ob$ious solution moti$ated?
2. &s the architecture complete?
o Are all requirements co$ered?
o ,race some critical requirements through the architecture (e.g. $ia use
cases).
3. Are the comonent descritions sufficiently precise?
o -o they allow indeendent construction?
o Are interfaces and external functionality of the high-le$el comonents
described in sufficient detail?
o &nterface details.
/outine kind, name, arameters and their tyes, return tye, re-
and ost-condition, usage rotocol with resect to other routines.
0ile name, format, ermissions.
1ocket number and rotocol.
1hared $ariables, synchronization rimiti$es (locks).
o 2a$e features of the target rogramming language been used where
aroriate?
o 2a$e imlementation details been a$oided? (No details of internal
classes.)
4. Are the relationships between the comonents e3licitly documented?
o 4referably use a diagram
5. &s the roosed solution achievale?
o 5an the comonents be imlemented or bought, and then integrated
together.
o 4ossibly introduce a second layer of decomosition to get a better gri on
achie$ability.
6. Are all relevant architectural views documented?
o !ogical (1tructural) $iew (class diagram er comonent e3resses
functionality).
o Process $iew (how control threads are set u, interact, e$ol$e, and die).
o Physical $iew (deloyment diagram relates comonents to equiment).
o Development $iew (how code is organized in files).
7. Are cross"cutting issues clearly and generally resol$ed?
o 63cetion handling.
o &nitialization and reset.
o 7emory management.
o 1ecurity.
o &nternationalization.
o 8uilt-in hel.
o 8uilt-in test facilities.
8. &s all formali#ed material and diagrammatic material accomanied by
sufficient e3lanatory te3t in natural language?
9. Are design decisions documented e3licitly and moti$ated?
o /estrictions on de$eloer freedom with resect to the requirements.
10. 2as an e$aluation of the software architecture been documented?
o 2a$e alternati$e architectures been considered?
o 2a$e non-functional requirements also been considered?
o Negative indicators.
2igh complexity. a comonent has a comle3 interface or
functionality.
*ow cohesion. a comonent contains unrelated functionality.
2igh coupling. two or more comonents ha$e many (mutual)
connections.
2igh fan"in. a comonent is needed by many other comonents.
2igh fan"out. a comonent deends on many other comonents.
11. &s the flexiility of the architecture demonstrated?
o 2ow can it coe with likely changes in the requirements?
o 2a$e the most rele$ant change scenarios been documented?