Buy it from Amazon.com
Buy it from Amazon.co.uk
Einkaufen von Amazon.de
In Preparation
Foreword by Professor Michael Jackson
Snippets and Images from the Book
As information
technology grows in power and reach, systems become more ambitious and more
tightly integrated. The discipline of defining—or, perhaps,
engineering—requirements becomes broader and deeper: it now embraces almost
every project that aims to defining a human or technical need and to find a
means to satisfy it.
Inevitably, the requirements engineering community is a very broad church. Its
adherents includes practitioners and thinkers of all inclinations, ranging from
those who relish challenges in the softest human and social terms to those who
prefer to grapple with the hard-edged technical intricacies of defining the
details of required software behaviour in any problem context from a physical
device to a business organisation.
Ian Alexander and Ljerka Beus-Dukic are teachers and practitioners, very comfortable in the centre and softer areas of the discipline. They are interested above all in the process of discovering requirements in realistic human contexts, and their book reflects and conveys the scope of their interest, experience and wisdom. It is filled with practical advice based both on experience and thought. They offer insights and help in the vital pragmatics of eliciting and clarifying the needs of multifarious stakeholders, and of balancing their conflicting interests and goals. They are strong on the social skills that the practitioner needs to identify what is really required, and on the techniques of trading off stakeholders’ requirements against one another and against what is achievable in practice.
The book is annotated with aphorisms drawn from a multitude of sources—some from the ever-growing literature of requirements engineering, some from thinkers as diverse as Winston Churchill and Walter Vincenti, a wonderfully insightful aeronautical engineer. Every human milieu provides illuminating examples: the provision of a meal, the construction of an Indonesian outrigger boat, the use of a hand-held wireless device on a mountain hike—all furnish both insight and amusement.
The book has an interesting matrix organisation. Earlier chapters focus on the elements of requirements—stakeholders, goals, scenarios and priorities. Later chapters focus on the contexts and sources—individuals, groups, and artifacts—from which these elements can be elicited and the full requirements fashioned. Two final chapters offer advice on trade-offs and on how to put it all together in the eventual implementation project.
This book is not only of practical value. It’s also a lot of fun to read. I particularly liked one remark that chimed happily with my own prejudices: “We believe that for any task, whether you are learning from a book or doing practical work on a project, you need to balance periods of action with periods of reflection.” I agree wholeheartedly. And I’m sure you will agree, as you enjoy this book, that its authors have followed their own advice to admirable effect.
Perhaps your first thought about requirements work is that it is simple: you just write down what you need.
Perhaps your experience of trying to write down what you need is that it is not easy: you did not get what you wanted.
“Simple but not easy”: why is that? Things that look simple but are not easy include many traditional skills and crafts.
A tram service offers to provide fast, safe, and reliable travel for passengers (and their shopping) around a town. It does that at the price of a considerable investment in infrastructure. That includes the trams themselves, street redesign (see the photograph above), track, tram-stops, information systems, ticketing, maintenance depots, and so on.
Introducing a tram causes side-effects. One likely effect is disruption to other modes of transport. Car drivers may find sharing a road with a tram difficult. They may not be allowed to drive on the tram tracks. Some roads will be made one-way. It may be difficult to cross the tram route. The remaining routes may become congested by queues of cars.
Trams can have complex effects on people and businesses, both positive and negative. People can travel further and faster on some routes, using the tram. But they can take people away from businesses as easily as bring people in. A tram stop in front of a shop or a hotel could bring more customers by tram, or it might put off customers who like to arrive by car.
Each stakeholder has a different set of goals for the tram service.
A workshop is a kind of performance. Many people will attend, so each minute of workshop time costs many minutes of salaried time. Each participant wants to benefit from the time invested. Each participant will make a judgement on whether your workshop – and you – were worth their time.
It is therefore better to rehearse your plan in ordinary ‘slow’ time, and to discover your mistakes in private, rather than to make costly mistakes in workshop time.
Workshops are like theatre, too, in that people want to enjoy the time, as well as to get results. Getting stakeholders’ “buy-in” is often critical to success. An element of showmanship is necessary. That means planning, rehearsal, and playing the role.
Direct use of Improvisational Theatre (“Improv”) techniques is also possible (scenarios, role-plays...); or, Improv can be used as a training aid for better team-based innovation performances. Simple techniques such as acting a scenario around a flipchart model of a user interface can be very effective.
(c) Ian Alexander 2008