Requirements in Context Part 6: The Evolution Of Computerized Business Functions

“Those who cannot remember the past are condemned to repeat it.^”(1)

This series started with the classic “Swings” cartoon that originated over 40 years ago. I am guessing that the majority of readers of this series were not practicing IT professionals back then. Since I was (just), I thought it worth exploring a slightly different context before getting into the topic of detail functional requirements. In this article we look at computerized business functions from a historical context.

Calculators Supporting Business Functions

In the beginning (around the same time as our swings) there was the four function ‘pocket’ calculator. Those four functions were ADD, SUBTRACT, MULTIPLY, and DIVIDE. Even way back then there was the concept of ‘gold plating.’ Almost immediately after the basic four function calculator was introduced it was superseded by the five function calculator. The fifth function? One near and dear to every business professional – SQUARE ROOT.

Proud new owners of these devices would begin by adding a pair of numbers. They (me included) would immediately perform the same calculation using pencil and paper. This was to confirm that this technological marvel knew what it was doing. This was the earliest recorded example of user acceptance testing. It should be noted that no one ever (and I mean EVER) tested the SQUARE ROOT function. All that mattered was that this function was there. Once this fifth function was available no one wanted to be seen with a calculator that only had four functions.

Related Article: Requirements in Context Part 5: Detail Requirements for Build or Buy

Even with only four (useful) functions, the calculator was, and still is a very useful business tool. The only difference is that business people today don’t buy calculators. They just use the ones that come with their phones, PDAs, and laptops.

Computers vs. Calculators

Many people would be surprised to learn that today’s function-rich computers, at their heart, are only able to add, subtract, multiply and divide. Any more sophisticated mathematical functions like, dare I say, square root, are based on algorithms that utilize those basic four functions.
Ultimately what separates the computers from the basic calculator are two capabilities:

Compare two data items – The ability to test one item against another and know if one is greater than, equal to, or less than the other.

Move data – The ability to move data from one location in memory to another location in memory.

Really. I’m not making this up. That’s pretty much it.

The ability to compare values allows a computer application to go down one instruction path or another depending on the result (or ‘looping back’ to a previous point). What we see at the human level as “If income is greater than expense then …” is an example of something a computer can do that a calculator can’t.

The ability to move data allows the computer to:

• Receive data from any ‘connected’ input source – from the part of computer memory that received the data from an external source to that part of memory where a function operates on it. Typical input sources are databases, batches of records, real-time input devices and on-line users.
• Reformat the data within memory – once input data has landed in memory, it’s available to functions that operate on it. Those functions might use it for calculations or for ‘shaping’ it into other formats (e.g. scanned grocery items into purchased items).
• Deliver data to a ‘connected’ output source – from a location in computer memory that data has been input to or operated on, it is moved to a location associated with a target output device or system. It most likely has undergone some form of realignment to conform to a storage format, or positioned for display on a GUI device.

Just like the four primary math functions have been developed into re-usable higher-level functions, computer languages have developed higher-level ‘compare’ and ‘move’ functions. One example of this evolution is the Sort function. Second and early third-generation programming languages such as Cobol did not include a sort function. When a batch of records about to be processed was required in a particular sequence, they would first be processed by an application (called a sort ‘utility’) that did nothing but move the records around until they were in the designated sequence. Nothing but moving and testing until all was in order.

NOTE: In those early days of sort utilities, developers of applications that read the resulting sorted data would test each record as it was input. This was to ensure that each record was ‘bigger’ than the previous one. Reminiscent of those early pocket calculator adopters manually checking results?

Today’s SQL language is a good example of the evolution of functions to support business processing. That language includes data moving capabilities with its “Order by” and “Group By” clauses, and of course, it utilizes the compare capability with its “Where” clause.

Computer-supported Business Processes

The phrase that is stuck in my head at the moment is, “The more things change, the more they stay the same.” I believe that applies perfectly to where we are today with computer-supported business processes. What has changed are the input and output technologies and computer internal and external storage capacities. But business processes then and now are made up of steps that capture, update, validate, display and calculate data.

NOTE: Another thing that has not changed in all of these years is the diamond shape to represent a point at which a comparison is performed. The more senior readers will remember the original manual version of Visio – the Flowchart Template. For a trip down memory lane (or for younger readers, a trip to the IT museum), I recommend doing a web search on “plastic flow chart template picture”.

Detail Functional Requirements

With this understanding of the fundamental functional capabilities of computers, we return in the next article to the basic theme of this series – Requirements in Context. In particular detail functional requirements.

I leave readers with a challenge – Name a business process or activity that is not fundamentally calculating, comparing and/or moving data. If you think of one, please offer it in a comment below.

⁽¹⁾ George Santayana