Chapter 5
5.1 Compeltesinglegole
Inappropriate goals, the writer will not be able to determine when an exemplary ends, when another use case begins.
the reason:
Too many use cases may account for most of the efforts to go to the details;
Big use case restriction reuse;
Excessive use cases can only describe part of certain value implementations;
and so:
Write each use case to describe a complete and definition of good goals.
The characteristics of the initial speed are:
It is related to a well-defined participant;
It is valuable to the participants or participants representing the people represented by participants;
It consistent with other goals determined by the system at this level;
• Avoid contact with the specific excuse details, and write the use case of completing the target fragment;
5.2 VerbphraseName
The meaningless normal name does not make the reader expects, nor does it provide a convenient reference point.
the reason:
The name determines the tone and associations for readers, and can provide a focus for writers;
The appropriate use case name enables the reader to see a big profile and is valid for the entire use case;
and so:
Name the use case with a active verb phrase on behalf of the main participant target.
5.3 Scenarioplusfragments (Main Scene Branch]
Readers must be able to read specific scenarios or their stories they are interested in; otherwise they may change frustration, or miss important information.
the reason:
An interesting use case requires the branch of the main successful scene;
Write each branch as a complete story will blur the difference between the stories variants;
Separation of each variant will also make the work of the writer very difficult;
Need to determine the main successful scene;
and so:
Write the successful storyline as simple scenes and do not consider any possible failure. In this scenario, the story piece is placed on what happens.
5.4 ExmaustAlternatives
Use cases can have a lot of branches, and some branches means that developers will misunderstand the behavior of the system, such a system is not perfect.
the reason:
Developers need to know how to handle errors;
Progress pressure limits the time when developers can identify various changes;
Information about change is helpful to build a robust design;
and so:
All branches and failures in use in use must be captured.
5.5 ADORNMENTS
It is difficult to use an example to mess with the case.
the reason:
The purpose of the use case is to clearly express the functional requirements of the system;
Should not be omission to help understand the use case or have valuable information on developers;
and so:
An additional area is created outside the scenario text of the use case template to accommodate additional information useful for associated use cases;
Use examples and other supplemental requirements tightly, for example: performance requirements, user interface descriptions, constraints, business rules, data dictionary, etc.
5.6 PreciseandReadable
It is not perfect for non-technical readers, or the developer is not perfect, it is likely or causes a system that constructs poor and inappropriate.
the reason:
Users should be readable for people and developers;
Developers have a tendency to add detail and solutions;
Non-technical people may miss some necessary considerations;
It is very bad for customers and developers to provide different demand documents;
and so:
The use case requires enough readable to make the public can read and evaluate;
The use case requires enough precise to develop the system they are building.
