Task: Design the Solution
Design the Solution
Disciplines: Programming

Purpose

To describe the elements of the system so that they support the required behavior, are of high quality, and fit within the architecture.

Relationships

RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    Outputs

      Main Description

      This task is about designing part of the system, not the whole system. It should be applied based upon some small subset of requirements. The requirements driving the design could be scenario-based functional requirements, non-functional requirements, or a combination.

      This task can be applied in some specific context such as the database access elements required for some scenario. In this case the task might be applied again later to deal with a different context on the same requirements. Keep in mind that to actually build some functionality of value to the users, all contexts will typically need to be designed and implemented. For example, to actually utilize some system capability, it will have to have been designed and implemented in its entire context, such as user interface, business rules, database access, etc.

      For cohesion and completeness, this task is described as an end-to-end pass of designing a scenario of system usage. In practice, this task will be revisited many times as the design is first considered, portions are implemented, more design is performed based on what was learned, etc. The healthiest application of this task is in very close proximity to the implementation.

      Steps

      Gain Understanding of Requirements

      Examine the relevant technical specifications to understand the scope of the design and the expectations on the design. If necessary, work with the Stakeholder and Analyst(s) to clarify ambiguous or missing information. If the requirements are determined to be incomplete or incorrect, work with the analyst to get the requirements improved and possibly submit a change request against the requirements.

      Identify Design Elements

      Identify the elements that collaborate together to provide the required behavior. This can start with the key abstractions, design, domain analysis, and classical analysis of the requirements (noun filtering) to derive the elements that would be required to fulfill them.

      Determine Collaboration to Realize Scenario

      Walk through the scenario distributing responsibilities to the participating elements and ensuring that the elements have the relationships required to collaborate. This step is about ensuring that a quality model is being created that is robust enough to support the requirements.

      Refine Design Decisions

      Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the architecture. In this step the design can take into consideration the actual implementation language and other technical decisions. Revisit the identification of the elements and the collaborations that realize the scenarios, if necessary, as this refinement takes into consideration details at a lower level of abstraction. Discuss testability issues, such as design elements that are difficult to test or critical performance areas, with the tester and architect.

      Design Internals

      Design large or complex elements or some complex internal behavior in more detail.

      This might just involve devising an algorithm that could be performed to produce the desired behavior. Add additional operations, attributes, and relationships to support the expectations of an element.

      Communicate Design

      Communicate the system's design to those who need to understand it. Though this is described here toward the end of the task, communication should be going on throughout the steps. Working collaboratively is always better than reviewing the work after it is complete.

      Here are some ways to communicate the design:

      • Formal models specified in UML.
      • Informal diagrams that render static structure and capture dynamic behavior.
      • Annotated code that communicates information about the static structure. This can be supplemented with textual descriptions of collaborative behavior across code modules.
      • Data models to describe the database schema.

      Here are some examples of individuals who will need to understand the design of the system:

      • Developers who will implement a solution based on the design.
      • Architects who can review the design to ensure that it conforms to the architecture or who might examine the design for opportunities to improve the architecture.
      • Other designers who can examine the design for applicability to other parts of the system.
      • Developers or other designers who will be working on other parts of the system that will depend on the elements designed in this task.
      • Other reviewers who will review the design for quality and adherence to standards.
      Evaluate the Design

      Evaluate the object design for coupling, cohesion, and other quality design measurements.

       

      Consider the design from various angles to ensure that it is a high-quality, communicable design. Work with other technical team members; an independent party can provide a fresh perspective. Use the tester and architect to provide perspectives on design quality and adherence to the architecture. However, when identifying potential reviewers, keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even more value by actively participating in the design effort itself. If design flaws are identified, improve the design.

      Key Considerations

      This task will be applied numerous times. Design is best performed in small chunks.