“Beautiful Soup, so rich and green, Waiting in a hot tureen! Who for such dainties would not stoop? Soup of the evening, beautiful Soup!” —Lewis Carroll, Alice’s Adventures in Wonderland
It starts innocently. One of the marketing staff has a request from a customer to add an extra pull-down menu. Then a requirement arrives to add an export interface to the product, the product manager wants to include a new analysis report, and the DBA asks for another new field in the database and to change the color of the background. All of these requirements, and many more, are passed to the developers for inclusion in the product. The features of the product grow with each addition, but after a while, everyone—marketing, customers, and development—loses sight of how all these pieces fit together and how they help achieve the business goals. The project that once set out with the intention of meeting a specific purpose has instead become an indigestible soup of unconnected features.
The situation becomes soupier because each of the interested parties views the product’s requirements very differently and there is no common, connective thread. Marketing groups each collection of requirements as a marketable feature—not necessarily with any functional cohesion. The developers group the requirements according to the implementation technology they are using. Each customer thinks of the requirements in terms of the individual fragments of his own work. The impact of these unconnected requirements is that nobody has a consistent way to talk about progress or to make decisions about changes. It becomes impossible to make trade-offs in terms of the themes of a product release because there are no coherent themes; instead, the product becomes a bag of miscellaneous tricks.
So, why do so many products end up as feature soup? It starts with the sources of the requirements: people.
People naturally think that their own requirements are the most important. Different locations of the same organization, or different customers, want their own, idiosyncratic features, and it’s no surprise that their demands do not take the overall business integrity of the product into account. That is the job of the analyst.
When piecemeal requirements arrive, the analyst needs to map them to the business processes that they affect. This mapping provides a way to show different people the effects (sometimes surprising) that a proposed change might have on their work. This analysis provides the analyst with the basis for discovering what people really need—and whether a change offers a real benefit or is just another feature tossed into the soup.
Another contributor to feature soup takes the form of designers including a new feature without considering its overall connections with the existing product. Designers should ask, “Is it within the declared scope?” “What are the interfaces with the existing product?” “Does it overlap or confuse anything that already exists?”
Repeated failure to address these issues leads to a product made up of disconnected fragments. The nature of requirements based on disconnected features means that there is no objective definition of what is in or out of scope. Hence, it is easy for extra requirements to seep into the project from a variety of sources—and they do. The more fragmentary the product becomes, the more difficult it is to assess and to make coherent changes; the downward spiral continues.
Organizations that stay out of the soup share a number of characteristics:
Tom DeMarco gives the keynote at the OOP Konferenz 2015 in Munich, January 29, 2015.
Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich. Translation by Andreas Brandhorst.
Read Tom DeMarco's article from the July/August edition of IEEE Software: Sigil, BlueGriffon, and the Evolving Software Market.
Announcing the publication of the third edition of Tom DeMarco and Tim Lister's iconic text, Peopleware: Productive Projects and Teams. The book is available now from Amazon or directly from Addison Wesley. See press release on Business Wire.
"This war isn't going to blow anything up, only turn everything off."
Read Tom DeMarco's essay from the July/August issue of Software Magazine. It's entitled, Bells, Whistles, Power, and the Requirements Process.
The preparation course for the IREB "Certified Professional for Requirements Engineering" is now available as video training. Learn at home or any other place. Including questionnaires to prepare you for the multiple choice test.