Eric Evans
Addison-Wesley, 2003
ISBN 0321125215
Buy it from Amazon.com
Buy it from Amazon.co.uk
This is an interesting and well-written book, and it is of course about many things including, especially, requirements. That this goes under the heading of 'design' only confirms a trend that has been going on at least since Henry Dreyfuss' wonderful Designing for People back in 1955. This is that people from many different backgrounds find they need to cover the question of how to obtain accurate requirements from clients, customers, users, stakeholders -- and they describe that activity in their own language, whether that is the language of human-computer interaction, contextual design, software, or whatever.
Evans, like Dreyfuss, is a designer: in Evans' case, an expert object-oriented software designer (as the praise he gets from Martin Fowler and Kent Beck demonstrates). He writes in a light, conversational but focussed style, and his easy familiarity with software design and modelling concepts makes the book very approachable, whether the reader is into software or not. It's very welcome that practitioners should be thinking so openly about how to keep their software in line with the domains that they are serving.
Evans rightly characterises dialogue with stakeholders as a messy, iterative activity. He contrasts this with the Waterfall model, which he says "fails because it completely lacks feedback." That isn't really fair to Royce (who invented the waterfall) but it does neatly describe the trouble with many of the inappropriately rigid life-cycles imposed on too many projects in the last few decades. The trouble with uncontrolled iteration is that it can be wasteful, and it can lead to poor software which consists of one requested feature after another, heaped up without a plan:
"if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features." (page 14)
Clearly, therefore, as Evans admits, telling user stories and refactoring are not in themselves enough. It is essential to identify what stakeholders in the domain actually need, not only in terms of concrete features of the software, but by abstraction to discover the underlying principles of the domain. Is this a rediscovery of the need for proper analysis to elicit goals, to structure domain knowledge and expertise, to write requirements, to model and to design as traditionalists like Richard Stevens would argue? Possibly; it also hints strongly at the need for a Domain Theory like that of Alistair Sutcliffe in which knowledge is properly organized in a reusable way to support successive software development projects.
© Ian Alexander 2004