Requirements And Design

From CritiqueOfUseCases.

In a thought experiment, I came up with the idea that there are guaranteed to be two different, incompatible modes of expression on a software project. It is no good trying to make just one. And there is always going to be a translation jump between them.

The first is a person's wishes for the behavior of a system. The second is the program itself. They are fundamentally incompatible because the first is necessarily imprecise and the second is necessarily precise. At the moment of wishing for something, the person doesn't know / can't express all the ramifications, interrelationships and details. Adding the extra precision, the person generates implications that either are not clearly understood or are not necessarily really requirements, or contain mistakes. Every new statement generates interrelationships between the previous statements. This is inevitable. But at some point, the person might back off and say, "Wait, all I really want is ..." (my example is when I go to the barbershop - all I want is for my hair to look nice. Then they start asking if I want more cut here or there. If I actually give the instructions, then my hair doesn't look nice).

To me, this jump from imprecise to precise is unavoidable, and rife with errors. It doesn't matter if you use OO or SA, or pseudocode, or drawings or text, at some point you make a jump. At that point, it doesn't even matter if you change descriptive paradigms. Traceability matrixes don't help. There is a language of the user, there is a language of the programmer, and the programmer has to connect the two through a leap of imagination.

And there is necessarily duplicate maintenance involved, since both are busy changing (one of the items mentioned in CritiqueOfUseCases).

Use cases are not the only way to get the wishes out of the minds of the users - in former days, alert programmers created the user manual first. The user manual is another place to get the customer to express "all and only" what they want. (where did I read that story recently about writing the user manual for 4 months, 2,000 LOC in the 5th month, and 20,000 LOC in the 6th month?). --AlistairCockburn

MichaelJackson talks about this as the informality and unboundedness of the real world (and by implication the desires of human beings for computer systems to impact the real world) compared to the formality of software system descriptions. See SoftwareRequirementsAndSpecifications.

As Michael shows, what you call the jump between the two is not just at design time. It also occurs, inevitably, as we struggle to enter "real world data" into the running, formal system. He uses a nice illustration from a Punch magazine cartoon many years ago where a railway porter is confronted by a "non-standard" animal a passenger wants to take on a train - a gerbil, say - and is looking at a rule book which only mentions dogs and cats. The punchline: "your gerbil's a cat so you don't have to pay".

the actual text of the cartoon was: Railway Porter (to Old Lady travelling with a Menagerie of Pets). "'STATION MASTER SAY, MUM, AS CATS IS 'DOGS,' AND RABBITS IS 'DOGS,' AND SO'S PARROTS; BUT THIS 'ERE 'TORTIS' IS A INSECT, SO THERE AIN'T NO CHARGE FOR IT!" [Punch, 1869, Vol. 57, p. 96]

Which means that our systems always need to learn, to evolve, whatever level of abstration they have reached. But I also entirely accept your point that the evolution will mean duplicate maintenance will always be required, looked at from this level. OnceAndOnlyOnceDoesntScale? in that sense.

I also really like there is a language of the user, there is a language of the programmer, and the programmer has to connect the two through a leap of imagination. This is indeed the designer's responsibility not the user's (which is why I prefer that term designer, although one day maybe I'll make the grade to JustaProgrammer) and simply cannot be reduced to rote or method in the conventional sense.

--RichardDrake

This is so true and unobvious, Alistair, it needed to be said!

I disagree that traceability doesn't help. It does help when you fix a translation error and need to fix all the consequential mistakes generated downstream. I suppose that's why people do it.

How do you deal with this problem? UseCases don't solve the problem because there is still the line to cross between Human and Computer. -- SunirShah

When I wrote that traceability doesn't help, I was referring to the wish of some people that simply marking that requirementA lives in designElementX suddenly confers on the two the ability to stay in sync. The two change, and the connecting lines change also (that makes three).

I rely on that PeopleAreGoodAtLookingAround?, to make the coarsest-grain traceability chart the people can get away with. PhilGoodwin said about the same thing in CritiqueOfUseCases. --AlistairCockburn

Perhaps it all comes down to IkiWisi?, Ill Know It When I See It.

Because there are the Two to which Alistair refers, they want to become One, the desire and the program meeting the desire. But the Two move, each affecting the other (gravitationally perhaps) and each affected by Others as well. They cannot become One, but they can become more nearly One.

Part of the value of incremental development styles such as prototyping and XP is that by showing the Two to each other, both learn and change and become more nearly One.

To me it's more that in XP you keep the Imprecise in the spoken realm, which is much nimbler, and put the Precise (desire and implementation of desire) into code (tests and program source). Also, UserStories are very short, helping traceability (we can do it in our heads, 'cuz we were just looking at that code a short while ago). --Alistair

You've captured something very important about XP and any LightweightMethod? worthy of the name here Alistair. In ControlledRapidEvolutionaryDelivery we called this principle DocumentToDeliver.

There is no translation.

There are two parties struggling to collaborate. The designer's contribution is to be a leader in this joint effort, so that the system (whose specification (s)he owns) comes out satisfying the client's requirements. As MisterNameless? above says, these Two are affected by their interchange. The designer can use many techniques to aid him/herself, for example creating a Business and System Vision in which the to-be system is in use in the client's to-be context, and working well.

This kind of designer is often called a business analyst or system analyst, but the task is at least as much synthesis as analysis. --- BruceAnderson