Clients requirements on use case diagram

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.

Your requirement examples seem to correspond to goals. This is a good start for thinking about use-cases, leaving full freedom about how to best achieve the goals:

• Your example: process and package order is a popular use-case for company staff to satisfy their clients. It raises however a question: will there be a use case for the customers to order?

A use case represents a set of behaviors offered by a system, with observable result, that is if value for actors or other stakeholders. You need to make sure that your chose requirements meet these criteria; not all requirements are suitable for a use case diagram.

• Your example: promote the pizza shop is a popular business goal. It is however unclear if this is a side effect (or wishful thinking) or if the system actively promotes the shop, and who could be the primary actor.

Last but not least, a use-case involves actors. You need to identify those. And you should consider rewording the use-case from the perspective of the primary actor.

• In your example, is it really the system that ensure a timely delivery? Or isnt't it more that the system helps some delivery agent to proceed with the right deliveries at the right moment? In this case, consider rewording into: deliver packages in time.

The resulting use-case diagram should provide the big picture. Keep in mind that it makes no sense to graphically all the requirements: some narrative would describe each use case with more explanations about requirements, constraints and expectations.

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.