"Can you help me figure this out?"

My friends know how much I love math and puzzles so we spend a few hours (or weeks) reverse-engineering a convoluted spreadsheet or code snippet.  This hobby has led to the discovery that many companies are held hostage by some legacy application that performs a critical computation that no one understands and are unable to identify if the output is correct or not.

While at university, students were provided textbook software that required only entering parameters — the software hid the calculations and just displayed a result.  By manually performing the equations, I demonstrated to my professor the software operations were incorrect.  At the time, I thought it was an isolated incidence, but unfortunately, headlines are full of projects that fail spectacularly due to similar software math errors:

• Loss of $327 million by NASA Mars Orbiter due to one team calculating thruster force in pounds of force while another team calculated in metric newtons.


• Loss of $440 million by Knight Capital Group due to an error in the trading algorithm.


• Loss of $500 million by the European Space Agency due to the Ariane 5 rocket explosion because of an error in documenting the floating-point number decimal places.

Ron Ross defines a Computation Rule as "…a complete statement that provides an algorithm (usually mathematical) for arriving at the value of a term…."^[1]  Too often, Business Analysts fall prey to believing that documenting the underlying math is not necessary.  Just like my textbook software, most people rely on computational software to perform complex math and assume that is "good enough," resulting in incomplete development of a Computational Rule.

Often, I hear, "…but a stakeholder provided the information for us…."  That is acceptable; however, the BA needs to work with the stakeholder to fully document the computational rule and related computed terms.  The related business and data requirements need to be defined to include:

• a high-level description of the purpose of the algorithm that the average reader can understand.
• each variable, with an understandable definition.
• unit of measure (feet, metric).
• number type (whole, decimal, positive, negative).
• the operand ("+", "-", "*", "!").
• the range (maximum / minimum values).
• "truth table" for identifying the "pass/fail" of various combinations.

I build a spreadsheet replicating the operations based on the Computation Rule definitions so I can review with the stakeholder.  It is critical when performing this assessment to ensure that negative testing is included, as there is always the "Oh, I forgot about this scenario…" moment.

Remember, this work is not just for the initial development and testing but will be used for the entire software life cycle.  You may be required to get out of your comfort zone, Business Analysts, but remember, Math Matters!

References

[1]  Ronald G. Ross, Business Rule Concepts:  Getting to the Point of Knowledge (4th ed.), Business Rule Solutions, LLC, ©2013, 2009, 2005, 1998.  ISBN 0-941049-14-0.  Available at http://www.BRSolutions.com/b_concepts.php.  

# # #