When analyzing and gathering requirements the work should be performed at the abstracted level, the basic functional level, and the detailed level.

Unfortunately for the data industry, looking simply at the task to be done is the most common approach, but leads to many of the issues that plague the industry.  Although this ‘blinders on’ view applies to many data related tasks, it is most prevalent in the requirements gathering tasks, and has the most devastating effects when it occurs there.  So, for this discussion, although the principle applies to all data related work, it will be discussed in term of requirements gathering.

There are three primary levels at which to gather requirements:

• The Abstract Level
• The Standard Task Level
• The Detail Level
  

The 3 Levels of Requirements Gathering


The Standard Task level is what people are most familiar with, and therefore, the level most often performed (even if poorly) for requirements gathering.  It entails the basic, primary, and ‘common case’ knowledge for a task.  Standard-level analysis addresses the specific needs at hand, ensuring that immediate requirements are met (Kulak & Guiney, 2000).

What are the basics of the standard level requirements? 

As an example, standard requirements for a particular data point - customer middle name - would include (but not be limited to) frequency in relation to other data points (can a person have more than one middle name?), the maximum size allowed, is it required or optional, and other characteristics.  The standard level of requirements should also include how it is used within the solution.

Example of 3 Levels of Question Types to Gather 3 Levels of Requirements


The Abstract Level is essentially what is seen by backing up and taking a high level look, not just at the task at hand, but at how that components fit into the overall picture. 

Using the ‘middle name’ example, knowing about the requirements for the personal middle name for other person data sets (vendor, employee, marketing contact, etc.) is an abstract.  To see all persons and their characteristics and verify both uniformities and differences is an abstract requirement.  To see if abstract needs can be consolidated and therefore minimize the overall solution development and maintenance effects is an abstract requirement..

At the abstract level, the focus is on recognizing patterns, maximizing uniformity, and identifying potential areas for reusability (Dennis, 2015).

Sample of 3 Levels of Requirement Questions

The Detail Level is exactly as it sounds – taking those standard requirements already gathered and getting to the nth level of detail.  This is the layer, typically left undone, that can eliminate the assumptions and miscommunications that take place.  These assumptions inevitably add cost to the system, through rework, failed user acceptance testing, etc. 

Unfortunately, failure to perform this detail level also leads to post implementation errors as customers invariably have data that tests out the assumptive details.  If you don’t ask the detailed questions, to gather the detailed requirements, then what would have been an acknowledged answer (a business requirement) is replaced with an assumption. 

This principle, most specifically in the Detail Level is measurably recognized as a key factor in whether business requirements are in fact discovered, and eventually met in the development phase (Johnson & Revenaugh, 2015).  This then ties back to the principle of using a variation of the Delphi Technique, starting with a template assembled through expertise, so details do not get forgotten.  As the study shows, there are astounding results differences between those using these reductive practices and those using additive practices.

The primary benefits of applying this ‘3 levels of requirements’ principle include:

• Timeliness of development and maintenance
• Pattern recognition (reducing code and complexity)
• Uniformity between systems, components within a system, and team members
• Addresses immediate needs immediately.
• Reduces errors, implementation issues, and ‘whack-a-mole’ scenarios.
• Uniformity of data architecture