- Introduction
- Understanding the Requirements
- Elaborating the Use Cases
- Understanding the Hidden Complexity of Requirements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Elaborating the Use Cases
Once some of the use cases have been named, you're ready to start investigating the real complexity of the system. Your hardest task is to guess how many use cases you will eventually have to deliver. This is difficult because everybody forgets things. It's extremely unlikely that the initial list of use cases is complete—it's likely to contain some use cases that are interesting to think about but will never actually be implemented, and it's likely to be lacking some really crucial use cases that will make everyone wonder how they were missed.
As long as you work in collaboration with the eventual end users, you can normally manage to name most of the use cases in the first few weeks of a project. You'll never manage to get them all at the start of a project. Some new use cases will only be identified after the users have been working with the application for a while and discover new ways that the application could help. This is perfectly normal. It's why most software developers choose to develop incrementally, delivering a small part of the application initially and then adding extra features every few weeks or months.
All you need to get started is a few use cases that the project sponsors consider important enough to be delivered first. Once you have these, the time has come to work with your users to semi-formally document how the system will work for each use case. To do this, you need to record the guarantees for the use case, and then document the main success scenario. The guarantees define what correct operation of the application looks like. The main success scenario describes the design for the actor's interaction with the application. This design of how the users will interact with the application is part of the requirements for the software. This is why you must have users actively involved in defining use cases, because if developers write them what you get are applications that were easy to develop but are a real pain to use.
Club Secretary : Notify members about special events. Send out information about forthcoming events and races to members.
Minimal Guarantee:
Event details are recorded in the application.
Members are never sent a duplicate notice about the same event.
Success Guarantee:
Selected members are sent email containing an event notice.
The notice is recorded as being sent to the selected members.
Main Success Scenario:
Club Secretary: Enter event details.
Club Secretary: Choose members to send notice to.
Membership System: Display number of members to be notified and await confirmation from the Club Secretary.
Membership System: Send email notification to every selected member.
Membership System: Record that notice was sent to selected members.
In this example, the users have decided that sending out multiple emails for the same event is a really bad idea, hence the guarantees stating this requirement. Step 3 of the main success scenario shows how the membership system shows up in the use case, and why when writing the use case it's important to put the minimum constraints on the design of the user interface.
It's perfectly acceptable to place technology constraints on the developers. Step 4 states that the membership system sends out email for notification. If that's what the users want, then that's what should be recorded as a requirement in the use case. On the other hand, if the users don't care how notification happens, that step would have been written as Membership System: Send notification to every selected member and the developers would then have design freedom to play with phone, fax, email, and possibly telepathy for notifying the membership about the special event.