客户对用例图的要求

Question

I want to create a use case diagram based on customer requirements (pnline food ordering system), which are for example

1. ensure on-time delivery
2. process and package orders
3. promote the pizza shop

How can I put these requirements on use case diagram? Could you please explain on specific example?

for 1) could it be like that: display order details < inlcude > display time left to prepare order

Answer 1

There are a couple of ways how to model that. The first step is always to read and understand the requirements. So putting them in some sort of order is vital. There are dedicated tools to deal with that and they may or may not be helpful (I'm talking of DOORS and the like). A more simple way is to create a profile for requirements management in UML that contains requirements elements where you can reference the customer documents and already put them in a certain structure.

Now in the next step you synthesize these requirements to use cases. That is you pinpoint the added values and make them visible. Actors and UCs shall be clearly visible.

Once you have done that you relate UC and requirement elements with realize relations (or some other stereotyped dependency depending on the profile you use). This way you have a nice traceability that connects requirements and UC for the upcoming design steps.

A more simple approach would be to just attach constraints to an elaborated UC model containing requirement text. That could be done for simple (school) projects. Though it's unlikely you find that in the industry. Either you go to war (see above) or you have just a little chit-chat with some insults.

---

Regarding the synthesis of UCs I recommend to read Bittner/Spence about Use Case Modeling. The best read you can find.

Answer 2

Use cases describe operations, requirements are part of operations' restrictions.

First, model the operations or activities of the customer, then add the requirements as constraints of each use case.

Answer 3

Your requirement examples seem to correspond to goals. This is a good start for thinking about goal-oriented use-cases, leaving the designers opportunities to think about how to best achieve the goals.

• For example: process and package order is a clear (and popular) use-case for company staff to satisfy their clients. It raises however a question: who will pass the order that is to be processed?

A use case represents a set of behaviors offered by a system, with observable result, that is if value for actors or other stakeholders; not all requirements are suitable for a use case diagram.

• For example: promote the pizza shop is a popular business goal. But will the system have some observable behaviors that do it, and if yes with what users? If the answer is that a nice system will automatically result in more sales, then it is wishful thinking (from a software engineering point of view). But. if there is some functionality that makes the system performing some promotion then keep such use-case, but think of rewording it to clarify what the system is expected to do (eg make advertisements? present the shop? carry out some email campaigns?)

Last but not least, a use-case involves some actors. You need to identify those. And to further promote a goal-oriented design, you may consider rewording the goal and behavior from the user perspective.

• For example, does the system really ensure a timely delivery ? Or does it support some users who ensure it? If the user is the delivery agent, you could rephrase it into: deliver packages in time .

With all this, you may come to a use-case diagram that provides the big picture. But you would never show graphically all the requirements. Some narrative would describe each use case, and there you can document the more detailed requirements.