What's New?

The papers are grouped as follows:

• Requirements Risk Management (RRM)
• Monitor Feasibility Tactics
• Avoid Mistakes Tactics
• Mitigate Tactics
• Minimize Comm Tactics
• Minimize Other Tactics
• Monitor Tactics
• Staff Tactics
• Plan Tactics
• Prepare Tactics
• Other Requirements Stuff
• Testing
• The Exchange

Identifying and Controlling Requirements Risk  (v40 1.2M  Posted: 6/15/09)
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.

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.

Using Incremental Commitment  (v01  250kb  Posted: 9/26/07)
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.

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.

A Lot, a Little, or Just Enough?  (v05 145kb  Posted: 6/27/09)
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.

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.

Individualizing Requirements Information  (v02 45kb  Posted: 2/14/06)
Requirements Engineering should have its own requirements - specifically the types and forms of information to be communicated. Information choices should be individualized to the many contexts associated with a project. Different types of systems need different types of information.
Template tailoring is the commonly suggested approach to information selection, but is only useful when there is little variance in the customer base and the type of system. A more powerful approach is individualization using components. This paper describes a process for individualizing requirements information.

Sheets to Individualize Requirements Information  (v01 21kb  Posted: 2/14/06)
This spreadsheet contains lists of information types that can help you create your own comprehensive menu from which your individual projects will make their selections i.e., individualize.

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

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.

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.

What's It Mean?
(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.

Let Me Be Perfectly Clear
(v07 350kb  Posted: 1/06/08)
This presentation shows why standard approaches to defining terms are ineffective and then describes 7 types of rich definitions that are both precise and contextual .

Just Enough Precision
(v01 300kb  Posted: 1/06/08)
This presentation shows why standard approaches to defining terms are ineffective and then describes 3 types of rich definitions that are both precise and contextual. [Short form of Let Me Be Perfectly Clear]

Just Enough Precision Webinar Q and A
(v01 23kb  Posted: 1/31/08)
The questions and answers resulting from a webinar on Just Enough Precision

Rich Glossary Template for Word
(v04 222kb  Posted: 12/4/07)
This Word file can be used as a template for a Rich Glossary (i.e. a glossary filled with rich definitions).

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.

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.

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 http://www.visual-literacy.org/periodic_table/periodic_table.html#

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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)