One of the reading notes on writing effective use cases

1. Full formal use case format: (1) Single-column text (not a table) (2) Step number (3) No conditional statement (4) The numbering sequence for the extended part is a combination of numbers and letters

Full formal use case template < name >

The < use case name should be a use case target represented by the verb phrase of the active voice > Use context :< A longer description of the target, and, if necessary, trigger events > scope :< design scope to consider the system as a black box at design time > level :< overview, user goals, sub-function one of the three > main Performer:< Master performs this role name or description of the main performer > project-related people and benefits :A list of project stakeholders and key interests in < use cases > Preconditions:< What we want, the state of the surrounding environment has reached > Minimum Guarantee :< How to guarantee the necessary information before all exit operations > Success Guarantee :< The status of the environment when the target is completed > Trigger Event :< What caused the use case, possibly a time event > Main Success Scenarios : < here to write from the trigger event to the goal completion and clear steps > < step number #>< action description > Extensions : < writes an extension here, each time an extension is written, each extension points to a specific step in the main scene > < changed steps >< conditions ;:< actions or sub-cases > < changed steps >< conditions ;:< actions or sub-cases > List of technical and data changes : < here to write about possible branches of the scene due to changes in technology or data > < step or change number #>< change list > < step or change number #>< change list > Related information < All additional information required for the project >

2, graphic symbols have two usability problems, first, the end user and business performers can not be familiar with these symbols, and will not have the patience to learn these symbols; second, the graph does not fully represent what you need. The use cases themselves are words, and any graphic is just to help the reader find the text they want to read.

3. Factors that affect the writing format of use cases

(1) Contradictory factors: business environment, social function, different culture

The first factor in this list is really not too much, especially in China, vast territory, a lot of projects may be northern companies to do projects in the south, different cultural backgrounds, language is not very consistent, this will directly affect the accuracy of demand acquisition

(2) Understanding levels

Originally the development personnel and the business personnel to exist the understanding level inconsistency question, the developer does not have the business personnel to understand the business knowledge, the business personnel does not have the developer to understand the software development knowledge, therefore must reduce this factor the influence to have to find a common standard format "the language" (like the universal Use case format) and the very good division of labor and

(3) requirements of the relevant personnel of the project

Each stakeholder (that is, project-related people) have their own areas of concern, so their requirements are not the same, so-called tune, here embodies the incisively and vividly.

(4) experience and format

(5) Coverage

(6) Consistency

(7) Complexity

(8) Integrity

(9) Goals and tasks-what to accomplish and how to accomplish it

(10) Resources

(11) Other factors

There are so many factors, so demand research can not be promoted in a fixed mode, only in a relatively large framework, through the research personnel to play a subjective initiative and stakeholders to complete the needs of research, but these factors are to remind people in the needs of research process should pay attention to the problem.

4, five types of project standards, five kinds of situations:

(1) Understand the requirements, even if the use cases are not used at all in the final requirements document (see p108 for Templates )

Your use case is often used as a black box, most of which are user target levels. You can use a higher-level use case to describe the context, but you might want to avoid using use cases below sea level frequently.

(2) Business process modeling (see p108 for Templates )

People who read these use cases tend to be high-level, departmental managers, and senior executives, so try to make these use cases more readable and less detailed. The number of the step highlights the time order of the activity. Be sure to describe the handling of errors in the extension in order to reveal important business rules.

(3) design and quantify system requirements (template see p109)

Use this template when you are analyzing requirements for estimating the size and structure of the system. Later, you can refine the requirements to know the complete use case for completing this.

(4) write functional requirements in a short-term, high-intensity project (see p110 for Templates )

For time and economic reasons, you need to avoid coding overhead and write a full template, so you can use an informal format. But you still have to understand preconditions, guarantees, and extensions.

(5) in a long-term, large-scale project, at the beginning of incremental development to write detailed functional requirements. (See p110 for Templates )

You can use the above template when you are collecting behavioral requirements and need all the information in the full formal use case format. This template may be used in large, critical, expensive projects, or in projects with fixed budgets, or in applications where development components are not in place, in the initial phase of incremental development, where the quantification of previously designed use cases needs to be expanded and checked;

One of the reading notes on writing effective use cases