- 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
Understanding the Requirements
Requirements are very slippery things. Software developers often speak about "The Requirements" as if they're cast in concrete, never to be changed or questioned in any way. The reality, however, is that requirements come from people, and you can bet that whoever dreamed them up in the first place is just as capable of making a mistake or forgetting things as you are.
So the first thing you want to do whenever you hear about an idea for a new application is "explore the requirements space" and attempt to understand the vision for the application.
Exploring the Requirements Space
What this fancy-sounding phrase really means is that you need to meet with the person with the idea and have a conversation about what he or she is really trying to achieve. You need to get an idea of the motivation(s) underlying the request for the application. You also need a sense of how the application is intended to be used, and any ideas that people have for ways in which the application could be used.
Understanding the Vision
To do a really good job developing the application, you have to understand the vision for the application. This means that you have to work with the people who want the application, to jointly envision how the application will be and could be used.
For our little club membership system, let's make it easy and assume that what is wanted is an application for the club's membership secretary, that it would be used to send out reminders when membership fees become due, and that every so often someone would go to the trouble of manually entering the race results. Someone also dreamed up the cool idea of having the application pull down race results from the web and automatically update the members' results, but nobody was sure whether that would be really useful.
Defining the Project Scope
The next step to take is to define what the project is supposed to deliver. Yes, you understand the vision for the application, but what exactly does it mean in detail? How much complexity is still hiding under the covers? How many different users will there be, and exactly what do they expect to be able to do with the application?
To answer these questions, you have to do some more work with the people who want the application, precisely naming which user goals the application needs to support. You don't want to get stuck in "analysis paralysis," so forget about gathering all of the details about these requirements right now. All you want is a list of the users and the goals that the application is supposed to support.
Effectively, what you're doing is naming the use cases. You identify the primary actors, the important roles that the actors play when working with the application, and the goals that the various actors have. The combination of a primary actor and a goal is the name of a use case. (It's also useful to include a goal description so that there is some context to help people understand the goal.)
For our little membership system, here are some possible use cases:
Club Secretary : Maintain membership list. This includes adding new members, updating members' addresses, and removing members who decide not to renew their memberships.
Club Secretary : Send out membership renewal notices. Send out renewal notices to members before their memberships expire.
Club Secretary : Enter race results. Enter details of members' race results, possibly by downloading race results from the web.
Club Secretary : Notify members about special events. Send out information about forthcoming events and races to members.
Club Secretary : Publish age-ranked results. Produce lists of the best race results for each age category for inclusion in the club newsletter.
The first use case—Club Secretary : Maintain membership list—is really a summary goal, since it includes several related user goals:
Club Secretary : Enroll new member.
Club Secretary : Change details for an existing member.
Club Secretary : Record membership renewal.
Club Secretary : Remove expired member.
When trying to determine the overall size and complexity of an application, you have to watch out for these summary goals. Yes, they're great for organizing our thinking about the application, but an amazing amount of work can be hiding inside an innocuous statement like "Maintain membership list."