Effective use case Patterns read Note three

Fifth use case 5.1 compeltesinglegole

Inappropriate targeting will make it impossible for writers to determine when a use case ends and when another use case begins.

Reason:

Too large a use case may take up much of the attention of the stakeholder as a result of too much detail;

Large use-case restriction reuse;

Too small a use case can only describe some part of the value implementation;

So:

Write each use case to describe a complete and well-defined goal.

The characteristics of the muzzle velocity target are:

? It is related to a well-defined participant;

? It is valuable for participants or participants to represent the stakeholders;

? It is consistent with other objectives identified at this level for the system;

? Avoid connecting with specific pretext details, and write the use cases to complete the target fragment;

5.2 Verbphrasename

A generic name that doesn't make sense does not give the reader any expectation, nor does it provide a convenient reference point.

Reason:

The name determines the tone and relevance of the reader and can provide a focal point for the writer;

The appropriate use case name enables the reader to see a large overview and is valid for the entire set of use cases;

So:

Name the use case with an active verb phrase that represents the main participant's goal .

5.3 scenarioplusfragments (main scene + branch fragment)

Readers must be able to read specific scenes or stories of interest to them very easily, otherwise they may become frustrated or omit important information.

Reason:

An interesting use case needs to capture the branch of the main success scenario;

Writing each branch as a complete story will blur the difference between story variants;

Separating each variant will also make it very difficult for writers to work;

Need to clearly identify the main success scenario;

So:

Write a successful storyline as a simple scenario, regardless of any possible failures. Below this scenario, put a piece of the story that shows what will happen.

5.4 Exhaustivealternatives

A use case can have many branches, and missing branches means that developers misunderstand the behavior of the system, and such systems are imperfect.

Reason:

Developers need to know how to handle errors;

The progress pressure limits the time that the developer can identify various changes;

Having information about change helps developers build a robust design;

So:

You must capture all the branching and failure conditions that are handled in the use case.

5.5 Adornments

including non-functional requirements in use cases can be difficult to confuse and blur use cases quickly.

Reason:

The purpose of use cases is to clearly express the functional requirements of the system;

You should not omit information that helps you understand the use case or is valuable to the developer;

So:

Create additional areas outside of the scene text of the use case template to accommodate supplemental information that is useful for the associated use case;

Use cases and other supplemental requirements are tightly linked, such as performance requirements, user interface descriptions, constraints, business rules, data dictionaries, and so on.

5.6 Preciseandreadable

Use cases that are too complex for nontechnical readers, or too imprecise for developers, are likely to lead to poorly constructed and inappropriate systems.

Reason:

For stakeholders and developers, use cases should be readable;

Developers have a tendency to add details and solutions;

Non-technical stakeholders may omit some of the necessary considerations;

It is bad to have a collection of different requirements documents for customers and developers;

So:

Use cases need to be readable enough to enable stakeholders to read and evaluate;

Use cases need to be precise enough so that developers can understand the systems they are building.

Effective use case Patterns read Note three