Requirements? What Exactly Do You Mean?

Requirements? What exactly do you mean?

Recently I got involved in discussions, arguments, debates (usually due to my own highly opinionated opinions ) about requirements management. It used to be a favourite topic of mine years ago when I was with another employer, but at Microsoft it doesn’t get a lot of airtime – so I am glad this is changing!

What I find most irritating about this topic is the term “Requirement”. If you consult one of the world’s authorities on this matter, the Oxford English Dictionary you’ll find the following definition:

• The act of requiring; a requisition, request.
• The fact of being requisite; necessity.
• That which is required or needed; a want, need.
• That which is called for or demanded; a condition which must be complied with

So according to the world’s authority a requirement is a request, a necessity, a want, a need or a condition.

I quite like this description because it states the obvious – “Requirement” it is a fairly broad definition to begin with. It surprises mehow this wishy-washy term survived all these years in our industry to describe one of the most fundamental concepts of software engineering. It’s time to fix it….

Requirement Types

I assume every competitive business has a vision and goals of what it wants to achieve. The more sophisticated ones may even have metrics describing goals in measurable terms.

To realise the vision and goals, businesses structure activities around processesproviding the capabilities required to achieve the goals.

The manifestation of these processes is typically a collaboration of one or more employees performing specific tasks.

Some of these tasks are executed manually others are automated. The automated tasks are performed by systems which in turn are often constraint by the technology used to implement them.

I hope none of this astounds you – it isn’t rocket science!

This simple example highlights that using the term “requirement” is too simplistic to identify all the “requirements” as defined by the world’s authority – we need to be able to distinguish different types! This isn’t very difficult and without trying to hard I can come up with the following types:

With a little more extra effort, I can also work out how these requirement types relate by creating a requirement type hierarchy (Figure 3). Again it’s not rocket science nor does it take very long to do it.

What we have at this stage is:

1) A more robust vocabulary to better communicate with all stakeholders what we mean by “requirement”.

2) Definedour traceability requirements (Note: a requirement type!), very handy if you plan to use a tool to capture this information.

I am notdone with this topic (watch my blog), but it’s a start and enough for today.

Next time someone asks you about “Requirements” – ask “What exactly do you mean?”