Special Reports

Identify the System's Highest Priorities

Determining the priorities of one software feature over another can be difficult. Here's how to tackle that challenge.

• By Rob Keefer
• 06/01/2006

Identify the System's Highest Priorities
Working with users on requirements analysis can be difficult. Here are some ways to tackle that challenge.
by Rob Keefer

June 1, 2006

In the summer of 2005, engineering students across the country raced solar-powered cars for the North American Solar Challenge competition. Participants in this event designed, built, and raced a solar-powered car 2,500 miles from Austin, Texas to Calgary, Alberta.

A minimum set of requirements for this car would be the power system (solar panels, motor, and so on) and a maneuvering system (accelerating, steering, and stopping). Each of these systems might be complex in its own right, and getting them all to work together is an even greater challenge.

Generally, software systems also contain complex subsystems. Many techniques have been developed to gather, organize, and trace requirements of software systems. Often, however, technical leaders on software projects struggle to determine which subsystems to build first.

To build a solar-powered car, the essential requirement is the power system. There is no need for a maneuvering system until the car can move. However, the power system needs to be able to support the weight, friction, and other constraints that the maneuvering system places on the car. Therefore, at the beginning of the project, the engineering team must consider the maneuvering system, but its focus should be on the power system.

Unfortunately, the highest priorities of software systems are often not as clearly defined. A software development team can employ a few techniques to begin to identify the highest priorities of a system.

1. Focus on what makes the system functional. At the beginning of a project, the development team needs to determine the essential requirements of the system and focus on the most important portions of those requirements. For example, to build the car's maneuvering system, an engineering team should work on the 'accelerate' requirement first because the steering and breaking requirements are not relevant until the car is moving.
2. Focus on what makes the system useful. Once the team has created a functional system, it can begin to focus on portions of the system that enable it to be used. Continuing with the maneuvering system analogy, once the car can move forward, it is functional as a car but not very useful. The car actually becomes useful when you add a steering mechanism and brakes.
3. Focus on what makes the system pleasurable. Finally, the development team can focus on the features that make the product something people want to use. Completing the maneuvering system analogy, a solar-powered car that can go forward, be directed, and be stopped is functional and might be useful, but it won't gain many adopters until it can back up, too.

At each stage of requirements analysis, developers need to be able to communicate the amount of effort it takes to implement a feature that satisfies a requirement, and need to understand the importance of that feature to the customers. One useful technique is to have the customers buy features with play money (poker chips work, too).

After the requirements have been defined:

1. Have the development team assign dollar amounts to each feature. The dollar amount is based on the amount of effort the team thinks it would take to build the feature. A one-day feature might be assigned $5; a one-week feature, $50; and a two-week feature, $250.
2. Next, the development team should estimate how much work it can accomplish given a set amount of time (for example, five person-months over the next 30 days). Then the team should translate the amount of work into a dollar amount (say one person-month is $500, so the team has $2,500 worth of work it can sell).
3. Give the customers this predetermined amount of play money and allow them to purchase the features most important to them. This forces the customers to make the difficult decisions on how they want to spend their money, and provides a tangible demonstration of what they are asking the development team to do.
4. When the money runs out, the development team knows exactly which features it needs to focus on. Upon completion of the purchased features, the development team and the customers should get together and play the game again.

As the game is played, the development team might ask the customers questions to help determine the value of a certain feature. For example, "If we implement that feature, how will that help the system?" or "Why should we implement feature X before feature Y? Is X really more valuable?" This prompting can help customers through this difficult and somewhat painful process of determining the priorities of one feature over another.

By playing the money game at each stage of requirements analysis (functional, usable, and pleasurable), the development team can be sure it's adding the most value to the system under construction. If the project is canceled or some other change in the organization occurs, the development of the system might not be a complete waste because the team added the most valuable features first.

The priority of requirements in a software system might be more difficult to understand than those of a solar-powered car, but developers can apply techniques that help determine the relative importance of those requirements.

About the Author
Rob Keefer is the director of the Agile Development Center at Strategic Data Systems in Dayton, Ohio. In this role, he has architected and led the development of a number of software systems. Rob has also written a number of articles, and frequently speaks on the topics of agile software development, software architecture, and user-centered design.