Requirements

Requirements are what the software must do.

Specifically: a requirement is a singular need which must be satisfied for the system to work correctly, e.g., an ATM must allow a customer to withdraw money from his/her account.

Issues:

dilbert

So, let’s have some “fun”, and try to capture some requirements from a customer.

I’ll be the voice of the customer (VOC) and tell you what I (think) I want, and it’s your job to figure out what it is that I will really want/need.

Use cases

Use cases are a way of describing how the system will satisfy its requirements.

A use case shows a scenario where one or more actors use the system.

Properties of a use case:

Note that although the use case will generally specify a sequence of steps, these steps must focus on WHAT the actor or actors experience, and NOT how the system achieves the functionality. So, the use case must not mention objects, methods, code, etc. The use case should also not describe the user interface: that is a separate activity.

There may be multiple paths through a use case. For example: if an error occurs, or if there is “optional” behavior seen in some cases, etc.

There are different ways of writing a use case. For some use cases, a single sentence might suffice. For more fully-specified use cases, listing a series of numbered steps is a good approach. As with any documentation, diagram, model, etc., the purpose is to specify an aspect of the system in enough detail to be useful, but not too much detail. Excessive detail is a waste of time.

So what does a use case look like? Here’s the example from “UML Distilled”, including alternate paths, called extensions:

Buy a Product from an Online Store

MSS - Main Success Scenario:

1. Customer **browses catalog and selects items to buy**

2. Customer goes to check out

3. Customer fills in shipping information (address, shipping info)

4. System provides full pricing info, including shipping

5. Customer fills in credit card info

6. System authorizes purchase

7. System confirms sale immediately

8. System sends confirming email to customer

Extensions (alternate paths):

3a: Customer is a regular customer

	.1: System provides current shipping, pricing, and billing information
	
	.2: Customer may accept or override those defaults, returns to MSS at step 6
	

6a: System fails to authorize credit purchase

	.1: Customer may re-enter credit card info (returns to MSS at step 5)
	
	.2: Customer may cancel purchase

Let’s work an example: Uber (Ride Sharing App):