Preface

There are more things in heaven and earth, Horatio,
than are dreamt of in your [requirements] philosophy.
                                    Shakespeare

Once upon a time

Requirements development (RD) used to be simpler. Requirements shaped the goals of product development. Books and training taught that requirements should be comprehensively elicited, analyzed, and specified before coding. It seemed reasonable that goals should be defined before solutions.

This comprehensive specification approach held sway until the 1990s, when a paradigm shift declared that having comprehensive specs early doesn’t work. The focus shifted from creating an entire application to creating the next few increments. User stories, executable tests, and extensive customer conversations were believed to provide enough requirements information for the next increments and that both requirements and the application should be developed incrementally, partly because the developing system would deepen stakeholders’ understanding and thereby clarify requirements.

This change raises the questions:

  • Exactly what is the role of requirements in product development and how should this role be performed? 
  • When, if ever, are written specs valuable?

From a historical perspective, it seems that requirements practice has shifted from one silver bullet (Waterfall) to another (Agile). As Fred Brooks [Ref. 0.1] told us long ago, in the increasingly complex reality of software development, there are no silver bullets. He also told us that there is a difference between essential and accidental complexity. Essential complexity is inherent in the problem to be solved and must be addressed by any effective solution. The challenge is to understand the essential complexity of requirements development and avoid the siren call of simplistic strategies.

The challenges and opportunities inherent in the expanding role of software and in Agile development have caused an evolution in our understanding of RD. The purpose of this book is to share new RD perspectives and pragmatic techniques based on this evolving understanding.

Why is requirements development so difficult?

If you had to choose between getting a root canal and developing requirements, which would you pick? It might be the dental work, since the pain interval is shorter and Novocain can help.

Why is RD so difficult?  It’s difficult—and always will be—because it is not consistent with our normal behavior. Its major challenges are not technical, but rather psychological and social.

The challenges of RD include:

  1. Unavailable or unfocused information sources.
  2. Stakeholders unclear about their needs.
  3. Stakeholders change their mind about what they want.
  4. Disagreements about requirements and priorities.
  5. Problems in making requirements precise.
  6. Tacit stakeholder knowledge, which is hard to access.
  7. Emergent understanding by stakeholders, which can’t be scheduled.
  8. Poor understanding of quality attributes, e.g., safety and security.
  9. Concrete thinking by critical stakeholders, who can only identify problems in an implemented system, not in descriptions or models.
  10. Misunderstandings, e.g., because of ambiguous communication.
  11. Implicit requirements, which may escape detection during development.
  12. Rapid changes in the application, domain or technology.

Most of these challenges relate to people and workings of the mind. This means that allocating more time, purchasing new tools, and reorganizing a project team will rarely improve RD.

While not every project has all of these challenges, many projects face some of them. Effective management begins with an early recognition of these challenges and the use of challenge-specific mitigation tactics.

Backstory

I used to believe that specifying document content and task steps could improve software quality. While this approach has its place, decades of experience have taught me that complex problems need customized situation-specific strategies. For example, if developers are unfamiliar with an application domain, they must be guided to sufficient understanding or replaced by developers who do understand. A customized approach should be grounded in risk analysis and management; in other words, should entail figuring out what to fear and how to reduce risk.

Why another book on requirements?

Current RD books thoroughly cover the tasks, techniques, and tools of requirements elicitation, analysis, specification, and validation. While this information is valuable in dealing with many situations, these books omit or contain inadequate information about:

  • Stakeholder understanding
  • Demonstrations of developer understanding
  • Quality attributes
    • Supporting and conflicting relationships
    • Goal definitions
    • Achievement strategies
    • Verification strategies
  • Mixed requirements strategies
  • Requirements management
  • Requirements risk analysis and management

Objectives

This book provides new perspectives on the goals and strategies of RD as well as the nature of requirements information and understanding. It describes the limitations of uniform approaches to requirements (e.g., Waterfall or Agile) and provides rationale and details so that you can use these new perspectives in your RD activities.

Scope

This book is not about basic RD. It does not present basic concepts nor is it a catalog of requirements analysis techniques. It does, however, present new concepts and approaches to understanding requirements and their cost-effective development.  

When application development approaches (e.g., Agile) are discussed, only their requirements activities are considered. In addition, we describe aspects of verification activities because they are directly affected by requirements.

The many factors contributing to project success include:

  • Task-adequate understanding of the problem, the customer’s intent and goals, and the project assumptions and risks.
  • Effective communication.
  • Effective requirements development.

This book should improve your understanding and management of these factors. I hope you find a few ideas to improve your requirements practices and remove requirements from your list of major project hazards.

Reference material

The references in each chapter include supplementary readings from articles and books. All referenced articles are freely available on the book’s website at www.understandingrequirements.com. This book contains about 10% of the content when the supplementary readings are included.

The 3D quality model (discussed in chapter 3) is freely available at www.quality-aware.com/daves-q-a-stuff.php.

The referenced articles and quality model are important supplements to the book’s content.

Unfamiliar terms, such as tool names, are not defined since your favorite search engine can easily locate their reference material

Audience

This book is meant to help experienced practitioners improve their requirements practices and those of their team.

If you are committed to using a uniform RD approach and your practices are working, please stop reading. You will find this material unhelpful, confusing, or annoying.

If your requirements practices don’t always work or you are willing to consider new ideas to deal with a broader range of real-world situations, read on.

Product owners and managers, as well as project managers, should find the content especially useful since they are often responsible for requirements development and management. Other potential readers include requirements leads, technical leads, analysts, testers and other verifiers, quality support staff, developers, consultants, and customers.

An ideal reader understands the basic concepts of RD and has at least two years of experience wrestling with requirements. Readers with this background will be able to compare the proposed RD approaches to their experience.

In addition, this book can provide a solid foundation for a graduate course or seminar in software requirements. If you would like to discuss using the book for this purpose, send an email to david@clearspecs.com.

Your feedback is welcome

If you use some of these ideas, please let us know about your experiences, both good and bad. If you come across ideas that you feel are incomplete or confusing, or if you have questions, send an email to david@clearspecs.com.

We plan to post experiences and tips on getting the most out of the book. Please consider contributing.

Supplementary readings (References)

The papers referenced in this preface are available at understandingrequirements.com/preface-and-chapter-1-references.php

0.1. Brooks, Frederick P. Jr. (1987) “No Silver Bullet: Essence and Accident of Software Engineering” IEEE Computer 20 (4)