Requirements Elicitation & Management: 5 Habits Of Effective Business Analysts

Requirements, like the systems they are intended to create, can get quite complex.

This complexity emanates from their dependencies, dynamic nature and the environments in which they have to be implemented, which are typically fraught with political, economic and technological constraints, to mention a few.

A requirement does not exist in isolation and is often dependent on one or more requirements. For example, a requirement may become necessary or redundant because of another. BAs are expected to spot these dependencies as part of requirements management to prevent a waste of the organization’s limited resources.

Also, requirements by their very nature are dynamic —they change with time. An excellent requirement today can very easily become redundant tomorrow if the circumstance or environment necessitating that requirement changes. Companies that adopt a culture of continuous improvement are more proactive and thus, better able to adapt to changing business needs.

Requirements also vary depending on the stakeholder you liaise with. This is why it’s important to identify the stakeholders that can make or break your project from the onset.

Though requirements elicitation improves with time and experience, taking note of this collection of tips and best practices will ensure you stay on top of them from the get go, and that the requirements you elicit reflect actual business needs.

1. Visualize

Have the vision of the end product in mind when eliciting requirements. Visualization is a powerful technique that you should apply as much as possible. It will help you identify what questions to ask stakeholders and provide a frame of reference from which requirements may be drawn. Though some would argue that BAs should not be involved in system design, the process of visualizing becomes achievable when you create a mental image of “how” the requirement could be implemented.

2. Scope

Ensure that the scope of the project is properly documented.

There’s nothing that can derail a project faster than excluding requirements that should be in scope or including requirements that are not within the scope of what should be implemented. Knowing what the defined scope is and enforcing them in the face of stakeholders with divergent interests and opinions are two different things. The BA does not need to work alone, however. The role of the project manager involves scope management while the sponsor ensures that the objectives of the project are clear from the get-go. When these key parties are in alignment, it becomes much easier to identify requirements that should be treated with less priority.

3. Engage

It’s important to ensure that relevant stakeholders are involved in all stages of the project. Develop a communication plan that will ensure that stakeholders are regularly informed of changes to expect. Let’s face it – Stakeholders are human. They may not immediately understand the full implications of an impending change until the go-live date approaches, albeit late in the day. To reduce the scale of surprise and avoid missing requirements, the BA should engage stakeholders actively, validate requirements with them as often as possible, and point out whatever they think is missing.

Requirements should be reviewed by the technical team as well, to ensure that they can be implemented within the constraints of the available technology. For requirements to be successfully implemented, the BA must learn to strike the right balance between conflicting requirements.

4. Model

Use models to increase your understanding of what is needed. Over time, I’ve discovered that while using text to represent requirements works, displaying these same requirements via other models, e.g. business process diagrams, or even the use of mockups, reveals other aspects of requirements that would not have been immediately identifiable via text alone. The same applies to stakeholders and the technical team. Different models focus on different aspects of requirements and should be used to complement one another. For example, an entity relationship diagram would appeal more to the development team than a use case diagram, which business stakeholders can relate to more easily.

5. Simplify

Requirements that are “superfluous” should be eliminated to ensure that simplicity is sustained.

Also, BAs should ensure that their requirements and ensuing designs are practical—will they actually be used in real-life scenarios? While a requirement may seem necessary and feasible at the point of elicitation, it may not be practical to have it implemented. For example, let’s assume you are building an archiving software that involves specifying mandatory search criteria in order to find a document. A search criteria like “retention period”, while useful as a document attribute, is not as practical as “document type” or “document date”.

Business Analysts play a pertinent role in determining what functionality a system should or should not have. If you can ask these questions of every requirement, the implemented solution will have a higher possibility of acceptance:

1. Vision: How will the system work to fulfill this requirement?

2. Scope: Is this requirement within the scope of what the project is intended to accomplish?

3. Engage: Have I discussed this requirement with ALL relevant stakeholders?

4. Model: Have I presented this requirement in a manner that is easy for ALL to understand?

5. Simplify: Is this requirement necessary and practical?

 What other habits do you think business analysts should have when managing and eliciting requirements?