Lets take the Payroll Processing program that we designed in RAPTOR in the last module, and add some additional logic to it. We need to have it do the following: Company-Wide Payroll and Tax Data Input Validation. Validate that all of the input tax rates are logical and correct (not negative; not greater than 100%, certainly). Chances are, there are sensible default values for these parameters, values that are not zero. For example, the withholding rate for Social Security and Medicare taxes does not change very often. So maybe by initializing these values to their sensible defaults, you end up changing the behavior of the user with the program: does the bookkeeper want to accept the defaults, or type in some other in-range number? In this module, since were not too skilled and cunning with nested loops well do this as a series of nested IF tests: INITIALIZE taxparameters to sensible default valuesINPUT taxparameter_1 IF taxparemeter_1 IS within range THEN INPUT taxparamenter_2 IF taxparameter_2 IS within range THEN ... ... ... ELSE Output an error message about taxparameter_2, default will be used instead ENDIF taxparameter_2 ELSE Output an error message about taxparameter_1 ENDIF taxparameter_1 Do the rest of the program... Per-Employee Data Validation. Test to make sure that the total number of hours worked is not negative, and not greater than some reasonable maximum (if the pay period covers two weeks, it certainly cant exceed 24*14...), and that the hourly pay rate is less than what you think is a reasonable maximum. Would our default values strategy work here? Or should we use a loop? As part of this, youll have to modify the prompts to the user, so that theyre told what good data is to start with, vs. garbage data; and then develop the logic that checks the data, and either tells the user Wrong, do over! and prompts for and gets input, or moves on to processing. STRONG HINT: would these data validation chores be a great opportunity to use a subprogram? How would you do this in RAPTOR? This would then lead us to think about appropriate test data. Test data, we recall, usually is from three logical domains: Expected values, which should process in to correct outputs Boundary condition values: on one side, the last correct value to process; on the other side of the boundary, the first out of range error to properly catch and handle Really ridiculous data (like an hourly pay rate of $0.00000000001 and number of hours worked = 0.00000000005) Be sure to update the documentation in your RAPTOR program, to show when youve modified it and what youve done to it. Follow the instructions in the module item to submit your RAPTOR program for this week.