About the Second Edition
The motivation for the content changes in the second edition is based on different yet convergent factors.
The first set of factors is based on the success of the book in the
marketplace
, which has generated many positive comments and much encouragement, as well as constructive criticisms. While comments range widely, two consistent themes emerged.
-
The "more use cases" theme.
The first edition (subtitled
A Unified Approach
) reconciled and combined two major viewpoints on requirements techniques. The first, perhaps a more traditional approach, described the way in which requirements specifications are created and detailed to prescribe system behavior using declarative techniques ("the system shall . . ."). The second, the use case approach, described the way in which use cases could be used to define the majority of the functional behavior of the system. We combined these techniques in the first edition in order to create a common, and hopefully more holistic, approach. Based on feedback, we did achieve some success. However, one criticism of the work is that, while we recommended and described the use case method, we did not go far enough in helping the reader develop or apply this technique. Moreover, in presenting both techniques, we
confused
some readers who wanted to better understand which technique to apply and when.
-
The "it's a big book with many techniques ”
please
be more prescriptive" theme
. The first edition of this book was intended to be a comprehensive work, a
one-stop
-shopping reference for any technique readers might need to define requirements for a system of any type. We hope this provided value to our readers because we truly believe that there is no "one
size
fits all" solution to each specific software engineering challenge. And yet, the reviewers' theme remains: "Does it have to be this hard? Can't you be more prescriptive?"
A second set of factors driving this same theme is based on my own experiences in using the book as I work with companies to help them achieve their software development objectives. Some have software applications that require multiple techniques; some can make time for a
fairly
rigorous
introduction to a full requirements management discipline. However, others need to document a specific set of requirements for a specific software application and they need to do so
immediately
. Starting tomorrow. There is no time or interest in a debate about which technique might be more effective or about the
nuances
of anything. "Just give me one technique, make it simple, and get me started right now," they say.
Fortunately, these two sets of inputs are mostly convergent and the answer to both is fairly clear.
For most
teams
, in most circumstances, a combination of (1) a well-
considered
Vision document, (2) an identification and elaboration of the key use cases to be implemented, and (3) a supplementary specification of the nonfunctional requirements is adequate and appropriate for managing software requirements
. In addition, if this is the
chosen
method, the elaborated use cases can directly become the foundation for system testing.
To this end, this second edition of
Managing Software Requirements
has new content, a new theme, and a new
subtitle
:
A Use Case Approach
. In this edition, the use case technique is the cornerstone technique, and a more prescriptive approach has been chosen and represented. For example, Chapter 14, A Use Case Primer, has been added to provide a more fundamental basis for understanding and applying use cases. It should serve as a tutorial adequate for an
otherwise
uninitiated individual to be able to learn and begin to apply the technique. The HOLIS case study has also been updated to reflect a more use-case-centered approach. Chapter 26, From Use Case to Test Case, has been added to
illustrate
how the use cases can directly drive a comprehensive test strategy as well as serve as direct input to the test cases
themselves
.
In addition, we've made one substantial enhancement motivated solely by our own purposes. Chapter 17 (which appeared in the first edition as Chapter 18, The Champion), has been
renamed
Product Management and enhanced with new material designed to help teams understand how to
turn
a software application into what we call
the whole product solution
. Since getting the requirements "right" cannot by itself ensure commercial success, this chapter provides insight and guidelines for those activities (such as pricing and licensing, positioning and messaging) and other commercial factors that transform a working software application into a
software product people want to buy
.
Also, since modern software development processes are becoming more iterative, we decided to
repurpose
the first edition's chapter on quality so that this edition's chapter would provide a more comprehensive look at quality within the context of a modern software process. Thus Chapter 29, Assessing Requirements Quality in Iterative Development, speaks directly to iterative techniques for gathering and improving requirements within an overall iterative development framework.
Finally, we also took the opportunity to address a new undercurrent in the industry, a movement toward what are perceived as lighter, less formal
methods
. In the extreme,
Extreme Programming
(XP), as espoused by Beck and others, could be interpreted to eliminate process entirely. Perhaps more correctly, XP incorporates certain keystone processes, such as direct customer requirements input, directly into programming practices, but it's also fair to note that the concepts of "software process" and the "M" word (methodology) are studiously avoided. Perhaps less extreme and considered by some to be more practical, the introduction of
Agile Methods
, as advocated by Cockburn and others, has also taken root. Though
controversial
in some circles, these lighter approaches cannot be ignored, and we've addressed these in the requirements context in another new chapter, Chapter 30, Agile Requirements Methods.
Of course, no book can be all things to all people. In order to make this edition as readable as possible, we eliminated a number of topics and chapters from the prior version and
shortened
others.
We sincerely hope that you will find this revised text more approachable, as well as easier to use and apply, and that it will better help you and your teams to manage your software requirements.
|