Mastering the Requirements Process

_____________________________Books

Mastering the Requirements Process

A New Book from Suzanne and James Robertson

Foreword by Gerald Weinberg

Mastering the Requirements Process describes an industry-tested process for gathering and verifying requirements. It provides techniques and insights for discovering precisely what the customer wants and needs.

"Mastering the Requirements Process shows, step by step, template by template, example by example, one well-tested way to assemble a complete, comprehensive requirements process." - Gerald Weinberg

The specification template in this book provides the basis for your own requirements specifications. It guides you to the correct specification content as each part of the process reveals different aspects of the products functionality and properties.

This book shows you how to make the requirement measurable and testible. By providing a measurement a fit criterion for each requirement, the requirements analyst can describe precisely what the customer wants, the designer can construct a product that exactly matches the requirement, and the tester can determine whether or not the final solution satisfies the requirement.

"The Robertsons' concept of fit criteria is -- all by itself -- worth the investment of your time to read the whole book. Fit criteria and the allied discipline of quality gateways enable you to build requirement sets that are measurable, provably correct and testibly complete." - Tom DeMarco

The book includes the experience that the authors have gained from over two decades of requirements and systems analysis experience, in various countries around the world.

"This is an important and timely book, written in an easy and clear style. The authors are well known and respected consultants, and have many years of experience in teaching and advising organisations about their requirements process." - Bashar Nuseibeh, Imperial College, London.

"This is a nicely crafted, well-thought-through, complete, up-to-date view of the task of creating a requirements specification for a software project." Bob Glass

Complete review by Bob Glass, Editor-in-Chief, Journal of Systems and Software

"The book soon began to impress me with its practical knowledge. It became apparent that Suzanne and James Robertson have dealt with the real-world problems of gathering software requirements. As a result, I think the book makes a valuable contribution to the literature of software engineering." Capers Jones

Complete review by Capers Jones, Chief Scientist Artemis Management Systems

Mastering the Requirements Process is published by Addison-Wesley US and Addison-Wesley UK.

Available from Addison-Wesley, Barnes & Noble, Amazon.co.uk and your local bookseller.

[ top of page ]

Pre-publication review by Bob Glass

Requirements are a make or break phase of the software development process. If the requirements are carefully chosen to represent what the customer wants, needs, and expects, then the project has a good chance of success. If not, the project may very well be doomed.

That said, it is easy to say that this book is about an important topic. But is it a good book about that important topic?

My vote is "yes." This is a nicely crafted, well-thought-through, complete, up-to-date view of the task of creating a requirements specification for a software project.

Nicely crafted? It is well-written, readable, never pedantic. Well-thought-through? The authors base the book on seminars they have given and honed over the years. Complete and up-to-date? Not only are the basic topics covered, but the authors also mention such advanced topics as requirements reuse, requirements patterns, traceability, and an event + use case-driven approach.
The book is written for the requirements novice. There are plenty of detail-level discussions of steps and approaches, templates for framing the results, and an elaborated case study (how refreshing it is to see a case study based on de-icing roadways, rather than one of the traditional, overused topics like video rental or cruise control!) But the book can also be useful to the patient requirements expert - there is more verbiage than the expert will want, but by scanning carefully the essence of the book can be easily distilled out. Importantly, the essence of the book is conceptual rather than formula/methodology-driven - the authors say the book is intended "not as a set of canonical rules that must be obeyed, but as a reliable companion to intelligent work."

Given all of that, I found some things that were mildly annoying: Some of the terminology the authors use is cutesy, although often it is appropriate, but (a) "blastoff: as the term for project start? (the projects I've been involved with rarely start with a "blast"!); (b) "requirements leakage" for requirements that erroneously get accepted into a project? (I would have thought that things leak out of a project, not in!) . The authors claim that their book can be used not just for customized software development projects, but also for software maintenance and even for projects that aggregate pre-built packages. But later they say that the requirements process should never consider the technology of the solution (all well and good for customization, but impossible for the latter two categories). . The authors take the (debatable) position that "object-orientation has become the standard way of developing systems," but then mix the two terms "use cases" and "event-driven" as if they were the same, both related to the OO approaches. In my view, event-driven approaches are rather different from object-oriented ones (for example, Visual Basic allows the programmer to build an event-driven system, but the result may or may not (likely not!) be object-oriented).
The authors speak of a "post-mortem review" (an excellent idea), but it is not until page 271 (near the end of the book) that it becomes clear that "post-mortem" means "after the requirements phase," not "after the project is complete." (Either could be correct, but the authors should make it clear which they mean when they first bring up the topic 250 pages earlier). . There is an appropriate and thorough discussion of the topic of "fit," by which the authors mean that requirements should be expressed in a measurable way. But the authors fail to acknowledge that some things simply don't lend themselves to measurement, with the result that much mischief is done by those who attempt to measure the unmeasurable (e.g., the terrible tendency to state "the software product shall be modular" in terms of the length of program segments - "modules shall contain no more than 50 lines of code").

Things I particularly like about the book are . Requirements representation is treated as a pragmatic topic, where requirements are to be readable by both application customers and software designers. There is none of the formal specification discussion that computer scientists love to advocate but that seldom fits the needs of real-world requirements. . There is also a nice discussion of software tools, appropriately mentioning that they are a means to an end, not an end in themselves. (Interestingly, there is no mention of the now-in-disrepute term "CASE"!) . The discussion of the "quality gateway," which covers the process of making a final decision as to which requirements to include in the final specification, is both important and nice. There are very well-done discussions of such topics as "requirements creep," "gold plating," "traceability," and "viability." (I was reminded of the wry comment by Jerry Weinberg at a conference many years ago that software may be the only discipline where the answer to the early-project question of feasibility is always "yes"!) . The discussions of the avant-garde requirements topics like requirements reuse and requirements patterns are very nice. I was less pleased with the discussion of traceability - what the book contains is excellent material, but it fails to go far enough to note that tracing requirements into design and code, although extremely desirable, is so far an out-of-reach topic (due to the "explosion" of business requirements into design requirements as the life cycle proceeds, an explosion estimated by some to be measured in orders of magnitude).

There should be at least one book on requirements in the library of every enterprise, even every software professional. You could do a lot worse than choosing this one.

-----------------------------------------------------------
Robert L. Glass
Editor-in-Chief, Journal of Systems and Software
Editor/Publisher, The Software Practitioner
1416 Sare Road
Bloomington, IN 47401
voice/fax: 812-337-8047
rglass@indiana.edu

[ top of page ]

Pre-publication review by Capers Jones

Over the past five years the author and his colleagues at Software Productivity Research have worked as expert witnesses in about a dozen lawsuits involving breach of contract for software projects.

In every case the plaintiffs charged that the contractors were late in delivering the products, and that the software contained far too many errors when delivered. But in every case the defendants claimed that the delays were caused by excessive changes to the requirements after the contract had been agreed to.

We have been able to measure the rate at which requirements change over time, and the observed average in the United States is about 1% per month for software contracts. If a project is initially sized at 1000 function points and is delivered 24 months later with a final size of 12,400 function points, then it clearly grew at a rate of 100 function points a month, which is 1% of the initial size.

Our studies also have shown that software requirements contribute about 20% of the total number of errors or defects found in software projects. The U.S. average for errors in software requirements is about 1.0 per function point. This is only about 20% of the total volume of errors found in software projects.

However, requirements errors are very difficult to remove compared to other classes of error such as coding errors. The removal efficiency of requirement errors is only about 77%, while more than 95% of coding problems are usually removed before delivery. This means that when software projects are delivered, the number of latent requirements errors is greater than any other category. This also means that much of the subsequent high maintenance costs of software projects are really the costs of fixing requirements problems.

Because errors in requirements are very resistant to later removal the most effective approach is to prevent them from occurring in the first place. Consider the example of example the Y2K problem. The Y2K problem actually originated as an explicit requirement in order to save storage costs. That explains why millions of Y2K problems were never found by means of normal testing. Once an error passes from the requirements to other software deliverables and the code itself, the error cannot be found by normal testing or defect removal operations.

There is no question that software project requirements have been a very weak link in the chain of software engineering technologies.

With this kind of background data on software requirements problems, I started to read Suzanne and James Robertson's book on Mastering the Requirements Process with some reluctance. I feared the book would be theoretical and divorced from real-world issues.

But the book soon began to impress me with its practical knowledge. It became apparent that Suzanne and James Robertson have dealt with the real-world problems of gathering software requirements. As a result, I think the book makes a valuable contribution to the literature of software engineering. There are only a few books that have provided practical guidance for minimizing requirements problems, and this new book deserves a place beside Jerry Weinberg and Don Gause's Exploring Requirements: Quality Before Design.

If the book sells well, then it is possible that it might even play a role in minimizing some of the risks of litigation that are associated with ambiguous requirements that change rapidly over time. I think the book might reduce requirements defect levels significantly, and also raise the efficiency with which these troublesome errors are removed.

The book is solidly grounded with scores of examples of actual requirements. These requirements are subdivided down into various categories such as functional requirements and non-function requirements.

Of even more value in the context of reducing potential litigation, the book is very strong in dealing with ways of validating requirements, exploring their quality implications, and even dealing with the cost and schedule implications. Indeed, it is failure to consider quality, costs, and schedules when specifying requirements that often shows up in a litigation context.

The text is clearly written and the illustrations are both numerous and helpful. In fact the format and layout of the book is one of the most effective I've seen in quite a while. The balance of text and graphics is just about right, and the page layouts are also very well done to achieve optimal readability.

The book emphasizes the general nature of requirements, but also handles some of the more recent approaches that have been developed for gathering requirements in an object-oriented context. For example use cases are discussed and illustrated rather well.

The book also addresses a topic that will grow to considerable importance in the future: reusing requirements. This is a one of the first treatments of requirements reuse that I've encountered. Too often the literature on software reuse focuses on code, and ignores the other artifacts with potential value for reusability.

The book is very good, but no software book is perfect. In our studies of software engineering practices we often divide software projects into six size categories, and explore whether a technology is useful to the whole software universe or only part of it. The six size categories are an order of magnitude apart:

1 function point
10 function points
100 function points
1,000 function points
10,000 function points
100,000 function points

Traditional software requirements specifications average about 0.5 pages per function point. The methods put forth by Suzanne and James would appear to include somewhat more complete documentation than normal, and so would probably run a bit larger.

This means that unless a fully-automated method is available for handling the requirements paperwork, the methods Suzanne and James discuss might work well up to about 1,000 function points in size. (1000 function points is equivalent to about 107,000 COBOL source code statements.)

For an application of 1000 function points, the methods suggested in the book would probably lead to requirements specifications in the 600 page size range. This might be a bit cumbersome, but not too difficult to deal with later during development.

However, for applications in the 10,000 and 100,000 function point size ranges, the volume of requirements paper documents might begin to exceed the capacity of the development team to handle. In the 10,000 function point size range, the requirements might top 6,000 pages. In the 100,000 function point size range, the requirements might top 60,000 pages.

Of course applications in the 1000 function point range are more than 20 times as common as applications in the 10,000 function point range. Therefore the book certainly is useful for many thousands of applications. However, the problems of requirements for really large applications above 10,000 function points need some additional guidance outside the current book.

On the whole, the book is well written, will illustrated, and a valuable addition to the software engineering literature. For typical software projects in the range of 10 to 1000 function points the book can be highly recommended. For really massive systems in the 10,000 function point range and beyond, portions of the book will be very useful. The book's principles will work, but quite a bit of automation will be needed to handle the volumes of requirements associated with such large applications.

-----------------------------------------------------------
Capers Jones
Chief Scientist, Artemis Management Systems
Burlington, Massachusetts

[ top of page ]