So with all the talk on how critical it is to understand the details of your product before you waste time developing the wrong thing, it’s worth having a think about what defines a product.

The makeup of the product can be looked at in a couple of ways.

  1. Features. these describe the aspects of the product in terms of customer value and marketing approach. These are the aspects of your product that make your product what it is, and can make little reference to any kind of implementation detail.
  2. Components. This is all about the implementation. These are the parts that literally make up the product. Like you see in a shopping list, or a Bill Of materials… Though of course components may not all be physical things.

All features and components have requirements. Requirements can be functional or non-functional.

In the process of defining the product, requirements are said to be gathered up (which brings us the fun mental images of the previous person who had the same idea as you flinging them down in frustration, and engineers with dustpans and brushes sweeping carefully under a table.)

Functional Requirements describe some aspect of the actual purpose of the thing you are trying to make. These are generally details of the things that you got so excited about when first thinking up the product idea.

Non-functional requirements often relate to components rather than features, and generally describe fundamental things that the product has to do, often before it can do the things that are the reason why it exists. They are often called qualities as they can relate to things like safety or reliability or manufacture-ability or update-ability.

Requirements have levels of importance. In natural spoken language, words like “shall”  “must” “should” “may” and “can” might have different meanings to a reader (especially shall and must, or may and can – most people see these as synonyms) In requirement declaration they are quite specific.

Now that we know what a requirement is, how do we define them?

Well, the simplest way to do it is [part] [requirement strength] [possible negation] [description]….

the cat should sit on the mat. (obviously  this requirement is a should – as you can’t make a cat do anything)

But is this a complete piece of information? does it give a person the ability to pick up the true need behind it? to evaluate it relative (beyond imperative strength) to other requirements or possibly suggest other approaches? No.

In agile development a 3 part requirement is used, which also ties in an owner of the requirement and a reason for the requirement.

As: the cat’s owner/slave
I need that: the cat should sit on the mat
So that: my little furry darling doesn’t get cold on the stone flooring overnight in winter

This 3 part requirement assembly is a bit slow and a bit clunky and often reads a bit funny in practice.. And becomes especially repetitive with a lot of non-functional requirements… But if you follow it then it means you have never defined a requirement without also defining a reason for the requirement existing and the person or people it effects. If you follow it, you always have the reason why it exists so someone learning it for the first time can understand the context, and the requirement can be modified or replaced in future with less danger. You have packed the requirement and the needs behind it into a portable format.


How about storing them?

You’ll find that if you think about a project for long enough you will mentally form and store lots of requirements. You will also find that you don’t always remember all of them all the time, and when you need to pass on the requirements to someone else, it can get difficult and confusing. So, the human brain isn’t the best storage space for these things,and you need a fast and reliable way of getting them out of there as soon as possible.

There’s got to be a thousand ways for organising and tracking requirements. From general ticketing systems, to agile/lean kanban boards (like trello!) to a spreadsheet, to a simple text file or a word doc.

What you use depends on what is important to you and your team, and what is able to be used effectively by you and your team. At the minimum, it should be possible to maintain a history of changes to the records. It should be very hard to destroy information accidentally. And the information does need to be easily modifiable at least during the process of writing them all up. After all this it also pays to have a way of going through them all one at a time, and making sure each is addressed, as development progresses.