Process Design (Requirements)

1. 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

4. 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 flowchart or other specification method • These are done BEFORE the execute step (instead of just jumping right in to solve the problem)

6. 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 Planhow 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)