This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Misfits, or, there's no such thing as a requirement
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
Johanna argues that "Users can't know their requirements early", and illustrates with a simple but illuminating story.
The term "requirements" seems to be part of our final vocabulary - we assume there's such a thing as "what the system should do" (irrespective of whether the customers know or don't know what the system should do). We don't really question the deeper reasons why requirements should change over time, or change when users are exposed to the system; we acknowledge these as annoyances or hindrances in efforts which would otherwise be straightforward.
In Notes on the synthesis of form, buildings-architect Christopher Alexander discusses the design process in terms of "misfits". Design, says Alexander, is a matter of harmony, of good fit, between a form (what is being designed) and a context (where we use the thing being designed). A misfit occurs when some aspect of the form clashes with some aspect of the context. Instead of "requirements", we might use the term "misfits". In Johanna's story, we have a context - lodgings away from artificial illumination, thus subject to the natural diurnal cycle; and a form - the house itself, with its various devices including artificial lights. Good candidate misifts in Johanna's story are wasteful use of electricity in daylight, risk of accident when coming home to a dark entryway, needless effort in resetting the timer.
What misfits buy us is a way of looking at the design process which doesn't require sorting "functional" from "non-functional" requirements, explains why requirements change over time and explains why a stable solution is nevertheless eventually produced.
Consider simple problems, say ones involving a handful of what Alexander calls "misfit variables". Take the design of a wrench, for instance. The goal is to adjust all of these variables in the object being designed so that there is a good fit between form (the object) and context (which includes when, where, how, who (etc.) is using the object). This is quite simple if the variables are independent. It gets more involved if the variables are related to each other: say, the length of a wrench handle relates to the "excessive cost of materials" misfit, but it also relates to the "insufficient torque" misfit, and in the other direction to the "risk of stripping bolt corners" misfit.
Design becomes hard when adjusting one misfit variable in the "right" direction causes another misfit. With these complex problems, the interrelations between misfit variables make it impossible to compute an "optimal" solution in any feasible amount of time. The interrelations are such that any adjustment causes a "ripple effect" of misfit in other variables, which in turn affect other variables, etc. These ripple effects are the reason why users frequently change their minds about requirements after they've seen the software.
Alexander shows us how to take a step back from the detail of each misfit variable, and view the whole network of them. Design is a matter of partitioning this network so as to minimize "ripple effects". Notes describes one method of achieving this partitioning.
Alexander uses the same boolean networks, which he borrows from cyberneticist Ross Ashby, which were used later by complexity science theorist Stuart Kaufmann to illustrate "self-organization". (There's more than one interesting convergence here. Kaufmann in turn inspired the agile process Scrum. Alexander was also the inspiration for the design patterns movement, among which many are now agile proponents.) They draw different conclusions, but somewhat similar and compatible with each other.
Alexander shows that our preconceived notions of which misfits group logically together, and thus our breakdown of the design process into component efforts, have actually little to do with how the network "wants" to be carved up so that a stable solution emerges. On a related note, Kaufmann shows that whether the network of conflicting misfits eventually "settles down" to a fairly stable and ordered configuration is essentially a matter of how interconnected the variables are. Too much interconnection, and the network never stabilizes; too little, and no "interesting" form can arise.
The term "requirements" implies that there is a constancy to the various bits of "what the system must do", and that the bits don't interfere with each other. That's way too simple a picture.
Previous Topic
