The Absurdity of MoSCoW Requirements

Preface: 012210 -  This specifically ignores prioritization and instead explores the MoSCoW method. Figured that was worth mentioning, when I went back and read it. Thanks!

—

This article has been born from a trend that I have seen gain traction over the past few years. People are building requirements matrices of sorts, and they are coming with MoCSoW associations. I think there is a disconnect, and I want to address it.

A requirement is something that is required. The term ‘requirements‘ has taken on a new meaning within software projects, but I want to address that and try to make a case for logic here.

MoSCoW refers to a method in which System features are either MUST haves (absolutely needed), SHOULD have (we wouldnt die without it, but it should be there), COULD have (we will see as we go along how likely it is), or WON’T have (determined to be out of scope, part of V2, or just erroneous).

A requirement is not something that is “nice to have”, or “will not” be had. If it is required, it is needed. Otherwise, it would not be called a requirement. It would be called a goal, an ambition, or a hope, dream, fantasy, etc…

We write requirements as such: “The System SHALL do X, Y, or Z”. We use short, declarative statements. We dot notate TRUTHS about the System. We assert. A requirements document is a very assertive document. It reads like a dictum. It is a dictum.

We do not say, “The System MIGHT do A, B, or C” or “The System WONT make us toast in the morning.”

Issues regarding priority and the inclusion or exclusion of functionality are scope issues, not requirements issues. If we are developing against requirements, we better know what we are requiring. See the image on my homepage to get a sense of what happens all too often.

Now, it is perfectly sensible to use MoSCoW as a way to prioritize features, functionality, or any given aspect of the System. This happens during Discovery, Inception, Envisioning, or whatever your chosen approach calls that part of the project where you figure out what it is that you are building.

However, when have defined requirements, you have gone through a lot of discovery. You have the ingredients of a contract. This is where I think people get confused. A contract does not have to be like the Ten Commandments, etched in stone. It can accomodate best practices.

The contract, although binding, can and should include the provisions associated with iterative developement. If you do not assume that there will be changes in a software project’s scope, you are assuming that you know everything about the project at the onset. This is never the case. If you have ever written a scope document for a project of significant size and delivered without making any changes, I want to know about it. You will be the only one in the world who has pulled that off. You would have to be some sort of BA super hero. I know they are out there… I have just yet to meet one.

Now, many of us are practioners of some form of Agile SDLC or methodology, and we know that scope will change. This does not mean that our contracts read, “The System will consist of functionality that we aren’t quite clear on yet, but we will figure it out as we go…” It means that the client is aware of and understands that AUP (my favorite right now) affords us the ability to deliver what the client really wants without asking them to make decisions they are not equipped to.

Initial scoping can be, and will be, fuzzy around the edges. However, when writing requirements, there is no fuzziness. If a requirement changes, that potentially calls for a scope change. That calls for a process that is very easily woven into Agile development and is indeed assumed by it. Having defined requirements does not inhibit Agility. It engages Agility.

I just wanted to get that off my chest. A requirement is REQUIRED until it is no longer a requirement.

MoSCoW classification belongs in scoping, context diagramming, brainstorming, and the like. It does not belong in requirements. Your requirements are your rock. You cannot have wishy-washy requirements or you will be forever developing against nebulous ambitions. Let’s build Systems the best way that we can, and if we can, overdeliver. PMI calls it gold-plating, and warns against it. PMI is not a good software methodology.

In an iterative or Agile environment, gold-plating goes away and what emerges is client-focused, top-notch software, aimed at exceeding client expectations.

And still, a REQUIREMENT is required. If it cannot be done, it is not a “nice to have” – it is a headache for the Project Manager and probably a series of meetings and excuses. This is the only way I know to honestly undertake the task of building software. Be truthful, be positive, and be Agile – but focused on and true to the peculiar discipline we call a project.

Thanks,

Josh