Process Design(Requirements)

2

Recall the Four Steps of Problem Solving*

• Orient• Plan• Execute• Test

These apply to any kind of problem, not just spreadsheet development, programming, or process design, but we will focus on those kinds of problems in this course

* [Carlson and Bloom, “The Cyclic Nature of Problem Solving: An Emergent Multi-Dimensional Problem Solving Framework”, Educational Studies in Mathematics, Vol. 58 Number 1, 2005]

3

Some Common Business Processes

• Doing the payroll• Fulfilling an order• Inventory• Billing

Each of these can be complex, and benefits from a well-defined process

Process Design Overview(and how it relates to the four steps)

• Orient: Develop requirements (use cases and tests)

• Plan: Design the user interface, identify the objects, plan the flow of action (specification)

• Execute: Implement the actual process• Check: use the tests you developed to verify

that your process is correct

5

Defining a Process Clearly (First Steps)

• Orient– Start with what we want to have happen: inputs and outputs– Write use cases to make sure we have covered all the

possibilities– Define tests to determine if our process works properly, once it

is defined• Plan

– Design the user interface– Figure out and specify how it should work, using a flow chart or

other specification method• These are done BEFORE the execute step (instead of just

jumping right in to solve the problem)

First Step: Use Cases

• A use case is a scenario that runs through the process

• It helps us visualize the process and refine our understanding

• Usually there is at least one “normal” version of the process. We start with that and then bring in unusual or exceptional versions.

7

Use Case Principles

• Each use case covers exactly one scenario, so normally there are no conditionals (ifs)

• A use case is testable. We define the test at the same time we define the use case.

• The set of use cases covers all the possible scenarios (unless there are too many…in which case it covers the most important ones, trying for a representative sample)

8

Tests Before Design

• We define the tests before we say how to perform the process

• This ensures that the process we set up really does what we wanted it to do

• We have to think through what we want the process to do, and try to identify all possible cases, before we specify how to do it; otherwise, the “unusual” cases may not be handled well

9

Simple Example: Candy Machine

• There’s a lot of new vocabulary and concepts here, so let’s illustrate them with a simple example

• We’re going to define the process of getting candy from a candy machine

• We start with WHAT: what is supposed to happen, precisely? What items/people are involved?

• We’ll come up with tests to make sure it works properly

10

A very simple mechanical machine

11

What should happen?

• Use Case 1 (first draft):– User puts a coin in the coin slot and turns the

handle– A candy comes out the candy slot

You might be tempted to stop with this. But there are some other factors to consider.

12

Possible Problems

• What if the machine is empty?• What if the user puts the wrong coin in the

slot?• What if the user tries to turn the handle

without putting a coin in the slot?• What if the coin receptacle is full?

13

New Use Case 1: Normal Operation

• Use Case 1– User puts the correct coin in the coin slot and turns the

handle– There is candy in the machine, and the coin receptacle is

not full– A candy comes out the candy slot

• Test 1– Put the proper coin in a machine that has candy in it and

does not have a full receptacle, and turn the handle. A candy should come out the candy slot. Repeat a few times.

14

Use Case 2: Empty Machine

• Use Case 2– User puts the correct coin in the coin slot and turns the handle– There is no candy in the machine– The coin receptacle is not full– No candy comes out the candy slot

• Test 2– Putting a coin in an empty machine and turning the handle

means the machine will eat the coin and no candy will come out• Other Options

– What other options did we have for this case? – What are the tradeoffs?

15

Use Case 3: Wrong or Bad Coin

• Use Case 3: The wrong coin– The user puts the wrong coin in the coin slot– The user tries to turn the handle– The handle doesn’t turn

• Test(s) 3– Try putting coins that are too large, too small, or made

out of wood in the slot. The handle should not turn.• Considerations– How much can we afford to spend building a machine

that can detect bad coins?

16

Use Case 4: No coin

• Use Case 4: No coin– The user does not put a coin in the coin slot– The user tries to turn the handle– The handle doesn’t turn

• Test 4– Try to turn the handle when the slot is empty. It should

not turn. • Considerations– We need to know that it is feasible to build a machine

that works like this

17

Use Case 5: Full Receptacle

• Use Case 5– The user puts the correct coin in the coin slot– The coin receptacle is full– The handle will not turn

• Test 5– Put a coin in a machine with a full coin receptacle. The

handle should not turn• Considerations:– It is one thing to specify this, it is another to build a machine

that reliably works this way. There are again tradeoffs involving cost and reliability of the machine

18

Possible Conflicts

• What if there are two problems? For example, the receptacle is full AND the machine is empty?– The use case for an empty machine says the machine

should take the money– The use case for a full receptacle says the handle won’t

turn• We covered this by putting the condition that the

receptacle is not full in the use case for an empty machine. We need to check all use cases to make sure there are no such conflicts.

19

More Aspects

• We only covered the use of the machine by a person who wants to buy candy

• There is another type of use: how does the owner of the machine retrieve the money? How does the owner refill the candy? To fully specify the machine, we need to describe these with use cases as well.

• How much should the machine cost? (Depends on the business plan.) How reliable does it need to be? The designer needs to know this as well!

20

Even More Aspects

• Beyond this is the question of the business plan– Do we sell or rent out the machines? For how much?– How much should the candy cost? Where do we (or

the buyers of our machines) get it?– Who collects the money? How do we get it? Who

refills the machine?• These are beyond the scope of our current

project, which is to develop requirements for the machine that the engineers can use to design it

21

Next: Plan/Specify/Design

• So far we have looked at the first step of the design process: saying what we want to do. (We’ve also written some tests to use later.)

• This is called Requirements gathering, and is the Orient step

• Next we’ll look at the Specification/ Design step, which is where we Plan how the process will work

22

Not Always a Linear Process

• The process of problem solving does not always proceed in a linear fashion through the four steps

• We might develop requirements for what we want but then find out in the design phase that it would be too expensive or unreliable to build

• Be prepared to try designing for a set of requirements and then going back and changing the requirements

• It is much more expensive and time-consuming to change the requirements or design after you start executing than before, which is one reason why the early steps are so important

23

Good Communication is Vital

• In general, the person who does the requirements may be a different person from the one who designs the process.

• In that case there may need to be several discussions about issues that come up; the designer shouldn’t change the specification unilaterally

• Use cases are good for creating and communicating requirements; we also need a good tool for creating and communicating design

• For this we’ll use flow charts (next session)