Use case in 486

[Iftikhar Arain]

What, if anything, is WRONG with the following analysis use case?
Use case: Sell goods
Description: Accept tender from a customer, package products being purchased, and remove the products from inventory.
Actors: Clerk
Preconditions: Customer has chosen products to buy from inventory.
Postconditions: Products are no longer in inventory. Store cash balance is increased.
Steps:

A. There are design details intermixed with the requirements.

B. The actor's actions and system responses are not separated.

C. "Sell goods" is too broad to be a use case.

D. There is nothing wrong with this use case.

I think the answer D is correct plz correct me if I am wrong and tell me the correct answer.

[Ilja Preuss]

I also think D is correct...

[struts]

C. "Sell goods" is too broad to be a use case.
I think "C" is correct. The test is tryinhg to test the real UML work experience. Have u ever used kind of "Sell goods" as the name of a use case ?

[Ilja Preuss]

Originally posted by struts:
C. "Sell goods" is too broad to be a use case.
I think "C" is correct.

Why is it to broad to be a use case? What responsibility of a use case can therefore not be fullfilled?

[Iftikhar Arain]

I also think sell goods is to broad but what about the design details are intermixed with requirements as in the use case description there are some words like " remove items from inventry."
I think this is postcondition and not allowed in use case description or any design detailed in the use case.
plz correct me if I am wrong.

[Ilja Preuss]

Originally posted by Iftikhar Arain:
I also think sell goods is to broad but

Than perhaps *you* can tell me why?

what about the design details are intermixed with requirements as in the use case description there are some words like " remove items from inventry."
I think this is postcondition and not allowed in use case description or any design detailed in the use case.
[/QB]

I don't think this a design detail, but a business requirement. Inventory here seems to be a business term; there is no hint on how this inventory should be represented in the system, as far as I can tell.

[Kishore Sirivelu]

C is right. Sell goods could imply how the sales operation is setup, what kind of a store is used:whether it is like Wal-mart or a street vendor, etc. Here it just describes a transaction in a store. Hence, "Sell goods" is too broad a description for the use case.

[Ilja Preuss]

Originally posted by Kishore Sirivelu:
C is right. Sell goods could imply how the sales operation is setup, what kind of a store is used:whether it is like Wal-mart or a street vendor, etc. Here it just describes a transaction in a store. Hence, "Sell goods" is too broad a description for the use case.

I think C refers to the content of the use case, not its name. And the content is in the description. As long as anybody on the team has an idea of what content "sell goods" refers to, the name could be just perfect, IMO.