Why does it matter?
If there is indeed an inherent sequence or hierarchy in the relationship between Functional Requirements and Performance Requirements (alternatively known as Quality or non-functional requirements), then there is the potential for a a definable, teachable process to the design of systems.

The systems to be designed may be wide-ranging in type, but will include software-based, system-based or organisational or a 'system' of business processes. This paper proposes there is inherently, such a sequential and hierarchical relationship and recognising it, allows us to clarify our thinking in understanding and tackling complex systems problems on behalf of stakeholders.

A starting point is to recap on definitions.

Function Requirement: What a system has to do: the essence of a system, its mission and fundamental functionality.

Performance Requirements: The performance levels that the stakeholders want – their objectives. How good?

(Definitions taken from the book "Competitive Engineering" by Tom Gilb.)

A ‘Function Requirement’ invites the “why” question. “Why does it need to do this ? To solve what problem, to meet what requirement ?”.  

Stakeholders' Objective
 

If that “why” question is asked at the highest architectural level of a given Function Requirement, the “why” question is answered by a statement of the kind… because we want to achieve (or maintain) a certain state (or set of states), ie. goal-states. The Function required is a proposed solution as a means to achieve that set of goal-states.

Since the question is being asked at the highest level functional level, could it be that those goal-states equate to the key performance levels the stakeholders want ? ie. From the book's definition above: their objectives?

eg. Why do you want to build this WAP-enabled mobile phone ? Because we think its sales will help us achieve our revenue goals / market-share goals etc

An example: when President Kennedy committed the USA, before that decade was out, to landing a man on the moon and returning him safely, Kennedy was stating the mission. That is, the 'functional' aspect of what was to be done. If you ask the question "why was that to be done?", you get an answer in terms of catching up with and overtaking the Soviet space programme. In effect, a 'performance' or goal state requirement.

So at the highest level at least, the set of Performance Requirements would appear to be a necessary predecessor to the Function Requirement. Is there a pattern here ?

Do we in general, propose a Function Requirement as a solution to the problem of… here’s the goal state (performance parameters) we want. How do we achieve it ?

The answer is a Function Requirement = “What a system has to do: the essence of a system, its mission and fundamental functionality”

In other words, the Function Requirements set  - it must do these things – is a solution to a Performance Requirements set. By doing these things we expect to achieve the goal-states.

Once we have that Function Requirements set, then we can propose designs by which to achieve them.

The next problem is… “well if that’s the design, then it in turn must meet these performance requirements in order to play its role in the greater system”.

As the diagram shows, this is an infinite regression – the trick is to choose the interesting portion of this chain.

Conclusion (and why it matters!): whenever you encounter an initiative or project in a business organisation, you can ask yourself  "what is the 'performance requirement' being worked on here"? (More accurately, there will usually be more than one. There will be a set of performance requirements).

Should you then feel suitably emboldened, you can ask quietly and carefully, "how well does this initiative or project address and satisfy the implicit performance requirements"? The answers can be informative and intriguing, but that's a subject for a separate article!

________________________________
 

Copyright © Business Transition Technologies Ltd 2006. All Rights Reserved.