Functional or function requirements?

May 8, 2009

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.


Requirements and stakeholders

May 7, 2009

When assessing requirements practices within projects I often find a clear list of stakeholders has been created as part of project management activities. This list is usually part of a project plan, PID, or similar document. The associated sensitivity analysis is less common – and less public – but in most cases some sort of analysis has been done by project management.

Unfortunately I cannot say the same for the requirements discipline. Typically – among my clients at least – the requirements manager is happy to refer to the stakeholder list provided by the project manager. Occasionally they have been involved in the analysis. Hardly ever do I see an analysis of what I consider useful from a requirements perspective.

While requirements stakeholder analysis (and management) has an overlap with project management stakeholder analysis, I believe there are some important differences. I will not go into the differences here, instead I wish to look at some often neglected aspects of requirements stakeholder analysis. To my mind, a requirements manager should be looking for answers to questions such as:

  • Which stakeholder groups have a valid interest in the product or service being developed (or modified)?
  • Who is a suitable representative for each valid stakeholder group for requirements-related decision making purposes?
  • Is this representative available for the project?
  • Does the representative have the mandate to make the necessary decisions?
  • How should the project involve each valid stakeholder group in requirements development activities? Note that this could be done entirely through the representative, or could involve several other members of the group – e.g. in interviews and workshops.

To answers these questions, some characteristics of each stakeholder group will need to be collected. This is often called a stakeholder profile. As a minimum this should include the name and short description of the stakeholder group and what their interest in the product or service is. Many other useful attributes have been suggested, notably by Ian Alexander, Suzanne & James Robertson, and Karl Wiegers. Pick what is relevant for your situation.

For example, one organization I worked with knew that some stakeholder groups were spread out geographically, while others were concentrated at the company’s headquarters. This was relevant when deciding on workshop participation for eliciting requirements – flying people in from the other side of the world is costly both financially and in the time it takes up for these people!

It is a happy day when I stumble upon a project in which the requirements manager has looked at even half of the questions. Am I asking too much? Why is requirements stakeholder analysis (unlike project management stakeholder analysis) so poorly understood – or poorly performed?

Any ideas and comments are welcome! Also I’d love to hear your experiences with requirements stakeholder analysis.