As a business analyst , you will interact with different stakeholders in the project and each of them will have their own business requirements. As a result, there will be numerous business requirements . Some of the business requirements may conflict with one another. On the other hand, the project team will have to manage the project within the constraints of time, cost, quality and risk. You will be pulled in different directions as regards to how many requirements can be fulfilled by the team within the constraints and the client wanting everything and more! Moreover, in many systems, there are features that are rarely used. You will have to bring the right balance so that the business objectives can be met.
In the best interest of the success of the project it is imperative for you to prioritize requirements. Prioritization of requirements will -
Prioritization helps in streamlining work and bring everyone to the same plane regarding the business objectives. There are different techniques of prioritizing requirements -
It is a technique where the requirements are categorized as -
|'Must'||Mandatory Requirements critical to the system|
|'Should'||Important Requirements and are valuable to the customer|
|'Could'||Desirable Requirements but not the most important functionalities|
|'Won't'||Not required for now. They can be planned for in future releases.|
The MoSCoW matrix will help to understand what are the key requirements of the customer for successful completion of the project. It helps in trade-offs as the project team is aware of what is more important and what is less important. It also helps in managing scope later on in the project if there is risk to schedule and cost.
The different terms should be clearly explained to all stakeholders else there can be confusion.
Let us look at some requirements for an e-commerce site and prioritize them using the MoSCoW method -
|User should be able to sign up and log in||Must|
|Payment Integration Gateway||Must|
|Show Purchase History||Should|
|Post Review of Products bought||Could|
|Share your purchase on Facebook||Won't|
This is a technique where the requirements are mapped to key business objectives. If a requirement cannot be mapped to a business objective, it is considered out of scope. Here the key business objectives are defined. It is then assessed if implementation of each requirement can be aligned to the business objective. The requirements that cannot be aligned are omitted.
In the e-commerce website example, the key business objectives could be -
1) Increase customer visits and increase number of registered customers
2) Increase sales on the website
In this case, the following requirements will be of higher priority -
The following requirements may not be of high priority as they are not directly related to the business objectives and can be developed in future releases -
In this method all client representatives are given an imaginary sum of 100 dollars or 100 points. These are to be distributed among the listed requirements. The client representatives assign points or dollars to each requirement. The requirements that have been allocated a higher amount on a ratio basis are considered within the application scope. The other requirements are postponed for future releases. This technique is good if there are limited number of requirements. If the list of requirements is long, 100 units are not enough. A higher amount should be considered or requirements should be grouped and the the groups should be allocated dollars/points.
There are some other ways of prioritizing requirements such as ranking the requirements on criticality or assigning weightage to requirements.
There are some challenges to prioritization of requirements that a BA has to handle. Some customers may want all requirements incorporated. Others might feel if they give some requirements a lower priority, they would not be implemented. Project leads or BAs try to avoid conversations in which they have to reject requirements of clients. But it is important to rank requirements. Requirements prioritization finalizes project scope and ensures the most important functionality is implemented.
Let us know, what techniques do you use for prioritizing requirements.
Global Association of Risk Professionals, Inc. (GARP®) does not endorse, promote, review or warrant the accuracy of the products or services offered by EduPristine for FRM® related information, nor does it endorse any pass rates claimed by the provider. Further, GARP® is not responsible for any fees or costs paid by the user to EduPristine nor is GARP® responsible for any fees or costs of any person or entity providing any services to EduPristine Study Program. FRM®, GARP® and Global Association of Risk Professionals®, are trademarks owned by the Global Association of Risk Professionals, Inc
CFA Institute does not endorse, promote, or warrant the accuracy or quality of the products or services offered by EduPristine. CFA Institute, CFA®, Claritas® and Chartered Financial Analyst® are trademarks owned by CFA Institute.
Utmost care has been taken to ensure that there is no copyright violation or infringement in any of our content. Still, in case you feel that there is any copyright violation of any kind please send a mail to firstname.lastname@example.org and we will rectify it.
2015 © Edupristine. ALL Rights Reserved.