“To not anticipate is already to moan.” Attributed to Leonardo da Vinci

As software requirements analysts, we have crucial decisions to make regarding those errors often considered rare. This is part 2 in a series of 3 posts on how to define requirements for error conditions, specifically data errors.

Data Errors can broadly be classified in a few distinct categories described below. We need to see which of these our application is likely to encounter and devise strategies for dealing with them. The nature of our application and target audience will determine what responses are appropriate.

If we do NOT define clear error handling requirements, then we are entirely at the mercy of the development team and how they decide to handle these scenarios. This can lead to some unpredictable outcomes. 

Developers are experts at trapping and handling errors in the most expeditious manner possible, but not necessarily in the most user friendly, informative or intuitive manner. This is not a criticism of the way they practice their craft, just an experience-informed observation of the way developers view the world. 

It is the business analysts’ job to tell them how to handle Data Errors once they have been trapped. Better yet, with a bit of careful planning up front, we can even eliminate most of these errors. If we have not anticipated, then in the words of Leonardo, we might as well already be moaning.

Key sources of Data Errors are:

1. Corrupt Data. This is data that for any reason whatever has become corrupted because it contains information that is not in a format and type usable by the application.
2. Different Data. This is data whose format and type can vary depending on the context or locale. A good example is ZIP or Postal Code. In the US, ZIP Codes are just 5 numeric digits or 5+4 numeric digits. But in Canada, Postal Codes are 6 characters long and are a combination of numbers and letters.
3. Missing Data. This is data that the application is expecting but not always receiving. A good example of this are Credit Card Validation codes. These codes can be used in addition to the card number to determine the authenticity of the card but not all applications use them. But since they are not required to complete a credit card authorization, if we choose to use them, they can easily be missing, especially if we are consuming transactions from third party sites.
4. Additional Data. This is the converse of Missing Data, and is quite common especially if we are consuming or exchanging data with third party services. If clear instructions are not provided to the Development team, by default, they will likely discard everything other than what is defined as “required.” If there are certain scenarios where the additional data is needed, we will start running into errors.
5. Volume of Data. This is caused when transaction volume far exceeds the designed capabilities of the application. This is common for web applications that experience extremely high traffic in a very short time period, or for seasonal spikes in demand that are not properly planned for.
6. Language Differences. These errors are caused by script differences between languages. Obvious differences like those between English and Japanese are caught by most analysts. The more subtle differences like those between English and Spanish character sets can cause a surprisingly large number of errors.

In the next and final installment of this series, I will show how to define software requirements that address potential data error scenarios.