When Business Requirements Aren’t Good Enough


Requirements are inputs to achieve the project objectives that transcend from routine operations to enhance the value proposition of a business endeavor. Stakeholders invariably perceive an endeavor to be successful only if they are able to clearly correlate the derived outcome to predefined business requirements. Thus project success is best defined in terms of effective user requirements.

A simplistic interpretation of ‘requirements’ stipulates that it is “a promise to deliver the right outcome”. This is a very basic assumption but draws out the merit and intention of a carefully laid down user requirement. A promise to uphold and deliver the desired outcome is a true reflection of the intent and clarity while formulating effective requirements. The role of a business analyst is critical to ensure that the requirements identified and agreed upon are capable of attaining the desired outcome.

Case Study

We will attempt a study of an endeavor where things went wrong, wherein an intended enhancement of a business process did not end up delivering the desired outcome. (N.B. the organisation name shall remain anonymous. Permission to use the assignment for this article was sought and approved by the client.) I was exposed to this case when I was asked to support the resolution of an incident and investigate the possible causes. This is the story of when requirements go wrong!

Current State (Prior to the Enhancement)

The process constituted steps to process direct debits towards customer loan repayments. It was inefficient, was disconnected, and exposed the organisation to risk.

  1. Disconnection: Users have to generate customers’ direct debit payments due for a given day from a designated system (referred to as system 1 for the purpose of this study) and upload the file to another system (referred to as system 2 for the purpose of this study). The file is currently uploaded manually. However, it can easily be streamlined and set up for automation by eliminating user intervention.
  2. Inefficient: Manual handing of system files is not considered efficient and is incompatible with systems integration practices. It not only slows down the process but also exposes the database to umpteen risks and errors that can potentially render the process ineffective.
  3. Risk: A significant risk associated with manual data handling is compromise in confidentiality of sensitive customer information (i.e., bank account details) and its potential exposure to theft.

A business analyst was asked to look into the possibility of automating a process where the current process had multiple manual touch-points. The business analyst studied to understand the desired future state and successfully documented the desired process to recommend a stable future state. The future state process design was supported by requirements and rules to guide the endeavor to streamline the process. The proposed solution entailed the following transition:

  1. Integrate system 1 and system 2 to establish seamless processing.
  2. Minimize user intervention in processing direct debit payment files.

These requirements and the desired process map were communicated to the Information Technology (IT) team for development and implementation. The enhancement was tested based on the requirements and rolled out to production.

What Went Wrong?

On day one of go-live, the business users identified a defect in production associated with the roll-out of the direct debit process enhancement. They were unhappy and expressed their dissatisfaction pertaining to the entire process of solution development. They instantly claimed that the ‘requirements ‘elicitation was passive and ineffective in capturing all the critical parameters’.

In an attempt to understand and define the problem statement, the business analyst had asked the question “What do you do and how can it be done better?” The users stated their story and expressed the pain and how they envisaged the desired solution. It appeared that the users narrated their story by focusing on the future state. It mainly revolved around how they would like the future to be. This is a common practice, where business users tell their stories while thinking forward. The business analyst then documented what he/she was told, got it reviewed, and shipped it to the IT team for development. This is what IT received as ‘requirement’:

‘The solution must integrate system 1 and system 2, where user intervention is not required to process direct debit payments files.’

This requirement caused a serious discomfort and embarrassment to the business. Day one from going live, according to the incident description, ‘direct debit entries for written off and closed accounts are being generated … This has impacted x% of customers with written off accounts...'  (N.B. The anonymity agreement with the organization subject of this case study restricts revealing the whole details of the impact.) Why wasn’t this requirement good enough?

  1. Generic and high-level requirements. Insufficient details were provided to progress on to the development phase of the solution with such requirements.
  2. The business analyst took it for granted and believed what he/she was told to be the complete truth that would hold true in all scenarios. Even though he/she documented the current state process accurately, he/she did not go beyond and above what he/she was told. However, the information gathered turned out to be incomplete. The business analyst missed details, business rules, exceptions to the rules, etc. (a) and (b) are examples. Hence the requirement was incomplete.
    1. When the users generate the file from system 1 and upload it to system 2, system 2 processes the file, excluding certain accounts, using a set of criteria that stipulates that “closed and written off accounts must not be included in the direct debit processing”.
    2. System 2 also validates information contained on the file and pops up errors on the screen for the user to validate and manually exclude or rectify before uploading.
  3. The business users reviewed their story. In general, users validate only what they have communicated. They tend to trust that the business analyst knows what they are doing and seldom proceed to question their domain. The user safely assumes that they are only required to validate their own story and not the interpretation of the business analyst.
  4. In general, the IT team expects that the requirements provided are complete and have been validated to ensure the desired outcome. Their focus is limited to the system or functional requirements and its implementation across the impacted technology components.

How Could This Have Been Prevented?

The root cause analysis reflected that the process went wrong at every stage of the process. However, the requirements elicitation stage showed passivity and slackness that cascaded to the subsequent stages of the process. This could be correlated to the passive approach adapted by the business analyst.

It is the role of a business analyst to gather information and conduct intelligent application of knowledge acquired through reasoning and assertion of facts relevant to the current scenario. It is imperative to ask the right questions, examine every step of the process, and understand what happens behind the scenes.

The user only narrates the story that they can visualize; they don’t necessary communicate every episode of the story. Thus the business analyst should have been diligent enough to identify the gaps and evolve a comprehensive plan with intelligent requirements.

When the requirements are elicited, do the users provide details? They tell story, not requirements. Jonathan Gottschall, author of The Storytelling Animal, says science backs up the long-held belief that story is the most powerful means of communicating a message. People tell stories because it is a part of human nature; we like to tell stories, read books, and dramatize on TV, cinema, etc.

In this case study, the business analyst did requirements ‘elicitation’ but no ‘analysis’. In the requirements elicitation context, business users tell stories because they like to be heard and understood. However, listening to the user story is not ‘analysis’; it’s merely ‘elicitation’. Information can be amassed through various collection disciplines: human source, written communication, documents, and many others. The system of remodeling the unknowns to acknowledged facts, issues, conditions, legacy, and human sources is the analysis that identifies the requirements.

In summary, requirements analysis is not an exact science. We are called ‘analysts’ for a reason: being able to walk in, assess, analyse, and construct a process that would work for the instance we have at hand. We don’t heedfully auricularly discern stories and convert them to ‘requirements’. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and perspicacious curiosity to transform stories to abstracts and propose the needs. In this case study, the story as told by the user covered only the highlights and left the investigation of the unknowns to the analyst.


Author: Adam Alami, Sr. Business Analyst

Adam Alami is a seasoned IT consultant with over 18 years’ experience. Business Analysis and Project Management is his passion. His experience revolved around major business transformation projects. He is a versatile IT professional. He accumulated a wealth of cross industry experience with Tier 1 businesses in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.

Adam has a passion for research. His research interests are IT Offshoring, Global Project Managements, Banking Technology, Business Analysis, Information Technology and Culture, Enterprise Innovation and Business Solutions.

Email: [email protected]
Website: www.adamalami.com

Like this article:
  19 members liked this article


Ryan Milligan posted on Wednesday, March 16, 2016 4:10 PM
While I understand and appreciate the premise of the article, this seems like a pretty extreme example, and something people would lose their jobs over. Was the solution not tested before deploying to production to ensure that all of the business rules were being applied? For such critical data, both sides are at fault for this oversight. Business requirements are not meant to be used by developers as they are often far too broad and open to interpretation.
Adam Alami posted on Wednesday, March 16, 2016 7:29 PM
As stated in the article 'The root cause analysis reflected that the process went wrong at every stage of the process. However, the requirements elicitation stage showed passivity and slackness that cascaded to the subsequent stages of the process. This could be correlated to the passive approach adapted by the business analyst.'
The whole process has issues. The requirements was just part of a bigger issue.
Testing was another issue in the whole process. The business offshore their testing activities. The offshore provider test the solution based on communicated requirements.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC