Take a Moment Help define the State of the Practice by answering the following question:

We actively manage our reqts risk

Technical Papers Print E-mail

Check out LiteRM, the (inexpensive) lightweight requirements manager that stores a rich assortment of information, provides the core capabilities of heavyweight RMs and is easy to learn, use, and change.

Check out our latest papers on: Managing Developer Understanding

  • Visualize and Manage Developer Understanding
  • Improve Requirements Understanding by Playing Serious Games

The technical papers are grouped as follows:

Requirements Risk Management (RRM)


Identifying and Controlling Requirements Risk (v44 1.4M Posted: 5/24/10)
Developing a strategy to deal with the actual and potential problems in requirements development, can reduce the number and severity of the problems that do occur. This presentation describes a set of tactics that you can use to develop your risk management strategy.

RRM Tactics Checklist and References (v37 110kb Posted: 6/15/09)
A list of tactics that you can use to compose your requirements risk management strategy and a list of references for several of the tactics.

The Myth of Risk Management (v01 847K Posted: 6/04/09)
Pete McBreen examines the nature of risk on software development projects. He concludes that most risk management is misguided and ineffective. This is partially due to the politics or culture in some organizations that make risk unmentionable. It is also due to a failure to openly acknowledge project uncertainty and unpredictability.

Monitor Feasibility Tactics


Prioritizing Requirements (v01 160kb Posted: 9/20/07)
Don Firesmith describes the challenges and risks of prioritizing requirements and provides a survey of prioritizing techniques.

Project Termination Doesn't Equal Project Failure (v01 49kb Posted: 1/31/07)
Barry Boehm argues that project cancellation may be due to good project management. He discusses organizational risk taking and states that no project cancellations may mean too little risk taking.

Better Management of Development Risks (v01 891kb Posted: 5/20/10)
Barry Boehm presents a development model to integrate system acquisition, system engineering, and software engineering. The model provides points at which the risks going forward can be better assessed and fit into a risk-driven stakeholder resource commitment process.

The Only Winning Move (v01 72kb Posted: 12/04/03)
Organizations that don't expect and encourage about 20 percent of their projects to be stopped, may either be wasting resources or implementing only the safest bets. Denying reality or always playing it safe may be the riskiest strategy of all.

Avoid Mistakes Tactics


Safety Check (v01 92Kb Posted: 3/19/08)
Steven Smith discusses the importance of personal safety and describes a way to measure it.

Human Requirements Engineering
(v01 287kb Posted: 10/26/07)
Paul-Roux Wentzel and his coauthors describe the way people are different and how those differences should be handled in a requirements engineering context to tap their full potential.

Controlling Prototype Development Through Risk Analysis (v01 657kb Posted: 06/11/09)
Baskerville and Stage describe a new approach to the management of evolutionary prototyping projects. The main unsolved problem in prototyping is the difficulty in controlling such projects. The article uses an explicit risk mitigation model and management process. This approach enables appropriate risk resolution strategies to be placed in effect before the prototyping process breaks down. It facilitates consensus building through collaborative decision making and is consistent with a high degree of user involvement.

Overview of Cooperative Learning
(v01 231kb Posted: 5/20/10)
Roger and David Johnson describe how learners may perceive and interact with one another. They can compete to see who is "best", they can work individualistically toward a goal without paying attention to others, or they can work cooperatively with a vested interest in each other's learning as well as their own. They describe the advantages of a cooperative environment.

Agile Requirements for Stepsister Projects (v01 336kb Posted: 4/01/06)
Many projects don't fit the criteria for an efficicient, effective requirements process. Language barriers, large teams, and tunnel vision are all things that can turn your project from Cinderella into a stepsister. Find out what Jennitta Andrea suggests to help you overcome these obstacles.

Requirements Information Strategies: Does One Size Fit All? (v13 147kb Posted: 5/24/10)
In this paper, we define the requirements information that should be elicited and communicated on a specific project as "just enough" based on the risk of inadequate understanding of higher priority requirements. We show that this risk primarily depends on the initial understanding of stakeholders i.e., that "just enough" decisions are context-dependent. We show that no context-free approach to requirements (e.g. comprehensive or Agile) is best in all situations and that the "just enough" approach entails these context-free approaches as special cases. We identify risk mitigation tactics to deal with "not enough" requirements. Finally, we describe the "just enough" selection process and provide four examples.

Agile Requirements Methods (v01 136Kb Posted: 1/30/07)
Dean Leffingwell discusses the formulation of requirements methods that reflect the types of risks inherent in your environment. He describes Extreme, Agile, and Robust Requirements Methods as examples.

Minimize Communication Tactics


What's It Mean? - Eliminating Vagueness with Precising Definitions
(v01 717kb Posted: 4/9/09)
Imprecise language makes understanding and, therefore, verification more difficult. This article describes techniques for detecting and repairing vague and ambiguous software requirements.

Clearly Specifying System Requirements (v29 1.6Mb Posted: 5/22/06)
This PowerPoint presentation is an introduction to practical detailing techniques for requirements specification. Precision is inevitable in software development. Both code and tests are precise specifications. This presentation focuses on techniques that add essential details to risky requirements using precise models. The detailing techniques include (a) precise use cases, (b) test specs, (c) entity specs, (d) derived conditions, (e) action contracts, (f) derived values, and (g) quality specs. Each technique has its domain of effective application and can be applied incrementally. In many situations, several techniques should be used.

Using Requirements Specification Patterns (v01 49kb Posted: 5/29/05)
In this paper, we recommend minimum sets of specification patterns for different types of systems. First we describe a comprehensive set of spec patterns and a classification scheme of system types. Then we identify the spec patterns to use for each type of system.

Requirements and Business Rules (v01 44kb Posted: 5/29/05)
This paper explores the relationship between a detailed classification of requirements information and a detailed classification of business rule information.

The Clear Specs Challenge (v06 52kb Posted: 5/12/04)
This paper defines the challenge process and shows how the ClearSpecs techniques (detailed definitions and precise use cases) could be used to specify the Merchandise Return capability of a Sales Support System.

Building a Business Case for Detailed Specs
(v01 38kb Posted: 6/26/03)
This paper describes a cost-benefit analysis for the use of detailed system specifications. The presentation begins with assumptions about the requirements process and then provides a formula for the Return on Investment (ROI) in moving from one specification strategy to another. We demonstrate the formula by comparing the minimal specing in Extreme Programming to detailed specification using the ClearSpecs techniques.

Adding Bits of Precision to Usage Models (v01 146kb Posted: 3/6/03)
For interactive systems, usage models are an important component of the requirements specification. In the spirit of agile methods and "just enough" written communication, well-understood user activities might be communicated by XP user stories and subsequent discussions. In cloudier areas, more details should be written to reduce the risk of misunderstanding. This paper describes nine techniques that you can use to increase the precision of your usage models. Each technique can be used alone or in combination to supplement your current practice. Readers are assumed to have a basic understanding of use cases.

A Q&A Intro to ClearSpecs Usage Modeling (v05 130kb Posted: 5/22/04)
This article gives the components of a ClearSpecs usage model; explains how ClearSpecs models relate to UML models; and details where ClearSpecs modeling can be effectively used. There is also a list of references.

ClearSpecs Model of a Library Management System (v02 111kb Posted: 5/12/04)
This is an example of a precise model of a familiar system. This usage model for a library management system covers book transactions such as check out, return, add, remove, and the displaying of various sorted lists. It covers constraints such as book status (checked out or available) and staff user vs. ordinary borrower, among others. The system also includes retinal scan and bar code scanning.

Precise Use Cases (v05 129kb Posted: 5/22/04)
This paper describes a precise form of use case that promotes the specification of inter-actor options and alternative course conditions. Precise cases use an activity description language with a Structured English grammar. The design goals for the notation were to maximize understandability by application experts, not familiar with formal object-oriented concepts, and to supply sufficient information and structure to support both manual and automated test design. In addition to a detailed example, a development process, and guidelines for modeling and test coverage are provided. The appendix contains a substantial use case example. The reader is assumed to have a basic understanding of use cases.

Use Cases: Give More to Get More (v02 500kb Posted: 11/15/05)
This Powerpoint presentation describes the elements of a Precise Use Case.

Modeling Alternative Courses in Detailed Use Cases
(v03 75kb Posted: 2/15/04)
Real-life interactions between systems and users entail decisions and alternative courses of action. Within detailed use cases, there are many categories of alternative courses each having a distinct semantics. This paper describes an integrated framework for categorizing alternative courses and provides modeling recommendations for each category. The paper also examines the impact of alternative courses on use case conditions (i.e., constant conditions, preconditions, and post-conditions) and recommends a three-level strategy for specifying conditions.

Specifying Consequences with Action Contracts (v02 182kb Posted: 3/3/03)
This paper describes a technique, action contracting, for the specification of goal-directed actions. Contracting can be used to specify consequential action rules, rather than algorithms, for any goal-directed entity (e.g., person, system, product, component, class, or object). If an entity can be effectively tested for functionality, that functionality can be contracted. Action contracts are readable by clients and writeable by most software professionals, with minimal training.

Quality Specs
(v02 38kb Posted: 2/28/04)
This paper provides a template for the precise specification of quality (non-functional) requirements. Four examples are included.

Quantifying Quality Requirements
(v01 82kb Posted: Live2/17/04)
Erik Simmons describes Intel's use of Planguage, created by Tom Gilb. Planguage is a keyword-driven language that allows measurable, testable quality requirements to be written. Planguage is easy to learn, flexible, compact, extensible, and prevents omissions by providing a consistent set of parameters for quality requirements. In this paper, Planguage keywords and syntax are introduced. Examples of quality requirements before and after using Planguage are given, and the experiences of introducing Planguage within a product engineering environment are discussed.

Periodic Table of Vizualization Methods (v01 500Kb Posted: 9/20/07)
Lengler and Eppler provide a periodic table of 100 visualization methods and describe how to use it. Examples of each method can be found in pop-up frames by mousing-over the table enties at

Visual Requirements (v01 164Kb Posted: 7/1/08)
Becky Winant describes 3 types of diagrams and how to turn them into powerful requirements tools. Becky discusses turning diagrams into models that help illustrate software's 3 dimensions: function, information, and behavior.

Minimize Other Tactics


Collaborate for Quality (v01 158Kb Posted: 7/1/08)
Ellen Gottesdiener provides advise on using workshops to determine your project's requirements. Ellen describes how to apply proven patterns for effective collaboration and provides examples from successful efforts.

Know What's at Stake (v01 800Kb Posted: 5/30/07)
Harty, Evans, and Reid describe the need for and an approach to explicit non-functional requirements (NFR). They see NFRs treated as second-class requirements and illustrate the consequences of this.

Detect Requirements Defects


HIgh Impact Inspections (v01 500kb Posted: 8/28/05)
This PowerPoint presentation describes the details of High-Impact Inspections. This form of technical review is a powerful alternative to Fagan Inspections.

Detecting Missing Requirements (v06 750kb Posted: 5/23/06)
Requirements development is difficult for many reasons including the challenge of detecting missing requirements information. This PowerPoint presentation catalogs over a dozen techniques for this task and provides details on four of them.

Detecting Defects in Existing Requirements (v04 500kb Posted: 5/24/06)
It is difficult to uncover defects in existing requirements. This PowerPoint presentation surveys the range of requirements information and the set of issues that need to be checked for individual requirements and for the entire suite.

Will It Work (v01 510kb Posted: 10/31/07)
Hammond, Rawlings, and Hall describe approaches to reducing the requirements risk in large heterogenous distributed systems. In particular, they describe the use of "rich traceability" as a framework for verifying that the allocation of a requirement to multiple processes is sound.

Monitor Tactics


Test-Driven Requirements (v01 303Kb Posted: 1/30/07)
Roland Cuellar describes the power of designing test cases early.

Use of Satisfaction Arguments (v01 298Kb Posted: 11/30/07)
Attwood, Kelly, and McDermid illustrate the use of satisfaction arguments to support the derivation of requirements.

Spec Quality Control (v01 526Kb Posted: 3/19/08)
Tom Gilb describes a relatively inexpensive sampling technique to assess the number of major defects in a requirements spec.

Learning From Mistakes (v01 132kb Posted: 10/10/07)
David Card describes Defect Causal Analysis, a process for culling systematic errors from problem reports in order to develop strategies for preventing defects or detecting them earlier.

Stop the Insanity (v01 582Kb Posted: 7/1/08)
Ed Weller discusses using root cause analysis (RCA) to understand mistakes and avoid repeating them. Ed distinguishes errors, faults, and failures and describes common problems with RCA.

Mitigate Tactics


Incremental and Iterative Development (v01 2.51M Posted: 6/8/08)
Alistair Cockburn clears up the confusion about the relationship between incremental and iterative development.

Staff Tactics


Developing a Reqts Team (v01 52kb Posted: 12/28/06)
Forming, Storming, Norming, and Performing. No, they are not a law firm, but the stages of team development proposed by Bruce Tuchman in 1965. It may help your requirements team.

Plan Tactics


Overcoming Reqts Modeling Challenges (v01 82kb Posted: 10/10/07)
Scott Ambler suggests what to do when an organizations culture is not condusive to effective software development efforts or project stakeholders do not understand the implications of their decisions.

Brainstorming Fraud Risks (v01 170kb Posted: 10/26/07)
Mark Beasley and Gregory Jenkins provide a readable primer on brainstorming risks. Although written for accountants, it describes a brainstorming process that can be used for all types of risks. The article discusses how a team can avoid pitfalls inherent in brainstorming sessions while maximizing their benefits.

Common Requirements Problems (v01 96kb Posted: 11/2/07)
Donald Firesmith summarizes 12 of the most common requirements problems, describes their negative consequences, and relates the industry best practice to help solve them.

Requirements Risks Can Drown Software Projects (v01 241kb Posted: 10/10/07)
Theron Leishman and David Cook describe several requirements risks and consider strategies to help mitigate them.

Prepare Tactics


Building a Reqt Fault Taxonomy (v01 101kb Posted: 1/31/07)
Jane Hayes describes her work in creating a requirements taxonomy based on a sample of incident reports for NASA space station software.

Ongoing Requirements Discovery (v01 358kb Posted: 1/31/07)
Robyn Lutz analyzed anomaly reports from 8 spacecraft projects and found several patterns of requirements discovery. She demonstates the value of analyzing requirements-based issue logs.

The Ritual of Retrospectives (v01 89Kb Posted: 7/1/08)
Norm Kerth describes how to maximize group learning by understanding past projects. Norm discusses how to structure the meeting and 3 precautions to consider.

Other Requirements Stuff


Maybe We Shouldn't "Write" Requirements (v01 50kb Posted: 2/21/03)
In this column, David presents a problem familiar to many of us--what is the best way to record requirements? Given the limitations of static templates, how can we best manage high-volume, multidimensional requirements information?

Exploring Agile (v01 50kb Posted: 3/29/08)
Bob attempts to figure out exactly what Agile development is and where it works by analyzing the Agile Manifesto and its supporting principles. He proposes changes to some troubling statements.

Aphorisms about Requirements (v01 56kb Posted: 2/21/03)
"The requirements puzzle will have pieces missing...Expect requirements development to be a shared learning experience...For wicked problems, the picture keeps changing...Right the first time can be the enemy of good enough...Risk requires higher resolution." This paper explains these aphorisms related to requirements development and management.



Testing Complex Logic (v01 63kb Posted: 8/06/03)
Choosing effective tests for complex logical expressions can be difficult. This paper describes a black box strategy for choosing such tests. The strategy is shown to be a natural generalization of current methods for choosing tests for simpler expressions. The strategy chooses combinations that are not only effective at revealing implementation defects but, perhaps more important, are effective at helping detect defects in the requirements themselves.

In addition, if there are dependencies between variables in the required logic, a variant of the strategy excludes those truth-value combinations that are "impossible" because of the dependencies. It extends the required expression to include dependency information and then derives tests from this extension. This strategy is the only test selection method that smoothly incorporates dependency information. It also permits the dependency information itself to be partially validated through analysis of the "impossible" cases developed by the basic strategy, but excluded by the variant.

What Test Designers Wish from Software Models (v01 253kb Posted: 12/08/06)
Testing is getting harder. To keep up with ever growing complexity of software and the testing task, new approaches to test development must be used. One of these approaches is automated test design based on precise models of software behavior and usage. Today, commercial support in this area is weak. There is a current and growing need for a variety of commercial tools supporting automated design. The purpose of this presentation is to provide insight into the information requirements for automated test design to (current and potential) vendors of software modeling tools. It is hoped that this information will catalyze a number of commercial development efforts.

How to support better software testing (v01 1.7Mb Posted: 8/17/03)
This paper describes the elements of a Testability Maturity Model (TMM) that addresses the issues that support or retard project testing. The TMM covers information availability and relationships as well as best practices in support of test. It is a pragmatic model that can be used to assess and improve testability.

What's your testability maturity? (v01 1.1Mb Posted: 8/17/03)
This paper contains a testability score card based on the Testability Maturity Model. The scorecard entries are described along with a strategy for maximizing the impact of the evaluation.

The Growth of Software Testing (v01 2.4Mb Posted: 8/17/03)
This paper traces the evolution of software test engineering by examing changes in the testing process model and the level of professionalism. The current definition of best testing practice aims for defect preventation as well as detection.

The Exchange


Vol. 2005 No. 3 Cooperation and Learning Styles (Posted: 9/24/05)

Vol. 2005 No. 2 Survey Says ... (Posted: 8/22/05)

Vol. 2005 No. 1 Good Requirements are UnAmerican (Posted: 4/20/05)

Vol. 2004 No. 3 Why So Difficult? (Posted: 11/25/04)

Vol. 2004 No. 2 No Hows? (Posted: 08/10/04)

Vol. 2004 No. 1 Requirements Team Development (Posted: 04/01/04)

Vol. 2003 No. 2 RD is a team game (Posted: 10/21/03)

Vol. 2003 No. 1 Effective Involvement of Stakeholders (Posted: 7/30/03)


Clearer Requirements