# Customer Requirements Contains Equations that Cancel to Nothing

I have a project where the customer requirement specifies a report and contains mathematical equations for the contents of some of the columns on that report. One of the columns on this report is a running total which starts at a opening value, and which 'should' remain at that opening value all the way down the report because the other stuff balances out. I.e. if something had gone missing, the value would change and the customer would see that there is a problem.

The reason I quoted the 'should' in that last paragraph is because the spec defines an equation for this column, and I can mathematically prove that it cancels out to 'the value from the previous row'. In other words, the value will never ever change from the opening value.

So my options are:

• Implement the equation as spec'd, I suspect the interpreter will not resolve the equation so there will be a performance hit
• Do some cancelling out, and implement the column value as 'value from the previous row'
• Send the question back up the chain to the customer and risk missing the deadline because of several days lost to bureaucracy and impromptu math 101 lessons to explain the difference between "yeah, it'll never change, it's there just in case" and "it. will. never. change."

I've pretty much decided what I'm going to do, but I thought it was an interesting question. What do you think is the professional thing to do?

-
Implement the specification per the client's request but also send the question up the chain. At this point the client is "correct" until you can explain their requested specification appears not to do what they want. – Ramhound Apr 2 '13 at 12:37
@Ramhound - this should be an answer. I'd vote it up. – Dan Pichelman Apr 2 '13 at 15:16
Its already been suggested they implement the specification `as-is` but still bring the possible mistake to the client. – Ramhound Apr 2 '13 at 16:47

Do the easier of implementing the equation specified in the formula or spitting out the previous row's value, incorporating a prominent comment in the code explaining why it is as it is.

At the same time, send your question back up the chain. If they get back to you with a spec change in time to implement it, then implement it. If not, your butt's still covered because your output meets the original spec.

-

If the goal of the formula was to check for missing values, construct a test that should verify that the software can detect that a value is missing. If the formula is wrong, the test will not be successful. Then it can be flagged, investigated, and fixed.

-

Provide a counterexample, rather than a mathematical explanation, to the chain of command. That way they can immediately see that it's broken, even if they aren't mathematically inclined.

-