For example, you could write use cases about logging into a system, managing an account or creating a new order.
For example, if you were writing a use case about how an ATM machine functions, the stakeholders would include the bankers and the ATM owners. They are not present when the user uses the ATM machine to withdraw cash. However, they must be satisfied that systems are in place to verify the amount of money in the user’s account before dispensing cash and to create a log of transactions in the event of a dispute.
For example, if you were writing a use case implementing software to create purchase orders, topics that would be In would include producing reports about requests, merging requests to a purchase order, monitoring deliveries, and new and existing system software. Topics that would be Out would include creating invoices and non-software parts of the system.
Users are all of the people who will engage in the activities described in the use case. For example, if you are writing a use case for logging into a software system, the users would be anyone who must log in. Preconditions are those elements that must be in place prior to the start of the use case. For example, users with permission to use the system have been identified and entered into the system ahead of time, so the system will recognize their usernames and passwords when entered. The basic flow is the procedure the users use to achieve the primary goal of the system and how the system responds to their actions. For example, the user inputs a username and a password, and the system allows the user in. Alternate flows explain less common actions. For example, the user is on a different computer and must answer a security question. Exception flows detail what happens when the user cannot achieve the goal. For example, the user inputs an invalid user name or password. Post conditions are those elements that must be present when the use case is completed. For example, the user can proceed to use the software.
Alternate flows and exception flows are written to describe the actions when there are obstacles to the goal. If the user is denied access because the system didn’t recognize her computer, she may be prompted to verify her identity by answering a security question. If the user inputs an invalid username or password, she may be prompted to answer a security question and enter an e-mail address to receive new log in information.
Get the level of detail right. For example, if writing a use case about implementing technology, don’t exclude details about how the software responds to users. Alternatively, adding too much detail about how the software functions reads more like system design implementation than a use case.
