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