email article printer friendly

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).