next up previous contents index
Next: Architecture Up: Four Fundamental Phases Previous: Incomplete and Non-Monotonic Requirements

The Design Phase

The design phase is summarized in Table gif on page  gif.  

  [IMAGE ]
Table: The Design Phase

In the design phase the architecture is established. This phase starts with the requirement document delivered by the requirement phase and maps the requirements into an architecture. The architecture defines the components, their interfaces and behaviors. The deliverable design document is the architecture. The design document describes a plan to implement the requirements. This phase represents the ``how'' phase. Details on computer programming languages and environments, machines, packages, application architecture, distributed architecture layering, memory size, platform, algorithms, data structures, global type definitions, interfaces, and many other engineering details are established.

The architectural team can now expand upon the information established in the requirement document. Using the typical and atypical scenarios provided from the requirement document, performance tradeoffs can be accomplished as well as complexity of implementation tradeoffs.

Obviously, if an action is done many times, it needs to be done well. A seldom used action needs to be implemented correctly but it is not obvious the level of performance that is required. The requirement document must guide in this decision process. An example of a seldom used action which must be done with high performance is an emergency shutdown of a nuclear reactor.

Analyzing the tradeoffs of necessary complexity allows for many things to remain simple which, in turn, will eventually lead to a higher quality product.

The architecture team also converts the typical scenarios into a test plan. The team, given a complete requirement document, must indicate critical priorities   for the implementation team. A critical implementation priority leads to a task that has to be done right. If it fails, the product fails. If it succeeds the product might succeed. At the very least, the confidence level of the team producing a successful product will increase. This will focus the implementation team.




next up previous contents index
Next: Architecture Up: Four Fundamental Phases Previous: Incomplete and Non-Monotonic Requirements

Ronald LeRoi Burback
Wed Jul 30 10:49:53 PDT 1997