Task Descriptor: Design the Solution
Identify the elements and devise the interactions, behavior, relations, and data necessary to support some functionality.

Render the design visually to aid in solving the problem and communicating the solution.

Based on Method Task:  Design the Solution
Relationships
RolesMain: Additional: Assisting:
InputsMandatory: Optional: External:
  • None
Outputs
Steps
Understand requirement details
Examine the relevant requirements to understand the scope of the design task and the expectations on the design.

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 identified in the architecture, domain analysis, and classical analysis of the requirements (noun filtering) to derive the elements that would be required to fulfill them.

Identify elements in all perspectives being considered when performing this task.  This could include identifying user interface elements, control elements, data elements, and elements relating to interfacing to other systems or devices.

Existing elements of the design should be examined to see if they should participate in the collaboration.  It is a mistake to create all new elements in each execution of this task.

This list of candidates must be expanded to include special-purpose participants that handle particular roles in providing the required behavior such as transaction processing or adherence to some security specification.  The Entity-Control-Boundary Pattern provides a good start for identifying elements.

Determine how elements collaborate to realize the scenario

Walk through the scenario distributing responsibilities to the participating elements.  These responsibilities can be simple statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc.  This step is about ensuring that a quality model is being created that is robust enough to support the requirements.

Identify the required relationships between the elements based on the walkthrough of the scenario examining how the elements initiate each other's behavior.  As with the responsibilities, these relationships can just be defined at this step.

Look to the architecture and previous design work to create a consistent collaboration.  Look to reuse existing behavior and relations or to apply similar structure to simplify the design of the overall system.

Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the existing elements.

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.  As refinement takes into consideration details at a lower level of abstraction, this might necessitate revisiting the identification of the elements and the collaborations that realize the scenario.

In particular make decisions in regard to

  • specific details of relationships between the elements
  • operation detail
  • existence and detail of data attributes necessary
  • usage of inheritance and interfaces to improve the design

Incorporate design mechanisms from the architecture. Apply consistent structure of the elements and organization of the behavior as in other areas of the design and use patterns identified in the architecture.

Design internals (for large or complex elements)

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. This could involve another whole pass through this task where the scenario under consideration is one behavior element of an element that requires significant design consideration.  Add additional operations, attributes, and relationships to support the expectations of an element.

The state of the element managed over the course of its lifetime can be designed to ensure proper behavior in various usages.

Communicate the design

Communicate the 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.

Some ways to communicate the design are:

  • formal models specified in UML
  • informal diagrams that static structure and capture dynamic behavior
  • annotated code that communicates information about the static structure supplemented with textual descriptions of dynamic behavior across code modules 

Examples of individuals that will need to understand the design are:

  • developers who will implement a solution based on the design
  • an architect 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

When considering reviewers, keep in mind that if someone can add value by reviewing the design, then they could have added even more value by actively participating in the design effort itself.

Evaluate the design

Evaluate the 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.

Properties
Predecessor
Multiple Occurrences
Event-Driven
Ongoing
Optional
Planned
Repeatable