How detailed does a use case diagram need to be?

Question

I'm doing use case where users can make reservation of different services such as hotel, car rental etc.

If I just want a simple use case, ignore the part that user has to log in and make payment etc. Technically is the answer below acceptable? If not, why?

A)

ACTOR           USE CASE 
Customer        Make Reservation

B)

ACTOR           USE CASE
Customer        Make Hotel Reservation
Customer        Make Car Reservation
Customer        Make XXX Reservation
Customer        Make YYY Reservation

How detailed does a use case diagram need to be?

Answer 1

The point of use cases is to start thinking in more detail about the actual steps that go into achieving the user's goal. You haven't really done that work yet.

Each of the things you list might be the name of a use case, but you need to describe the process involved.

You need to think about the question: what does the user need to do in order to make a hotel reservation?

There are a number of things a user might need to do (depending on your software).

• Search for a hotel that meets certain criteria.
• View hotel information.
• View availability.
• Request a reservation.

These are the sorts of things that might appear in a diagram. The level of detail can vary according to your needs and preference, but if you aren't breaking a task down into steps, you aren't really using use cases.

Things like log in and payment might be quite relevant to the design and operation of the site, so I wouldn't omit them prematurely. Questions may come up such as:

• Does the user need to log in or is there a path where they can make a reservation as a guest?
• If the user does need to log in, at what point in the process is required?
• Do you have to pre-pay for all reservations, or are there different options?
• What is the process if payment fails?

Answer 2

In my company, a use case is built in business specifications that are handed down to developers so they can analyze and work on a requirement. Also, these use cases are used later by QA team. So, use cases should be more detailed. If, for every use case the user needs to log on, then you can omit that, but can specify it in the beginning of a document. To a developer or QA, use case Make Hotel Reservation means nothing, if this use case is not specified in detail somewhere in a document. So: Customer Open page MyHotel/Reservation Customer Enter DateFrom and DateTo... etc