Less Post More GET

Please banish the use of the word “Requirements” from your software development lexicon.  Immediately.

For many software teams the requirements document is the king of documents.

You know the routine. The software team works with the customer (or customer proxy) to put together a “complete” list of “requirements”. Once that is done, the team writes the software implementing the requirements and voila! the project is done.

Or maybe not.

Every software project I’ve ever been on has involved scope management. This is a process of determining if a requirement is truly a requirement for right now and whether it could be delayed until part of a future version or release. This is performed not only when “requirements” are being first developed, but also during development/testing/deployment in an effort to meet a project timeline constraint.

Words Matter

In the Agile development world, “requirements” is sometimes replaced with “features”.  This is a very important change, mostly related to the meaning of words and cognitive dissonance.

Think about it.  “Requirement” is based on the word “require” – something compulsory or necessary by rule. For someone to agree to postpone a “requirement”, you are basically asking them to admit it wasn’t actually required in the first place – thus, it wasn’t a “real” requirement.  And therein lies the problem…

Asking someone to postpone a “requirement” is asking them to admit a mistake.

This points to the beauty of using the word “feature” when describing the software desired.  Features connote desires.  And it is OK for customers to desire pretty much everything.  “You want features, load me up!”  Throw features on the deck, list them like crazy.  Pile them on, as project managers, we’re not afraid of hundreds or thousands of features.  Knock yourself out – as long as they are prioritized.

Once we start developing, we can then start having conversations such as:

• Do we have enough features to deploy?
• Would you like to change the priorities of the features you’ve listed?
• Any new features?”

Those are much, much easier conversations to have and project decisions will be made much quicker without the debates about whether a “requirement” is actually a requirement.