Writing protocol for describing use cases in software development

Describe the use case specification

It should be avoided that a use case diagram consisting of actors and use cases is a use case model, and the use case diagram simply outlines the various services that the system can provide, giving us a general understanding of the functionality of the system. In addition, we also need to describe each of the detailed information, which is contained in the use case specification, the use case model is a use case diagram and a detailed description of each use case-use case the specification of the composition. A template for the use case specification is provided in RUP, and the use case specification for each use case should contain the following: brief description (Brief Description)
The function and purpose of the use case are briefly introduced. Event flow (flow of event)
including the basic and alternate streams, the event stream should represent all the scenarios. Use case scenario (Use-case Scenario)
Including success scenarios and failure scenarios, scenarios are primarily composed of a combination of basic and alternative streams. Special needs (special requirement)
Describes the non-functional requirements associated with the use case, including performance, reliability, availability, and scalability, and design constraints (the operating system used, development tools, and so on). Pre-conditions (pre-condition)
The state that the system must be in before executing the use case. Post condition (post-condition)
A set of states that the system may be in after the use case has finished executing.

The use case specification is basically expressed in textual form, in order to more clearly describe the event flow, you can also choose to use a state diagram, activity diagram or sequence diagram to assist the description. As long as the clarity of the expression is helpful, you can paste the graphical display of the user interface and process, or other graphics, in the use case. As activity diagrams help describe complex decision processes, state transition diagrams help describe system behavior related to state, and sequence diagrams are suitable for describing time-based message delivery.

Basic Flow

The basic flow describes a scenario in which the use case is most normal, in which the system executes a series of activity steps in response to a service request made by the participant. We recommend that you describe the basic flow in the following format:

1) Each step requires a numerical number to clearly indicate the sequence of steps.

2) summarize the main content of each step with a short headline so that the reader can quickly understand the main steps of the use case by browsing the title. In the early days of use case modeling, we only needed to describe the level of the event flow step title to avoid getting bogged down in the details of the use case description prematurely.

3) When the entire use-case model is basically stable, we describe in detail the interactions that occur between the participants and the system for each step. It is recommended to use bidirectional (roundtrip) description to guarantee the completeness of the description, i.e. each step needs to be described from the positive and negative two aspects: (1) What information the participant submits to the system, and (2) what kind of response to the system. See appendix for specific examples.

When describing the exchange of information between participants and the system, it is necessary to indicate the specific information passed back and forth. For example, only stating that the participant entered the customer information is not clear enough, it is best to say explicitly that the participant entered the customer name and address. You can often use a glossary to keep the complexity of use cases manageable, define customer information in a glossary, and use examples to avoid getting bogged down in too much detail.

Alternate Stream

The alternate flow is responsible for describing exceptions or occasional cases during the execution of a use case, and the combination of alternate and basic flows should be able to overwrite all possible scenarios for that use case. When describing alternate flows, the following elements should be included:

1) starting point: The alternate flow starts at which step of the event stream;

2) Conditions: Under what conditions will trigger the alternative stream;

3) Action: What actions the system will take in this alternate stream;

4) Recovery: How the use case should continue after the alternate stream has ended.

Alternative streams can be described in a format that is consistent with the format of the basic stream, and they need to be numbered and outline their contents in headings, preceded by the letter prefix a (alternative) to indicate the difference from the basic flow step.

use case Scenarios

Use cases in the actual execution of the time there will be a lot of different situations, called use case scenarios, it can be said that the scene is an example of use cases, we describe the use case to cover all the use case scenario, otherwise it may lead to the omission of requirements. In the use case specification, the description of the scene can be represented by a combination of the basic stream and the alternate stream. Scenarios can help us prevent the omission of requirements, but can also help in the subsequent development efforts: developers must implement all the scenarios, testers can design test cases according to the use case scenario.

Special Needs

Special requirements are typically non-functional requirements, which are proprietary to a use case, but are not intended to be described in the event flow text of a use case. Examples of specific requirements include legal or regulatory requirements, application standards, and the quality attributes of the system being built (including availability, reliability, performance, or support requirements). In addition, other design constraints, such as operating system and environment, compatibility requirements, etc., can also be documented in this section.

It is important to note that the special requirements that are specific to the use case are recorded here, that they are not proprietary to some of the global non-functional requirements and design constraints, and that they should be recorded in the supplementary statute.

front and rear conditions

A precondition is a system state that must exist before a use case is executed, and a post condition is a set of states that the system may be in after a use case is completed.

Examine the use case model

Once the use case model is complete, you can examine the use case model to see if there are omissions or errors. It can be checked mainly from the following aspects: completeness of functional requirements
Whether the existing use case model completely describes the function of the system is a sign that we judge whether the use case modeling work is finished. If we find that the system functions are not recorded in the existing use case model, then we need to abstract some new use cases to document these requirements, or to summarize them in some existing use cases. Whether the model is easy to understand
The greatest advantage of the use case model is that it should be easily understood by different stakeholders, so the most important guiding principle of use case modeling is its understandable nature. The granularity, number of use cases, and the complexity of the relationship between model elements should be determined by the guiding principle. Is there an inconsistency?
The system's use case model is carried out by multiple system analysts, the model itself is composed of multiple artifacts, so we have to pay special attention to the existence of inconsistencies or conflicts before the different artifacts, to avoid inconsistencies within the model. Inconsistencies can directly affect the accuracy of the requirements definition. Avoiding the semantics of ambiguity
Good demand definition should be non-semantic, that is, different people's understanding of the same needs should be consistent. In the description of the use case specification, the definition of ambiguous requirements should be avoided, that is, no ambiguity.

                                                                             Citation: http://www.ibm.com/developerworks/cn/rational/r-usecase-atm/