Requirements management made easy

REQUIREMENTS MANAGEMENT has been discussed for at least 15 years. As a discipline and as a practice, it has become more and more complex. We have lost sight of the fact that requirements management was created to simplify product development, to reduce its cost, and reduce the inherent risk associated with building systems and software. Instead, requirements management has become yet one more chore, one more error-prone activity.

Requirements are those externally observable characteristics of a system that a user, buyer, customer, or other stakeholder desires to have present in the system. Requirements management is the set of activities encompassing the collection, control, analysis, filtering, and documentation of a system's requirements. Requirements management consists of three activities:

Requirements elicitation is the art of understanding the needs of stakeholders, and collecting them in a repository for future analysis. The needs can be expressed quite abstractly and in terms of a problem; for example, “I want to reduce my billing error rates by at least 35 percent.” And the needs can be expressed quite specifically and in terms of a solution; for example, “I want there to be a large red button on the operator's console” In all cases, these needs are called features.

Requirements triage is the art of deciding which features are the appropriate features to include in the product. Rarely is it possible to satisfy every requested feature gathered from every stakeholder during the elicitation activity. Disparate priorities, limited resources, time-to-market demands, and risk intolerance are but a few of the reasons for this. Triage takes into considerations all the painful realities of the marketplace and makes the decision of which features we will build now, which will be built in the next release, and which will be deferred until even later.

Requirements specification is the art of detailing the exact external behavior of a system that will address the features selected during the triage process. The level of detail of these requirements depends greatly on the situation. For example, if specifying a hand-held remote mouse, it might be sufficient to state, “The system shall contain three programmable buttons, corresponding to the three buttons on a standard three-button mouse.” However, if the device were to be mounted in a holster and controlled by robotic fingers instead of being hand-held, then the statement of requirements for the buttons would need to be considerably more detailed.

According to the CHAOS Report of the Standish Group (see sidebar), 71 percent of all software development projects result in complete failure (that is, premature cancellation or shelfware upon completion). As reported by Capers Jones [Patterns of Software Systems Failure and Success, International Thomson Press, 1996] and Steve C. McConnell [Rapid Development: Taming Wild Software Schedules, Microsoft Press, 1996], poor requirements management is generally considered to be one of the major causes for product failure. After all, if we do a poor job of understanding our customers' needs, if we do a poor job of deciding the right features to build, and if we do a poor job of writing down what we think we want out of a system, how can we possibly expect a successful project? All the development techniques and tools and whatever level of process maturity you have achieved will be of no use to you if you are not building the “right” product.

Alan M. Davis is founder and president of Omni-Vista Inc., a Colorado corporation that helps companies prevent software disasters. He is a fellow of the IEEE and founder of the IEEE International Conferences of Requirements Engineering. He is also the author of Software Requirements: Objects, Functions and States [Prentice Hall] and 201 Principles of Software Development [McGraw Hill], and the editor for the Journal of Systems and Software and editor-in-chief emeritus of IEEE Software.

Ann S. Zweig is cofounder and vice president for product development at Omni-Vista Inc. She has 16 years experience working in the software and biology industries, and has led her company's development team to six on-time, within-budget product deliveries.

Requirements Elicitation. Requirements elicitation is the art of determining all possible features that you might want to include in your next product. This is the time to be broad and inclusive. The candidates may come from potential customers, existing customers, customers of customers, users, marketing, sales win/loss reports, change requests, trouble reports, features rejected from earlier releases, internal development personnel, manufacturing, customer support personnel, inventors/innovators within the company, management, and so on. We will use the term stakeholder to identify any of these sources of candidate features.

The techniques of requirements elicitation vary considerably depending on the specific situation. For example, if you have identified a set of key stakeholders that are committed to mutual success and are willing to help you help them, you might seriously consider facilitated group sessions (brainstorming). To conduct one of these sessions, assemble key stakeholders in a room with plenty of wall space. Announce the purpose of the meeting: to learn potential features for version x of product y. Advise participants that the goal is to synthesize the largest possible list of candidate features. To do so, participants should encourage each other as much as possible, and not criticize any idea. In many cases the seemingly most outrageous idea can become the catalyst for the creation of the best ideas.

For another approach, especially useful when you are unable to isolate such stakeholders in one place, you might consider an analysis of needs, pains, and solutions in Michael T. Bosworth's Solution Selling: Creating Buyers in Difficult Selling Markets [McGraw-Hill Professional Publishing, 1995]. In this approach, the target customers are analyzed in detail. Their activities are modeled, their pains identified, the impacts of those pains explored, current solutions to those pains delineated, and the features that could alleviate those pains most effectively are listed. Obviously, the more information you can gather from “real” potential customers the better. But in any case, the idea of deriving candidate features from a thorough understanding of customers and their pains is difficult to argue with.

Other elicitation techniques include interviewing, as explored by Donald C. Gause and Gerald M. Weinberg [Exploring Requirements: Quality Before Design, Dorset House, 1989]; ethnomethodologic studies, as explored by Marina Jirotka, Joseph Goguen, and Mathew Bicketon (editors) [Requirements Engineering: Social and Technical Issues (Computers and People), Academic Press, 1994]; surveys; and requirements workshops, as explored by Dean Leffingwell, Don Widrig, and Edward Yourdon [Managing Software Requirements: A Unified Approach (The Addison-Wesley Object Technology Series), Addison-Wesley Publishing Co., 1999].

Interviewing is ideal when you have identified a reasonable-sized set of representative stakeholders and it is feasible to meet them each individually. It is also helpful when competitive, logistic, or political issues make it impractical to gather stakeholders in one place for brainstorming. Ethnomethodological studies try to eliminate preconceived notions of problems and solutions to those problems. The objective third-party observer in these studies eliminates the bias inherent in interviewing and brainstorming. Surveys work especially well when the population of representative stakeholders is too large to assemble in one place or too large to be interviewed. However, they only work well when you have very specific questions that you want answered. They eliminate the spontaneity inherent in interviews or brainstorming Requirements workshops are a special case of brainstorming.

Tools are available to assist in a variety of elicitation techniques For example, computer-assisted cooperative work (CSCW) tools can facilitate brainstorming sessions whether the stakeholders are co-located or are physically distributed [Kathy Spurr, Paul Layzell, Leslie Jennison, and Neil Richards, Computer Support for Co-operative Work, John Wiley & Sons, 1994] and tools such as those provided by GroupSystems.com (see sidebar). Forms such as Bosworth's pain sheet (while not automated, to our knowledge) can be used easily to organize and analyze pains, impacts, competition, and remedies. Online polling tools such as those by VantageNet (see sidebar) can gather opinions of many stakeholders and be useful aids to performing surveys.

Requirements elicitation is the most difficult of the three requirements management activities because you are creating something from nothing.

The result of elicitation is a list of candidate features, each annotated with relative technical risk, an estimate of effort required to address the feature, and a relative priority or measure of importance from the customers' perspective. Tools exist to record this result. These range from basic tools such as word processors, spreadsheets, and databases, to simple requirements-specific repositories such as those by Omni-Vista, to more complex requirements management tools such as those by Rational, QSS, and Technology Builders Inc. (See sidebar to find out where to learn more about these tools.)

Requirements Triage. Requirements triage is the process of deciding precisely which product is to be built.

From a purely development manager's perspective, triage is quite simple. Development managers estimate the effort and time required to satisfy the stated features. They compare these with the budgets and schedules given to them. If they are not compatible, the development manager simply removes features until the work involved is compatible with the given schedule and budget! Presto! Triage is complete. Just one problem, however: removing features may have a positive affect on development risk, but this logic completely ignores impacts on market, price, revenue, and profit. See Donald Reinertsen's Managing the Design Factory: The Product Developer's Toolkit [Free Press, 1997] for a discussion of this phenomenon. Thus, requirements triage must consider marketing, financial, and development factors.

The goal of requirements triage is quite straightforward:

■ A set of features

■ Which can be implemented using available resources and with acceptable levels of risk

■ Which can be sold at an acceptable price to a known market

■ In sufficient quantities to achieve

■ Acceptable levels of revenue and profit

■ And thus achieve a reasonable return on investment.

You will note that the naive development manager's view of triage previously explained considers only the first two bullets.

These variables are at the disposal of the team performing triage:

■ Add, delete, or change a feature

■ Make the delivery date earlier or later

■ Increase or decrease the resources applied to development

■ Increase or decrease the price

■ Increase or decrease costs of goods sold

■ Increase or decrease the resources devoted to marketing and sales.

Triage, then, is the process of altering assumptions about these six variables until the results are acceptable. Once you arrive at an acceptable set of values for the variables, most companies produce a product plan. A product plan (also called a “business case”) details:

■ Which features are to be included

■ What market is to be addressed (or for internal developments, what internal problem or opportunity is to be addressed)

■ What percentage of that market is likely to be successfully sold (or for internal developments, what percentage of potential users will actually use it)

■ How many resources (and over what time frame) are required for development

■ How much risk exists for development, sales, meeting the schedule, meeting the development budget

■ How many units will be sold and at what price (or for internal developments, how many times will the system be used)

■ How much revenue will be generated (or for internal developments, how much savings or revenue or reduction in cost, or reduction in errors will occur), and over what time frame

■ What is the organization's return on investment.

Tools are available to assist in some aspects of requirements triage. For example, tools by Omni-Vista allow users to decide which requirements will enable the project to complete on schedule and within budget. Other Omni-Vista tools allow users to witness the effects of features, resources, and cost of goods sold on revenue, risk, profit and return on investment. Primavera has a tool that allows users to simulate over time the effects of making key product planning decisions. And QSS has a tool that allows users to compare the effects of decisions on technology, risk, and marketing.

Requirements Specification. Requirements specification is the task of documenting the precise external behavior of the system that is to be built. It takes the features selected during requirements triage and expands them into considerable detail. The primary purpose of this is to ensure that customers and developers have the same understanding of what is to be built; all developers have identical understanding of what is to be built; testers are testing for the same qualities that developers are building; and management is applying resources to the same set of tasks that the developers are performing. Traditionally, these requirements have been documented in a requirements specification. More recently they are being maintained in a database or repository of discrete requirements, rather than in a formal document.

Numerous textbooks have been written to teach how to properly document requirements. For example, see Leffingwell, et al. (mentioned above); Alan M. Davis and Marilyn D. Weidner, Software Requirements: Objects, Functions, and States [Prentice Hall, 1993]; and Ian Sommerville and Gerald Kotonya, Requirements Engineering: Processes and Techniques (Worldwide Series in Computer Science) [John Wiley & Sons Ltd., 1998].

According to Alan Davis, et al., in “Identifying and Measuring Quality in Software Requirements Specification,” [IEEE International Software Metrics Symposium, May 1993; reprinted in Dorfman and Thayer's Software Requirements Engineering, Second Edition, IEEE Computer Society Press, 1997], every documented requirement should be at least:

■ Correct, in that it describes something the stakeholders want

■ Consistent, in that it does not conflict with other requirements

■ Unambiguous, in that it has only one possible interpretation

■ Verifiable, in that there must exist some means by which we can check that the final system meets this requirement.

Most requirements tools allow you to record these annotated requirements.

REQUIREMENTS MANAGEMENT HAS somehow grown over the years to be more and more complex. In actuality, it is a straightforward set of activities. Performing each of the activities is quite simple. The most complex aspect of requirements management is doing the background investigation (for example, learning what effect on sales will occur when a feature is eliminated). However, these investigations must be done whether or not you perform requirements management; otherwise you embark on a risky business route. You invite your company to become a statistic, to become part of the 71 percent of projects that are never completed or become shelfware. ■