|
|
Recommended Requirements Books
 |
Mastering the Requirements Process - Suzanne and James Robertson
"Mastering the Requirements Process shows, step by step, template by template, example by example,
one well-tested way to assemble a complete, comprehensive requirements process." - Gerald Weinberg
"The book soon began to impress me with its practical knowledge. It became apparent that Suzanne and James
Robertson have dealt with the real-world problems of gathering software requirements. As a result, I think the book
makes a valuable contribution to the literature of software engineering." - Capers Jones
Amazon.com
|
 |
Writing Better Requirements - Ian Alexander and Richard Stevens
This book provides practical and detailed guidelines on how to write user requirements in a style that is understandable
by business people and developers. The authors' approach to writing requirements addresses the "gulfs to be bridged" between: development
and marketing, users and developers and staff and customers. They provide convincing examples of how even the simplest project has a
complex set of stakeholders and how the requirements depend on identifying and involving these stakeholders. And the section on
workshops is packed with hints on how to run a requirements workshop and get tangible input from all the stakeholders. Scenarios
are effectively used to identify, structure and link goals and requirements. Each goal is connected to a number of primary and exception scenarios and each scenario is made up of a number of atomic requirements.
The chapter on requirements writing gives advice on how to write good atomic requirements and also discusses common pitfalls like ambiguity, speculation and rambling and how to avoid them. Frequent exercises (along with sample answers) steer the reader to detailed consideration of the everyday problems of a requirements engineer.
I found the discussion of different names for requirements, constraints and goals to be a trifle confusing. But, to be fair, requirements engineering is an emerging discipline and terminology has not yet stabilised.
I recommend this book to anyone who would like a clear non-academic guide to what requirements writing is, or should be, all about and why it matters. The book is suitable for business people and developers. The authors have done what they set out to do; they have bridged the gap. Review by Suzanne Robertson. Amazon.com
|
 |
Contextual Design: Defining Customer-centered Systems
This book has more yellow Post-it notes sticking out of the top than any other on my bookshelf. That's because there are so many insights inside that I do not want to lose. Please do not be misled by the word "design" in the title. The important part of this book is about contextual inquiry, where the developers work with the users to understand the work needs before attempting to design anything. Beyer and Holtzblatt give us a raft-load of ideas on how to get close to the customer, and how to understand what is really going on.
Contextual Design places great faith in the customer data - information and understanding of the customers and how they work. "Without a clear understanding of your customers, based on real events rather than anecdotes, and captured explicitly, you have no criteria for deciding on one action or design decision over anotherÉ.. But customers cannot tell you the important aspects of their own work practice because they are implicit and unrecognized. ÉContextual Inquiry reveals the hidden aspects of the work practice; paper prototyping reveals how a particular design plays out in the real work context."
This book is highly recommended for business analysts, and anyone whose work is understanding work.
Amazon.com
|
 |
Requirements by Collaboration - Ellen Gottesdiener
With thanks to Ian Alexander for the following: It really isn't every day that someone writes a book that provides a completely fresh take on requirements. Ellen Gottesdiener has managed to do just that. This readable and practical book is visibly based on a wealth of direct experience of facilitating requirements workshops, and her message is focused exclusively on the power of the workshop approach. This does mean that this book isn't for every project - if you are working on a subsystem under a strict contract, there is little scope for collaborating with stakeholders to work out the
requirements together. To her credit, Gottesdiener carefully points out the limits of her approach, and she is admirably well-read.
The book uses the language of Use Cases, and refers to other UML diagrams along the way. It also mentions software from time to time, but this is definitely a book that is useful in systems of all types - from civil engineering projects to personal music players.
There are parts of this book that benefit enormously from Gottesdiener's natural enthusiasm, and the simple fact that she is American. She is able to talk in a simple and effective way about making workshops fun; about drawing mandalas and using the 4 principles of the native American medicine wheel; even about using toys as prizes and holding warm-up exercises to get people into collaborative mood.
Even engineers who have been running workshops for years will find new insights, conceptual tools and techniques in this lively and welcome contribution. Every requirements engineer should have a copy in a handy place on their bookshelf. © Ian Alexander 2002
Amazon.com
|
|
Software Requirements - Styles and Techniques -Soren Lauesen
Soren Lauesen's new book, Software Requirements - Styles
and Techniques deals with traditional and more cost/effective ways of expressing
requirements. He looks at ways of gathering, verifying, and maintaining
requirements; ways of getting commitment from the stakeholders, and ways
of ensuring that you meet the business goals. The book discusses the styles
and techniques useful for different project types, for instance software
developed specifically for the customer, software bought off-the shelf and
adapted for the customer (COTS), and software developed for a broad market.
The book illustrates everything by means of real-life requirements. It
also deals with difficult requirements, for instance how to specify ease-of-use,
how to specify very complex computations, and how to deal with 200 reports
that the old system has, and the new system may or may not need. The book
shows two full, real-life specifications and large parts of several others.
It also has exercises and figures suitable for presentation and discussion.
Amazon.com /
Amazon.co.uk
|
|
The Art of Innovation. Lessons in creativity from IDEO, America's leading design firm - Tom Kelley
In this book Tom Kelley, the brother of IDEO founder David Kelley,
tells stories. And like good stories, we learn from them. Kelley sets out to teach us how IDEO come up with their great products - the original Apple mouse, the Palm V, Handspring Treo, and their Visor Edge, TiVo and countless others. Through his recounting of brainstorming sessions, prototyping efforts and other activities at IDEO, we learn how to do it ourselves.
Why is this important? In the software industry we must continually innovate, and yet we get little training in how to innovate. The lessons that
Kelley teaches are applicable to software products not just the flashy desktop products aimed at consumers, but also the day-to-day software that we build for in-house consumption. Try Kelley's book, you will find it enjoyable and valuable.
Amazon.com
|
 |
Software Requirements & Specifications - a lexicon of practice, principles and prejudice - Michael Jackson
This is a book of ideas. You may not agree with all of them, but all of them will make you think about the subject, and some of them will make you think differently about the subject. Jackson deals with 75 topics, and lends his wit and thought to the field of software requirements analysis, specifications and design. He is not concerned with method, just some of the thinking that should be going on as you are gathering requirements. He is concerned that we understand the problem well before attempting to find a solution to it. This means analysing and structuring the problem itself, not the solution.
While Jackson does not present a method, Ben Kovitz (ibid.) makes more of Jackson thoughts. Highly recommended.
Amazon.com
|
 |
Software Requirements - Karl Wiegers
Karl Wiegers takes a look at the requirement topic with the project manager in mind. He treats the requirements process with an eye on risk management and change management, and some wise words on negotiating the harder steps of the development process. This is to be commended, as requirements and project management are far more closely linked than many people seem to see.
But it is not all project management. Karl also presents a lot of good advice on how to gather the requirements from a practitioner"s point of view. He presents a case study for a chemical tracking application that appears throughout the book, and the stories from the authour"s experience are worthwhile reading.
Recommended reading from a wise and charming author.
Amazon.com
|
 |
Exploring Requirements: Quality Before Design - Donald Gause and Gerald Weinberg
This book has been around for quite a while, but continues to be one of the important books in the field. Gause and Weinberg explore the area of requirements that most people find hard - the ambiguities, the difficulties in understanding people, the little things that are said that cause the requirements person to completely misunderstand the user's intention. It is not hard, say G & W, to get what you ask for. The problem is asking for what you really want. And this is the crux of the book - how to think about requirements, how to understand what the user is saying, how to listen to what is really being said.
It is not just the content that causes this book to remain popular. Don and Jerry's style has a lot to do with that. They are witty and wise. They entertain you as you learn. The stories of the requirements for the Do Not Disturb and the Superchalk products are particularly engrossing. They make sure that you are provoked as you work through their other examples.
But I feel that the lasting legacy of this book is the authors' ability to discuss frankly how requirements gathering is not an easy task. It is a challenge for the analysts and their users, indeed for all the stakeholders. G & W also talk about the delight when the requirements analysts understand what the user is thinking, even when the user is not articulating his thoughts.
This book is essential reading for everybody in the field of requirements.
Amazon.com
|
 |
Requirements Engineering and Rapid Development, an object-oriented approach - Ian Graham
Amazon.com
|
 |
Process for System Architecture and Requirements Engineering - Derek Hatley, Peter Hruschka and Imtiaz Pirbha
Amazon.com
|
 |
Complete Systems Analysis: the Workbook, the Textbook, the Answers - James and Suzanne Robertson
From the Foreword by Tom DeMarco "Suzanne and James Robertson serve as your hosts for the unique experience that lies ahead. From the very first page, an extraordinary and wonderful page, you will know you're in good hands. You'll know too that this book is fundamentally different from any other analysis text you may encounter. It doesn't lecture at you, it doesn't take up your time telling you anything you already knew. It lets you proceed not only at your own pace, but in your own direction. It's a book that you don't exactly read at all; instead you sort of ski through it, along a path of your own choice. Well, they'll explain all about that......"
This is a book about the craft of systems analysis and systems modeling. It looks at how you can understand a business by modeling it. The book teaches all the models that a business analyst needs to come to grips with any piece of work under study.
"the Robertsons' theory is heavily integrated with practical exercises. . . . you will appreciate the tremendous effort the Robs have put into making this book a true learning tool." - Warren Keuffel, Software Development
Amazon.com
|
 |
Customer-Centered Products: Creating successful products through smart requirements management - Ivy Hooks and Kristin Farry
This book promises to be different. Hooks is very experienced, with a long career at NASA behind her. Kristin Farry is 'an engineer and pilot and a space shuttle flight controller'. This is not your normal requirements book. As soon as you are inside it you understand that they are addressing managers, and telling them how to ensure that the requirements are written before the product is built. I loved the debunking of the corporate requirement management myths:
- Everyone knows what the project is about.
- Everyone knows how to write requirements.
- We already have a requirements management process in place.
- Everyone understands our requirements process.
- Nothing can be done about bad requirements.
Buy this book for your boss.
|
 |
Problem Frames - analyzing and structuring software development problems - Michael Jackson
Jackson is back with a follow up to his Élandmark
Software Requirements & Specifications. This time he has lent his wit and intelligence to analysing and structuring the kind of problems faced by the software developer. Jackson argues that software development is about solving problems where there are very few well-understood problems. The aeronautical engineer does not have to be told that the plane has to fly and carry passengers, and by the way, take off and land. But as software is so malleable, we are usually faced with problems that very little of the basis is known.
His inference is that you must start by asking: What kind of problem is this? What purpose is being served in the world? What behaviour and properties must the computer have to achieve that purpose? JacksonÕs problem analysis takes you from the level of identifying the problem to the level of making the descriptions needed to solve it.
The central idea of this book is to use problem frames in problem analysis and structure. A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions.
Jackson is always informative and thought-provoking. Not a bad combination.
Amazon.com
|
 |
Practical Software Requirements: a Manual of Content & Style - Benjamin Kovitz
"Authored with an eye toward the novice, Practical Software Requirements is a comprehensive guidebook for drafting project requirements. The author's in-depth examination includes non-hierarchical ways to break down complex problems, elements of the problem domain, and different information needed to address different problem types.
An extensive style section addresses the detail of making information
understandable focusing on how to group and sequence topics, writing definitions, and how to avoid boring the reader. Filled with examples this title should be considered required reading BEFORE graduation!" -- CompBookReview.com, October 99
"Kovitz starts by demolishing "the myth of functional decomposition" (which is actually the title of Section 1.1). As he points out, a good engineer is one who knows a lot about problems that have been solved in the past, and can use that knowledge to figure out which of those proven solutions should be applied to the present problem. Defining a problem's requirements is therefore really about gathering the information needed to choose, and customize, a solution (or set of solutions).
All of this is good stuff, and I learned quite a bit from the first few chapters of this book -- especially Chapter 5, which describes five common kinds of problems, and the sorts of questions that a requirements document should answer for each." - Gregory V. Wilson for Dr. Dobb's Journal, August, 1999
Even this brief glimpse of Kovitz' approach may be enough to hint at where he is coming from, and the suspicion is confirmed by the cover blurb: "he has worked as programmer, tester, system analyst, user-interface designer, and technical writer". This bespeaks an impressive personal knowledge, but perhaps specifically not a process view, and maybe especially not a systems view. Kovitz aims at and achieves great clarity of human communication with other engineers, just as in his user-interface work -- and there are excellent UI examples in the book, including a fully-worked Bug Log which, as he says, 'interfaces only to people' -- he certainly helped systems to communicate with their users.
Kovitz has written a fresh, lively, honest, funny, and provocative book on a serious engineering topic.... Ian Alexander
Amazon.com
|
 |
Software Requirements: Objects, Functions and States - Alan Davis
Amazon.com
|
 |
Managing Software Requirements: a Unified Approach - Dean Leffingwell and Don Widrig
Amazon.com
|
 |
Requirements Engineering: a good practice guide - Ian Sommerville and Pete Sawyer
Amazon.com
|
This work is copyright © 1995 - 2002 Atlantic Systems Guild, but may be
adapted for your internal use provided copyright is acknowledged.
|
