Customer Reviews

2 Reviews
5 star:
4 star:    (0)
3 star:    (0)
2 star:    (0)
1 star:    (0)
Average Customer Review
Share your thoughts with other customers
Create your own review
Most Helpful First | Newest First

2 of 2 people found the following review helpful
5.0 out of 5 stars Probing Questions for 'Nonfunctional' Requirements, 3 May 2011
I. Alexander (London, England) - See all my reviews
This review is from: The Quest for Software Requirements: Probing Questions to Bring Nonfunctional Requirements Into Focus; Proven Techniques to Get the Right Stakeholder (Paperback)
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: Processes and Techniques (Worldwide Series in Computer Science), 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: How to Specify Products and Services 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 Architecture: from Business Views to Architecture), 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: Workshops for Defining Needs, 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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No

1 of 1 people found the following review helpful
5.0 out of 5 stars A valuable asset to the practicing requirements specialist, 17 Jun. 2011
Jeremy Dick (Oxfordshire, UK) - See all my reviews
This review is from: The Quest for Software Requirements: Probing Questions to Bring Nonfunctional Requirements Into Focus; Proven Techniques to Get the Right Stakeholder (Paperback)
Roxanne Miller has dared in this book to express her aversion to the term "nonfunctional" requirements - a dislike shared by so many systems and software engineers. She quite rightly suggests replacing the term with a richer classification. (Read the book to find out what this is!)

As the title suggests, the main focus of the book is on requirements elicitation through interviewing, and nearly half the 300 or so pages are devoted to incredibly thorough lists of questions that can be used to elicit a wide range of types of requirement spanning the whole taxonomy. (Incidentally, this means that the second half of this book does not lend itself to being read cover-to-cover! The 2000 questions are definitely reference material! But it is this reference material that makes this book valuable to the practicing requirements "producer".)

Even though the book is clearly scoped for software requirements, practically all of the same principles apply to the wider systems field. Clearly the taxonomy would need to be extended to cover the constraints relating to physical entities, such as mass, fluid dynamics, emissions, and so forth; but many of these concerns are so discipline-specific that it is difficult to imagine that any single volume would be appropriate to capture them.

One thing the book is definitely NOT about is how to express requirements (in words or otherwise). However, since the expression of requirements is a subject that rather interests me, I found a rich source of example requirement statements in Roxanne's book, embedded in the classifications of Part 2. Many of these statements I would want instantly to rewrite, but that is not the principle concern of the book!

All in all, I find this book a valuable addition to the requirements stable, one that complements the topics covered by other volumes.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No

Most Helpful First | Newest First

This product

Only search this product's reviews