First Things First: Prioritizing Requirements 1

1 Copyright 1999 by Karl E. WiegersFirst Things First : Prioritizing Requirements1 Karl E. WiegersProcess are never thrilled to find out they can t get all the features they want in of a new software product (at least, not if they want the features to work). However, if thedevelopment team cannot deliver every requirement by the scheduled initial delivery date, theproject stakeholders must agree on which subset to implement First . Any project with resourcelimitations has to establish the relative priorities of the requested features, use cases, or functionalrequirements.

2 Prioritization helps the project manager resolve conflicts, plan for staged deliveries,and make the necessary trade-off Prioritize Requirements ?One characteristic of excellent Requirements is that they are explicitly prioritized. Whencustomer expectations are high, timelines are short, and resources are limited, you want to makesure the product contains the most essential functions. Establishing each chunk of functionality srelative importance lets you sequence construction to provide the greatest product value at thelowest cost. Customers and developers must collaborate on Requirements do not always know which Requirements are most important to the customers, andcustomers cannot judge the cost and technical difficulty associated with specific project manager has to balance the project scope against the constraints of schedule,budget, staff resources, and quality goals.

3 One balancing strategy is to drop or defer low priorityrequirements to a later release when you accept new, higher priority Requirements or other projectconditions change. If customers don t differentiate their Requirements by importance and urgency,the project manager must make these trade-off decisions. Because customers may not agree withthe project manager s decisions, they must indicate which Requirements are critical and which canwait. Establish priorities early in the project, while you have more options available for achievinga successful project s difficult enough to get one customer to decide which of his or her Requirements aremost important; gaining agreement among multiple customers with diverse expectations is evenmore challenging.

4 People naturally have their own interests at heart and they aren t always willingto compromise their needs for someone else s benefit. However, making such priority decisions isone of the customer s responsibilities in the customer-developer prioritize Requirements initially from the perspective of how valuable each oneis to them. Once a developer points out the cost, technical risk, or other trade-offs associated witha specific requirement, though, the customers might decide it isn t as essential as they developers might also determine that certain lower priority functions should be implementedearly on because of their impact on the product architecture.

5 When setting priorities, you need tobalance the business benefit that each function provides against its cost and any implications it hasfor the product s architectural foundation future evolution. 1 This paper was originally published in Software Development, September 1999. It is reprinted (withmodifications) with permission from Software Development Things FirstPage 2 Copyright 1999 by Karl E. WiegersGames People Play with PrioritiesThe knee-jerk response to a request for customers to set priorities is, I need all of thesefeatures.

6 Just make it happen somehow. This doesn t help. It can be difficult to persuadecustomers to set priorities if they know that you may never be implement lowpriorityrequirements. A developer once told me that priorities are unnecessary, because if wewrote something in the software Requirements specification (SRS), we intend to build , that doesn t consider the issue of when you should implement each may not wish to bother with priorities, because that conflicts with the we can do itall attitude they want to convey to their customers and reality is that some features are more essential than others.

7 This becomes apparentduring the all-too-common rapid descoping phase late in the project, when lower priorityfeatures are jettisoned to ensure the product is shipped on schedule. Setting priorities early in theproject helps you make those trade-off decisions along the way, rather than in emergency mode atthe end. Getting a feature half-developed before you determine that it s low priority is wastefuland left to their own devices, customers will set perhaps 85% of the Requirements at highpriority, 10% at medium, and 5% at low priority. This doesn t give the project manager much towork with.

8 Steve McConnell identified Requirements scrubbing eliminating those that are notessential and simplifying any that are unnecessarily complicated as a best practice for rapidsoftware development (see Rapid Development, Microsoft Press. 1996).On one project I know of, the management steering team became impatient when theanalyst insisted on Prioritizing the Requirements . The managers pointed out that they could oftendo without one feature, but another feature may need to be beefed up to make up for the omittedrequirements. They reasoned that if they deferred too many Requirements , the resulting systemwouldn t achieve the revenue that the business plan promised.

9 When you evaluate priorities, lookat the connections and interrelationships among different Requirements and their alignment withthe business ScalesA common approach to prioritization is to group Requirements into three prioritycategories. Table 1 shows two typical three-level scales. All such scales are subjective andimprecise, so everyone involved must agree on the meaning of each level in the scale they is a key attribute of each requirement that should be included in the SRS or requirementsdatabase. Establish a convention for your SRS so the reader knows whether the priority assignedto a higher-level requirement is inherited by all of its subordinate or derived Requirements , orwhether every individual requirement should have its own priority issue is the granularity at which you prioritize Requirements .

10 Even a medium-sizedproject can have hundreds or thousands of detailed functional Requirements , too many to classifyanalytically and consistently. You need to choose an appropriate level of abstraction for theprioritization. This could be at the use case level, the feature level, or the detailed functionalrequirement level, whichever makes logical sense for your Things FirstPage 3 Copyright 1999 by Karl E. WiegersTable Requirements prioritization mission critical requirement; required for next releasesupports necessary system operations; required eventually but could waituntil a later release if necessarya functional or quality enhancement.