Problem solve Get help with specific problems with your technologies, process and projects.

Developing use cases that support business goals

Discovering use cases that account for the whole value of your project requires a meticulous approach. Expert Rob Apmann explains how to define use cases with business goals in mind.

We're reviewing requirements for a system that will have multiple access methods: call takers, voice response and Web access. How should the system boundaries be defined? I mean just the core system, ignoring the access method? What do you think of an approach that develops most of the document without regard to access method, and then has a table listing which functions are accessible by which method? A problem with the document we reviewed is that it focuses too much attention on access method (how touch tones are processed, for example, bordering on but not getting into design) instead of focusing on core functions. Could we treat an access system as an external black box and specify it elsewhere?

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.

Software requirements gathering:
How to communicate with the client for effective requirements engineering

Software requirements elicitation and documentation

Requirements gathering, SRS and use cases

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.

This was last published in April 2008

Dig Deeper on Gathering Software Requirements Use Cases

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.