Requirement Management

Requirements Management

Requirement ManagementThe gap between “what we know” and “what we think we know” is filled by the knowledge and the experience. What we know is about the facts and what we think we know succinct the assumptions. This is marked as the baseline for the business analysts (or the one seated on the chair of BA) during the requirements management and thus the BAs have to strive always to maintain the credibility of the requirements throughout the project life-cycle. The most appropriate way to mitigate the chances of bogus requirements getting developed or documented is to frame questions and avoid muddiness. The BAs are advised to focus on the different aspects of the requirements and then frame questions to nullify the chances of any ambiguity during the requirement elicitation and documentation.

What is Requirement?

Referring to the world of dictionary, the requirement is described as, “Something which is necessary and must be fulfilled to achieve the result”. Requirement word itself is self-explanatory and sometimes begets a cringing feeling (especially with the phrase “change in requirement”). But this should not happen with the BAs as they have the primary tasks to manage and maintain the requirements’ credibility throughout the life-cycle of the project.

Requirement management is one of the knowledge areas in the IIBA BABOK, bible for all amateur and professional business analysts. This book demonstrates the activities and considerations to manage the requirements. The requirements are expressed to mass and diverse audience and thus it should be managed and communicated in such a way that the stakeholders with different backgrounds can understand easily. Requirement management assists in measuring and analyzing the simulations developed for the change requests and thus helps in achieving the business goal and objectives. BABOK classifies the requirements as below:

  • Business Requirements: It defines the higher level goals and objectives of the organization with the details of the reasons of the project initiation.
  • Stakeholder Requirements: It defines the needs of the stakeholder(s) and the steps taken to cater the same. The different stakeholders are provided with different formats of the same set of requirements e.g. the business owner is more interested in understanding the end product and the numerical figures while the developer is interested in knowing the cases and techniques to be followed to develop the same.
  • Solution Requirements: The proposed solutions for the business and stakeholder requirements are discussed under this section. The solution requirements are further sub-categorized to: functional and non-functional requirements.
  • Transitions Requirements: It defines the capabilities of the implemented solution for smooth facilitation of the current state of the enterprise to the future state. These are temporary requirements and are developed when both the current and new solutions are in place.

Requirements elicitation techniques help the business analysts to complete the documents and then they are properly communicated to all the stakeholders for approval and development, but the tasks of business analysts do not end here. He must have to take care that the requirements should not go off the skull and the credibility of the requirements are maintained throughout the project. This process or technique is covered under the knowledge area Requirements management and communication as defined in IIBA BABOK. Requirement management maintains the importance of the requirements and thus the complete process is divided into different stages which can be mapped with the different phases of development life cycle, as below:

Stages of Requirement Management

Different phases of SDLC







Construction and Testing


Verification or Testing




Disclaimer: 5 stages of requirement management is described in the training courses of Villanova University 

Requirement management is thus identifying and monitoring the needs of the business and the stakeholders and to apply the most suited and accepted solution. It helps in understanding the effects of the change requests on the current state and also helps in linking the business goals and objectives to the actual solution that is constructed and delivered. The key points to remember for requirements management throughout the project life-cycle can be, thus, defined as:

  • Elicitation from authentic source: It is advised to elicit the requirements from the responsible sources to avoid any ambiguity and rework in the future. E.g. Business Requirements should be elicited from the business owners and the fellows who are the investors and directly related to the profit-loss figures and on the other hand the different stakeholders should be involved to understand the stakeholders’ requirements. No matter how less or more influencing the stakeholder is but his vote and advice should be considered at the time of completing the stakeholders’ requirements. Business analysts are advised to update the documents referring the authentic sources. Sometimes the use of tools is preferred for graphical representations, if required.
  • Validation: Once the requirements are documented, the major responsibility comes to get them validated from the different sources. BAs have to take care of the validation of the requirements to maintain the credibility of the same throughout the development. Should there any deviation in the requirements, the same be documented and validated to avoid future re-work. The technical discussions are also very important and thus the BAs have to take care that the mentioned requirements are feasible and can be accommodated with the technological scope.
  • Defining the priorities: The set of requirements once documented and validated are set for the development and implementation but “what should go first” is defined by the business analysts considering the business and stakeholder requirements. The solutions proposed for the business and stakeholders’ requirements should be analyzed and then the priority of the requests should be defined. It’s recommended to maintain the back-log of the requirements and normally BAs are the owners of this back-log container to add/remove the change requests keeping in mind the baseline requirements. Agile methodology strongly supports the back-log definition.
  • Version control and Traceability: Management of requirements demands the proper records of the version change or updates in the requirements (requirement variance). These changes should be version controlled for further auditing and to compare the actual result with the expected result. This version change is pretty useful in the cases of change management to keep the record of the baseline requirements. These recorded requirements should be traceable to all the solution components for better impact and risk analysis.

Requirements are the spine for the development of any application and till the application is live the changes are unpredictable. BAs therefore, play a very crucial role in managing the requirements for the ease of the development team and the business owners. Fixing the issues during the development is much easier and economical than to fix them as a part of the change request or bug-fix.

Requirement management is thus an important part of the business analysts’ task-list and it’s up to them how they manage the momentum as the project progresses.

Happy Reading!!!

Leave a Reply