Rosemary
Hossenlopp and Kathleen B. HassManagement Concepts, 2007
Rosemary
Hossenlopp and Kathleen B. Hass
Management Concepts, 2007
ISBN 1567262104 (paper, 211 pages)
Buy it from Amazon.com
Buy it from Amazon.co.uk
From the rear cover: "This book helps you learn how the business analyst works collaboratively with the project manager and other core team members to create plans that customize elicitation activities to the unique needs of the project. The author presents techniques used by successful business analysts and defines key business analysis terms. This book lets you examine the principles and practices for pragmatic, effective requirements elicitation and learn how to work collaboratively with project members and other core team members. You can discover the steps necessary to create customized elicitation activities for the unique needs of each project."
The authors of this promisingly-titled book, Hossenlopp and Hass, both have a background in project management. The focus of this book is "business requirements" by which the authors mean not simply (a la Robin Goldsmith) requirements from a business - which could apply to any kind of system or service - but specifically requirements for business process support software. This message is reinforced by the strapline "Business Analysis Essential Library" on the front cover and "Introducing the first comprehensive resource for professional business analysts!" on the rear.
The book is structured as 3 parts.
Part I, Requirements Elicitation at a Glance, is a single chapter that looks briefly at what elicitation is, terminology, and the question of when it is complete.
Part II, Planning Requirements Activities - nearly half the book - has chapters on setting up the team, assessing project size and risk, stakeholder analysis, choosing the life-cycle, and planning requirements activities. It can be seen that most of this is not "elicitation" as such, and the authors' strength in project planning is revealed. For example figure 6.2 gives a clear and helpful work breakdown structure (WBS) which gives at least as much guidance as the text on how to organize requirements activities.
Part III, Elicitation in Practice, takes up a scant 50 pages. The chapters cover workshops, interviewing, surveys, review, interface analysis, and "supplemental requirements", i.e. non-functional requirements (NFRs), the required qualities and constraints.
The advice given in the body of the book is clear and practical, but is almost entirely phrased in general terms, with no examples (text, diagrams, or tables) in the chapters.
The Appendices occupy the final quarter of the book, with detailed templates consisting of document headings and italicised guidance text but despite the "sample" in the title, very few actual examples; and many sections (e.g. risks, glossary, use cases) contain no examples at all.
The use of the term "supplemental requirements" (SRs) for NFRs was obscure to me. Chapter 13 (just over 2 small pages) did nothing to clarify matters, as the first page just referred me to a table claiming the benefits of eliciting SRs to be "uncovers areas of end-user/customer solution adoption risk", while the disadvantages include "difficult for end-users to articulate quality specifications without prototypes so they can visualize the proposed business solution". A second table advises readers to scale the elicitation effort for small, low-risk or large, complex, high-risk projects, for instance by conducting separate meetings for SRs, but again without saying anything about the substance. Appendix B section 6.0 fortunately gives a template, including access management, external interfaces, hardware interfaces, software interfaces, communications interfaces, security, performance, software quality attributes ("some to consider are maintainability, supportability, interoperability, availability (if not covered under performance)"), and business rules. Thus the SRs can be seen to include interface and performance constraints, qualities, and rules. Examples are given in the appendix of the interface requirements but not of the other types.
The guidance offered in this compact book is plain, practical and accurate. Contrary to the title which implies a focus on requirements discovery, the book is strongest on requirements management aspects such as planning, documenting and review. Business analysts will find it helpful with templates that can be applied directly to their projects.
(c) Ian Alexander 2009
You may also like:
