A use case is a sequence of actions that provide a measurable value to an actor. Another way to look at it is a use case describes a way in which a real-world actor interacts with the system. In a system use case you include high-level implementation decisions. System use cases can be written in both an informal manner and a formal manner. Techniques for identifying use cases are discussed as well as how to remain agile when writing use cases.
Informal System Use Cases
The informal system use cases (or) steps are written in very brief, bullet/point-form style. They contain just enough information to get the idea across and no more. The below listed examples take technology issues into account, for example the text "Student inputs her name and address" implies some sort of information system. The reference to the system also implies the same.
Formal System Use Cases
Formal system use cases version is much more detailed than the corresponding use case, and is typical of the type of use cases that people will write in documentation-intense environments.
Identifying Use Cases
How do you go about identifying potential use cases? Constantine and Lockwood (1999) suggest one way to identify essential use cases, or simply to identify use cases, is to identify potential services by asking your stakeholders the following questions from the point of view of the actors:
- What are users in this role trying to accomplish?
- To fulfill this role, what do users need to be able to do?
- What are the main tasks of users in this role?
- What information do users in this role need to examine, create, or change?
- What do users in this role need to be informed of by the system?
- What do users in this role need to inform the system about?
For example, from the point-of-view of the Student actor, you may discover that students:
- Enroll in, attend, drop, fail, and pass seminars.
- Need a list of available seminars.
- Need to determine basic information about a seminar, such as its description and its prerequisites.
- Obtain a copy of their transcript, their course schedules, and the fees due.
- Pay fees, pay late charges, receive reimbursements for dropped and cancelled courses, receive grants, and receive student loans.
- Graduate from school or drop out of it.
- Need to be informed of changes in seminars, including room changes, time changes, and even cancellations.
It is very easy for use case modeling to become un-agile. To prevent this from happening you need to focus on creating artifacts that are just good enough, they don't need to be perfect. I've seen too many projects go astray because people thought that the requirements had to be defined perfectly. The use case isn't perfect yet the world hasn't ended. Yes I could invest time to fix these issues but what would the value be? Nothing.
Why does this work? Because in an agile environment you'll quickly move to writing code based on those requirements, you'll discover that you don't fully understand what is required, you'll work closely with your stakeholder to do so, and you'll build something that meets their actual needs. It's software development, not documentation development.