Capturing Implicit Requirements

Introduction

A typical SDLC project starts with a requirements-gathering exercise followed by an analysis phase. During the requirements analysis phase, a detailed study is done in order to identify the different pain areas that would be addressed by the software that would be delivered. Often we come across situations, or more appropriately, business scenarios, wherein the requirements are not clearly documented.  They are vague and do not provide any clarity as to what exactly is expected. This leads to ambiguity, and finally, a software that delivers everything except what the client asked for! Unfortunately, this discovery happens during the user acceptance phase. Defects are identified that inadvertently point to requirements that have not been clearly captured/documented. A standard reaction of the business users would be, ‘We thought that this was going to be delivered…it is an Implicit requirement!’ Once we hear this statement, a typical ‘passing the buck’ game starts between the IT department and the Business Users.

This situation could have been easily avoided if the Business Analyst had taken the efforts to identify the implicit requirements. A key responsibility of a Business Analyst is to define the Scope of the system that is going to be built, and in this process, ensure that the Explicit as well as Implicit requirements are clearly documented.

Understanding Implicit Requirements

Let us begin with understanding the difference between an Explicit and an Implicit requirement. Usually, the requirements that are stated by the business users in the different meetings and interviews are categorized as Explicit requirements. These requirements are the easiest to capture. They are usually supported by loads of Documentation, or for that matter, even a legacy system screenshot!

Implicit requirements are the hidden or ‘assumed’ requirements. Business users expect these to be delivered and hence may not feel the need to explicitly mention them in the business meetings. It could be challenging to actually define the scope as there is no clear-cut documentation or boundary available. The keyword here is ‘scope’. Let us try to understand this with a very simple example:

User requirement: 

Screen to capture the following employee details:

1. Employee number
2. Employee name
3. Department

Implicit requirement: 

1. Capture Designation as well

Since it is an Employee data capture screen, the business users would assume that there is a field to capture Designation as well. This would definitely be an Implicit requirement. But is it right to assume that this is the ONLY implicit requirement?

For instance, I can add a couple of other implicit requirements, such as:

1. Duplication check required on the ‘Employee number’ field
2. Should have the facility to Search for an existing Employee

Here is where the dilemma starts. Some Business Analysts would totally agree with my listing of implicit requirements, but I am sure there would be many others in the Business Analyst world who probably disagree. For instance, Search facility could be provided as a separate screen, and hence that would be a separate requirement altogether.

The key point here is to recognize that capturing the implicit requirement is more of a need than a luxury.

Another example would be in a data processing centre where the performance of a data entry operator is measured by the number of entries that have been done in the system. For example, consider a typical airlines scenario wherein millions of passengers travel daily. A data entry operator in such a scene would have to enter hundreds of passenger coupons in the system and his KRA or performance is measured on the basis of the number of coupons he enters in the system. In such a scene, the Business would need a system that would capture data quickly and in a highly efficient manner. Here, the implicit need is that the data capture form has to be designed in such a manner whereby the maximum data/information on the form can be entered using the keyboard rather than using the mouse. In other words, maximum information must be enterable using keystrokes rather than using the mouse.

If this implicit requirement is missed out, then we end up in situation where the data entry operator would never meet his KRA, and looking at the bigger picture, the airline would miss its SLA. This could lead to tarnishing the airline’s image and would ultimately impact its business.

Scope Control

If documented well, Implicit requirements can be used as an excellent tool to control the scope, which in turn will lead to lesser defects and finally a Satisfied Customer! But at the same time if the boundaries for the requirements are not clearly documented, it can be misused and will lead to Scope Creeps, huge defects and a Dissatisfied customer.

This leads us to the conclusion that the Business Analyst community would have to use certain proven methods to define and bound the scope. A cost-benefit analysis will be the ideal way to deal in this situation. There may be a scenario wherein an endless list of implicit requirements inadvertently increases the cost with no visible benefits. On the other hand, it is quite possible that by deciding to incorporate minimal implicit requirements, the client would reap huge benefits.

In a nutshell, in order to ensure that the implicit requirements are never missed out, we would need to take a step back and always try to understand what exactly the Business user is looking for and if we have really understood this need. To conclude, we Business Analysts do play a role of ‘the Truth Seeker’ and thus need to unravel what lies beneath, in our quest of understanding Business requirements!

Don’t forget to leave your comments below.

---

Aruna Parameswaran : A technical person with 12+ years of experience who moved into a Fucntional role by choice. Working as a Business Consultant with an IT organization and have led the Requirements phase of multiple implementation projects across geographies,primarily Asia-Pac and UK with some exposure to the US geography. Have spent the last 6 years specializing in the Life Insurance domain in the UK and Asia-Pac regions