Thursday, May 17, 2012

Modal-Driven Development

If extracting feature motivations, requirements and priorities from stakeholders is an art, presenting the analysis requires artfulness. The MoSCoW method suggests using English words Must, Should, Could and Won't as an alternative to purely numeric priorities to make it more transparent that not everything listed will be delivered.

But reversing the MoSCoW rules can help to obtain the implicit prioritisations. You'll frequently hear "we must have a solution to X" or "Y should be improved in this release" or "we'd like to get Z into the payload if we could". Key verbs like this can be mapped to prioritisations, e.g. P1 (must), P2 (should), P3 (could). We use these clues to bootstrap priority discussions and, perhaps surprisingly, I often apply it to my own bug reports to get an idea of my intuition on an issue.

You ought to beware that there will not be a 1:1 mapping between key word and priority, and negation does not help. For example, "could not" might be "must" but can be "could":
"I'm sorry but we could not do A, the customer would scream." 
"We're currently doing A, B and C; but we could not do A."
And "must", "should" and "could" may have epistemic and deontic readings that context mightn't disambiguate. Take this, from a bug ticket I read this week:
 "In Release A the behaviour should be more robust but in Release B we have to fix the issue." 
How can "should" be read? Could the reporter be saying that he thinks Release A is already more robust, or might he think that we still have to make Release A more robust? (He meant the former; our triage prioritised on the latter.)

So, now you've read this, could your requirements analysis be improved?
Image: FreeDigitalPhotos.net

5 comments:

  1. I fail to see how this post applies to the HICCUPPS(F) heuristic model.

    ReplyDelete
  2. Hi Kimball,

    It's not intended to. Hiccupps is the name of the blog but the content isn't restricted to just that heuristic.

    James

    ReplyDelete
  3. Interesting point. The distinction between epistemic and deontic modality is important. I'd noted the problem, but not really thought it through in those formal terms.

    I think your examples could be a bit clearer. I don't think the ambiguity you mention is likely to be expressed in the way you quote, and I think that detracts from your important message.

    I've tried restating them here to make them look superficially clearer while retaining the ambiguity. Have I got it right?

    "We can't do A because performance is awful"

    "We are doing A with the old application, but we can't do it with this new one".

    Or is that not what you're trying to say?

    James Christie

    ReplyDelete
  4. Hi James,

    Thanks for the comments. We discussed this further in email and here's a summary:

    I think you've got a point about the examples although I've heard and seen both forms, so I do think they're legitimate. Some emphasis can help to disambiguate:

    "Performance is awful, we can not do A"

    "We're doing A now but we can not do A"

    The second example is probably the weaker and gave you more trouble, to the extent that you didn't see the reading I was intending. This is reflected in your restatement of it which seems stronger than "we might or might not do A" to me.

    You noted that this discussion reinforces how treacherous and confusing these modal verbs can be and that if you saw them in a spec or bug report you'd object that they weren't clear. I think that's true to the extent that the reader recognises an ambiguity at all - as in the final example.

    We've agreed on an alternative which preserves the ambiguity for both of us and seems more natural and I've edited it in.

    Thanks again, I enjoyed the discussion and I think it's improved the post.

    James

    ReplyDelete
  5. Clearing this up off-line proved very useful. It's worth stressing that the exercise emphasised the problems these modal verbs can cause.

    You attempted to create a finely nuanced ambiguity. I inferred a different lack of clarity, missing the ambiguous interpretation you were trying to point towards.

    So I got it wrong when my senses were tuned to spot ambiguity. How much more likely would it have been for me to infer the wrong meaning in a normal, pressurised work situation? A point well made!

    James Christie

    ReplyDelete