Refining Problems and Goals
October 11, 2007 8:47 am business, softwareBruce responds to my prior post on requirements:
…I think you also have misinterpreted the user’s statement of the requirement.
Ted’s discarded first sentence IS a problem statement, but only for the second sentence (password confirmation field).
I don’t think the last sentence is a goal for the two requirements, in fact it has got nothing to do with problem statement. Interpreting it as the goal causes your question 5 to yield a negative answer.
The last sentence is (I think) a statement of a second problem, which leads to the second (but already stated) requirement. I would interpret the paragraph (briefly) as…
I didn’t really put any interpretation into the validity of the first and fourth sentences, nor did I attempt to answer any of the questions I asked. I just used them to illustrate the questions & types of statements themselves.
However, Bruce’s disagreement shows exactly the kind of process I was looking for when assigning qualifiers and questions to the sentences in the first place. He brings up valid points which prompt further action:
- acceptance (if everyone on the team is convinced he’s right)
- counterargument (if someone on the team thinks he’s wrong and can explain why), or
- clarification (go back to the requirement writers and ask for more information to confirm or deny the assumptions we’ve made
The last two actions restart the process until full agreement is achieved. If you have enough people with good reasoning skills and tenacity to see disagreements through until they’re resolved, then the results of your analysis will probably be very close to the hypothetical “most correct answer possible.”
Along the way, all of your requirements, problem statements, and goals stand a good chance of complete replacement. That’s a good thing — if you’re doing the wrong thing, it doesn’t matter how well you do it, you’ll still come out with a poor result.

October 11th, 2007 at 10:45 am
“enough people with good reasoning skills and tenacity to see disagreements through”
Or until the boss says, “OK we’ve debated this enough. Everybody has valid points but I’m making the call and we’re going with X.”
October 11th, 2007 at 1:48 pm
‘Or until the boss says, “OK we’ve debated this enough. Everybody has valid points but I’m making the call and we’re going with X.”’
No. The boss doesn’t make the call on what is the correct interpretation of the customer’s requirements. The customer does.
If the boss is wrong, now is the best time to find out, not at delivery.