Design the architecture
Analyze the Requirements Specification to generate the architectural design, its arrangement in subsystems and software components
defining the internal and external interfaces.
-
Identify design stakeholders and their concerns (e.g., what they expect to find in the Software Design).
-
Identify the relevant architectural mechanisms that could be used to satisfy the requirements, paying special
attention to the nonfunctional requirements. By architectural mechanisms we mean any pattern, heuristic,
tactic, or rule of thumb that is useful.
-
Identify at least one type of architectural view that addresses each design concern.
-
Design the software architecture by documenting relevant architectural views. This typically involves
considering the various architectural mechanisms available, producing diagrams in various visual notations, and
also documenting the rationale (e.g., alternatives considered, tradeoffs, assumptions, risks, results from
various forms of analysis, ...) that lead to the view. The requirements (both functional and non-functional)
and design concerns should all be addressed by the architecture. The architectural views should at least
identify the major building blocks of the design (layers, subsystems, high-level components, ...).
TIP: one way of performing this step is by recursive decomposition. You start with a set of requirements, and a
single component (the whole system) that must satisfy all these requirements. You then subdivide this component
in two or more components, assigning to each a subset of the requirements. You keep on decomposing in such a
fashion until a satisfactory level of granularity is obtained. For functional requirements, this is relatively
straightforward, because functional requirements can typically be mapped to specific portions of a system. For
non-functional requirements however, this is hard, because such requirements affect the whole system (for
example, it is hard to point to a portion of code that implements the "maintainability" or the "performance" in
a software system.
|
Describe the user interface
Describe in detail, the appearance and
the behaviour of the interface, based on the Requirements Specification in a way that resources for its implementation can be foreseen.
-
This point is worth considering for interactive systems where the development of the user interface is
anticipated to be nontrivial.
-
If the system under consideration does not have a user interface (e.g. a web service), this step is simply
ignored.
-
For a system that has a user interface which poses no specific challenges, the user interface can be considered
simply as another feature of the system to be developed.
|
Provide components details
Provide the detail of software components
and their interfaces to allow the construction in an evident way.
-
For each high-level component of the architecture, provide the component details in such a way that the design
is clearly understood by the people who will implement the solution (e.g., the programmers). As for the
architectural design, multiple views should be used to ensure that the various aspects of the design
(structure, behaviour, allowable interactions) are clearly expressed.
-
Verify that the detailed design of each architectural element is performed in accordance with the constraints
imposed by the architecture.
|
Generate or update the Traceability Record
-
The traceability record should have been produced during the requirement analysis activities.
-
Verify that every design element can be traced to a requirement.
-
Verify that every requirement is represented in design.
|
|