Task: SI.3.3 Document Software Design
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    Outputs
      Steps
      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.