Using Decision Tables for gathering requirements and development.

We are in the IT business, and a lot depends on how requirements are gathered. If we as IT Gurus try to implement a technology and ignore the requirements, then we have failed.

Our employers and clients are not interested in the latest technology, but they are rather interested in delivering the functionality their requirements dictates.

There are many ways to document requirements and there are times where you have to be innovative on how to document your client’s wishes and dreams. The better you are in this at the beginning, the better the final product will look at the end of the project.

One of the techniques I used many times to document and code requirements is Decision Tables.

Decision tables are a way to describe an action based on a various conditions and inputs.  Remember logical gates and truth tables ? if a set of inputs are in certain mode then expect an output with predictable result.

Now back to requirements, just to simplify things we tell a story:

In a web page application, the user has 3 sets of radio buttons. Each set has multiple possibilities and depending on the combinations of those sets, a different SQL should be executed in the database to retrive the required data from the database.

The first set has Input type where the user decides he wants to use a contract number ,phone number or company number to query the database,

The 2nd radio button set defines a filter on which to retrieve historical data in the result set or not.

The 3rd set defines the source system of the data CRM or Billing.

Each combination of these options will require a different SQL statement to be executed. My way of implementing this in writing requirements and coding was using decision tables.

Now with the combination as 3*2*2= 12 possibilities, the amount of If-Then statements could be overwhelming. It is better to use  the SWITCH statement for coding this feature. A better solution is to put the decision parameters and the SQL’s into some kind of a hash map, where the key is the conditions and the value is the SQL.

Since we can only use one key in the HashMap data structure, the best approach was to combine the Conditions into a string and use that string  as the hash-map key. a sample of that string as below.

• PHONE_ALL_BILLING
• COMPANYID_ALL_CRM
• … etc

Wait; it gets even better. the requirements also mentioned that in case the input is a ContractId, then the application becomes the one to decide the source system by running one extra SQL statement!

How on earth could this be added in requirements and code ? no problem.

The GUI was modified by disabling the source system radio set when contractID is selected. And an IF statement is added to fill in the source system part based on the test SQL (I called it TEST_A).

The same hashmap was still used, but just changed the way to formulate the index key.

An alternative method was to utilize the factory or decorator design patterns, but for the application being developed this would have been an overkill.

The only risk in using a hash-map, is that if  the same key is defined twice, the value will be overridden and the old value will be lost.

Simple is beautiful isn’t it ?