Requirements Prioritization

Requirements once elicited and approved from the authentic sources are further put for analysis and the first step in the process of requirement analysis is to prioritize the requirements in the order of their implementation. It is mandate for business analysts to prioritize the requirements as it’s a process to add value to the deliverables. The business analyst (or the one seated on the business analyst’s chair) has to consider certain factors while prioritizing the requirements so that the smooth process can be implemented. These factors or aspects which are considered at the time of prioritizing the requirements are: importance, risk, cost, benefit, time, strategy etc. The software development is a set process and the requirements are said to be changing till the final version is deployed in the production environment for the end-users and thus its a challenge for a business analyst to keep track of the requirements and alter the priority with the progress in the development but the decision on prioritizing the requirements depends on the decisions made by the stakeholders involve in the project and business analysts being a liaison between different stakeholders have to co-ordinate the activity.

Why to prioritize the requirements?

Eliciting the requirements and fit them into the releases to develop the functionality is a major step towards the success of the development of the software/project and it’s very important to understand the risk of not prioritizing the requirements. In the words of Frederick P. Brooks, “The highest single part of building a software system is deciding precisely what to build… No other part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later” Thus to mitigate the risk of re-work in the later part of the development, it’s advisable to define the requirements and prioritize them before starting the implementation. In simple words, “No matter prioritization technique is considered simple, medium or difficult it’s a fundamental activity for successful implementation.”

Continue reading

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.

Continue reading