The requirements island

What is a requirement?
Hang on; I don’t want to start another war on what the best definition of “requirement” is. We have too many of those already.
I just want to reflect on something that has been bugging me the last few months (sorry). That is: why do so many people talk about requirements as if they are something completely separate?

“A requirement must be solution independent.” or “That’s architecture, not requirements”, and also “Those are goals, we don’t need to capture them.”

To me requirements are not an island, to be kept well away from the dangerous influences of other landmasses. Please, no! Requirements are just one kind of information in a universe full of related and relevant other kinds of information: goals, stakeholders, architectural principles, designs, test cases, business rules, processes, object models… the list is endless.

Requirements on their own are meaningless. Documents with only a long list of requirements are useless and should be forbidden! Requirements derive meaning from their context, the information surrounding it. Relating a set of requirements to a process step helps understand the requirements, and helps us check if the set is correct and complete.

Mind you, that doesn’t mean that the requirements discipline should take on the modelling of all this information so they can relate it to requirements. Preferably not – each to their own. But in the requirements discipline there is nothing splendid about “splendid isolation”. I’m all for the Bazaar approach to requirements, not the meticulously crafted requirements Cathedral (see Eric Raymond’s “The Cathedral and the Bazaar“).

Functional or function requirements?

I’ve been using the terms “functional requirement” and “non-functional requirement” for many years. They seemed fine. When at first I read Tom Gilb‘s book “Competitive Engineering” – I believe I read the draft version which he had available as PDF on his website for a while – I did’t think much of his use of “function” requirements. It seemed academic and of no real help.

Then, as I started giving more and more requirements courses, I began to wonder why so many people had trouble grasping the difference between functional and non-functional requirements. I found that they often struggled because of long-term associations with “functional” as something that is useful. Thus they reasoned: “Well, a high reliability or fast response time can be very useful, and this must therefor be a functional requirement.” The same happened when I used the Dutch terms “functioneel” and “niet functioneel” for Dutch audiences.

I started to experiment with different explanations, and found that a “function requirement” was not only a much more precise description, it also caused much less confusion. I went back to Tom Gilb’s book and read it a few more times (not the whole book, mind!). It was growing on me…

Instead of functional and non-functional requirements, I now prefer to use the terms function and quality requirements. This has several added advantages. For example, I find it much easier to explain the difference, it helps people detect combined requirements (such as: “The blogger can add up to 20 tags to the post.”),  it is easier to convince people of the need for traceability between functions and qualities, and I can talk about how you can count functions while you always have qualities – to a greater or lesser degree.

I would like to go into more detail about this, but it will have to wait till another day.