Skip to main content

Assessing Requirements in Requirement Gathering Sessions

For a Business Analyst a project begins with requirement gathering or eliciting requirements (a popular term used to describe this task).

Workshops, interviews and brainstorming sessions – the more a Business Analyst conducts these methods of requirement gathering, the clearer a picture gets to him / her. Amidst these exercises, how important is it for a Business Analyst to simultaneously analyse a requirement or rather weigh a requirement? In other words how necessary is a requirement?

Although a thorough analysis is undertaken once all the requirements are gathered, it does help if certain requirements are assessed at the time of requirement gathering.

In one of my recent sessions certain high level requirements were discussed. These requirements were for an application that was requested to be developed for an internal sales team. Post the overview began the requirement gathering. I had my set of questions ready and took up one module at a time. A couple of minutes into the session, just as I was about to jot down one requirement, there came an opinion from one of the stakeholders. An experienced IT professional who has been associated with the organization for about 15 years and who is an SME on Financial Technology, begged to differ with this requirement. He posed some very important questions:

  • Is the requested feature really required?
  • What if there were an alternative? What if the purpose could be solved with a slightly different form of the feature?
  • The time effort and cost analysis if this requirement were worked upon and the time effort and cost analysis if an alternative were developed.

Now it took some solid ideas for the SME to convince the stakeholders to alter the requirement. All the stakeholders dug deeper into analysing the actual ‘requirement’ of this ‘requirement’.

To sum up an alternative was agreed upon. This alternative served the purpose of the business stakeholders, was economically feasible and could be developed in lesser time all without compromising on the quality of the application and the purpose of the feature.

Not all the requirements that are put across have the same nature. But there could be times when the business users are hell bent on having a complex feature in the application or they may want to implement a module on an existing application just because they happened to experience a fancy feature in the application of a competitor. While some requirements may be very helpful to the business, there may be certain requirements that can be optimally altered.

  • Requirement Gathering shouldn’t be about just jotting down requirements – Some requirements may not be needed at all or there may be better alternatives available. Such alternatives should be put on the table and discussed. The following questions can be asked:
    • How purposeful is the feature / requirement?
    • If the requirement is essential but it will take a lot of time to develop what can be done to deliver an alternative?
  • Stakeholders may come from either a technical background or a non-technical background – Some of them may be from a non-technical background but may possess a sound technical knowledge. However, if a stakeholder is from a non-technical background and doesn’t know the development process thoroughly, chances are high that a Business Analyst will have to discuss a requirement in more detail. They may not know the development process thoroughly. But you do. You know how much effort goes into developing the smallest of module of an application.


A stakeholder may not be completely aware of the time taken for development or the cost involved in undertaking the development of a module and making changes. In such cases, a Business Analyst has to dive deeper and ensure that the requirements serve the purpose of all.

  • In most projects, requirements undergo frequent changes – Stakeholders expect to go live with a product with almost all the requirements raised by them; even the changes. However given factors such as cost time analysis, project development time frame, priority of the project and availability of the resources deployed, it may not be possible to involve all the features during the launch. The requirements thus need to be prioritized keeping in mind the interests of all the stakeholders. While the major requirements can be taken in the first phase, the remaining can be put into the subsequent phases.
  • Requirement Gathering along with simultaneous analysis helps to save time during documentation and consequently project planning – If a doubtful requirement is discussed then and there and the alternatives are weighed, the stakeholders can reach on a consensus and consequently the requirement can be clearly documented and closed. This saves a Business Analyst from consequent follow ups required for requirement clarity or discussing changes.
  • A project may seem to be a simple at first however it’s only when these requirements are thoroughly analysed that the complexity of the development can be understood. Thus questioning a requirement in the interest of project development is important.

Weighing requirements is as essential an activity as requirement gathering. If done in the initial requirement gathering sittings, the subsequent processes – requirement documentation, sign off and planning can be smoothly accomplished.