Is this a good use case?

Question

I've been studying object oriented analysis and, so to get started with this in practice I've decided to first of all build my own management system to have my customers data and so on. Trying to gather requirements for the first time and write use cases for the first time led me to some doubts. I want to ask here about some doubts regarding the use cases.

One of the requirements I've thought of was "manage customers". From this requirement I've obtained some use cases:

1. Register new legal person as customer;
2. Register new natural person as customer;
3. Update and correct customer data;
4. Remove a customer from the system;
5. Read customer's summary;

Now, I'm greatly in doubt about all of this. First, is this right: take one single requirement and from it derive many different use cases? Or should be just one use case "Manage Customers" containing everything?

Second, I'll give an example about what I did. I choose to start by the first one. So I wrote the following use case:

Title: Register new legal person as customer;

Actor: User;

Scenario: The user chooses to register a new company as customer. The user informs the company data and the system validates the data informed. The user is then prompted to inform the data of the responsible for the company and the system validates the data informed. The user is then taken to the list of all legal person customers.

Now, I'm pretty sure I'm not doing this right. First, this seems to simple, it's just like if we said "well, the user goes and register the data". Second, all of the others use cases would be exactly like that, so I can't see how this is going to help me out. Third, from this use case I could obtain just three possible objects "legal person customer" and "responsible for the company", so I really think this is not enough.

Also, usually there are many requirements like that "manage customers", "manage employees" or "manage suppliers" and it seems at first tha they will always be like that. Is this correct? Those kind of requirements always end up with this kind of uses cases that are simple like this?

Am I doing this right? Is there something wrong with the uses cases I've figured out and the way I wrote that particular use case? How do we work with this kind of use cases that are so simple that the scenario is almost like just stating again the objective of the use case?

I know there are many questions there, but any kind of help is appreciated. I'm starting now to work with this kind of thing and I'm unsure if I'm doing things right. Thanks very much in advance!

Answer 1

These use cases look fine to me.

What you may not be realizing is that use cases can differ based on "roles..." that is, some people may have the authority to review customer accounts, but others may not. The roles and responsibilities of a product manager are going to be dramatically different than those of a clerk.

Consequently, writing your use cases this way will surface requirements based not only on what kind of information certain users have access to, but also what services are required and expected from the system by each user.

Your use cases will also help you define the roles... If you find that a lot of the use cases are similar, you can combine their common elements into a role. Like many other software development activities, this process is iterative: you will refine your use cases as you and your customer begin to understand them better.

Answer 2

Much of the benefit of use cases comes from the answer to "What if?" For example, you say the system validates the information. What will your validations be? Are some fields mandatory, or is this just about the phone number or email address meeting a particular format? Let's say it's that some fields are mandatory,

What happens when the data doesn't meet the rules?

Can you save a customer that's only partially filled in? Will you just have to hit Cancel and lose all the other fields you typed in? If you can save a partial one, will it look different on the list of all customers? Will there be some things you can't do with it because it's not valid yet?

As you go through these use cases you will think of others too. For example what does it mean to remove a customer? Do you throw all the data away or keep it in some sort of history or archive section? If you keep it, how does a user ever go and look at it? Would you still include it in some summaries or lists or reports? What is the point of keeping it, or of deleting it?

And that might make you think hey, I should be able to back this data up some how. Or export it to Excel. Or make a list I can paste into some other application. And more use cases appear to you.

The most important thing about them is the thought process they lead you through. This matters most when you're interviewing someone else to get the business needs, and less when it's yourself, but it's still not zero. They can also be a handy reference for you later.