Use case identification for Requirement documents and use cases for Requirement documents

Use case identification for Requirement documents and use cases for Requirement documents

Case identification for Requirement documents

 

Case recognition is vital to your needs. Please give me some comments on this article.

1. use case diagram

A dynamic view that consists of actors, Use cases, and their relationships to describe system functions is called a Use Case diagram.

Ø the use case diagram is the product of requirement analysis. It mainly describes the relationship between participants and use cases, and helps users visually understand the functions of the system.

The use case diagram visually expresses the system requirements and has the advantages of being intuitive and standardized, and overcomes the shortcomings of pure text description.

The use case method defines system functions completely from the outside, and completely separates the requirements from the design.

 

2. Use Cases

Use cases represent an external function of the system, which analyzes the obtained requirements from the user's perspective. A collection of actions executed by the system to complete a relatively complete function

Ø is a system function that is externally visible.

Ø represents a complete function

There are a series of actions

 

3. Key points for identifying use cases 3.1. observability → use cases stop at system boundaries

Describes interactions rather than internal system activities.

3.2. Result value → use case is a meaningful target

Business functions, non-system processing

3.3. system execution → result value generated by the system

Which must be processed by the system;

3.4. Observed by participants → business languages and user views

Description from the perspective of participants and use the business language;

3.5. A group of use case instances → Use Case Granularity

Use Cases must have paths and paths must have steps. All these steps are Observability and most often make mistakes: granularity is too small, falls into functional decomposition, and granularity is too small, it generally leads to the description of the technical language instead of the business language.

Granularity of C (Create), R (Read), U (Update), and D (Delete)

All businesses will eventually become CRUD? Can CRUD provide value for Actor? CRUD masks the business and changes it to Relational Database Modeling: "The system is the addition, deletion, modification, and query of data". It cares about data storage and maintenance, but ignores the user's purpose.

If CRUD does not involve complex interactions, you can use a case to "manage XXX;

Whether it is C, R, U, D, it is to achieve the "management" goal;

Even many types of basic data management can be expressed using one use case;

Independent paths containing complex interactions can be used as use cases.

 

3.6. Use Case naming

Start with a verb;

 

 

 

 

 

 

 

 

How to propose the use case design ideas in the document as needed

It is directly dependent on the quality of requirement document writing. Generally, the process of converting my requirements into use cases is as follows: 1. Read all the requirements for a general understanding; 2. Focus on reading the functions described in this requirement, position in the software. Find the interface relationships with level, level, and level. In this step, you should be able to get the business process, test process, and test focus. 3. sort out all requirements to form the test points. At the same time, these test points form a test flowchart 4. Conduct detailed analysis and testing on each process node. These are my personal work summaries. However, some of our colleagues directly test the existing requirements without considering the association with other modules. After the first round of testing is completed, perform the interface test. I personally disagree with this method.

The requirements and design documents referenced in the software test cases are as follows:

The requirement document describes the details.
The design document is a general description document.

It mainly describes, restricts, inputs, and outputs functional points in the requirement document.