EXPERT RESPONSE
It is very easy to fall into the trap of designing the system while figuring out what value you need the system to provide. This is particularly true if the process of defining the requirements involves not only the product managers or business analysts, but brings the development team into the equation early in the process.
The approach I would recommend is to initially focus on the specific areas of value you want the system to provide. You need to start with the business goals of the system and keep those in mind while you define the use cases.
As an example, let's consider a fictional bank that currently only provides telephone-based inquiries to their customers. There may be a business goal to decrease the cost of telephone-based customer service center by decreasing the hours the call center must be open. Essentially, the goal is to give customers access to a sufficient level of account information during the hours the call center is closed.
The next step is to determine what use cases will be valuable and to whom they will provide value (actors). In this example it might be clear what use cases the customer service center already offers. Check Account Balance, Transfer Money and so forth and there may be some new use cases that don't really fit the call center model; such as Pay a Bill. Keeping in mind the goal to offer customers a sufficient level of account access while the call center is closed, you need to determine what use cases would be most valuable. Don't forget to interview your customers (actors) about what they think might be most valuable, it is often not the same as what you think they might find valuable. Actors can be internal and external users, in this example you would not want to forget about the Customer Service Reps as an actor, by strictly focusing on the customer. Both of them would likely use the same system.
Once you have the use cases defined and prioritized you need determine what type of access you would provide for each of these use cases. I like your idea of a table listing the functions (use cases) and the corresponding access methods that apply to each use case. In this example "Pay a Bill" might be available via Web access, while "Check Account Balance" would be available via the Web, directly from customer service, and also via a touch tone phone response system.
There is no question that somewhere along the line someone will need to determine how the touch tones are processed, or how the security certificate is configured for the website. Write those questions and ideas down for later, but don't get distracted and lose sight of defining what value it is that the system will supply to some set of users, allowing you to achieve the stated business goal.
|
|
 |
Throughout the process of discovering the use cases you will come across "requirements" that are not use cases, but that are important to the overall success of the system. For example if you are providing secure Web access, there might be a requirement that you utilize HTTPS, and obtain a security certificate for the website. It is important to capture these requirements -- I think of them as supplemental requirements. The research and development team will need to know that you expect the Web connection to be secure, or that you expect access to be available on Internet Explorer, Firefox, and Safari, so you must write that down. Ultimately, the use cases that you define should directly support the stated business goals of the system you are developing.
|
