Update on Specifying Goals

I updated the Planet Project article on Specifying goals, using some of Tom Gilb's approaches and recent experience with the topic from one of my projects.

In this project, we struggled somewhat to explain to our subject-matter experts the importance of beginning with the (ultimate) end in mind. They thought they had to describe every little step, every button and every view of an IT application down to the smallest detail.

My favorite example was the following sequence (from a use case description), repeated a hundred times within the requirement specification:

1. User does some inputs
   
2. User "sends" the input, i. e. confirms his inputs
3. System checks inputs against rules X and Y
4. Systems shows an error message in case the checks fail.
5. ...

I finally got them with suggesting an alternative solution, roughly like this:

1. User does some inputs
2. (System has to make sure rules X and Y are not broken)

I guess the key was to make up a scenario which used quite a lot of sarcasm:

1. "I think I am an expert user."
2. "I do these simple inputs. Damn I'm good!"
3. "Now send the stuff to the stupid machine." *klick*
4. "Ooops ... What the ...."
5. "The stupid machine says I did it wrong?!"
6. "Why didn't it prevent me from doing it wrong, is there anything this machine is useful for?"

:-D