1

CS 106Computing Fundamentals II

Chapter 12“Design Requirements”

Herbert G. Mayer, PSU CSHerbert G. Mayer, PSU CSstatus 6/29/2013status 6/29/2013

Initial content copied verbatim fromInitial content copied verbatim fromCS 106 material developed byCS 106 material developed by

CS professors: Cynthia Brown & Robert MartinCS professors: Cynthia Brown & Robert Martin

2

Syllabus Four Steps of Problem SolvingFour Steps of Problem Solving

Common Business ProcessesCommon Business Processes

Process Design: The Four StepsProcess Design: The Four Steps

Message To YouMessage To You

Defining ProcessDefining Process

Use CasesUse Cases

Tests Before DesignTests Before Design

Simple Mechanical MachineSimple Mechanical Machine

Possible ProblemsPossible Problems

Possible ConflictsPossible Conflicts

Plan/Specify/DesignPlan/Specify/Design

3

Four Steps of Problem Solving*

1.1. OrientOrient

2.2. PlanPlan

3.3. ExecuteExecute

4.4. Check Check – AKA Test– AKA Test

These 4 broad categories of systematic thinking These 4 broad categories of systematic thinking apply to any kind of problem, not just spreadsheet apply to any kind of problem, not just spreadsheet development, programming, or process designdevelopment, programming, or process design

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

3

4

Common Business Processes

Doing the payrollDoing the payroll

Fulfilling an orderFulfilling an order

InventoryInventory

BillingBilling

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

4

5

Process Design: The Four Steps

1.1. OrientOrient: Develop : Develop requirementsrequirements --use cases and --use cases and tests; what is the right number of tests?tests; what is the right number of tests?

2.2. PlanPlan: Design the user interface, identify the : Design the user interface, identify the objects, plan the flow of action, i.e. write a objects, plan the flow of action, i.e. write a specificationspecification

3.3. ExecuteExecute: : ImplementImplement the actual process the actual process

4.4. CheckCheck: use the developed : use the developed tests tests to verify that your to verify that your process is correct –at least for those casesprocess is correct –at least for those cases

6

Message to You, yes You • You as You as business and finance major business and finance major will generally not will generally not

be involved in the SW implementation processbe involved in the SW implementation process

• Yet you are the ones defining, funding, and getting Yet you are the ones defining, funding, and getting agreement to the Requirementsagreement to the Requirements

• You contribute to the Specification, at least by You contribute to the Specification, at least by reviewing and correcting or approving what SW reviewing and correcting or approving what SW engineers did specifyengineers did specify

• Hence you must practice Requirements and Hence you must practice Requirements and Specification work; see later materialSpecification work; see later material

• Therefore, the best training for you is to go though all Therefore, the best training for you is to go though all 4 steps here at CS 106 in VBA4 steps here at CS 106 in VBA

6

7

Defining Process Clearly

OrientOrient 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

defined

PlanPlan 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 These are done BEFORE the execute step in structured design and programming; design and programming; Agile SW development Agile SW development blurs blurs this separation deliberatelythis separation deliberately

7

8

First Step: Use Cases

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

• It helps us visualize the process and refine our It helps us visualize the process and refine our understandingunderstanding

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

• Theoretically an iterative process that ends, when no Theoretically an iterative process that ends, when no more changes need to be defined more changes need to be defined

9

Use Case Principles

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

• A use case is testable. Define the A use case is testable. Define the testtest at the same at the same time we define the use casetime we define the use case

• Set of use cases covers all the possible scenarios, Set of use cases covers all the possible scenarios, unless there are too many, in which case it covers the unless there are too many, in which case it covers the most important onesmost important ones

9

10

Test Before Design

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

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

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

10

11

Simple Example: Candy Machine

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

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

• We start with We start with WHATWHAT: what is supposed to happen, : what is supposed to happen, precisely? What parts/people/modules are involved? precisely? What parts/people/modules are involved?

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

11

12

Simple Mechanical Machine

12

13

What Should Happen?

Use Case 1 (first draft):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 You might be tempted to stop with this. But there are other factors to consider!other factors to consider!

13

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 What if the user tries to turn the handle without putting a coin in the slot?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 A programmer –VBA or other– must account for all such casessuch cases

• In rare situations it may be OK to skip a problem case In rare situations it may be OK to skip a problem case –knowing –knowing it shall never happen- but the case must it shall never happen- but the case must be clearly documented + commentedbe clearly documented + commented

14

15

New Use Case 1: Normal Op

Use Case 1Use 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 1Test 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

Use Case 2: Empty Machine

Use Case 2Use 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 2Test 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 OptionsOther Options What other options did we have for this case? What are the tradeoffs?

16

17

Use Case 3: Wrong or Bad Coin

Use Case 3: The wrong coinUse 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) 3Test(s) 3 Try putting coins in the slot that are too large, too small, or

made out of wood. The handle should not turn

ConsiderationsConsiderations How much can we afford to spend building a machine that

can detect bad coins?

17

18

Use Case 4: No coin

Use Case 4: No coinUse 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 4Test 4 Try to turn handle when the slot is empty. It should not turn

ConsiderationsConsiderations We need to know that it is feasible to build a machine that

works like this

18

19

Use Case 5: Full Receptacle

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

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

should not turn

Considerations: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 complexity and reliability of the machine

19

20

Possible Conflicts

• What if there are two problems? For example, the What if there are two problems? For example, the receptacle is full AND the machine is empty?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 We covered this by putting the condition that the receptacle is not full in the use case for an empty receptacle is not full in the use case for an empty machine. We need to check all use cases to make machine. We need to check all use cases to make sure there are no such conflicts.sure there are no such conflicts.

20

21

More Aspects

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

• There is another type of use: how does the There is another type of use: how does the ownerowner of of the machine retrieve the money? How does the owner the machine retrieve the money? How does the owner refill the candy?refill the candy?

• To fully specify the machine, we need to describe To fully specify the machine, we need to describe these with use cases as well.these with use cases as well.

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

21

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, These are beyond the scope of our current project, which is to develop which is to develop requirementsrequirements for the machine that for the machine that the engineers can use to design itthe engineers can use to design it

22

23

Next: Plan/Specify/Design

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

• This is called This is called Requirements GatheringRequirements Gathering, and is the , and is the Orient stepOrient step

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

23

24

Not Always a Linear Process• The process of problem solving does not always proceed The process of problem solving does not always proceed

in a linear fashion through the four stepsin a linear fashion through the four steps

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

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

• Believe it or not Believe it or not at times requirements change during at times requirements change during the development process, forcing the designer to go back the development process, forcing the designer to go back to earlier stagesto earlier stages

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

24

25

Good Communication is Vital

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

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

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

• For this we’ll use flow charts or equivalent toolsFor this we’ll use flow charts or equivalent tools

25

26

References

• Agile Manifesto organization: http://agilemanifesto.org Agile Manifesto organization: http://agilemanifesto.org

• Agile SW Development: Agile SW Development: http://en.wikipedia.org/wiki/Agile_software_developmehttp://en.wikipedia.org/wiki/Agile_software_developmentnt

26