Patricia Ferdinandi
Addison-Wesley, 2002
ISBN 0201738260 (paper)
500 pages
Patricia Ferdinandi
Addison-Wesley, 2002
ISBN 0201738260 (paper)
500 pages
Buy it from Amazon.com
Buy it from Amazon.co.uk
Other Reviews
This book is a description of RE intended for the engineer capturing and managing requirements for Internet systems. The world of such systems is generally supposed to operate at its own speed and according to different rules from other systems -- indeed, that collective belief was strong enough to support a tremendous South Sea Bubble in the shape of the Dot-Com boom, with bizarre terms such as burn rate (how much of someone else's money you were wasting), Internet economy (that fraction of the capitalist world whose share price rose continually despite the lack of either profits or dividends), and virtual company (an investment whose soundness was guaranteed by originality, image, and complete lack of substance). After the implosion of the bubble, money is managed more rationally, but something of the bizarre flavour remains.
The book is interesting for its language which in many cases has nothing in common with the familiar language of RE. You won't find Stakeholder or Viewpoint, for instance in the enormous (18-page) glossary; but you will find Requirement Focus and Perspective, and the term Community is defined in the text (but not the glossary). In fact, Community, Perspective, and Focus are defined to be the 'three dimensions [that] properly categorize each individual requirement'; they are respectively the corporate function, level of detail, and the specialized view, which 'when applied [as questions] to the requirements set framework, create the requirements pattern' -- which taxonomic masterpiece is what the book is about.
There is talk in the book of anti-patterns as well, including such (happily) familiar items as 'Scope Creep'. As you might expect, each anti-pattern is documented like a Christopher Alexander-inspired / Gang of Four Pattern. This can be seen as a good idea, trendy, or verbose according to your taste.
For example, the Problem of Scope Creep is:
The Solution is
A further page (of an Appendix called 'Requirements Pattern Language') is taken up with the Context, Forces, Resulting Context, Rationale, and Syntax of the Scope Creep pattern. To me, this is cumbersome in the extreme; why not have a lively example, or a story, or a graph of the cost of late changes? By the way, the Forces section does not mention the powerful forces on a project -- like customers changing their minds, or just asking for 'one slight modification' that turns out to break the back of the project; it just talks about what happens when you add new requirements, and repeats (for the third time) the need for review. What needed to be said was that Process is shown by this anti-pattern to be the one white knight that can gallop to the rescue of the fair damsel project in distress; far from being a boring and burdensome extra, a sensible, practised and defensible process is absolutely essential.
Ferdinandi has clearly laboured mightily to write this behemoth of a book. It's difficult if not impossible for those of us who aren't writing requirements for the Internet world to judge whether she has succeeded in her assigned task. Certainly nobody seems to have tried to do anything similar; its nearest relation on my bookshelf is perhaps the distantly-related and strongly process-based Leffingwell & Widrig -- but Ferdinandi doesn't even mention the RUP. To an outsider, the book appears curious rather than helpful; perhaps to the Java-enabled, JIT-aware (Just In Time) proponents of the black art, the book will be wonderfully useful and appropriate.
Ferdinandi is undoubtedly a genuine practitioner, but the practical wisdom which certainly lurks beneath the surface of this book is hard to access through the rather dry and extensive prose. The book seems to want to organize, classify, and categorize everything -- for instance, the subsections of Appendix B are literally classified by their applicability to the cells of a 2-D matrix, a requirements meta-pattern; to give you an example, one cell takes two pages (out of 60 for the Appendix) to discuss how to ask IT Designers the How question; no fewer than 25 variants of How d'you do that? are given in full, with the purpose of each one. This is impressive but a bit overwhelming, like the endless rows of dried beetles and dusty ammonites in the museums of yesteryear. Perhaps it also diagnoses the problem with this book: it is so abstract at the meta-meta-level (after all, 'How do you collect and organize requirements?' is already a meta-level question to hard-pressed practitioners!) that it is hard to see the ground, dizzyingly far below. In confirmation of this, Appendix C is a 20-page hierarchical list of the requirements work packages that a project is supposed to have! '3.2.4.3.3: Determine degree of change' -- there must be 500 separate activities listed there. Agile methodologists and Extreme Programmers, eat your hearts out.
© Ian Alexander 2002 You may also like:
New requirements are added to the requirements set without a full understanding of their impacts on all other requirements (including project constraints) or work products (design, code, legal agreements) already developed.
Scope creep becomes a problem if a process is not defined to evaluate and approve the impacts the new or volatile requirements will have on the Internet program or a specific iteration. The requirements engineer must document the new requirement in its entirety (including priority) and assess the impacts of the new requirement (or any change to a requirement) on the approved requirements set. The impact must be reviewed and approved as a whole. This means that the new or changed requirement will probably create a change to project constraints such as budget, time, and resources.
