Ralph R. Young
Artech House, 2004.
Ralph R. Young
Artech House, 2004.
ISBN 1580532667 (boards)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Ralph Young is the author of the popular Effective Requirements Practices (2001), and he has now followed up that guide to project activities with a handbook for people who look after requirements (perhaps especially in large organisations). There is obviously some overlap - both books discuss process issues and offer a taxonomy of requirements, for instance; but this book is both more up-to-date and oriented more towards the practitioner, and it tells the 'how to do it' (at the level of project activities, not of the detail of analysis and modelling) where the earlier book said what had to be done.
I should declare an interest here: Young quotes and references several aspects of my work, including on Stakeholders and the Writing Better Requirements book. In fact he is consistently generous and collegiate in style, quoting and praising numerous named sources such as Ivy Hooks and Ellen Gottesdiener on different aspects of the field. Therefore, despite my deputy midwife's role in bringing this book into the world (with suggestions and comments on the manuscript), I think I can still write a reasonably objective review of the published book.
The book is organized straightforwardly into ten chapters.
The first introduces The Importance of Requirements, but in contrast to other books (including mine) where a similar argument is addressed mainly to managers wondering why they should bother, the message here is for the Requirements Analyst (RA) -- for whom indeed the whole book is written. In the section 'Factors affecting your career decisions', for instance, Young at once recommends "that you meet with your PM very early ... to allow you to conclude whether you can be effective in your role." In other words, there's no point taking on the job if you won't be allowed to do it as described in this handbook. This is not a book, clearly, which is going to waffle on about academic theories or the intricacies of modelling.
Chapters 2 and 3 look at the Roles of the RA and the Skills and Characteristics of an Effective RA, respectively. The roles and skills are presented both in the text and as matrices: e.g. facilitation is needed in all life-cycle activities, whereas advising on tools and techniques is needed in system initiation, analysis & design, and during operations. The skills are presented for 3 levels of analyst, from entry-level to senior, and a detailed job description is presented in a table that takes up just over 2 pages -- covering the skills, knowledge, responsibilities, and measures of performance. This is far more systematic (and dare I say it, better) than anything in the current literature, though Sommerville & Sawyer's RE: a good practice guide is a worthy precursor (but it focuses on process improvement rather than on practitioners). Chapter 7 revisits this core theme of the Handbook by discussing the RA's Specialty Skills (it doesn't mean 'on specialty requirements' but 'what you specially need to be able to do', like facilitating, estimating, and configuration control).
Chapter 4 looks at Types of Requirements. These are grouped into customer needs and expectations, analyzed system requirements such as functions, '-ilities', and performance, allocated subsystem / component requirements, and checks such as qualification requirements. To prevent the chapter from getting too dry, there is a welcome case study story to round things off. Young maintains a constant sharp focus on what needs to be done, by 'you' the reader and RA. He refuses to be side-tracked into details such as what attributes you should use to document your requirements, but provides plenty of pointers and references to sources in books and websites.
Chapter 5 covers Gathering Requirements (aka eliciting, discovering, capturing). As Young says 'A lot of time and effort is wasted' and he gives detailed reasons for this. He does not make the mistake of supposing that an 'effective proven procedure' is the sole solution: indeed, the lack of one is just reason #7! The others are crucial practical matters, like the fact that the project is 'just getting organized and things are confused' and tellingly 'There isn't much pressure to meet the schedule yet'. You can tell that he has been there and seen that. The RA has to work in the real imperfect world; tools, techniques, and even processes are only a part of the solution. There is a daunting but on inspection highly sensible 28-step checklist for project requirements gathering activities: 'perform requirements gathering' is step 22. There are plenty of pitfalls for the unwary: Young doesn't say that fools rush in, but the implication is there. There's even a suggested 'topics for training for RAs', i.e. an outline syllabus. As you'd expect, this covers not only 'the mechanisms, methods, techniques, and tools' but also 'having and using a requirements process' and 'reducing rework on the project'. After all, if systems engineering is about anything, it is the carpenter's maxim: measure twice, cut once. Young is right to emphasize the reduction of rework; few other authors even mention it.
Chapter 6 looks at best practices: something easily said and less easily done, because "it's a lot of work". 30 best practices are listed and described in a paragraph or two each, but first there's some practical advice on how to get people to adopt them, and at the end there's again a case study which tells a detailed story of a real project experience, and not a comfortable one at that.
Chapter 7 has already been mentioned. It again looks at a list of topics. These are framed as Socratic questions, like "Why are requirements errors so devastating and how can RAs help address the problem?" These are answered at length, quoting various authorities, and discussing the difficulties and risks of the proposed solutions. For instance, use cases are not accepted uncritically: "Be sure to digest [Kulak & Guiney's] considered list of problems related to using use cases before making a decision"; Tim Korson's 'Misuse of Use Cases' is also applauded.
Chapter 8 discusses 'An Integrated Quality Approach'. As with standards, the nice thing about quality approaches is that there are so many to choose from; Young mentions TQM, 6σ, Quality is Free, Zero Defects and ISO standards among others. Since "quality initiatives are difficult to sustain" (the enthusiasm fades when the guru walks away), Young rightly emphasizes the integral connection between requirements and quality, and the essential role of management. He then stresses some simple Guiding Principles, the first of which is "Customer satisfaction is imperative for our continued existence." The others are just as necessary. Using and valuing these helps "create a sense of purpose for employees". After that, quality improvement techniques have a chance of working.
Chapter 9 presents A Vision for Requirements Engineering. It asks how we should support project managers, customers, and developers through better requirements work. Young answers this in typically pragmatic fashion: "This is not a job for the most junior member of the team or the least talented member of the group." Indeed not.
Finally Chapter 10 looks at Moving Forward. Young recommends "not trying to change everything at once", and suggests selecting "three to six practices or areas for your own personal commitment list." The task, in other words, is not something theoretical, but a matter of learning how to do the job better -- and doing it.
This is an industrial handbook with a constant focus on 'how to'. The perspective is, as with Effective Requirements Practices, largely from the point of view of technical management, responsible for overseeing the slippery and complex activities that do much to determine the success or failure of system development projects, small and large.
The reader is helped by a full list of acronyms, a good and detailed glossary, a long list of references and an excellent index.
Requirements people in industry, whether their firms are as experienced as Northrop Grumman or relatively new to systems and software engineering, will find this a practical and thorough guide to what to do.
© Ian Alexander 2004