Guidelines: Important Decisions in Analysis & Design
Topics
- Decide How to Perform the Workflow
- Decide How to Use Artifacts
- Decide Which Reports to Use
- Decide How to Review
- Decide Whether to Generate Code
Decide How to Perform the
Workflow 
The following decisions should be made regarding the Analysis & Design workflow:
- Decide how to perform the workflow by looking at the Analysis & Design: Workflow Details. Study the diagram with its guard conditions, and the guidelines. Decide which workflow details to perform and in which order.
- Decide which parts of the Analysis & Design workflow to perform. The following are some parts that can be introduced relatively independently of the rest of the rest of the workflow.
|
Part of workflow |
Comments |
| Database design | Only used if the entities are going to be stored in a database. If you decide to not do database design, it means that you do not develop any Data Model. |
| Real time, using Rational Rose RealTime | If you decide to not do this, it means that you do not develop artifacts such as Capsule, Event, protocol, and Signal. |
- Decide when, during the project lifecycle, to introduce each part of the workflow. It is sometimes possible to wait until the Elaboration phase before introducing the Analysis & Design workflow. For example, if the development is in a well-understood domain, does not have demanding performance (or other non-functional) requirements, and will be based on a well-tried architecture, there is little need for prototyping during inception.
Document the decisions in the section "Core Workflows / Analysis & Design / Workflow", in the Development Case.
Decide How to Use Artifacts
Make a decision about what artifacts to use and how to use each of them. The table below describes mandatory artifacts and those artifacts used only in certain cases. For more detailed information on how to tailor each artifact, and a discussion of the advantages and disadvantages of that specific artifact, read the section titled "Tailoring" for each artifact.
For each artifact, decide how the artifact should be used: Must, Should, Could or Won't. For more details, see the Guidelines: Classifying Artifacts.
| Artifact | Brief Tailoring Comments (see the artifact for details) |
| Analysis class | Could have. Used if a separate analysis model is developed and maintained. |
| Analysis model | Could have. See Analysis class. |
| Capsule | Could have. Can be useful in modeling and designing systems that have a high degree of concurrency. |
| Data model | Could have. Used to describe the logical and possibly physical structure of the persistent information. |
| Deployment Model | Must have if you deploy the system. |
| Design class | Must have if you do Analysis & Design. The issue is deciding which stereotypes to use. |
| Design model | Must have if you do Analysis & Design. |
| Design package | Must have if you do Analysis & Design. Decide which stereotypes to use and how many levels of packages. |
| Design subsystem | Must have if you do Analysis & Design. |
| Event | Could have. |
| Interface | Could have. |
| Protocol | Could have. |
| Signal | Could have. |
| Software Architecture Document (SAD) | Must have if you do Analysis & Design. The main issue is deciding which architectural views you need in your specific project. |
| Use-case realization | Must have if you do Analysis & Design. |
Tailor each artifact by performing the steps described under the heading "Tailor Artifacts per Workflow" in the Activity: Develop Development Case.
Decide Which Reports to Use
Make a decision about what reports to use. As a starting point, consider using the following reports:
Decide How to Review
Decide on the review level for each artifact and capture it in the development case. See Guidelines: Review Levels for details.
Decide how to review and approve the results of Analysis & Design, and to what extent the results will be reviewed.
The advantages of a design review are:
- It detects problems that are impossible, or very difficult, to detect in testing. For example, issues of style, and layout.
- It is a way to enforce a common modeling style and an opportunity for individuals to learn from each other.
- It detects those defects that wouldn't otherwise get detected until later in the project during tests.
The disadvantages of a design review are:
- It takes time and resources.
- It is easily misused if not managed well.
The factors that can be altered are review techniques, resources, and scope. The following are some examples of what you can decide to do on your project:
- Decide that local changes to a subsystem are reviewed only by one peer, who conducts an inspection and hands over the results on paper.
- Decide on which parts of the design will not be reviewed at all; for example, review only some classes for each member of the project and hope that this assures the style is of a similar quality to the rest of the results.
- Decide that the Software Architecture Document will be reviewed by customer during a separate meeting.
- Decide to use formal review meetings for changes in important interfaces; that is, interfaces that affect the work of several project members.
For more information about reviewing and different kinds of reviews, see Work Guideline: Reviews.
Decide Whether to Generate Code
The way you do design differs depending on if you generate code from the design model or not. If you generate code, the design needs to be very detailed. On the other hand, if you do not generate code from the design, there is no need to be very detailed in the design. On the contrary, the details in the design has to be manually synchronized with the code.
