RTM’d today: Software Requirements, Third Edition

  • Article

Book cover for 9780735679665We’re thrilled to announce that Software Requirements, Third Edition (ISBN 9780735679665), by Karl Wiegers and Joy Beatty, has shipped to the printer!

Now in its third edition, this classic guide to software requirements engineering has been fully updated with new topics, examples, and guidance. Two leaders in the requirements community have teamed up to deliver a contemporary set of practices covering the full range of requirements development and management activities on software projects.

New chapters are included on specifying data requirements, writing high-quality functional requirements, and requirements reuse. Considerable depth has been added on business requirements, elicitation techniques, and nonfunctional requirements. In addition, new chapters recommend effective requirements practices for various special project situations, including enhancement and reengineering, package solutions, outsourced, business process automation, analytics and reporting, and real-time and embedded systems projects.

The book is targeted at business analysts, developers, project managers, and other software project stakeholders who have a general understanding of the software development process.

Preorder your copy from here, here, or here. While you wait for the book to arrive, feel free to download the sample chapters from the Microsoft Download Center.

Read on for the book’s Contents at a glance and an excerpt from the Introduction.

Contents at a glance

Part I  Software requirements: What, why, and who
Chapter 1  The essential software requirement
Chapter 2  Requirements from the customer’s perspective
Chapter 3  Good practices for requirements engineering
Chapter 4  The business analyst

Part II  Requirements development
Chapter 5  Establishing the business requirements
Chapter 6  Finding the voice of the user
Chapter 7  Requirements elicitation
Chapter 8  Understanding user requirements
Chapter 9  Playing by the rules
Chapter 10  Documenting the requirements
Chapter 11  Writing excellent requirements
Chapter 12  A picture is worth 1024 words
Chapter 13  Specifying data requirements
Chapter 14  Beyond functionality
Chapter 15  Risk reduction through prototyping
Chapter 16  First things first: Setting requirement priorities
Chapter 17  Validating the requirements
Chapter 18  Requirements reuse
Chapter 19  Beyond requirements development

Part III  Requirements for specific project classes
Chapter 20  Agile projects
Chapter 21  Enhancement and replacement projects
Chapter 22  Packaged solution projects
Chapter 23  Outsourced projects
Chapter 24  Business process automation projects
Chapter 25  Business analytics projects
Chapter 26  Embedded and other real-time systems projects

Part IV  Requirements management
Chapter 27  Requirements management practices
Chapter 28  Change happens
Chapter 29  Links in the requirements chain
Chapter 30  Tools for requirements engineering 

Part V  Implementing requirements engineering
Chapter 31  Improving your requirements processes
Chapter 32  Software requirements and risk management

 

Introduction (excerpt)

Despite decades of industry experience, many software organizations struggle to understand, document, and manage their product requirements. Inadequate user input, incomplete requirements, changing requirements, and misunderstood business objectives are major reasons why so many information technology projects are less than fully successful. Some software teams aren’t proficient at eliciting requirements from customers and other sources. Customers often don’t have the time or patience to participate in requirements activities. In many cases, project participants don’t even agree on what a “requirement” is. As one writer observed, “Engineers would rather decipher the words to the Kingsmen’s 1963 classic party song ‘Louie Louie’ than decipher customer requirements” (Peterson 2002).

The second edition of Software Requirements was published 10 years prior to this one. Ten years is a long time in the technology world. Many things have changed in that time, but others have not. Major requirements trends in the past decade include:

  • The recognition of business analysis as a professional discipline and the rise of professional certifications and organizations, such as the International Institute of Business Analysis and the International Requirements Engineering Board.
  • The maturing of tools both for managing requirements in a database and for assisting with requirements development activities such as prototyping, modeling, and simulation.
  • The increased use of agile development methods and the evolution of techniques for handling requirements on agile projects.
  • The increased use of visual models to represent requirements knowledge.

So, what hasn’t changed? Two factors contribute to keeping this topic important and relevant. First, many undergraduate curricula in software engineering and computer science continue to underemphasize the importance of requirements engineering (which encompasses both requirements development and requirements management). And second, those of us in the software domain tend to be enamored with technical and process solutions to our challenges. We sometimes fail to appreciate that requirements elicitation—and much of software and systems project work in general—is primarily a human interaction challenge. No magical new techniques have come along to automate that, although various tools are available to help geographically separated people collaborate effectively.

We believe that the practices presented in the second edition for developing and managing requirements are still valid and applicable to a wide range of software projects. The creative business analyst, product manager, or product owner will thoughtfully adapt and scale the practices to best meet the needs of a particular situation. Newly added to this third edition are a chapter on handling requirements for agile projects and sections in numerous other chapters that describe how to apply and adapt the practices in those chapters to the agile development environment.

Software development involves at least as much communication as it does computing, yet both educational curricula and project activities often emphasize the computing over the communication aspect. This book offers dozens of tools to facilitate that communication and to help software practitioners, managers, marketers, and customers apply effective requirements engineering methods. The techniques presented here constitute a tool kit of mainstream “good practices,” not exotic new techniques or an elaborate methodology that purports to solve all of your requirements problems. Numerous anecdotes and sidebars present stories—all true—that illustrate typical requirements-related experiences; you have likely had similar experiences. Look for the “true stories” icon, like the one to the left, next to real examples drawn from many project experiences.

Since the first edition of this book appeared in 1999, we have each worked on numerous projects and taught hundreds of classes on software requirements to people from companies and government agencies of all sizes and types. We’ve learned that these practices are useful on virtually any project: small projects and large, new development and enhancements, with local and distributed teams, and using traditional and agile development methods. The techniques apply to hardware and systems engineering projects, too, not just software projects. As with any other technical practice, you’ll need to use good judgment and experience to learn how to make the methods work best for you. Think of these practices as tools to help ensure that you have effective conversations with the right people on your projects.

Benefits this book provides

Of all the software process improvements you could undertake, improved requirements practices are among the most beneficial. We describe practical, proven techniques that can help you to:

  • Write high-quality requirements from the outset of a project, thereby minimizing rework and maximizing productivity.
  • Deliver high-quality information systems and commercial products that achieve their business objectives.
  • Manage scope creep and requirements changes to stay both on target and under control.
  • Achieve higher customer satisfaction.
  • Reduce maintenance, enhancement, and support costs.

Our objective is to help you improve the processes you use for eliciting and analyzing requirements, writing and validating requirements specifications, and managing the requirements throughout the software product development cycle. The techniques we describe are pragmatic and realistic. Both of us have used these very techniques many times, and we always get good results when we do.

Who should read this book

Anyone involved with defining or understanding the requirements for any system that contains software will find useful information here. The primary audience consists of individuals who serve as business analysts or requirements engineers on a development project, be they full-time specialists or other team members who sometimes fill the analyst role. A second audience includes the architects, designers, developers, testers, and other technical team members who must understand and satisfy user expectations and participate in the creation and review of effective requirements. Marketers and product managers who are charged with specifying the features and attributes that will make a product a commercial success will find these practices valuable. Project managers will learn how to plan and track the project’s requirements activities and deal with requirements changes. Yet another audience is made up of stakeholders who participate in defining a product that meets their business, functional, and quality needs. This book will help end users, customers who procure or contract for software products, and numerous other stakeholders understand the importance of the requirements process and their roles in it.

Looking ahead

This book is organized into five parts. Part I, “Software requirements: What, why, and who,” begins with some definitions. If you’re on the technical side of the house, please share Chapter 2, on the customer-development partnership, with your key customers. Chapter 3 summarizes several dozen “good practices” for requirements development and management, as well as an overall process framework for requirements development. The role of the business analyst (a role that also goes by many other names) is the subject of Chapter 4.

Part II, “Requirements development,” begins with techniques for defining the project’s business requirements. Other chapters in Part II address how to find appropriate customer representatives, elicit requirements from them, and document user requirements, business rules, functional requirements, data requirements, and nonfunctional requirements. Chapter 12 describes numerous visual models that represent the requirements from various perspectives to supplement natural-language text, and Chapter 15 addresses the use of prototypes to reduce risk. Other chapters in Part II present ways to prioritize, validate, and reuse requirements. Part II concludes by describing how requirements affect other aspects of project work.

New to this edition, Part III contains chapters that recommend the most effective requirements approaches for various specific classes of projects: agile projects developing products of any type, enhancement and replacement projects, projects that incorporate packaged solutions, outsourced projects, business process automation projects, business analytics projects, and embedded and other real-time systems.

The principles and practices of requirements management are the subject of Part IV, with emphasis on techniques for dealing with changing requirements. Chapter 29 describes how requirements tracing connects individual requirements both to their origins and to downstream development deliverables. Part IV concludes with a description of commercial tools that can enhance the way your teams conduct both requirements development and requirements management.

The final section of this book, Part V, “Implementing requirements engineering,” helps you move from concepts to practice. Chapter 31 will help you incorporate new requirements techniques into your group’s development process. Common requirements-related project risks are described in Chapter 32. The self-assessment in Appendix A can help you select areas that are ripe for improvement. Two other appendices present a requirements troubleshooting guide and several sample requirements documents so you can see how the pieces all fit together.