Table of Contents  

Chapter 1. Task-Adequate Understanding

We begin by considering the nature of requirements understanding. We identify mental activities that contribute to human understanding and identify those relevant to requirements. We also describe the dimensions of task-adequate requirements understanding as measured by sufficient (1) depth of understanding, (2) breadth of understanding, and (3) understanding across the stakeholder community.

Chapter 2. Demonstrating Understanding

When understanding is uncertain, ask for an early demonstration. Demonstrations may include verification strategies, test patterns, behavior rules, or usage models.

Chapter 3. Quality Goals

We explore the challenges of understanding quality goals.  While "Big Requirements Up Front (BRUF)" is an Agile anti-pattern, "Quality Goals Up Front (QGUF)" is essential to the cost-effective acquisition of high-quality systems.

Chapter 4. Specifying for Understanding

In addition to the demonstration techniques described in chapter 2, specification can be a cost-effective tactic for catalyzing requirements understanding.

Chapter 5. Checking Requirements

If there are defects in requirement’s information or understanding, there will be defects in results. Sometimes, it's cheaper to debug results. When it isn't, requirements and their understanding should be checked.

Chapter 6. Customized Requirements Development

Application development may involve reuse, third-party products, and in-house development.  Fixed RD strategies (e.g. Agile or Waterfall) do not work well in heterogeneous situations.  Mixed RD is a strategy that does because it is customized to project specifics.

Chapter 7. Requirements Management

We view requirements development and requirements management as an interacting pair of concurrent processes in the same way that product development and project management interact.  We describe eight management activities supporting the development of task-adequate requirements.

Chapter 8. Requirements Risk Management

Projects should identify the nature of their requirements risk and take appropriate action.

Appendix A. Reference Specification
Appendix B. Requirements Tools