[Tool] Effective Use Case writing rules

1. the use case is essentially a function decomposition technique.

2. Use Case readers:

1) end users or business experts; 2) programmers;

3. Case Writer:

1) At least one person with a programming background to obtain the accuracy and accuracy required by the description;

2) at least one person familiar with business rules;

3) at least one person familiar with how to use the system in practice;

Create a small use case writing team (smallwritingteam ).

Reason: use cases must be written by persons with different points of view and professional knowledge.

However, it is difficult to bring a group of people together. In theory, the more people put into use cases, the faster the case compilation can be completed. In fact, large teams will become inefficient. This is because large writing teams are bound to develop use cases through collective discussion and add many unnecessary features.

Therefore, a team of two or three members is small enough to facilitate communication and consensus.

Several smallwritingteams can be used, but a Use Case designer should be developed to ensure that all use cases are consistent with the vision. The ultimate goal is to keep the process manageable, and a large team will devote more energy to management.

4. Use Case Development Process:

1)First, the development case overview is helpful.After completing the summary of use cases, the accuracy of the use cases is continuously improved as the understanding of the system increases. Avoid getting into the details of case writing from the beginning, lose focus, and cannot describe all possible extension conditions. At the end of case writing, you must make a lot of modifications after learning about the system.

2) It may take a lot of time to understand system behavior, and the cost of delay is expensive. You need to write the case as soon as possible. After analyzing the requirements, the requirements may change, the cost of incorrect requirements is expensive.Develop use cases in an iterative and width-first manner, Each iteration will improve the accuracy and accuracy of the case set:

1> start with something simple, such as a list of participants/use cases;

2> briefly describe the main scenario of the use case, that is, the high-level use case, to include the main scope of the use case;

3> Expand the subset of the abstract and fill in the details;

4> review and adjustment;

3)It is not a good idea to use different templates for the same project.Different projects need to be formal to different degrees, and different teams need different degrees of standardization and strictness. Everyone has different preferences for templates. The use of public writing forms in the Organization facilitates communication. Based on the project-related risks, Project characteristics, and the format of the case selection for the involved personnel, and used internally during the development of the project.

4)Batch Review Cases

Cause: many people may need to review use cases, which is expensive and time-consuming. Review is necessary for verification and validation of preparation and content. Stakeholders have a vested interest in use cases, but the process of everyone's participation in writing is very expensive, troublesome, and slow. If only one small write group is used for review, the interests of all stakeholders will not be taken into account; review may be expensive, tedious, and time-consuming.

Therefore, there are two types of reviews: one is the review conducted by a small internal team, which may need to be repeated many times; the other is the review conducted by the entire team, it may only be performed once.

5)Moderately stop Use Case Development

Ignoring the huge fear of important demands makes it possible for the builders and stakeholders to extend the demand collection activities. Developing a case model that exceeds the needs of the stakeholders and developers will not only waste resources, but also delay the project progress. Most people can work with a reasonable ambiguity, that is, Self-evident. Telling lies in detail cannot make them more accurate. After the use cases are complete and meet the needs of the participants, you need to stop developing the use cases.

Test Case Model integrity:

1) complete, readable, logically correct, and detailed enough for developers.

2) are all participants and goals identified and documented?

3) Do customers and their representatives acknowledge that the use case set is complete and that each use case is readable and correct?

[Tool] Effective Use Case writing rules