Joy Beatty - Visual Models for Software Requirements

The most striking thing about requirements work is the enormous difference between what academics think it involves and what people in industry actually do.

The academics think they are far ahead, because they have a wide range of models and techniques, complete with experimental studies (done with specially tamed industrial tribespeople), theoretical analyses, and enormous textbooks full of excellent advice. They cant see why people in industry are being so slow to adopt their methods.

The people in industry think they are far ahead, because they have years of experience, software that works (after a bit of pushing and shoving), and proven methods of managing requirements with traceability matrices, reviews, configuration management, and attributes for priority and status. They cant see why people in academia are being so slow to catch up with reality.

Its like watching two cyclists on a circular racetrack, 180 degrees apart, endlessly circling.

Thats why it is so good to see this book from Joy Beatty and Anthony Chen. They are practitioners who speak from their own experience. Butand this is the crucial thingthey are familiar with the range of models advocated by researchers, and even better, they have steadily incorporated more and more of these into their practice. Now they have reached the point where they can see that the models they are using enable them conveniently and effectively to analyse all the requirements they come across. Theyve seen and heard the academics talking about, say, goal modeling using KAOS or i*. Theyve seen challenged projects that only needed a context model to inject clarity, or the disaster that looms on projects that lack something as simple and traditional as a data dictionary. And they have a practical handle on the essential fact that you have to use all these things together.

Theyve arrived at a clear understanding that in a requirements process, as in any system or product, the whole is more than the sum of its parts. An airframe, a pair of powerful engines, an avionics system, and an aircrew do not make an aircraft until they are integrated. When they work together, something new emerges that none of the parts could achieve on their own: the ability to fly.

To make a requirements process fly, the first step is to understand that there is more than one kind of requirements model. A shopping list of requirements is invaluable in a contract, but on its own, its desperately difficult to check for correctness and completeness, and it doesnt offer any suggestions on how to discover requirements, either. Different requirements models are needed to assist with discovering, checking, and analyzing the requirements. The shopping list is an output, not the one-and-only input.

Joy and Anthony identify four major classes of requirements model: those dealing with objectives, people, systems, and data.

Their objectives come closest to traditional requirements, but starting at a much earlier and more tentative stage, looking at what a businesss objectives are and from there working out how those needs can be met.

People , obviously, means looking at who has an interest in the system under design, how they will use it, and what they want from it.

Systems means exploring the context, interfaces, and events that govern what the new system will have to do. This is largely a traditional set of analysis techniques, often considered outmoded by those subject to the whims of software fashion, and it is creditably brave of Joy and Anthony to face up to this and to state clearly that oldeven if incompletedoes not mean wrong. The point is, of course, that 1970s-style system analysis on its own was not enoughfor example, it often failed for lack of proper attention to objectives .

Finally, data means defining the information that is needed by business users and exploring how it is used within the system. Again, much of this is very traditional, though it covers not only data analysis but state models and report analysisa modern take on an old topic.

There is a necessary complexity here. Requirements models interlock. Objectives relate to features, which relate to processes, which relate to use cases, which relate to the user interface. Joy and Anthony show how this requirements architectureyou could call it a meta-modelcan be tailored to the individual project. They have tried it, over and over, and it works.

The approach in this book is designed for software that supports business processes. Related but distinctively different requirements processes are needed for other kinds of projects, such as developing a family of mass-market products that include both hardware and software. Joy and Anthony focus specifically on one world: the world of software for businesses. The result is an innovative but compelling requirements approach.

- Ian Alexander, April 2012