Use Case features --- From elephant --- think in UML

Use Case features

Use cases have a series of features. These features ensure that the use case can correctly capture functional requirements, and these features are also the basis for determining whether the use case is accurate.

1. Use Cases are relatively independent

This means that it does not need to interact with other use cases to accomplish the goal of the participants alone. That is to say, the use cases are complete in terms of "functions. In essence, use cases reflect the aspirations of system participants. If they fail to fully fulfill the aspirations of the participants, they cannot be referred to as "taking money" as a valid use case. Because the complete information is money, no one will go to the bank to fill out the money order.

2. The execution results of use cases are Observability and meaningful to the participants.

For example, a background process monitors the operations performed by the participant in the system and backs up the data before the participant deletes the data. Although it is an essential part of the system, it should not be used as a case in the demand stage. Because this is a background process that is not observed by participants, it should be defined in the supplemental specification as a system requirement rather than a user requirement. For example, logging on to the system is a valid use case, but the password is not entered. This is because the login system is meaningful to the participants, so that they can get identity authentication and authorization, but simply entering the password does not make sense. Is it all input? Are there any results?

3. This event must be initiated by one participant. There are no use cases without participants. The use cases should not be started automatically or start another use case.

A use case is always initiated by a participant. The desire of the participant is the reason for the existence of the use case. For example, obtaining money from an ATM is a valid use case, but ATM bills are not. Do people still need to work if the ATM bills for no reason? From then on, you can stay at the ATM every day.

4. Use Cases must appear in the form of Dynamic Object phrases

The use case must have a receptor for action and action. For example, drinking water is an effective use case, but "drinking" and "water" are not ,. although our common sense of life tells us that when there is no water, people will not drink this action, and water will inevitably be drunk, rather than slide in, however, many examples I have seen are not named after "computing", "Statistics", "reports", outputs, and inputs ..

5. A use case provides a requirement unit, analysis unit, Design Unit, Development Unit, test unit, and even deployment unit in a timely manner.