Practice 10. Prioritize Requirements for Implementation

Bruce MacIsaac

Prioritize requirements to deliver value and drive down risks.

Problem

How do you decide what requirements to develop next? The right choices help you to maximize value to stakeholders and the business while balancing technical and business needs. Poor choices can lead you to deliver capabilities that aren't used or to identify problems late in the project that result in delays and even project failure.

This practice describes how to make choices that deliver value and drive down risks, while building a system that can evolve.

Figure 4.11. Decide What to Build First.

Poor choices can result in delays and even project failure.

Background

To identify and prioritize requirements for development, you should understand how requirements are classified.

Classifying Requirements

Classifying requirements into different categories helps developers and analysts to reason about requirements. One popular classification scheme is called FURPS+,^[17] an acronym for functionality, usability, reliability, performance, and supportability, with the "plus" referring to design, implementation, interface, physical, and other constraints (see Figure 4.12).

^[17] Grady 1997.

Figure 4.12. FURPS+ Classification Scheme.

People think mainly about the functional requirements. Recognizing the kinds of supporting requirements helps to identify and prioritize requirements.

Here are some examples of different kinds of requirements for an automated banking machine:

• Functionality: A customer shall be able to withdraw cash.

• Usability: 95 percent of customers shall be able to use the machine successfully without help or training.

• Reliability: Average system down time shall be under 1 hour per week.

• Performance: No system action shall take longer than 3 seconds to complete.

• Supportability: The software shall be upgradeable remotely.

• Design constraint: The software shall use a relational database.

• Implementation constraint: The software shall be implemented in Java.

• Interface constraint: The software shall interface to the credit processing system using the existing message queues.

• Physical constraint: The software shall require no more than 100MB of memory and no more than 10GB of disk space.

Analysts and developers use these categories to help ensure that all different kinds of requirements have been considered, and to prioritize categories of requirements.

Applying the Practice

To apply this practice, you should understand the stakeholders and project dynamics and assign roles to advocate for key goals, such as business value, quality, and technical feasibility. As you identify and clarify requirements, you can capture requirements attributes. These in turn help you to identify and prioritize scenarios and to group them into deliverable increments.

Understand Stakeholders and Project Dynamics

Before you can prioritize requirements, you need to understand the goals of your stakeholders and how they measure success.

Project Sponsors

Usually, one or more project sponsors pay the bills. What a sponsor values can differ from project to project. Sometimes the greatest value is placed on delivering usable functionality as early as possible, even if this means significant rework downstream. Other times, reducing overall long-term costs, or delivering high quality, are given higher priority. One sponsor may be interested in generating market interest by demonstrating prototypes of "sexy" features, while another may want to drive down key technical risks, such as performance and throughput.

When stakeholders have competing priorities, it is the project sponsor's overall goals that determine which take precedence. The project sponsor is thus the most important stakeholder. Nevertheless, he or she is usually driven by the needs of other stakeholders.

The project sponsor's overall goals determine which requirements take precedence.

Customers

The customer is the key stakeholder that the project sponsor needs to satisfy (and may even be the project sponsor). A customer is someone involved in the decision to acquire a product. A successful product must have customers, so customer needs are paramount. While some customers may be users, others are decision makers in management or procurement departments.

Users

The user is the key stakeholder that customers need to satisfy (and frequently is the customer). Customers frequently define success in terms of user success.

Other Stakeholders

There are many other stakeholders, including testers, trainers, installers, and so on in both customer and development organizations. Understanding the goals of these stakeholders helps you to understand the value of each requirement and to communicate that value to project sponsors.

Understand stakeholder goals to determine the value of requirements.

Taking the time to identify each of the stakeholders, their goals, and their success criteria for the project provides the context for prioritizing requirements.

Assign Roles to Advocate for Key Goals

Usually the sponsor wants everythingearly delivery of high-value, "sexy" features, minimum overall costs and risks, and high quality. The key is to achieve the right balance.

One way to achieve balance is to ensure that each goal in a project has an advocate. The legal system achieves balance by having a prosecutor and a defense attorney. On a software project, you achieve balance by ensuring that you have advocates for customer and business value (a customer or analyst), driving down technical risk (an architect), and ensuring quality (testers). A project manager can then balance the inputs from these advocates and manage the project on a daily basis in accordance with the goals of the project sponsors.

Figure 4.13. Balance Priorities.

The project manager balances inputs from key advocates to decide on prioritization.

Identify and Clarify Requirements

Before prioritizing requirements, you must first understand them, clarify those that are poorly understood, and challenge those that are risky.

Identify Key Functionality

Showing, rather than telling, ensures understanding.

A solid understanding of key functionality is needed to build a system that meets user needs. So how do you achieve such an understanding? Practice 9: Describe Requirements from the User Perspective is important, because it helps you identify the use cases and scenarios. The relative value of each use case can be assessed to identify core capabilities. Whenever possible, involve real users to ensure that prioritization reflects their needs. Iterative development is also key; it allows you to implement key parts of the working system and ask, "Is this what you meant?" rather than spending vast amounts of time creating ever thicker and more detailed specifications. Showing, rather than telling, ensures understanding.

Identify Supporting Requirements

So far the focus has been on the core functionality. You also want to ensure that you have identified all the other requirements that are importantthe URPS+ in FURPS+.

You can use categories and examples of supporting requirements (sometimes called technical, nonfunctional, quality, or supplemental requirements^[18]) as a checklist to verify if you have a requirement in a particular category.

^[18] Supporting requirement is a broader term than nonfunctional requirement. Many supporting requirements, such as requirements for logging and accessibility, are functional requirements that support major use cases, but are typically not themselves expressed as use cases.

But how do you come up with a complete set of candidate-supporting requirements? RUP's template and examples of "Supplementary Specifications" are a good starting point. Here are some other sources:

• Eeles 2004 provides a questionnaire that lists a large number of requirements types, along with questions for determining their applicability.

• The Software Engineering Institute has created a catalogue of "general scenarios"expressions of quality attribute requirementswhich can be reused across many different kinds of systems to define quality requirements.^[19]

  ^[19] See Bass 2003 and http://www.sei.cmu.edu/publications/documents/01.reports/01tr014.html.

Clarify and Stabilize Significant Requirements

Significant requirements that are poorly understood or likely to change should be prioritized for clarification and stabilization. This step is particularly important if those requirements affect core functionality, are architecturally significant, or have a major impact on effort estimates. In some cases it means that you should conduct further requirements analysis before implementing the requirement. In other cases some form of prototyping may work best.

Challenge Risky Requirements

I recall a project with a performance requirement to display radar data within a fixed response time. When the software was completed, measurements showed that the response time was almost 10 times the specified limit. The money was spent, and the project was supposedly complete, but an essential requirement had not been achieved. The project manager had few options. He directed the developers to fix the problem, and after much effort and expense, the response time was improved to about twice the required amount. No further improvement was possible, and the project manager prepared for a tense meeting with the prime contractor. Luckily, there was a happy ending: the prime contractor admitted having overstated the requirement, and the achieved performance level was better than actually required.

But there could easily have been a less nail-biting ending. The infeasibility of this requirement could have been demonstrated early in the project, before all the money was spent and the project manager had so few options. More important, someone could have challenged the requirement itself up front by asking, "Why is such a tight response time required?" Far less effort and expense would then have been spent on unnecessary optimization.

Identify and Prioritize Scenarios

Earlier we described the importance of identifying and prioritizing key functionality, best expressed as use cases. However, a complete use case often contains a lot of functionality. To demonstrate value, drive down risk, and get early feedback, you should typically deliver a subset of functionality, rather than complete use cases. The best way to express this subset is as a scenario, that is, a single path through one or more use cases, or sometimes even a subset of a scenario; see Practice 9: Describe the Requirements from the User Perspective for more information.

The basic scenarios of core functionality are a good place to start. Start with the basic "happy path," the most straightforward set of steps when everything goes right, while deferring alternative flows, variations of user input, and error condition checking until later. These will typically require many fundamental components and uncover patterns, because end-to-end scenarios usually involve all layers of the systemincluding user interface, business logic components, and infrastructure mechanisms such as data persistency and interprocess communication. These can often be used to assess nonfunctional requirements. For example, once a basic scenario has been implemented, measuring the performance of that scenario can identify problems or build confidence in the system's performance. And of course, core functionality is useful for getting early user feedback.

Take the air traffic control system use case "File a flight plan." A flight plan identifies an aircraft, when it is leaving, where it is leaving from, where it is going, and the trajectory it plans to follow. There are many kinds and formats of flight plans and countless types of trajectory, including blocking out chunks of airspace, formations with other aircraft, use of various kinds of distance and bearing beacons, and even uncontrolled ("I'm going to fly around and have fun"). Implementing this use case is a huge effort. So what should you focus on first?

Start with the simplest, most essential scenario and build up from there.

The answer is to start with the simplest, most essential scenario and build up from there. In this case the simplest scenario is to file a flight plan direct from point A to point B, specified as latitude and longitude. This scenario represents a fraction of the required logic for the use case, but by implementing it you achieve certain goals:

• You demonstrate the process by which flight plans are created and enable early user feedback on this process.

• You design and implement key elements of the system:

  - Trajectories and points on the earth's surface

  - Flight plans

  - User interface forms and dialogs

  - Supporting infrastructure (mechanisms such as interprocess communications, data distribution, and so on)

• You can measure system loading and response times for this scenario and determine if the architecture is likely to scale to meet these and other supporting requirements.

Additional scenarios are implemented based on stakeholder priorities.

Such a basic scenario is suitable for a first iteration. Additional scenarios are implemented based on stakeholder priorities. The following could be some competing priorities:

• Time to market of key features.

• Minimum overall cost and risk.

• Demonstration of "sexy" technical features to attract early adopters or keep sponsors interested.

If your main goal is to minimize cost and risk, you would typically add scenarios that establish the architecturein particular, scenarios that demonstrate component integration, key patterns, and quality attributes. For example:

• Implementing the main path of the most commonly executed use case is often enough to test system performance under expected load conditions.

• Establishing a pattern for using a logging mechanism is more important than completing functionality to produce nicely formatted log reports.

• Implementing a skeleton of the user interface for a few key scenarios may be enough to validate that the system is sufficiently usable.

• Risks with using a new technology can be addressed by building a part of the system that uses that technology.

Capture Requirement Attributes

At the most basic level, you could simply compile the use cases and nonfunctional requirements into a list and use that as a basis for planning. You could then describe what will be implemented in each iteration and supplement this with text detailing how much of each use case is to be implemented and what risks are to be mitigated.

In larger projects, trade-offs are facilitated by recording and reviewing requirements attributes. A spreadsheet, database, or requirements management tool can be used for this purpose.

In larger projects, trade-offs are facilitated by recording and reviewing requirements attributes.

We have found the following requirements attributes useful for prioritization.

• Benefit: Importance to stakeholders. Any ordered rating system will work. However, you should reserve the highest benefit rating for critical requirements, that is, those that are the reason the system is being developed, and without which the system serves no useful purpose. Lower ratings are relative to one another and are used (with other attributes) to decide which requirements should be considered for de-scoping.

• Effort: Estimated effort. You can use a numeric rating such as "effort days" or categories, for example: Low = < 5 days, Medium = 520 days, High = >20 days. In defining effort, you should decide which overheads (management effort, test effort, requirements effort, and so on) are included in the estimate.

• Architectural impact: Indicates how this requirement will impact the software architecture, for example:

  - None. Fits within the existing architecture.
  
  

  - Extends. Requires extension of the existing architecture.
  
  

  - Modifies. Requires changes to the existing architecture to accommodate the requirement.
  
  

• Stability: Likelihood that this requirement will remain unchanged and that the development teams' understanding of the requirement will also remain unchanged. You can use a similar categorization system: Low = <10%, Medium = 1050%, High = >50%.

• Risk: Percentage likelihood that implementation of the requirement will encounter significant undesirable events such as schedule slippage, cost overrun, or cancellation. Again, you could use categories: Low = <10%, Medium = 1050%, High = >50%.

  Alternatively, you can fold risk into the "architectural impact" described earlier, marking risky requirements as potentially extending the architecture.

These attributes help you to make good decisions about prioritizing requirements. To drive down risks, you prioritize high-risk requirements that affect the architecture, stabilizing unstable requirements as needed. To deliver value, you prioritize high-benefit, low-effort requirements and de-scope low-benefit use cases with high effort or high risk.

The most difficult decisions you have to make are when prioritizing high-benefit requirements against lower-benefit requirements that have high risk or that affect the architecture. Prioritization is ultimately a business decision, so if delivering early value is paramount (such as when showing off features to generate customer interest), you may choose to prioritize high-benefit requirements. If minimizing overall cost and risk is paramount, then you may implement architectural and risky requirements first.

One balanced approach is to prioritize architectural and risky requirements that are critical for a minimal release, ignoring requirements that could be deferred or dropped. This approach avoids investing in requirements that may not be needed or may change and speeds up completion of a minimal release, which in turn allows earlier user feedback. The architect should still consider likely changes (as described in Practice 16: Architect with Components and Services) to guide the selection of architectural choices, but implementation is limited to what is needed.

Additional Notes

There may be two use cases that use the same components and address similar risks. If you implement A first, B is no longer architecturally significant. If you implement B first, A is no longer architecturally significant. Similarly, the effort to implement a requirement depends on how much supporting infrastructure is in place. In general, therefore, the requirements attributes can depend on the iteration order and should be reevaluated when the ordering changes, as well as when the requirements themselves change.

Managing attributes of every statement within a use case is time-consuming. Instead, start with attributes at the use-case level, and if more than just the "happy path" is critical, add a note to explain what is critical. Notes don't scale, so for complex use cases you may wish to be specific about which parts of the use case (alternative flows, conditions, or special requirements) are critical and architecturally significant. You can do this by adding attributes to requirements within the use case and prioritizing accordingly. This level of management works best if supported by a requirements management tool.

Identify and Prioritize Deliverable Increments

In larger systems the number of scenarios can become large, and the interdependencies can be hard to follow. When planning iterations, it is best to think in terms of increments of deliverable functionality. Start by identifying the minimum functionality for a first usable release. Then identify additional minimum chunks of functionality that are worth delivering in a subsequent release. This sequence of releasable functionality provides a framework around which you can plan your iterations.

Start with the minimum functionality for a first usable release; then add functionality for subsequent releases.

Denne 2004 describes deliverable chunks as Minimum Marketable Features (MMFs). "Marketable" implies that the chunk of functionality stands on its own, delivering significant value to the customer, whereas "minimum" ensures that you focus on the minimum functionality that delivers that value.

Identifying MMFs can be done "top down" from the features described in the initial project vision or "bottom up" by grouping individual scenarios or subscenarios. Once requirements have been grouped into MMFs, you can prioritize and manage each MMF, rather than the individual scenarios or subscenarios it comprises. This can simplify requirements management and project planning. However, when the MMF spans iterations, as is often the case in early iterations while the architecture is being established, you will still have to prioritize parts of the MMF to implement in each iteration.

Denne 2004 also recommends separately identifying and prioritizing elements of the architecture, based on which MMFs require which elements. This can make it easier to reason about the priority and value provided by underlying architecture elements.

Other Methods

Traditional waterfall development details all the requirements, and then all the design, before implementing and testing. It is difficult to deliver a valuable subset of functionality, and there is no opportunity to improve the requirements and design based on experience gained from implementation and testing.

Unified Process and other iterative methods value incremental delivery of functionality, based on prioritized requirements. There are some differences in how prioritization is done, however. XP recommends that developers identify and communicate risks, but that the Customer decides which user stories are built first.^[20] In Scrum the Product Owner represents project stakeholders and prioritizes requirements.^[21] In RUP the System Analyst prioritizes by customer and business value, the Software Architect prioritizes by architectural value, and the Project Manager balances competing concerns and makes business decisions to satisfy the project sponsors.

^[20] 20 Beck 2001.

^[21] Schwaber 2004.

In practice, if there is good communication between the team and customer representatives, the same result is achieved. However, in RUP and OpenUP/Basic, the architect explicitly works out a proposed order of implementation to drive down technical risk. When scaled up for larger projects, Scrum includes an architectural prioritization approach similar to the Unified Process.^[22] In contrast to both the Unified Process and Scrum, XP is much looserthere is no explicit architectural prioritization.

^[22] Schwaber (2004) refers to this process as "staging."

Note that architectural prioritization need not compete with customer prioritization. The customer (or customer advocate) typically defines a minimum set of requirements for a first release. Supporting that minimum set takes a few iterations and requires much of the architecture. The role of the architect in this case is typically to prioritize work further for iterations leading up to that first usable release. If the architect wishes to add other work to drive down risk, then the project manager works with the various stakeholders to reach the right business decision.

Levels of Adoption

This practice can be adopted at different levels:

• Basic. Prioritize essential functionality for implementation.

  This allows early delivery of useful functionality and early user feedback, and generally speeds development.

• Intermediate. Balance priorities of architecturally significant requirements and requirements with high business and customer value.

  Establishing the architecture early allows developers to work in parallel in successive iterations, fleshing out the skeleton already established. Parallel work enables shorter iterations.

• Advanced. Systematically capture all relevant categories of requirements and the various attributes that contribute to prioritizing requirements.

  Managing a large set of requirements systematically requires time, effort, and discipline. Such investments are usually associated with larger projects, and the additional work usually requires longer iterations.

Related Practices

• Practice 1: Manage Risk emphasizes that risks are a major factor in selecting scenarios for implementation and recommends implementing the riskiest scenarios first.

• Practice 2: Execute Your Project in Iterations allows you to use iterative development to implement key parts of the working system, based on prioritized requirements.

• Practice 9: Describe Requirements from the User Perspective is key to developing an understanding of core functionality because of its focus on providing significant value. The use cases developed with this practice are the basis for the scenarios that demonstrate the architecture, in particular those that demonstrate key patterns and component interactions.

Additional Information

Information in the Unified Process

OpenUP/Basic describes a basic requirements prioritization approach suited to small projects, similar to that described in this practice. RUP adds additional guidance needed for larger and more specialized projects, including traceability and requirements management guidance. This additional guidance becomes particularly important when requirements involve more than one team or organizationfor example, when subprojects, reuse, product line engineering, and subcontracting are involved.

Additional Reading

For guidance on managing requirements, see the following:

Dean Leffingwell and Don Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000.

Kurt Bittner and Ian Spence. Use Case Modeling. Addison-Wesley, 2002.

For guidance on scheduling functional increments using business value, see the following:

Mark Denne and Jane Cleland-Huang. Software by Numbers. Prentice Hall, 2004.

For more on architectural requirements, see the following:

Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice, Second Edition. Addison-Wesley, 2003.

Peter Eeles. "Capturing Architectural Requirements." The Rational Edge, April 2004. http://www.ibm.com/developerworks/rational/library/4706.html.