Why Do Business Analysts Miss Software Requirements? - 2

This piece is a continuation of Why Do Business Analysts Miss Software Requirements? and provides more reasons why Business Analysts may miss out on key requirements necessary for system development.

Poor Requirements Elicitation

Despite the emphasis that has been placed on eliciting accurate requirements during elicitation events, some projects are launched without the inclusion of end users who will make use of the system once it is live. Having a knowledgeable SME on board the project does not replace the need to involve end users or frontline staff who are involved in operational activities on a daily basis.

To avoid building systems without taking into account real-life scenarios and complexities that can affect how the system is used, projects must involve end users from the beginning as much as possible until the software is implemented.

Islands of Knowledge

When analysts work in organizations where they are required to specialise in certain domains or business areas, they are less likely to have the “big picture” perspective that is often necessary to identify missing links on projects. 

Creating islands of knowledge can lead to situations where an analyst takes decisions without having a full picture of the effects. When only few stakeholders have the knowledge of the global effect of making key project decisions, when stakeholders that do have the full picture are not involved in analysis and when relevant information does not trickle down to BAs, it can lead to missed requirements.

For example, an analyst specializing only in the accounts payable (AP) module of an Enterprise Resource Planning (ERP) application is less likely to understand the implications of what happens in the inventory (receiving stock and processing returns) module when a supplier account is blocked within the AP module.

Ensuring that processes are tested end-to end and conducting regular knowledge transfer sessions among team members can however, minimize the impact of this.

Time Pressure & Poor Quality Assurance

So you’ve defined the solution to work a certain way but the developers didn’t quite follow the script and the testers signed off because the test cases weren’t exhaustive or extensive enough to identify missing requirements—key project activities have been rushed. Time and quality certainly go hand in hand; the more time you have on your hands, the more you can iron out the rough edges. Here's a scenario to consider:

The bank reconciliation team of a multinational company did not see a final demonstration of the reconciliation feature of their ERP before the system was fully implemented.

Though they had a brief session to see the feature in action, they had requested for some changes to be made to it. By the time the software was delivered (which was late) with the requested changes, the ERP system had already gone live. You can guess what happened next: the stakeholders were unhappy with the result and submitted change requests on day one.

It is critical to ensure that an estimation of how much time is truly required to complete every key phase of the project is done. Estimates done based on tight deadlines and unrealistic expectations of how much can be achieved within the time frame can be detrimental to the success of the project.

What else can cause BAs to miss key software requirements?

Picture Attribution: “Lost Or Found Directions” by Stuart Miles/Freedigitalphotos.net