SwArcDocDesignDocumentation

Design Documentation

Introduction

Purpose

Design documentation is the documentation of design decisions.

When a development group(team/department) receives the Architecture documentation, the group needs to make decisions on how to implement the architetural requirements.

When the development group makes decisions, that are not decided at the architectural level it is probably a good idea to document the design decisions.

Example of design decisions:

• things local to group.
• OS to use.

It looks like design is really a question of selecting the solution in a data driven way.

I originally thought that design docs where used for doing interface docs etc. but now it seems to me that the design doc is a very thing layer, simply stating the options, pitching the advantages and disadvantage of the various optional solutions.

So I Assume you would go from StoryCard or Requirement, through Design Docs to Requirements.

Templates

So a Design Entry would contain:

• Id:
• Headline:
• Description:
• Option:
• Headline:
• Description:
• Evaluation:
  • Id:
  • Type: Advantage/Disadvantage
  • Description:
  • Rating:
• Design decission:
• Option selected:
• Reasoning:

The rating thing should be some sort of Charter/six sigma, possibly tie it in to the objectives?

Open Issues

• Where does the context model come into play?: Is it perhaps the functional model?
• Where does the following fit in:
  • Identify concurrency inherent in the problem [Rum91, 262]
  • Choose basic strategy for implementing data stores
  • Identify global resources and how to control them

DESIGN_HEADER

• Description

• Selected design

• Selection reason

Design option X

• Description
• OptionEvaluation A
  • Description:
  • Rating

TODO maybe do this as a cano diagram?