1. 1 CS 106 Computing Fundamentals II Chapter 12 “Design Requirements” Herbert G. Mayer, PSU CS status 6/29/2013 Initial content copied verbatim from CS 106 material developed by CS professors: Cynthia Brown & Robert Martin

2. 2 Syllabus Four Steps of Problem Solving Four Steps of Problem Solving Common Business Processes Common Business Processes Process Design: The Four Steps Process Design: The Four Steps Message To You Message To You Defining Process Defining Process Use Cases Use Cases Tests Before Design Tests Before Design Simple Mechanical Machine Simple Mechanical Machine Possible Problems Possible Problems Possible Conflicts Possible Conflicts Plan/Specify/Design Plan/Specify/Design

3. 3 Four Steps of Problem Solving * 1.Orient 2.Plan 3.Execute 4.Check – AKA Test These 4 broad categories of systematic thinking apply to any kind of problem, not just spreadsheet development, programming, or process design * 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

4. 4 Common Business Processes Doing the payroll Fulfilling an order InventoryBilling Each of these can be complex, and benefits from a well-defined process 4

5. 5 Process Design: The Four Steps 1.Orient: Develop requirements --use cases and tests; what is the right number of tests? 2.Plan: Design the user interface, identify the objects, plan the flow of action, i.e. write a specification 3.Execute: Implement the actual process 4.Check: use the developed tests to verify that your process is correct –at least for those cases

6. 6 Message to You, yes You You as business and finance major will generally not be involved in the SW implementation processYou as business and finance major will generally not be involved in the SW implementation process Yet you are the ones defining, funding, and getting agreement to the RequirementsYet you are the ones defining, funding, and getting agreement to the Requirements You contribute to the Specification, at least by reviewing and correcting or approving what SW engineers did specifyYou contribute to the Specification, at least by reviewing and correcting or approving what SW engineers did specify Hence you must practice Requirements and Specification work; see later materialHence you must practice Requirements and Specification work; see later material Therefore, the best training for you is to go though all 4 steps here at CS 106 in VBATherefore, the best training for you is to go though all 4 steps here at CS 106 in VBA 6

7. 7 Defining Process Clearly Orient Start with what we want to have happen: input -> action-> output Write use cases to make sure we have covered all the possibilities; even the simplest of cases: write it and incldue Write tests to determine if our process works properly, once definedPlan 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 in structured design and programming; Agile SW development blurs this separation deliberately These are done BEFORE the execute step in structured design and programming; Agile SW development blurs this separation deliberately 7

8. 8 First Step: Use Cases A use case is a scenario that runs through the processA use case is a scenario that runs through the process It helps us visualize the process and refine our understandingIt 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 versionsUsually there is at least one “normal” version of the process. We start with that and then bring in unusual or exceptional versions Theoretically an iterative process that ends, when no more changes need to be definedTheoretically an iterative process that ends, when no more changes need to be defined

9. 9 Use Case Principles Each use case covers exactly one scenario, so normally there are no conditionals (ifs)Each use case covers exactly one scenario, so normally there are no conditionals (ifs) A use case is testable. Define the test at the same time we define the use caseA use case is testable. Define the test at the same time we define the use case Set of use cases covers all the possible scenarios, unless there are too many, in which case it covers the most important onesSet of use cases covers all the possible scenarios, unless there are too many, in which case it covers the most important ones 9

10. 10 Test Before Design We define some of the tests before we say how to perform the processWe define some of 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 doThis 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 wellWe 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 10

11. 11 Simple Example: Candy Machine There’s a lot of new vocabulary and concepts here, so let’s illustrate them with a simple exampleThere’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 machineWe’re going to define the process of getting candy from a candy machine We start with WHAT: what is supposed to happen, precisely? What parts/people/modules are involved?We start with WHAT: what is supposed to happen, precisely? What parts/people/modules are involved? We’ll come up with tests to make sure it works properlyWe’ll come up with tests to make sure it works properly 11

12. 12 Simple Mechanical Machine 12

13. 13 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 other factors to consider! 13

14. 14 Possible Problems What if the machine is empty?What if the machine is empty? What if the user puts the wrong coin in the slot?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 user tries to turn the handle without putting a coin in the slot? What if the coin receptacle is full?What if the coin receptacle is full? A programmer –VBA or other– must account for all such casesA programmer –VBA or other– must account for all such cases In rare situations it may be OK to skip a problem case –knowing it shall never happen- but the case must be clearly documented + commentedIn rare situations it may be OK to skip a problem case –knowing it shall never happen- but the case must be clearly documented + commented 14

15. 15 New Use Case 1: Normal Op 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 15

16. 16 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? 16

17. 17 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 in the slot that are too large, too small, or made out of wood. The handle should not turnConsiderations How much can we afford to spend building a machine that can detect bad coins? 17

18. 18 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 handle when the slot is empty. It should not turnConsiderations We need to know that it is feasible to build a machine that works like this 18

19. 19 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 turnConsiderations: 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 complexity and reliability of the machine 19

20. 20 Possible Conflicts What if there are two problems? For example, the receptacle is full AND the machine is empty?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.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. 20

21. 21 More Aspects We only covered the use of the machine by a person who wants to buy candyWe 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?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.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!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! 21

22. 22 Even More Aspects Beyond this is the question of the business planBeyond 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 itThese are beyond the scope of our current project, which is to develop requirements for the machine that the engineers can use to design it 22

23. 23 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 for later useSo far we have looked at the first step of the design process: saying what we want to do. We’ve also written some tests for later use This is called Requirements Gathering, and is the Orient stepThis 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 workNext we’ll look at the Specification / Design step, which is where we Plan how the process will work 23

24. 24 Not Always a Linear Process The process of problem solving does not always proceed in a linear fashion through the four stepsThe 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 buildWe 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 iterativelyBe prepared to try designing for a set of requirements and then going back and changing the requirements iteratively Believe it or not at times requirements change during the development process, forcing the designer to go back to earlier stagesBelieve it or not at times requirements change during the development process, forcing the designer to go back to earlier stages 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 importantIt 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 24

25. 25 Good Communication is Vital In general, the person documenting requirements may be a different person from the one who designs the processIn general, the person documenting 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 unilaterallyIn 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 designUse 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 or equivalent toolsFor this we’ll use flow charts or equivalent tools 25

26. 26 References Agile Manifesto organization: http://agilemanifesto.orgAgile Manifesto organization: http://agilemanifesto.org Agile SW Development: http://en.wikipedia.org/wiki/Agile_software_developme ntAgile SW Development: http://en.wikipedia.org/wiki/Agile_software_developme nt 26