Do use cases represent "an interaction" or "the interaction"

[JGrapes]

We write a use case to discover how a system might meet a users goals. It shows the interaction between the user and the system. From the use case, we derive the requirements. While the use case will show a specific interaction, does it need to show "the" interaction?

Example: I have a create record goal. Upon saving the record, I want the user to have an option to create another record, or go to a list of records.

At least two possible implementations:
1. System provides selections for "Save" and "Save and Create
Another".
2. System provides a selection for "Save". After saving, system asks user if he want to create another.

I'd rather not choose the implementation--I'll leave that up to the UI designer. But, my use case is probably going to show one behavior or the other.

As long as my requirements allow the UI designer to pick what he feels is best, does it matter what my use case shows?

[rcauvin]

Either way is valid and useful depending on the goals.

The standard distinction is between "essential" and "real" use cases.

An essential use case is relatively free of technology and implementation assumptions. A real use case is very specific about the nature of interactions and contains many technology and implementation assumptions.

It is important to recognize that essential and real use cases lie on a continuum. Few, if any, use cases are purely essential or purely real. In fact, I have argued that the only steps in a use case that may be completely free of design assumptions are:

1. The user's indication to the system that he wishes to achieve the functional goal of the use case.
2. The system's indication that it has delivered that goal.

A consequence of this realization is that only the functional goal underlying a use case and its associated nonfunctional constraints are truly requirements.

However, that in no way diminishes the value of fleshed out use cases, whether on the essential side or on the real side of the spectrum. Someone needs to design the users' interactions with the system. Eventually, someone needs to specify the nature of these interactions in nitty gritty detail.

[MTalbot]

As long as my requirements allow the UI designer to pick what he feels is best, does it matter what my use case shows?

I think it does matter, in the sense that the Use Case might lead the designer to THINK that there are requirements in a place where there are not.

If your use case lists...

8. User indicates that they want to save the record.
9. System saves the record.
10. User optionally indicates that they want to create additional records.

...then I think you are implying an order to someone who is going to implement based off your requirements.

[MTalbot]

However, that in no way diminishes the value of fleshed out use cases, whether on the essential side or on the real side of the spectrum. Someone needs to design the users' interactions with the system. Eventually, someone needs to specify the nature of these interactions in nitty gritty detail.

Welcome to the Dark Side....

[gescober]

I think it does matter, in the sense that the Use Case might lead the designer to THINK that there are requirements in a place where there are not.

If your use case lists...

8. User indicates that they want to save the record.
9. System saves the record.
10. User optionally indicates that they want to create additional records.

...then I think you are implying an order to someone who is going to implement based off your requirements.

Hmmm, but I don't think it does much harm here to have an explicit workflow. The UI choices would be to either have a "Create New" button here or to navigate the user to the Record list where they could invoke "Create New" again. The use case doesn't preclude either choice. What it does imply is that the user saves the previous record before creating a new one - which probably isn't necessary.

I would probably have written:

8. User Saves Record
9. System Saves Record to the database with metadata blah blah
10. User Continues to Create New Records until done.

When I have repetitive tasks like this, I'll use a for loop when I can.

Alternatively, or additionally, he could add the following to the pre-conditions:

Pre-Conditions: User may invoke Create New from a List of Records
Pre-Conditions: User may invoke Create New after completing a New Record...or something like that.

[MTalbot]

I would probably have written:

8. User Saves Record
9. System Saves Record to the database with metadata blah blah
10. User Continues to Create New Records until done.

When I have repetitive tasks like this, I'll use a for loop when I can.

I agree that being written this way DOES remove the ordering dependency that might be implicit from the way that I wrote my example. Which leads me to affirm that it does indeed matter how the use case is written if you want to ensure to maximize design options.

[AlanAJ]

I agree that being written this way DOES remove the ordering dependency that might be implicit from the way that I wrote my example. Which leads me to affirm that it does indeed matter how the use case is written if you want to ensure to maximize design options.

It doesn't quite remove the ordering dependency.

I am always suspicious of loops. The stated goal is to create a record. Unless there are constraints, one acceptable design option would allow the user to be in the process of creating multiple records simultaneously. If there are constraints, a mechanism for enforcing them is required, a pre-condition, for example ("User is not in the process of creating a record").

[gescober]

Ah, well we don't have quite enough information to know if creating a record is the goal. The goal may be to Enter Customer Information - could be one record, could be many. The user could be a data entry clerk whose role it is to enter customer records all day at a rate of 20 records an hour.

It really depends on what level you define your use case. If you've reduced it to Create a Record, then you may be dealing with a specific component within a larger workflow. You're more likely dealing with CRUD. And, if it is simple CRUD, then there probably wouldn't be need for any loops.

However, if you're thinking of the larger goal of Enter Customer Information, then perhaps you're following a workflow to achieve that goal in the manner that the user is most likely to follow. I'll want to articulate this flow in the use case so that the designer has a good sense of how the user goes about their work. As I noted, I don't think it's necessarily bad to have an explicit workflow that guides the designer.

[achen]

I think it does matter, in the sense that the Use Case might lead the designer to THINK that there are requirements in a place where there are not.

If your use case lists...

8. User indicates that they want to save the record.
9. System saves the record.
10. User optionally indicates that they want to create additional records.

...then I think you are implying an order to someone who is going to implement based off your requirements.

I agree with roger here, there is a style of use case that has very specific information. The whole point is to give context, sometimes it is better to be general, sometimes it is important to be specific.

Sally is a pharmaceutical rep, she meets with doctors on a regular basis. She doesnt sell the pharmaceuticals she only speaks with the doctors. The doctors then prescribe the pharmaceuticals based on information from the rep.

Sally uses the system to keep schedule her appointments with the doctors and to keep track of useful information about the doctors such as their kids names and birthdays and their favorite liquor.

Sally meets with Dr. Bob and discovers that he likes single malt scotch
Once she finishes her meeting she sits in her car and gets out her handheld device
She logs into the system
She enters the results of the appointment, including the fact that dr. bob likes single malt scotch
etc

Eventually I would want to take this to a more general case, but this level of information can give context, like sally needs to do this work from her car, or that sally drives from place to place etc. What are the implications of the environment?

[TimDaish]

I'd argue for "AN interaction" and not "THE interaction".

I think the implementation could be quite different from what is described in the use case. The use case helps the users to visualize using a system to do something and helps the dev team understand it - but the analysts, designers and coders should be free to devise the best, quickest, most efficient, most effective and most usable solution to allow the user to achieve their goal. In that case, the use case provided exactly what was needed - information about the users goal without constraints.

(User's don't make the best system designers!)