8/12/2019 Architecture Design Checklist

1/2

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 requiresor uses

relationshi)f. Interface(providedby the design entity)

g. Processing(including autonomous acti$ities)

h. Data(information !hidden" inside)%. &s the relationshi to the requirementsclearly moti$ated? &s it clear why the

roosed architecture realizes the requirements?

'. &s the software architecture as simpleas 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 interfacesand external functionalityof the high-le$el comonentsdescribed 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. ocket number and rotocol.

hared $ariables, synchronization rimiti$es (locks).

o 2a$e features of the target rogramming language been used wherearoriate?

o 2a$e imlementation details been a$oided? (Nodetails of internal

classes.)4. Are the relationshipsbetween 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.

8/12/2019 Architecture Design Checklist

2/2

6. Are all relevantarchitectural viewsdocumented?

o !ogical(tructural) $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 issuesclearly and generally resol$ed?

o 63cetion handling.

o &nitialization and reset.o 7emory management.

o ecurity.

o &nternationalization.o 8uilt-in hel.

o 8uilt-in test facilities.

8. &s all formali#ed materialand diagrammatic materialaccomanied by

sufficient e3lanatory te3t in natural language?9.

Are design decisionsdocumented 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 flexiilityof 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?