What is...P Oct 18, 2018 4 mins 48903 Views 2 Comments 3 Likes

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

BABOK 2.0 devotes a whole section to prioritizing requirements, noting, “Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements.” ¹Another writer notes, “Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost.” ²Requirements prioritization enables an analyst to ensure that requirements are ranked and implemented in a top-down approach.

Some organizations choose to eschew any type of requirements prioritization, effectively leaving the shape and implementation of their project to chance. This approach ignores some basic truths about requirements engineering, which are noted by Donald Firesmith in his article “Prioritizing Requirements”: some requirements are more important than others and therefore should be given higher priority; most projects do not have the dedicated to staff to implement all features at once; and many long-term projects experience shifts in priority as business needs change.³In virtually all projects, time and resources will dictate that only a certain number of requirements can be addressed at any given time. Therefore, it behooves the analyst to ensure that the requirements addressed at any specific juncture are the ones he or she believes to be the most important. Business Considerations in Requirements Prioritization

Business Considerations in Requirements Prioritization

When it comes to the process of assigning a requirement’s priority, any requirement may be prioritized at any point in its lifecycle, according to BABOK. But regardless of when it is done, before a requirement can be prioritized, an analyst must consider what is most important from a business standpoint. There are a number of possible business considerations , including value, cost, risk, difficulty of implementation, likelihood of success, stakeholder agreement and urgency, each of which is described in more detail below. Often, a combination of these methods is used when considering the business need; rarely is one alone used in a vacuum.

Value – This approach focuses on the business benefit of any given requirement; the requirements that will return the greatest business or economic value are given the highest priority. This focus on value helps to ensure “quick wins” for the organization.

Cost – With an eye toward funding, this approach may be implemented a number of ways—implementing the least expensive requirements first or first implementing requirements with the greatest ROI (return on investment).⁴
Risk – This approach prioritizes the riskiest requirements first, with the logic that should they fail, the project can be abandoned with a minimum of investment. This approach often makes sense when a controversial or untested initiative is planned.
Difficulty of Implementation – The inverse of the risk approach, a focus on difficulty of implementation places the highest priority on the requirements that are the easiest to implement—the safest bets. The benefit of this approach is that it allows a project to get some project benefits deployed quickly, enabling customers and other stakeholders to become familiar with the project and give critical feedback before the organization moves forward to deploy more difficult aspects of the project.
Likelihood of Success – Similar to difficulty of implementation, this method is frequently employed when a project is divisive and needs to shore up stakeholder support. It places highest priority on requirements with a high probability of success.
Regulatory Compliance – With this approach, the requirements that are needed to meet legal and/or regulatory requirements are given highest priority. If an organization has a high priority (for marketing or legal reasons) to incorporate certain regulation such as Section 508 compliance, requirements that force accordance with section 508 would be given highest priority.
Relationship to Other Requirements – Requirements often intermingle in complex relationships of interdependence. With this approach, requirements that support other high-priority requirements are also given high priority.
Stakeholder Agreement – With this approach, stakeholders must come to a consensus on which requirements are most important, and then those are given highest priority. Within most organizations, stakeholder agreement is likely to be at least a partial factor no matter what other prioritization methods are employed.
Urgency – To quote BABOK, “This approach prioritizes requirements based on time sensitivity.” ⁵An example of this approach would be if an organization wanted to unveil something at a trade show or to stockholders on a certain date. The requirements that would make up the public-facing pieces would have to be implemented quickly, and those would be given highest priority based on the urgency of the looming deadlines.

The above business considerations will factor in when one employs a prioritization method to logically rank requirements’ priority.

Prioritization Methods

Some of the more commonly used prioritization methods include:

Binary Search Tree – While a binary search tree is used in many other methods of information gathering, this approach is designed specifically for prioritizing requirements. Starting with one requirement as the root node, this method systematically compares each succeeding requirement to the root node, establishing child nodes—essentially creating a long list of prioritized requirements.⁶

Kano Analysis – Developed by Noriaki Kano, the goal of this method is to isolate customer requirements from incremental requirements. This marketing-savvy method assigns one of four categories to each requirement (each of which has a strong focus on the customer’s perspective): (1) Surprise and delight, (2) More is better, (3) Must be, (4) Better not be. For more information about this method, visit http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss.⁷

The Money Game – Coined by Larimar Consulting, this method has the analyst assemble stakeholders and give them each a certain amount of currency (board game dollars or coins, for example). Each stakeholder has fewer dollars than the project has requirements, and the stakeholders must spend their dollars on the requirement(s) that they want most. Once the analyst has counted the money, she can determine which requirements have the highest value to the group. ⁸

Numerical Assignment Technique – This method uses a straightforward scale of 1 (lowest priority) to 5 (highest priority). Stakeholders rank each requirement using the scale. Using their feedback, the analyst then gets a numerical average for each requirement and prioritizes them accordingly.⁹

Planning Game – Similar to the Numerical Assignment Technique in that it uses a numerical scale (but uses 1 to 3 rather than 1 to 5), this method uses customer input rather than business stakeholder input to glean an average for each requirement and then rank them by priority.¹⁰

100-Point Method – In this method, each stakeholder is given 100 points to “spend” on the requirements set any way they wish. For example, if a stakeholder strongly feels that only two requirements are truly needed, he can spend 50 points on each. However, if another stakeholder feels that 10 requirements are needed, but that two are more important than the others, she might spend 5 points each on the 8 less-important ones, and 30 points each on the two that are more important in her view.¹¹

Theory W – This method uses negotiation and continual risk assessment to ensure that every stakeholder has a “win” in the project—a requirement or requirements that he or she feels strongly about deploying on schedule. To accomplish this, each stakeholder must privately rank the entire list of requirements and decide which are truly most important and, and among those, which they might be willing to give up. Then as a group, requirement priorities are negotiated and subsequently protected from risks throughout the project.¹²

Requirements Triage – Requirements Triage can be a bit complicated since it goes through several steps, but those steps can do a great deal to ensure the business success of a project. The steps include factoring in what resources are necessary to complete a requirement and determining which requirements will best ensure a product’s commercial success. Because of the complex nature of this approach, it is recommended that analysts do additional research on this method before implementing it.¹³

Wiegers’ Method – Customer-focused and involving a bit of math, Wiegers’ Method calculates a requirement’s priority by dividing its value “by the sum of the costs and technical risks associated with implementation.” Using a scale of 1 to 9, a requirements value is assessed by determining both its importance to the customer and the consequences that would incur if that requirement were not implemented.¹⁴

Requirements Prioritization Framework – Complex but thorough in its approach, the Requirements Prioritization Framework is the only method mentioned here that assigns different stakeholders different levels of importance (and therefore their requirements prioritization different levels of importance). This approach also has the analyst rank requirements, allows stakeholders to rank requirements, and looks for deviations and possible cliques among stakeholders. ¹⁵

AHP – This method uses a pair-wise comparison to calculate the value and cost of each requirement, and then plots them each on a cost-value diagram. It is “a method for decision making in situations where multiple objectives are present.” Tools are available to support this method for analysts who are interested in exploring it. ¹⁶

Once an analyst has chosen the method(s) by which to select which requirements have highest priority, she should turn to her colleagues and other stakeholders for input to ensure that everyone is in agreement regarding the emphases of the project. She should also ensure that they understand and agree on the method(s) by which the requirements will be prioritized.

Stakeholder Input in Prioritization

In order for everyone to be on the same page regarding which requirements have the highest priority, an analyst must get stakeholder input. According to an IBM article, “Prioritization is often a negotiation process, one that involves a wide range of project stakeholders including your users, user management, senior management, developers, and your operations and support departments.” ¹⁷BABOK notes that the proper stakeholders from whom to elicit input may include subject matter experts, project managers, and project sponsors.¹⁸Other stakeholders may be appropriate to include in assessing priority, depending on the project’s needs. The process of getting stakeholder buy-in on assigned priority may be done via requirements review, in-person interviews, workshops, a meeting, or any other method that best fits the needs of the project.

Prioritization Designations

A project may use any prioritization designations that make the most sense to the analyst and her stakeholders, or that the parent organization has already established as a convention. As with most methods and formats in requirements, it is a good idea for an organization or business analysis department to adopt one or more standard convention for designating requirements if none have been chosen. This will ensure that programmers, engineers, and database analysts are able to get in the habit of understanding requirements prioritization at a glance. In addition to some of the specific the designations that go along with the methods described above, a few designation ideas that writers have suggested include:

High, medium, low¹⁹
Essential, conditional, optional²⁰
Numerical or scale ratings^{21 22}

These designations may be headers for sections so that all requirements under one section would have that designation. Or, requirements may be placed in some other order that follows an organization’s conventions, and the designation may be placed next to each requirement. Either method will assist engineers and developers in knowing which pieces of the project deserve the highest priority and therefore the most of their attention.

References for Further Study

For a more detailed study into prioritizing requirements, please refer to:

BABOK Guide 2.0, available for ordering here:http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge (Note that the BABOK Guide covers not only elicitation but is a thorough reference to all aspects of business analysis.)
http://www.slideshare.net/pvanabbema/organizing-and-prioritizing-requirements
Hass, Kathleen B. et al. Getting It Right: Business Requirement Analysis Tools and Techniques. (This book includes the chapter Transitioning from Elicitation, which covers Review and Refine Existing Requirements Documentation). Available for ordering at http://www.amazon.com/Getting-Right-Business-Requirement-Techniques/dp/1567262112/ref=sr_1_1?ie=UTF8&s=books&qid=1262788438&sr=8-1#noop.
“First Things First: Prioritizing Requirements” by Karl E. Wiegers. Software Development, September 1999. http://www.processimpact.com/articles/prioritizing.html

²“First Things First: Prioritizing Requirements,” by Karl E. Weigers. Software Development, September 1999. http://www.processimpact.com/articles/prioritizing.html

³“Prioritizing Requirements” by Donald Firesmith. Journal of Object Technology, vol. 3, no. 8, September-October 2004. http://www.jot.fm/issues/issue_2004_09/column4/

⁴“Practical Steps for Project Managers to Prioritize Requirements Using ROI,” Accompa, 2010. http://www.accompa.com/product-management-blog/2008/06/24/practical-steps-for-product-managers-to-prioritize-requirements-using-roi/

⁶“Requirements Prioritization Introduction,” by Nancy Meade. Carnegie Mellon University, 2008. https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements/545-BSI.html

⁷“Prioritizing Software Requirements with Kano Analysis,” by Scott Sehlhorst. Pragmatic Marketing, 2010. http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss

⁸“Prioritizing Requirements,” Larimar Consulting. http://blog.larimarconsulting.com/2009/12/prioritizing-requirements/

⁹“Requirements Prioritization Introduction,” by Nancy Meade. Carnegie Mellon University, 2008. https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements/545-BSI.html

¹⁰Ibid.

¹¹Ibid.

¹²Ibid.

¹³Ibid.

¹⁴Ibid.

¹⁵Ibid.

¹⁶Ibid.

¹⁷“Web service programming tips and tricks: Prioritize Your System’s Requirements,” by Scott W. Amber. http://www.ibm.com/developerworks/webservices/library/ws-tip-reqs.html#h3

¹⁸ “First Things First: Prioritizing Requirements,” by Karl E. Weigers. Software Development, 1999. http://www.processimpact.com/articles/prioritizing.html

²⁰Ibid.

²¹http://74.125.47.132/search?q=cache:y0qBlvAesFoJ:www.processimpact.com/process_assets/requirements_prioritization_worksheet.xls+requirements+prioritization&cd=2&hl=en&ct=clnk&gl=us

²² “Prioritizing Requirements,” by Donald Firesmith. Journal of Object Technology, vol. 3, no. 8, September-October 2004, pp. 35-47. http://www.jot.fm/issues/issue_2004_09/column4/