I use the phrase essential requirements to describe a set of clear statements about what the finished project will be able to accomplish, but not how.

Essential requirements are pithy, orthogonal statements that reveal the essence of why the project exists: to satisfy these needs.

They should be written so that anyone can understand them; jargon-free, colloquialism-free, active voice, highly factored writing.

A small project may have only five to ten essential requirements (one or two person-weeks worth of work). A medium sized project might have 20 (six to twelve person-weeks). A large project would have 30 or 40 (1/4 to 1/2 person-year). A gigantic project might have 70 to 90 (multiple person-years).

One narrows down the ideas to get to the very essence of what the product is supposed to accomplish. If you keep asking “why” enough you will run into these gems of intention. In theory, any system that meets all these requirements would be acceptable: at least, these requirements are a test for completeness.

People will try to conflate implementation details with requirements. Keep asking why. Don’t stop at “we just do”. The status quo is defined as what we just do. But, lurking behind the stonewall is a lack of understanding of the requirements. It is really important to find out why this is really needed. If you get as far as “because that is why people pay us” or “because that is what we’re trying to accomplish” you have found one of those essential requirements, but there are others.

Well, of course if you can add one, you can delete one!


But, nobody ever mentioned it. Because, everyone assumed delete would be there. But, it wasn’t, because it wasn’t specified.

Imagine that we are discussing a new system that delivers a service we call perlucidus that manages objects called clouds that contain content like movies or documents.

Requirements might look like this:
  1. It must be possible for people to create and set up their perlucidus account
  2. It must be possible to add, edit and delete clouds in a perlucidus account
  3. It must be possible to report on activity related to a cloud and for an entire account
  4. it must be possible to add, upload, download and remove content in a cloud
  5. it must be possible to access content in a cloud via a URL, but authentication is still required
  6. it must accept Facebook or Google Single Sign On logins or our own password authentication for access to content via URLs
  7. It must be possible to produce an accounting report showing account usage
  8. all authorized access to content must be logged and the log must be accessible to an admin user
  9. there must be a help facility that includes a quick-start and more detailed help (someone else will write this content)
  10. there must be a way for users to send feedback and ask questions
  11. there must be a way for us to notify the users of important messages when they log in (a “message of the day”)
  12. It must run on all devices with a web browser

Actually, that’s 12 requirements, and you already know a lot about it. In fact, essential requirements are one part of the shared artifact that everyone should be able to read and understand. These requirements are an instrument of building consensus. We can negotiate about what it should and shouldn’t do long before we ever implement it. That is the time to engage in lively debate and consider whether we understand what we are about to create.