|
Home
About the Guild
Articles
Books
–New Books
–Guild Books
–Guild Library
Consulting
Contact us
Resources
–Requirements
–Software Engineering
–Project Management
–Other
–Cocktails
Requirements Template
Seminars
–Mastering Requirements
–Risk Management
–Requirements Modeling
–Mastering the Requirements Process part II
Services
–Litigation Support
–Project Clinics
–Physical Exam
Volere
| |
The books listed here are notable books that have come our way
recently. There is also a list of books
by Guild authors.
 |
Requirements-Led Project Management — Discovering David's Slingshot Suzanne and James Robertson's new book published by Addison-Wesley. From Barry Boehm's foreword:
You'll find this book a treasure trove of experience-based guidelines and illustrative examples on how to get the requirements right on your project. These include guidelines and examples on treating the requirements as an investment activity in Chapter 2; getting the right people involved and understanding their cultures in Chapter 3; techniques for stimulating mutual learning and a shared vision among stakeholders in Chapter 4; the use of prototypes and simulations in Chapters 5 and 6; dealing with legacy systems in Chapter 7; and managing systems requirements, systems of systems requirements, and requirements processes in Chapters 9, 10, and 11. Each chapter concludes with a nicely balanced set of "What do I do right now?" and "What's the least that I can get away with?" checklists.
As a bottom line, the book does a wonderful job of lifting its readers from a focus on templates and objects to a focus on peopleÕs needs, capabilities, and ability to work together to achieve a shared vision of the requirements (and the design) for a system that will satisfy all their needs and constraints. I hope you have the opportunity to use its practices on your next project.
— Barry Boehm
Requirements-Led Project Management — Discovering David's Slingshot at Amazon
Read Ian Alexander's review
Download a sample chapter
|
|
We are very happy to announce that Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Tim Lister was awarded the 2003 Software Development Jolt Product Excellence Award in the general books category. The Jolt Awards are presented every year to products that have "jolted" the software industry in a positive way.
Greater risk brings greater reward, especially in software development. A company that runs away from risk will soon find itself lagging behind its more adventurous competition. By ignoring the threat of negative outcomesÑin the name of positive thinking or a can-do attitudeÑsoftware managers drive their organizations into the ground.
In Waltzing with Bears ,Tom DeMarco and Timothy Lister Ñthe best-selling authors of Peopleware Ñshow readers how to identify and embrace worthwhile risks. Developers are then set free to push the limits.
Go
to WWB page to download sample pdf.
Waltzing with Bears: Managing Risk on Software Projects at Amazon
|
|
Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle by Ian Alexander & Neil Maiden (Editors), John Wiley 2004.
A critical element that is lacking in too many projects is communication, and in particular skill in techniques for communicating needs. We believe that the scenario is one of the most powerful techniques for discovering and communicating requirements, and often the first choice for organising them.
On a lighter note, scenarios pass the party test, where the requirements engineer has to explain what he or she does for a living to a stranger in fifteen seconds. Where..
"I'm a systems, errm, a requirements engineer and I help to specify complex systems..."
gets a glazed look every time. However the description
"I get people to tell the stories of what their systems are meant to do, so they build the right thing"
always seems to work (and even arouse interest). Story-telling is so obviously sensible that it seems surprising that it's taken so long to become a mainstream engineering activity. Scenarios don't do everything — other approaches are needed to define goals and constraints, for instance.
In this book we present a range of scenario techniques from light, sketchy and agile to careful and systematic. There is no single 'right way' to use scenarios; we celebrate diversity in requirements discovery and modelling. There is supposedly a saying among French cooks that the English have only two sauces: brown Windsor soup (salted gravy thickened with flour); and custard (sweetened milk thickened with corn flour). Obviously if such a thing were true, the English diet would be somewhat monotonous. Happily, there are as many ways of using scenarios as there are French sauces — for every palate, season, and occasion; and like sauces, each basic scenario technique has any number of variations.
Scenarios, Stories, Use Cases at Amazon
|
 |
Balancing Agility and Discipline: A Guide for the Perplexed Our colleague Barry Boehm togetehr with Richard Turner have written a very useful book that cuts through some of the more outrageous cliams made on behalf of development methods. Nowadays, we have a choice of methods. On the one hand, there are the more agile methods that focus on individual projects, and how to get them done fast—the camp represented by Beck and Cockburn. On the other hand, there are the more disciplined methods, focused on setting up organizational processes for getting projects done with predictable high qualityÑthe camp best represented by the SEI, the CMMI, and Humphrey. Although these methods are often presented as mutually exclusive, they actually lie on a continuum. Boehm and Turner have worked out clear guidelines for determining where on that continuum a particular software development project is located—and therefore, how agile or disciplined a chosen methodology can or has to be.
Balancing Agility and Discipline: A Guide for the Perplexed at Amazon.com
|
 |
Software for your Head: Whenever you enroll yourself in
a group effort -- say a software development project -- you make
a tacit agreement to be bound by certain rules that govern interaction
within the group. The rules make up a protocol which establishes
such things as who may speak on what subject, what attitudes are
out of bounds, how much frivolity is OK, how much deference needs
to be paid to managers and senior members, etc.
Usually the rules of the protocol are informal, unwritten, implicit,
and unexamined. Jim and Michele McCarthy in their new book, Software
for Your Head, have set out to change that. They argue that
the quality of interaction is too important to be left unexamined.
And so they propose what they call the Core Protocols, a set of
explict ceremonies that directly affect team chemistry. This is
a radical and bold undertaking. I'm not willing to say (yet) that
they have entirely succeeded, but I am willing to say that you need
to know about this book. Reading it will change you and change your
practice. Whether you adopt the Core Protocols or not, you won't
be unaffected by them. The McCarthys are clearly on to something
here. If you had to choose between a project in which every task
were performed in an ideal way, or one in which the team interactions
were optimized, most of us would opt for optimized interactions.
Yet we agonize endlessly about process (how stuff gets done) and
not at all about interaction. Read Software for Your Head
and let it work its magic on you. (Review by Tom DeMarco)
Software
for Your Head from Amazon
|
 |
Applied Statistics for Software Managers: When I began to write
my Prentice-Hall metrics book (Controlling Software Project: Management,
Measurement, and Estimation) in 1980, I had a ton of collected metrics
to digest. I had been accumulating the data since 1975, but really
had no idea how to interpret it. I was a total novice in statistics
at the time, so my first task as I began to analyze my data was to
immerse myself in the arcane science of statistical methods. I used
a number of general purpose texts for this, but never attained the
degree of comfort that I felt I needed. Katrina Maxwell's book, Applied
Statistics for Software Managers, had it existed then, would have
been a godsend to me.
You may not be about to write a book about the metrics your company
collects, but if you're going to make any useful sense of them,
you would do well to pick up a copy of Maxwell's book. It is clear,
example-driven, and targeted prcisely on your needs. (Review by
Tom DeMarco)
Applied
Statistics for Software Managers at Amazon
|
 |
Writing Better Requirements: 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
Buy
it from Amazon.com
|
 |
Requirements by Collaborations: 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
Ian's
web site Buy
it from Amazon.com
|
 |
Planning Extreme Programming seems like a contradiction in
terms. However, most people seem to overlook the fact that eXtreme
Programming is not hacking, but a carefully defined way of developing
software. Martin Fowler brings his explanatory skills to complement
Kent Beck's words as they explain how to approach XP. The book is
aimed at managers, and how they should manage their XP projects. Our
own Tom DeMarco wrote the foreword.
Buy
it from Amazon.com
|
 |
Interaction Design - beyond human-computer imteraction by Jennifer
Preece, Yvonne Rogers and Helen Sharp. The book is not about buttons
and widgets. It starts way before that to look at the psychological
and social aspects of computer (and other device) users. The authors
are academics, and tend to aim their books at students. However, the
practicing professional will get a lot from this. They aim at interaction
designers and usability engineers. Their definition of interaction
design is revealing of the book itself "Designing interactive
products to support people in their everyday working lives".
This goes beyond the tradition view of designing for one user sitting
in front of a machine, and reaches designing the user experience for
a wide range of interactive technologies. The book is supported by
an innovative web site.
Buy
it from Amazon.com
|
 |
Agile Software Development by Alistair Cockburn.
"Coming of age for software developers means understanding
that software is a cooperative effort, not something individuals
do in isolation. This is a book that teams of software developers
can thrive upon, full of sensible advice for a cooperative development
approach." --Tom DeMarco
Buy
it from Amazon.com
|
 |
More Secrets of Consulting - The Consultant's Tool Kit by Jerry
Weinberg. Weinberg's original Secrets of Consulting has a place on
every consultant's (at least the ones that are making any money) bookshelf.
If you have not read Jerry's original book, you will be surprised
at how he makes simple analogies and symbols so meaningful. And how
these analogies, rules and symbols lead to a better personal performance
from the consultant. This time around he gives us the "consultant's
tool kit" of symbols. He devotes a chapter to each of these symbolic
tools, from The Wisdom Box to The Fish-Eye Lens to The Oxygen Mask.
Jerry Weinberg's career is the envy of most consultants that I know.
I find it wonderful that he is prepared to share the secrets of his
success.
Buy this book if you are a consultant, or thinking of becoming
one. Buy
it from Amazon.com
|
 |
Solid Software by Shari Lawrence Pfleeger, Les hatton, Charles
Howell is a book on software quality. The authors are well qualified;
each has a long history in the software quality field. The book sets
out to give you techniques for analysing the quality of your software.
The authors ask an interesting question: what do you want in the way
of quality? They point out that there is no universal yardstick for
software quality each fellow has a different need. What you
do about your quality depends on what you need. They give you plenty
of information on what to do.
Buy
from Amazon.com
|
 |
Michael Schrage is a fellow at MIT Media Lab (that kind of thing
always gets my attention). In Serious Play, Schrage looks
at the way that companies can use simulations and prototypes to
develop innovative products. He argues eloquently that innovation
requires improvisation, and that improvisation comes not from specification,
but from the models, the prototypes that people "play with"
on their way to inventing the better product.
Buy
from Amazon.com
|
 |
Information Visualization: Bob Spence has written a masterful
book, and one that we should pay attention to. While we work in
something called Information Technology, many of us have little
idea as to the real meaning of the "information" part
of that, and how we shpuld go about present our information. Spence
follows in the path of Edward Tufte (he makes numerous citations)
in discussing the little known art of representing information in
meaningful ways. If you would like to get beyond the pie chart and
bar charts as a way of showing information, get a copy of Spence's
book.
Buy
from Amazon.com
|
 |
This is interesting. Our associate Ian Alexander has uncovered The
Tacit Dimension by Michael Polanyi, a philosopher research fellow
of Merton College, Oxford. The nub of Polanyi's argument, and a much-quoted
aphorism, is that, quite simply, "we can know more than we
can tell."
He goes on: "This fact seems obvious enough; but it is not
easy to say exactly what it means. Take an example. We know a person's
face, and can recognize it among a thousand, indeed among a million.
Yet we usually cannot tell how we recognize a face we know. So most
of this knowledge cannot be put into words."
There in a nutshell is the key problem in requirements elicitation:
people know, and even know that they know, but cannot readily tell
us in detail what their knowledge is. Ian's
review explains more..
|
 |
The Art of Innovation: Lessons in Creativity from IDEO, America's
Leading Design Firm. 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.
Buy
from Amazon.com
|
 |
Writing Effective Use Cases by Alistair Cockburn goes a
long way to making this (unfortunately misunderstood) subject clearer
and easier. Alistair steers the reader deftly past UML, pointing
out that while UML is a graphical representation of a use case,
the most important part of it is the written description. That is,
what the use case actually does - the business rules, the process
requirements and so on. This book deserves to be read. Published
by Addison-Wesley, 2001
Buy
from Amazon.com
|
 |
Peer Reviews in Software: Karl Wiegers' new book is about a
subject that needs to be looked at closely - the review of software
products. Reviews are applicable to any of the deliverables that are
created in the development of software. He also looks at the cultural
and practical aspects of implementing an effective peer review program
in a software organization. Inspection is emphasized as the most formal
and effective type of peer review, but also describes several other
methods that span a spectrum of formality and rigor. Many references
point you to the extensive literature on software reviews and inspections.
Buy
from Amazon.com / Amazon.co.uk
There are a lot of free, downloadable peer review process assets
available at Karl's
web site, including defect checklists, inspection forms,
inspection data spreadsheets, a peer review process description,
links to sources of training, related tools, etc.
|
 |
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.
Buy
from Amazon.com / Amazon.co.uk
|
 |
Managing High-Intensity Internet Projects: Ed Yourdon has done
it again with his new, practical book on development of Internet
projects. Yourdon recognizes the differences that Internet projects
bring with them, and shows how to manages the negotiations and requirements
for Internet projects. He also tells you how to come up with strategies
that work, and how business processes are introduced into the development.
This book is aimed B2B and B2C projects, infrastructure or mobile
applications.
-
Buy
from Amazon.com
-
Amazon.co.uk
-
Also check Ed's
own web site
|
 |
Tom DeMarco's most recent book is a novel Dark
Harbor House, the story of an extended summer house-party
that takes place on an island off the Maine coast in the late 1940s.
" . . . brimming with high spirits and rollicking good
humor. A delightful tale about what is surely paradise on earth
- a summer in Maine."
- Tess Gerritsen,
author of Gravity
. . . a charming and amusing tale about the triumph of lighthearted
goodness over the forces of darkness. Never has a young man's loss
of innocence seemed so sweet and touching. Expecting from the title
yet another grisly thriller, I was enchanted to discover a sunlit
ruin of a summer mansion, full of quirky characters pursuing hilarious
private obsessions. I missed this book whenever I had to put it
down, and rushed to get back to it."
- Lisa Alther, author of Kinflicks
and Other Women
Download Chapter
1 in pdf format.
Dark
Harbor House from Amazon
|
 |
Process for System Architecture and Requirements Engineering,
by Derek Hatley, Peter Hruschka, and Imtiaz Pirbhai
Process for System Architecture and Requirements Engineering introduces
a new approach that is particularly useful for multidisciplinary
system development. It incorporates the coexistence of the requirements
and architecture methods and of the corresponding models they produce.
These two models are kept separate, but the approach fully records
their ongoing and changing interrelationships. Order
from Amazon
|
 |
Problem Frames - analyzing and structuring software development
problems by Michael Jackson.
Jackson is back with a book that follows along the path set by
his landmark Software Requirements & Specifications. This time
he talks about looking at the problem instead of leaping into the
solution. The problem is defined using jackson's Problem Frames,
and through these frames, gives you a clearer view of the real problem.
Buy
from Amazon.com
|
 |
The Tipping Point by Malcolm Gladwell
Gladwell describes the Tipping Point as "the magic moment
when ideas, trends and social behaviour cross a threshold and spread
like wildfire". He makes the point that big ideas do not necessarily
come from big organisations. He gives lots of examples of how one
creative person can overturn conventional thinking and cause big
changes. - SQR
Buy
from Amazon.com
|
 |
Managing Software Requirements - a Unified Approach
Dean Leffingwell and Don Widrig have recently published their Managing
Software Requirements - a Unified Approach. Object Technology
Series (Series editors Booch Jacobson Rumbaugh), Addison-Wesley,
2000. This book has a comprehemsive and practical approach.
Fatbrain.
Amazon.com
|
 |
Software Test Automation - effective use of test execution tools
by Mark Fewster and Dorothy Graham
This is a practical guide that shows you how to automate your testing.
The authors avoid the trap attempting to leave everything to the
tool, and instead show you how to make best use of the tools that
available today. The authors show that with proper planning, you
can design and re-use test scripts in addition to automating many
aspects of the testing process (such as comparing actual and expected
results).
Dorothy Graham is one of Britain's leading lights in the testing
field. What she says here, and her case studies, are well worth
the price of admission.
Buy
from Amazon.com
|
 |
The Innovator's Dilemma Clayton Christensen (New York: Harper
Business, 2000)
Christensen observed that market-leading companies frequently are
overtaken by new entrants, and he wondered whether the conventional
explanations (lack of agility, arrogance, etc.) really explained
this pattern. He studied, among many others, the disk drive industry.
He discovered that, contrary to popular belief, the incumbent leaders
were the ones to take best advantage of nearly every technological
advancement. The exceptions were few but crucial. They were characterized
by not actually improving the product along the dimensions of performance
valued by the mainstream customers of the market leaders. Consequently,
the incumbents spent relatively less of their resources developing
these technologies and finding a market for them. New entrants,
who believed in the value of the technologies, took them on and
sought out new markets that would value the advantages they brought.
Over time, the new technologies improved at a rate far faster than
the performance demands of the market leaders' customers. Eventually,
the new technologies became adequate in all the performance dimensions
on which they previously had been inferior, yet they retained their
additional advantages. Cut to the chase: the new entrants drive
the previous leaders out of the markets they once led.
This sounds at first like the old saw about incremental vs. breakthrough
technology improvements, but it is not. Even breakthrough technologies
were best exploited by incumbent market leaders, as long as they
were breakthroughs along performance dimensions that their customers
valued. One key insight is that the leaders were hostage to the
preferences of their customers, even when those preferences led,
ultimately, to the demise of the firm.
There is much more to say about this book, but I will stop here
as it is time to go. I cannot overstate my recommendation for this
masterpiece! - SMcM Buy
from Amazon.com
|
 |
Kent Beck's Extreme Programming presents a lightweight method
of developing small to medium systems. In his book, Beck describes
what XP is and how it works, and where it doesn't. XP uses programming
in pairs, unit testing, communal ownership of code, and simplicity
to motivate code improvement during the development process. I have
no doubt that XP will be misunderstood by people wanting to shortcut
the process. But before you start to tinker with it, see what Beck
has to say about this potentially valuable way of working.
Buy
from Amazon.com
|
 |
Peopleware: Productive Projects and Teams, 2nd edition by Tom
DeMarco and Timothy Lister
Two of the software industry's best-selling and best-liked authors
return with a new edition of their landmark software management
book. Using insights, observations and wisdom from years of management
and consulting experience, Tim and Tom explain to you why the major
software issues are human, not technical.
Buy
from Amazon.com
|
 |
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
Buy
from Amazon.com
|
 |
"Here's a management book which is just plain fun to read. The
Deadline is an innovative and entertaining story with insightful
business principles for team-based project management at the end of
each chapter." [John Sculley]
Buy
from Amazon.com
|
 |
Jim Highsmith's Adaptive Software Development: a collaborative
approach to managing complex systems. (Dorset House, New York
1999) describes an adaptive development cycle which includes a number
of "learning loops" each including speculation, elaboration
and learning. I particularly like his emphasis on focusing all decisions
around the project's mission and using that mission as a way of continually
asking are we on the right track? He draws from the fields of
cybernetics, engineering, chaos theory and economics for insights
into how to take precise and relevant measurements.
However, there are some crucial differences between his "organic"
approach and more traditional ones. The organic approach gathers
both inputs that can be measured (number of defects) and those that
cannot (how frazzled is the team). Instead of everything being driven
by comparing actual with expected, his approach is more concerned
with learning from experience and iteratively adjusting the approach.
Successful application of this approach relies very much on having
a focused group of stakeholders and developers and an honest project
manager. I recommend this book to anyone who would like some sound
advice on facing and becoming more effective in the chaotic reality
of systems development. Buy
from Amazon.com
|
 top
of page
|
