One of the major causes of system-development problems and failure is the omission of important requirements or the inclusion of unreasonably rigid requirements. Requirements errors are a primary factor behind most rework efforts, which according to industry statistics, can add up to 40 percent of the total development effort within a given project. It is almost certain that these requirements shortcomings are manifested as stakeholder dissatisfaction with the delivered system, resulting from failure to capture many of the "real" requirements.
These problems are partially caused by the absence of a systematic process to relate requirements to business goals either of the developer or the acquirer of the system.
The Pedigreed Attribute eLicitation Method (PALM) is a method that elicits and relates important requirements to business goals. PALM also captures the business goals for an organization that lie behind the development of a software-reliant system. These business goals, often poorly understood and poorly articulated, serve as the foundation for many of the quality attribute and behavioral requirements for a system.
A comprehensive list of potential business goals is used as the starting point for the elicitation. This reduces the likelihood that important requirements will be omitted. While doing the elicitation, the source and rationale for the requirements are captured as a pedigree. This pedigree reduces the likelihood of having unreasonably rigid requirements. The output of PALM is a collection of important requirements tied to the business goals that they support where the requirements have a pedigree.
PALM utilizes a comprehensive catalog of business goals derived from many years of academic study of organizations. It uses this catalog to elicit the specific goals for the system being developed. How these specific goals may change in light of changes in technology or the legal, social, business, or customer environments is also elicited. Finally, requirements for quality attributes such as security, performance, availability, usability, and modifiability are elicited and tied to how they support the specific product goals and their future evolution.
For example, if your system requires a transaction turnaround time of 0.2 seconds, can you say why it's 0.2 and not 0.3 or 0.1? Perhaps it's 0.2 seconds because a business goal is to beat your competitor's product that has a transaction time of 0.25 seconds. Now suppose the competition releases a faster version. If you didn't capture the business goal hiding behind the requirement, then your system's architect won't know that that your product needs an even faster time. The business goal will have been sacrificed because the requirement's pedigree wasn't captured.
The figure below illustrates the relationship between business goals and architecture. Some business goals lead to quality attribute requirements, as in the example above. A more usual example is a business goal to capture market share by providing best-of-breed quality in a domain. Other business goals might affect an architecture directly. For example, a business goal to make use of the development staff's current knowledge and training might lead the architect to choose a familiar technology over an unfamiliar one. On the other hand, a business goal to expand the staff's knowledge in an up-and-coming technology might lead to the opposite decision. Business goals that influence architectures are shown with sold lines in the figure.
Still other business goals don't affect the architecture at all. A goal to save cost might be met by lowering the thermostats in winter and making sure the last person to leave turns off the lights.
To build PALM, we surveyed the business literature and captured hundreds of business goals cited as influencing products. We clustered these into 11 categories of “standard” business goals, for example “growth and continuity of the organization,” “managing market position,” and “meeting responsibility towards society.”
We also produced a scenario format for systematically and consistently capturing a business goal. Parts of the scenario include the subject, object, environment, measure, pedigree, and change factors for the goal. Finally, we use the goals to vet the driving architectural requirements in play for the system being developed. For each driver, we ask what business goal it supports. For each goal, we ask what architectural drivers might help achieve it.
An exercise dedicated to eliciting business goals using PALM can be carried out in a day and a half. PALM can also be combined with the SEI’s architecture evaluation methods such as the Architecture Tradeoff Analysis Method (ATAM), as well as the Quality Attribute Workshop (QAW).
PALM takes place in a workshop format where representatives for the business-development, financial-support, and technical-development aspects of the product being constructed participate. This workshop is facilitated by SEI personnel who will perform the actual elicitation. PALM comprises the following steps:
Benefits of using PALM include
PALM's primary purpose is to produce higher-quality architectures with less rework, fewer unpleasant surprises, and more reliable achievement of cost and schedule goals. The primary beneficiary is the architect, but better architectures benefit a wide variety of stakeholders, including customers, managers, developers, testers, users, and acquirers.
SEI staff are available to conduct a QAW for your organization. Contact us using the link in the For more information box at the bottom of this page.
Relating Business Goals to Architecturally Significant Requirements for Software Systems, Paul C. Clements & Len Bass