Roxanne E Miller
Maven Mark Books, May 2009
ISBN 1595980679
Buy it from Amazon.com
Buy it from Amazon.co.uk
In this likeable book, Roxanne Miller looks at requirement discovery as a process of asking 'probing questions'. Despite the plethora of books on requirements, very few have focussed specifically on techniques for discovering them.
If Requirements Engineering consists of two broad sets of activities, Requirements Discovery (RD) and Requirements Management (RM) -- and even this small amount of structure and naming is barely agreed by practitioners and researchers, to be followed by Analysis and Design, then frankly most books are on Analysis and Design, with a nod to RD and RM. In Kotonya and Sommerville's classic Requirements Engineering, for instance, there are about 12 pages on 'Elicitation techniques', mentioning interviews, scenarios, observation, reuse, and (without an explicit heading) 'reading documents', i.e. archaeology; there is then a section on prototyping which could also qualify. Even Lauesen's excellent Software Requirements, Styles and Techniques basically confines 'Elicitation' to one chapter, though there is another on techniques including observation. Alexander and Beus-Dukic's Discovering Requirements does, I hope, address the subject directly, but there remains much to be explored. Unfortunately Miller's book came out too soon after Alexander and Beus-Dukic to have been able to mine it for possible techniques: it is one of the great strengths of Miller that available knowledge and suggested techniques are carefully considered, compared and incorporated. The domain certainly needs more of this.
Part One of the book, 'Right Process, Right People, Right Tools' looks in turn at context, stakeholders, and interviewing.
She begins with a quick but careful overview of the context of RM, explaining the RM process, including the classic levels of systems engineering (business, user, system) - and of course one can go down from there to subsystem and so on. There is then a brief but admirable coverage of life-cycles and the need for iteration. She then adapts the Zachman framework to RE (in a manner not unlike Hay's pioneering Requirements Analysis), yielding the topics data, process, logistics, roles, timing and purpose (what, how, where, who, when, and why). In other words, this book is all about questions, lots of them. (This is not a chapter on context modelling, which Miller would consider Analysis - in this she is more strictly focussed on RD than Alexander and Beus-Dukic.)
Chapter two seeks to involve the right stakeholders: again, this is not a chapter on stakeholder analysis, but advice on engagement, including building a profile of each stakeholder. There is an interesting classification of roles with respect to requirements: people can be requirement producers, suppliers, receivers or supporters. For instance a project manager is a supporter, a model analyst is a requirement supplier, while a requirements engineer is a producer. The classification is then applied to different industries - banking, insurance, higher education.
Chapter three is a more conventional look at interviewing. The chapter is structured with 'tips and tools' throughout. There are mnemonics and much practical guidance; and the summary
'Interviewing is very much a social skill that requires practice to master'
is spot on. The suggested reading includes Gottesdiener's wonderful Requirements by Collaboration, and acknowledges the valuable part that workshops can play, but there is no chapter on requirements workshops here.
Part Two, 'Right Approach, Right Questions' looks at how to discover 'nonfunctional' requirements (NFRs) (it turns out that Miller dislikes the term as much as anyone), and offers 'over 2,000 suggested elicitation questions': gulp. The motto at the start of Part Two however runs
'It is better to ask a few
well-thought-out questions,
than a lot of questions
without thinking.'
The challenge, of course, is to know which ones to choose.
Chapter four gives an overview of NFRs and explains why they are hard to write. It classifies NFRs into three types - Operation[al] Requirements, Revision Requirements, and Transition Requirements. These form the matter for Chapters 5, 6, and 7. Each section of these chapters is structured to identify the User Concern addressed, Related Categories, definition and discussion of the category, examples, and suggested questions for the requirements engineer or business analyst (Miller recognises both roles).
Chapter five covers Operation Requirements (for software only, remember) include security, availability, survivability and so on. Each is given a 3-letter code, e.g. AVL for availability, and each is associated with a 'User Concern', e.g. 'How dependable is it during normal operating times?', again for availability. Despite the practical, well-thought-out and commonsense approach here, it is at once clear how contentious this whole area is. And as usual, I wonder why so many books restrict themselves to software, when so much of the thinking - but crucially not all of it - applies to system requirements as well.
Chapter six covers Revision Requirements, such as flexibility (a real challenge), maintainability, and verifiability. No other book has gone into anything like this amount of detail on this topic.
Chapter seven covers Transition Requirements, namely interoperability, portability and reusability - again, a much-neglected area.
The modified Zachman framework is applied systematically to each software requirements category in each of these three chapters, resulting in a substantial quantity of questions to ask. For example, section 6.1.4 is Flexibility Suggested Questions, such as 'What information is heavily accessed?', with the guidance "Ask this to: determine flexibility metrics". There is roughly a page on each Zachman topic for each requirement category. The three chapters thus take up well over half the book, and over half of that consists simply of lists of questions. It is a prodigious feat of analysis, and as the cover blurb suggests, an unprecedentedly detailed answer to the novice analyst's question 'But what should I actually ask?'. Of course, analysts cannot be expected to hold 2,000 questions in their heads; nor should they mechanically (a la IBM systems analysis manual, circa 1967) step through so many questions and believe they have then done all the requirements. As Miller says, interviewing is a social skill, and mechanical guidance, even the best, can only take you so far. Analysts will certainly find Miller's guidance invaluable for reference, planning and interview (or workshop) preparation.
The depth of analysis implied is sobering; perhaps it will go some way to countering the neglect of the many types of requirement other than bare functions of software: for the truth is, most of the task is to discover the hidden requirements, assumptions, rules, context, implied constraints, conflicts and simple misunderstandings, not the day-to-day functions. If ever the phrase 'the tip of the iceberg' was appropriate, it is here. Functions for normal operations form the very tip; housekeeping functions, error-handling functions, and the user interface's required behaviour form several more layers, down to the surface and below; operational qualities such as reliability and usability form a yet deeper layer; and Miller's revision and transition categories lurk in the cold abyssal depths.
Miller has set herself a tremendous challenge in writing The Quest for Software Requirements. Few other authors have really concentrated on requirements discovery; and none have focussed solely on 'nonfunctional' requirements for business, nor attempted a comprehensive guide to questions suitable for eliciting them. Every business analyst should have a copy to hand.
© Ian Alexander 2011
| USA, Worldwide: | From the UK: |
|---|---|