% fortune -ae paul murphy

User precision

"The red car came through the light, hit the yellow one, and bounced into the power pole"

"The guy in the yellow car was definitely speeding when he hit that light pole and kind of glanced off it to end up in the intersection where the other guy hit him."

"It was a white van that set this off - he blocked on his left turn and that forced the red car to stop and that's when the yellow one hit him hard enough to push him into the signal pole."

"Both drivers were speeding, I saw it very clearly"

"No, there was no white van, just ask the guy on the bicycle who almost got hit when the blue car ran the light just ahead of the red one that got hit".

Can you tell what happened? how many of these witnesses do you think can reliably tell, at a glance, whether someone is speeding? How do you think these stories will change during the ensuing civil litigation?

Ok, so lets switch venue: "What do you do when you pick up a T1-A from the input stack?"

"Check the information against the data record from keypunch (!) and then file it."

"If when you click save it comes back with an outstanding, we forward a copy to Compliance and issue a records request to Microforms."

"If the microform record exists, add that record number on the screen"

"Verify the computer record"

"Check compliance status before sending it on for microfilming"

"See if the microform record exists, and if not make a new index entry for this one.

Can you guess what they're really supposed to do?

So what's the point? Well we haven't even talked about the communications barriers that arise from issues of personality; the perceived power relationships in the conversation; embedded, long term, organizational attitudes; or what happens when you go back to ask users to sign off on the correctness of your understanding of their requirements as expressed in glorious UML diagrams we first have to teach users to understand - even if we mostly rely on automated tools to produce them ourselves.

The reality is simple: interviews will help you get the broad strokes (there was a crash, they check T1-A records) but the only details you're likely to get right are the ones you understand from sources other than requirements interviews: things like common business patterns or other logical consequences of artifacts, like screens and forms, that you can see.

Bottom line, you won't get the specs right the first couple of times - and every new effort both improves the result a little bit and hardens organizational divides to make the next round more difficult and expensive.

So lets try it again - this time with an easily changed screen connected to a test database in front of us.

"Ok, lets grab some T1-As. This one's for someone named Hoagland, let me bring that up. Now what?

"Ok - lets put something that pops up if there's a previous record - like this? ok. This guy has one. Now what?

"Transfer the record number? That's all? ok lets automate that, if it exists we'll just fill it in, like this? and now we can get rid of our pop up, right? and just put a "No record" where the number goes if we don't find one so you know the check's been done. Ok, that works, now what?

"Wait a minute, do you want to do this for each of the last few years? no, just the last one? -is there a security issue in seeing those? no, ok how about we show that one, and let you click to see others? how about seven years? like this - ok, what's next?"

"Put it on the "send to microform pile", hit "Save" and get another - Rymbrouski. Lets bring Leo up, check - no record. Now What?

"Create the record - ok, that's it? I'll make a note - add that later to the record check for when we say "no record" so you don't have to do this anymore, ok, get next one -uh, grab one that's a compliance case from that pile - ok - lets check this one: he existed two years ago but not last year, -is that why he's compliance? no? ok, what do we do with this guy?

"email a copy of the record? How do we get Officer's name? - on his file? lets add that as an autopop - if it exists - gimme a minute while I trudge through the data dictionary, ah - ok, like that, so we'll put a button if you want to send it or cancel - and click, off it goes. So now that's automatic; Slick.

"We still have to notify microform? Why compliance already has the record - no big deal, here: can we just put a cc in email? Ok, lets do it for now and you get your boss to check with them, easy to change if they don't like it. So, Done. Now what?

Now, in reality, that kind of thing actually takes a lot longer, with a lot more give and take, than shown here, but the point is that when you ask people to describe what they do, they're usually about as accurate and complete as witnesses to a traffic accident. Ask them instead to actually do their jobs with you, and they'll have no trouble at all getting it right - meaning that as long as you can put up with being treated as an idiot for not having the system do stuff you've never heard of before, you'll eventually uncover all the organizational and special cases the application will have to deal with.

And when you're done you'll have a specification expressed as an application that works.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.