Customer Reviews

The Quest for Software Requirements

5 star:		(6)
4 star:		(0)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

The 'Quest for Software Requirements' is all those things mentioned in the 2 previous reviews. But I would like to highlight the deep and excellent treatement of Stakeholders. It is extensive, insightful, and the best treatment of stakeholders I have seen in a book. We need, as a software profession, to move from the narrow concepts of requirements for users and customers, to the broader and all inclusive notion of the system stakeholders, their values and needs - leading to a less risky set of requirements, and to priority information about those stakeholder requirements.

Of course I am delighted at the extensive treatment of quality requirements, as too many books gloss over the subject - like most software developers, and the Agile culture in particular does.
The incredibly detailed list of questions on all manner of subjects leaves me in two minds. They are really quite good questions. But I cannot see developers actually asking them and answering them for each project. But as a source for sampling and probing, for auditing a project I can see more use. I can also see their use in teaching students the kinds of things to look out for. A teacher student dialogue could be used to bring out why the question and its answer might be useful.

I would recommend this book as a requirements study textbook, to help nurture the new breed of software engineers to can think maturely about stakeholders and quality.

In an age when many technical books provide little more than cheerleading for one technique or another, it is refreshing to come across a book that is genuinely useful. The subtitle of Roxanne Miller's book gives us the clue as to what this book is about: "Probing questions to bring nonfunctional requirements into focus".

The book has two parts, which I will explain to show you why I think this is useful. In the first part Ms. Miller takes us through an introductory piece on requirements. She is not attempting to make this an exhaustive treatise on gathering requirements. Instead, its purpose is to bring readers up to speed and preparing them to mine the value of part two. In the second part of the book (I cannot call it the second half because it occupies most of the book), Ms. Miller provides us with an extensive list of nonfunctional requirements. Then comes the value: for each of the non-functional types she provides an expansive list of questions that the business analyst would do well to ask. This is not merely a checklist for the business analyst to tick off as he or she works through the pages. Instead, it provides questions that challenge the business analyst, and the stakeholders, to consider seriously the particular nonfunctional requirement type being dealt with at the moment.

Nonfunctional requirements are a major contributor to successful projects and products, and bewilderingly, are often ignored by development teams. Ignoring the nonfunctional requirements, or leaving them to the goodwill of the developers, almost always results in substandard products that are rejected by the users. Agile development teams are well advised to take note of this book--user stories are usually about functions or features. There is growing evidence that agile teams are not adequately discovering the appropriate nonfunctional requirements. Even a cursory reading of Ms. Miller's book reveals many requirements that could easily be missed by the user story writers.

I think that the best recommendation I can give this book is to say that I shall give a copy to the project on my consulting assignments. I know it is going to have a beneficial impact.

James Robertson, author Mastering the Requirements Process and Requirements-Led Project Management, London, April 2011

The Quest for Software Requirements brings the difficult and oft neglected topic of nonfunctional requirements to the forefront. After an excellent treatment of analyzing the 'who' (stakeholders), Roxanne's book dives deep into the details of nonfunctional requirements, supplying useful categories, examples, and question sets. Analysts, developers, testers, and network engineers alike will benefit by reading and referencing Roxanne's thorough resource.

Book Review of The Quest for Software Requirements, by Roxanne Miller, Certified Business Analyst Professional
This book fills a critical void in the business analysis and requirements engineering literature by answering a question that is critical to the success of any system development project: "How can the system's nonfunctional requirements best be determined?" While functional requirements describe what the system must do, the nonfunctional requirements define how well it must do it.
Nonfunctional requirements embody important elements of quality for software systems. A thorough specification of nonfunctional requirements creates systems (whether developed or purchased) that: have fewer errors, result in greater user satisfaction, have more realistic time and cost estimates, result in greater user satisfaction, are more comprehensive, and better fit business needs. These are vital ingredients in every development effort.
The Quest for Software Requirements defines and applies a user-focused classification for all of the categories of nonfunctional requirements. The intent of this book is to bring greater consistency, clarity, and understanding to the term "nonfunctional." The author succeeds superbly!
The nonfunctional classification comprises three software user needs:
OPERATION REQUIREMENTS: How well does the system perform for daily use?
REVISION REQUIREMENTS: How easy is it to correct errors and add functions?
TRANSITION REQUIREMENTS: How easy is it to adapt to changes in the technical environment?
These three requirement groups are further subdivided into 14 common nonfunctional categories. The book provides over 2,000 suggested questions to help you elicit nonfunctional requirements, and is a very useful feature of the book. In addition, this book offers step-by-step guidance on how to: (1) build a stakeholder profile and get the right people engaged, and (2) prepare for and conduct a successful requirements-gathering interview. These steps are critical in gaining commitment of the stakeholders, a critical objective.
The following outline describes the contents of the book:
PREFACE
a. Purpose and Scope
b. Who Should Reference This Book
c. Benefits of Using This Book
d. Skills and Experience Needed by the Reader
e. How This Book is Organized
f. What This Book is NOT
g. Collaboration Beyond This Book

PART ONE: Right Process, Right People, Right Tools

Chapter 1. Requirements in Context
1.1 What is a Software Requirement?
1.2 Levels of Requirements
1.3 A Requirements Management Process
1.4 Requirements and the Software Development Lifecycle
1.5 A Requirements Framework
1.6 What Requirements are NOT
1.7 Chapter Summary
1.8 Suggested Reading
Chapter 2. Involve the Right Stakeholders
2.1 Utilize the Right Sources
2.2 Engage the Right People
2.3 Build a Stakeholder Profile
2.4 Chapter Summary
2.5 Suggested Reading

Chapter 3. Interviewing Tips and Tools
3.1 Preparing for the Interview
3.2 Asking the Right Questions
3.3 Conducting a STAR Interview
3.4 Chapter Summary
3.5 Suggested Reading

PART TWO: Right Approach, Right Questions
a. The Anatomy of a Nonfunctional Requirement Category
b. How to Use the Suggested Questions

Chapter 4. Understanding Nonfunctional Requirements
4.1 Are the Definitions Dysfunctional?
4.2 Nonfunctional Challenges
4.3 Vital, Yet Why so Difficult?
4.4 Classification Efforts
4.5 A User-Focused Approach
4.6 Chapter Summary
4.7 Suggested Reading
Note that for ease of use of both in the book and on your projects, acronyms are provided for the 14 categories on nonfunctional requirements identified below.
Chapter 5. Operation Requirements
5.1 Access Security (ACS)
5.2 Availability (AVL)
5.3 Efficiency (EFC)
5.4 Integrity (INT)
5.5 Reliability (REL)
5.6 Survivability (SRV)
5.7 Usability (USE)
5.8 Suggested Reading
Chapter 6. Revision Requirements
6.1 Flexibility (FLX)
6.2 Maintainability (MNT)
6.3 Scalability (SCL)
6.4 Verifiability (VER)
6.5 Suggested Reading
Chapter 7. Transition Requirements
7.1 Interoperability (IOP)
7.2 Portability (POR)
7.3 Reusability (REU)
7.4 Suggested Reading

The layout of the book facilitates its ease of use. The following description is included at the beginning of Part Two.
THE ANATOMY OF A NONFUNCTIONAL REQUIREMENT CATEGORY
This section describes the presentation layout of each nonfunctional category included in chapters 5 through 7. As shown below, the following information is provided for each nonfunctional category:
(a) Nonfunctional Category Name. Each category is named.
(b) User Concern Short Description. A brief question is used to identify a general concern that users have regarding the software system.
(c) Related Categories. The relationship of this particular nonfunctional category to other categories is described. Information concerning how other categories might influence this category is provided. Guidance is provided concerning changes that might be made and other categories that might be affected.
(d) Category Definition. Each nonfunctional category is defined.
(e) Category Discussion. The nature of the nonfunctional category is described along with further information to clarify the category.
(f) Category Examples. Real-world requirement statements are provided to illustrate requirements derived from the requirements-gathering activities.
(g) Category Suggested Questions. A list of suggested questions is provided to help the user of the book apply the categories and to help ensure that nothing is overlooked.
The interest areas are:
DATA--What information is used within the system?
ROLES--Who (user roles) provides and/or receives information in performing these business functions?
PURPOSE--Why is the information necessary? What is the business rationale or strategy?
TIMING--When is the information used?
LOGISTICS--Where is the information used?
PROCESS--How is the information used? Is there a process or procedure that drives usage?
Having worked in the requirements area for many years and written several books in this area, I can attest that this book fills a critical void. It will help any developer perform his or her role. The application of the book will result in a much more robust definition of the real requirements. Its use will save time and money. It will result in more satisfied customers.

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.

Roxanne supplied fabulous information about an aspect of requirements so often overlooked...Non-Functional requirements. Her book will help you bring these type of requirements into the focus early in the development process...providing key information to designers, network engineers and many more involved in making sure what you build will work in the environment it is intended to work. I commend Roxanne in the organization of the book. So nicely presented it facilitates the reading and absorbing of her information.