“The expected always happens.” Benjamin Disraeli, via Bram Stoker’s Dracula.
As software requirements analysts, we have crucial decisions to make regarding those errors often considered rare. In this series of posts, I’ll discuss how to define requirements for error conditions, specifically data errors.
Unlikely. Unexpected. Unpredictable. Random. Intermittent. Rare. Typical responses given when you ask an astronomer the likelihood of a giant asteroid the size of a football field striking Terra Firma.
Coincidentally, they are also the exact same responses given by developers when queried about error conditions of all kinds landing with a resounding thud on the application for which we are defining requirements.
These adjectives are not bad approximations of reality for a well designed application (or a meteor sending us all on the same fiery path as dinosaurs a few million years ago). All these terms share a couple of traits – they are used to predict the probability or the frequency of occurrence of the event. And a third one. None of them are synonymous with “never.”
So, errors WILL definitely occur in applications. And our beloved Gaia WILL get clobbered again by a giant asteroid. Eventually. The only unknowns are when and how often. The giant asteroid gob smacking all and sundry we have been told is not likely to happen in our lifetimes. Tragically though for us, the errors in our beloved application will manifest in the course of our lifetimes. In fact, with my luck, a few days or weeks after it is released into the wild.
As requirements analysts, we have crucial decisions to make vis-à-vis errors. Do we want to address error conditions in the requirements? Which errors? Or do we leave it to the discretion of the development team to figure out what to do with them? These are non-trivial questions since time is always at a premium when defining requirements. And the first order of business is ALWAYS to define clear requirements so everyone understands what the application should do when all these errors are NOT occurring (and an asteroid landing is not imminent).
So, when we prioritize tasks and allocate time, we often decide to skip defining detailed requirements for error conditions or allocate the minimum time we think we can get away with. Two things drive this decision. First is the desire (and very real pressure) to define the feature itself thoroughly without worrying about errors. The second is habitual and is in large part due to the terminology used to define errors. It is not worthwhile wasting a lot of time and effort writing requirements for something that is unexpected, unpredictable, random, intermittent and rare. Right? Well, no. Not really. For System Errors, we can leave it to the discretion of the Development team. For Data Errors, we should get in front of the issue and define expected behavior when these situations eventually arise.
For the purpose of this discussion, a System Error is defined as a condition whose causality lies entirely within the application itself or the environment in which the application is running. These are code defects, logic errors, hardware failures or an Act of God. You do not write requirements for this. You will typically have policies defined at the project or corporate level on how these situations are handled.
Data Errors are errors introduced into the system because the application encounters a data condition that is unexpected. Or rare. Or random. You get it… These errors should be addressed in the requirements with clear instructions to the development team on how the application should behave when it encounters these situations. If not, we will be dealing with them via trouble tickets, bugs and change requests.
In part 2 of this post, I will show how Data Errors can be classified and identified easily so that requirements can be easily defined to handle them.
