Practice: Performance Requirements Cards

Practice Performance Requirements Cards

Objective

Performance requirements cards document the key operations and performance requirements of the product to be built.

Discussion

While some performance requirements could be defined on a feature card and others could be covered as acceptance tests on a feature card, there are many situations in which a distinct, and very visible, definition of performance and operational requirements is necessary. For example, myriad design decisionsin fact the major design decisionsin aircraft design revolve around weight. Weight isn't a function of a single feature, avionics or engines, but a property of the entire plane. Similarly, the expected load on an Internet site is a function of the site, not an individual feature. In these cases it would be inappropriate to have the performance requirement be an acceptance test for an individual feature, although in the case of aircraft design, each subsystem team is given a weight target. If subsystems are too heavy, teams must coordinate by trading weight credits and negotiating other performance criteria.

Performance cardswhich can have a different color than feature cardscontain the name , description, and quantitative performance goals of the product, as shown in Figure 6.3. A card might be labeled, say, "Database Size" or "Aircraft Weight Limit" or "Training Time." Teams should focus on those performance attributes that will drive the design process. For example, weight, payload, range, and speed are critical aircraft design parameters; each would have a performance card (obviously backed up by more extensive documentation). Performance cards should also contain acceptance testshow the team will demonstrate to the customer team that the product meets the performance criteria. These tests are essential when the performance criteria to be met involve critical real-world risks (e.g., planes falling out of the sky). Since some tests are very difficult to run until the product is fully built, creating interim tests (using simulations, prototypes , models, or historical calculations) should be considered .

Figure 6.3. Sample Performance Card

Some performance attributes can be derived from the guiding principles established during the Envision phase. Others are well known by engineers who work with specific products. In any case, while feature specifications tell the engineering team what to build, performance requirements often have more relevance to the design process itselfthey force design tradeoffs and often must be dealt with early in the project. They are a vital part of the information a product development team has to gather and analyze as it plans and implements features.