The State of Requirements Development in Software Today, Part III of a Multipart Series

Part I
Part II

The Business Cost of Poor Requirements

Use Cases

The most popular answer to the ongoing dilemma of how to develop better requirements has been the widespread introduction and adoption of use cases. First introduced by Ivar Jacobson in the late 60’s while he was working on Ericsson's AXE system, interest in use cases increased substantially in the early 90s and many software developers now employ use cases, or at least claim to, while developing requirements.  The person perhaps most responsible for the popularization and increased adoption of use cases today is Alexander Cockburn, whose book Writing Effective Use Cases is widely read and regarded as a primary text on the subject..

A use case is a segmented textual description of goal-directed interactions between a primary interactor (person or external system) and the system being used. Use cases may describe interactions to achieve primary interactor goals (e.g., place an order, reserve a book, fill-out a tax return) or subgoals (e.g., log-on, print screen, find reservation).

Use cases appear in many forms based on the amount of detail provided. A short use case would have an identifier, a title (describing the goal), and some natural language text identifying the interactors and summarizing the case.  A more comprehensive case (e.g., Cockburn’s full dress cases) might contain the following segments or even more (e.g. Priority or Frequency of Use):

• Identifier & Title
• Interactors & System descriptions
• Case conditions (pre-conditions & post-conditions)
• Success course (basic interactions)
• Extensions (alternative interactions)

The “success course” describes a minimal sequence of (inter)actions needed to successfully accomplish the goal of the case.  Extensions describe alternative actions by an interactor or by the system which may lead to failure or success in attaining the case goal.

There are many paths (scenarios) through a typical use case (as through a computer program) based on interactor choices and system responses. The case preconditions must all be TRUE in order to execute any path.  The case post-conditions will be TRUE upon completion of any path.  The preconditions and the post-conditions of the success course are often provided as well.

Use cases are not intended to detail or describe the actual software design or interface; that task is the responsibility of the development group, which builds their software so as to meet the requirements of the use case.

Limitations of Use Cases

When use cases first gained widespread attention in the 90s, the software community regarded them with the same enthusiasm as a drowning man regards a life preserver.  As opposed to the long, incomprehensible feature lists they were accustomed to working with, lists often developed without any operational context and rife with inconsistencies and ambiguity, use cases were a godsend.   They were seen as offering a means to finally bring a measure of order and structure to a process becoming increasingly chaotic as the development process became more complex and interactive.

But despite the important role they can play in the process of developing accurate, clear, and unambiguous requirements, several important limitations of use cases have impeded both their adoption and utility, particularly when used with larger development projects. These same limitations are shared by the natural language system overview that accompanies the set of use cases.  The limitations are:

• Conventional use cases still rely heavily on “natural” language. In point of fact, this is considered one of their great strengths.  Unfortunately, natural language, as we have already noted, is inherently ambiguous and many attempts to make it less so by writing more natural language leads to obscure and unreadable requirements.
• Conventional use cases do not put much emphasis on precisely defining the terminology employed in use cases and maintaining a glossary of these definitions; in fact, in “Writing Effective Use Cases” Cockburn explicitly excludes glossaries and definitions from the use case model.
• Conventional use cases, as noted by Cockburn, do not detail a software system’s business rules, that is, the rules governing the operation of an enterprise. “A store manager can override any return policy” is an example of a business rule.
• Conventional use cases do not address the issue of defining a system’s quality goals (e.g., performance, security, usability, etc.).

Some advocates believe that use cases can be extended to include detailed definitions and glossaries, business rules, and quality specs by simply adding sections to the conventional model. This strategy creates a scope clash. One use case describes the interactive processes for attaining a single goal.  Definitions, rules, and quality specs are associated with many if not most of the use cases.

Natural Language and Use Cases

To understand the limitations of natural language in developing specifications, consider this sample use case describing a requirement for a merchandise return function, a process that would be a normal part of a point-of-sales system for a retail clothing chain.

Title: Return Merchandise

Summary: Sales system must support merchandise returns. Missing receipts and manager overrides should be addressed.

Detail (natural language): Sales system must support returns of unopened, unused, or defective merchandise for up to 14 days from date of purchase. With a valid sales receipt, returns must be accepted at any store. Without a valid sales receipt, returns must be accepted only at the store where purchased, and then only if the customer’s sales record is located in the system and the customer provides a valid photo-ID. Any store manager can override these rules and accept a return.

A quick analysis of this passage reveals multiple points of ambiguity. For example, what is a “valid sales receipt?”  Is a sales receipt that has been written on or damaged in some way valid? Is the sales receipt valid if the person presenting it is not the person who bought the product?  Is the sales receipt valid if the person who returned the product is the person who bought the product, has returned it within 14 days, but forgot to bring their credit card with them for refund processing? Is the sales receipt valid if the person no longer has the credit card account they originally used to purchase the product?

To reduce ambiguity, this use case could be rewritten as:

With a valid sales receipt, which is any receipt that has not been altered so that the date or amount has been obscured, or presented by the original purchaser of the product, or presented along with a valid credit card, or presented by a purchaser who still maintains the account they originally used to purchase the product….

We are already well on the way to unreadability. Now, consider how a similar attempt to reduce ambiguity in the terms “order,” and “override” using natural language would cause this scenario to become an unending thicket of “ors” and “ands.”  Not only is natural language hard to read, particularly when trying to express conditional statements, its extensive use quickly inflates requirements to bulky and unmanageable levels.  Many people who have been involved in software development have had the personal experience of sitting down with a requirements document of hundreds of pages that contains paragraph after paragraph of dense, unreadable text.

To deal with the problem of ambiguity and bulk, conventional use case advocates recommend creating more subgoal use cases to simplify the requirements and increase readability. In many cases, this leads to an overabundance of cases which, in the aggregate, are difficult to track and maintain.

The Need for Precise Definitions

The NASA Mars Climate Orbiter fiasco is a classic (and expensive) example of a failure to precisely define terminology. While a wide variety of usage models were developed and maintained during the development of the spacecraft’s guidance software, none of these use models and cases made provision for a glossary of precise definitions that would include attributes, units, value ranges, and relationships for each entity in the application domain or system.  This definitional strategy would have forced the different engineering teams to standardize on (presumably) the metric system.  The question of creating detailed definitions was outside the scope of the usage models and was handled on an ad hoc basis.  The practical result was the loss of the spacecraft and the waste of over $230M.

Quality Requirements

One popular definition of use cases describes them as a “sequence of interactions that yields a measurable result of value for an actor.”  However, it is quite possible to create a system that meets the success criteria of a conventional use case but does not deliver “value” to the system’s users, as this observation by an IT director at a Connecticut hospital illustrates:

In 2000 a decision was made that we needed to replace our mainframe-based patient tracking software with a new, Windows-based system. I’d say we did good job of developing specifications in terms of the functionality and capabilities that the system delivers.  Unfortunately, we didn’t spend much time considering how the new interface would affect the productivity of our staff in terms of interacting with the new software. For example, our old system allowed most patient data to be entered from a single centralized onscreen form with a logical series of submenus being called from this central form.

Our new system has increased functionality over the old software, but the interface requires users to scroll through endless input menus instead of a centralized input screen. Submenus do not follow in a logical order, causing the unit secretaries and staff nurses to constantly have to scroll back to check on previously entered items (some of them use notepads to help them keep track of already entered information so they don’t have to do this. The software works, it delivers “value” per our requirements, but it is “out of spec” in regards to the time and accuracy we need to work at out best efficiency.

Driven by an IT market now firmly focused on ROI and measurable results for their investments in technology, after wasting billions in “shelfware,” the importance of non-functional requirements is steadily increasing.

Agile Development

Another response to the challenge to developing clear and effective software requirements has come from the development community in the form of the agile development movement. Agile development is often thought of as being synonymous with Extreme Programming or XP, but there are several development “movements” which fit under the agile umbrella, including SCRUM, Crystal, Adaptive, and Feature-Driven Development.

Underlying all these systems is an approach to developing requirements in a highly iterative manner. An agile environment encompasses these key elements:

• Incremental and iterative development. Agile programming preaches that a program should be written in small, highly testable units.
• Constant automated unit and verification testing (a process that tests if new code integrates and interoperates with a system’s current software).
• Pair programming.  Developers working in tandem to provide a quality and knowledge check on each other. (Few companies who employ XP techniques follow this practice.)
• User interaction with the development team, i.e., an “onsite customer”.  While a good concept in theory, practical considerations often make this impractical.  Instead, in IT-oriented projects, business or system analysts will often play the role of the “customer” or user of the software.  In commercial software firms, project managers, product managers, sales engineers and even sales groups may play the role of surrogate customer.
• Refactoring, a process of constantly reviewing and cleaning up “sloppy” or redundant code

The real-world success of XP to date, especially when employed in larger software projects, has been a very mixed bag.  The methodology’s first major test was the Chrysler C3, or Chrysler Comprehensive Compensation project.  C3 was a software development program designed to replace Chrysler’s mainframe-based payroll software system with a new Y2K client-server product. After over five years of development, during which interest in XP and agile programming techniques grew, Chrysler canceled the C3 project in February 2000, citing the fact that the Y2K period had passed, the mainframe software was still operating correctly, the C3 replacement was over budget and that the current implementation was only capable of paying 10K employees out of approximately 100K.  Many observers at the time noted that one of the primary reasons for the failure of C3 was that the scope of the project continued to creep due to the dearth of written requirements.

The collapse of the C3 project led to much soul searching and a reexamination of the contribution to project success that clear and unambiguous requirements have in developing software. As Matt Stephens and Doug Rosenberg point out in their analysis of C3 in Extreme Programming Refactored: The Case Against XP:

Written requirements—fleshed out, clarified, and signed off before production coding begins—help immensely in keeping a project focuses and on track, working toward a well-defined, unambiguous set of goals.

Ambiguity sinks projects.  If a requirement is ambiguous, get clarification and then update the written requirements.

The travails of the C3 project notwithstanding, XP and agile development in general have made a major contribution to software development practice via the concept of early unit and acceptance testing.  A unit test is a piece of code is designed to “prove” that a piece of production code works as specified. Extreme programming methods call for unit tests to be built before production code.

Note that agile development can be viewed as a strategy for creating detailed specifications (i.e. the code) early and often. Unfortunately the detailed specifications are not readable by the customer or client and therefore access to and validation of these details is indirect through the behavior of the code.  The details in the code can only be exposed through a very sophisticated testing strategy which is beyond the capabilities of most developers and customers.

Part I
Part II

Upcoming articles include a an ongoing look at new approaches in product management in requirements development, look at the current state of CRM marketing and sales, and an interview with Luke Hohmann, author of "Beyond Software Architecture: Creating and Sustaining Winning Solutions."

Join Our Mailing List

Other Resources

Primary Resources

A Directory of Resources for Software and High-Tech Marketers

Last Update: Week of July 25th, 2004

Site Sponsored by
 Aegis Resources
860.663.0552

Copyright 2003, 2004,
Aegis Resources, Inc.