Overview of Use Cases

When talking about use cases, many people may be familiar with them, but many will not actually use them. Next, based on the accumulation and reading of books over a period of time, we will summarize the following, which will inevitably lead to errors. We also hope to criticize and correct the mistakes and make progress together.

Use Cases are the product of the demand stage and used to help obtain and mine system requirements.

 

First, let's look at what isRequirementRequirements are the capabilities required by the system or project and the conditions that must be met (reference: JBR99 ). Waterfall is not recommended for Demand Management

The idea is that before programming, the first stage of the project tries to fully define and solidify the demand.

The ever-changing requirements of the system (RUP ). In the traditional waterfall method, it is unrealistic to try to define the so-called 'complete' requirement or specification description before development, even if the definition is

It may be incomplete. The biggest challenge of demand analysis is to find, communicate, and remember what is really needed.

 

Evolutionary and waterfall needs

The waterfall model was used in the early stages of software projects for demand analysis in 1960s and is considered universal and effective. However, since 1980s, this method gradually

It proved to be poor and caused a lot of project failures. The root cause is that software and large-scale manufacturing projects are considered equal. The latter is predictable and has a low change rate.

. However, software has a high change rate and has a large number of novelty and requires a lot of discovery and exploration. According to statistics, the average demand change rate of software projects is 25%, because

Therefore, any method that tries to fix or define all requirements at the beginning has a fundamental defect. [Thomas01] is cited here to study the failure factors of 1027 software projects.

Trying waterfall practice is the main cause of failure of these projects. 82% of projects list them as top-level issues. The conclusion is that any hypothetical requirement will not be met once a document is created.

Methods with significant changes are inherently flawed. It is inappropriate to spend a lot of time and effort to define the demand to the maximum extent. One method of compromise is: combining early

Quantitative iterative development of time periods, iterative and evolutionary demand analysis, and frequent stakeholder participation, evaluation, and feedback on local results.

 

Types of requirements:
The "FURPS +" model is used to classify UP requests. Its meaning is as follows:

Functionality: features, functions, and security
Availability: human factors, help, documentation
Reliability: Fault frequency, recoverability, and predictability
Performance: response time, throughput, accuracy, validity, and resource utilization
Support: adaptability, maintainability, internationalization, and configurability
+ Refers to auxiliary and secondary factors. For example: implementation, interface, operation, packaging, authorization, etc.

 

How to organize requirements:

Optional products provided by UP, mainly including:
Case model: a set of typical use cases.
Supplementary Specification Description: It is basically all content outside the use case.
Vocabulary: defines important terms in a simple form.
Business Rules: Describes the rules that many applications should follow.
And so on

 

Use Case:

Use Cases are case descriptions in the text form and are widely used in the discovery and recording of requirements. The use of regular meetings affects many aspects of software projects, including OOAD.

Input of a series of subsequent processes.

Note: use cases are not graphs, but texts. Readers must be able to distinguish between use cases and use case diagrams. The essence of use cases is to discover and record functional requirements by writing scenarios that use systems to achieve user goals.

 

Participants, scenarios, and Use Cases
A participant is a behavior-oriented transaction. It can be a person, a computer system, or an organization.
A scenario is a series of specific activities and interactions between participants and the system, also known as case instances. Is an execution path that uses a specific scenario or use case of the system.
For example, purchasing goods in cash, using a credit card, or failing to purchase goods if the amount is insufficient are all scenarios.

 

Use Cases and use case models

Use Cases are text documents rather than graphs. The Use Case creation mode is mainly used to write text activities rather than plotting.
The Use Case model can contain the use case diagram.

 

Motivation of use cases:
In software projects, lack of user participation is the main cause of project failure. Any method that facilitates user participation is worthwhile. The use case is such an excellent method,

This makes it possible for users or domain experts to write their own use cases.
Another value of use cases is to emphasize the user's goals and opinions.
For example, who uses the system? What are their typical use cases? What is the purpose?

Use Case is Requirement
It mainly describes the functional or behavioral needs of the system. In the Unified Process and other modern methods, use cases are recommended as the core mechanism for discovering and defining requirements.
Remember: Use Cases are real requirements (though not all requirements ).

 

Three types of participants:
Main participants
Assist participants
Behind-the-scenes participants

 

Three common use cases:
Abstract: A concise summary is generally used in early requirement analysis. You need to quickly understand the topic and scope, and you may only need to write it in a few minutes.
Informal: Informal paragraph format. Several paragraphs cover different scenarios.
Detailed Description: describes all the steps and changes in detail. At the same time, there are supplementary parts, such as preconditions and guarantee of success.

Guidelines for writing Use Cases

Criterion: Write use cases in an essential style without user interface constraints-write use cases in an essential style to avoid specific use cases.
Criterion: Write simple use cases-you do not like to read documents with a large number of text descriptions...
Guidelines: Write black box use cases-the difference between analysis and design lies in the difference between "what" and "how.
Guideline: Use the viewpoint of participants and participants-the core of the case
Criterion: how to discover Use Cases
1. Select system boundaries
2. Search for major participants

3. Determine the objectives of key participants
4. Define use cases meeting user goals
The Use Case name should start with a verb, in the form of a verb + ranking phrase.

 

Use case diagram:

UML provides an example Graph Representation to describe the relationship between the use case name and the participants. The relationship between Use Case charts and use cases is secondary in writing use cases. Use Cases are text documents. Writing use cases means writing texts.