In a previous post I discussed my difficulty in understanding the concept of non-functional requirements and how I planned to attend a lecture on the subject provided by my local branch of the Chartered Institute for IT.
Having now sat through this lecture, I am relieved to know that I was not alone in my confusion; and overjoyed that the concept clicked nicely into place while the speaker was providing examples and answering the lively questions put forward by members of the audience.
Indeed, the opening slide attested to the fact that there is ambiguity in the literature by providing three very different definitions of what a non-functional requirement actually is. Indecently, all three definitions differ again to the two that I had been given previously during my university studies.
The mist began to clear for me during the next slide, which turned to discussion of what a non-functional requirement is not. Or put another way – reinforcing the definition of what a functional requirement is; something that perhaps I had skimmed over in the past, feeling it to be understood intuitively.
The fact is: a functional requirement must ‘do’ something; it embodies a process that can be depicted in a flow chart. An example of this may be: ‘the mobile phone shall send and receive text messages’.
Non-functional requirements are simply everything else.
Sizes, shapes, colours, costs, etc. are all non-functional requirements. They don’t ‘do’ anything.
At this point it started to become apparent to me that the notion of functional requirements is possibly very widely misunderstood, and that the vast majority of a project’s requirements will actually fall into the non-functional category.
Furthermore, I have begun to develop my own theory regarding non-functional requirements as an attribute, or property, of another object. For example: a system may be made up of a set of components, but will also have its own non-functional requirements. These system level non-functional requirements may relate to the programming language or operating system used, the overall cost of the system, or characteristics of the target users.
Each component will subsequently consist of a set of functional requirements, which together specify what the component does, but also includes a set of component level non-functional requirements. These may relate to the component’s size, complexity, or how it interfaces with other components.
Finally, each functional requirement will in turn have its own set of non-functional requirements. At this level, these will relate to constraints on how the function is carried out; such as the expected length of a string being input into a webpage form field, or the font, colour, and size of a message that is displayed to the user.
I find it particularly interesting that at each of the levels (system, component or functional requirement level) a common set of non-functional requirements would reoccur with each new project. For example: the size of a system must always be considered, as must the font and size of a message to be displayed.
These common categories of non-functional requirements could quite easily be used as the basis for a template or automated tool that could then be used to speed up requirements gathering activity, whilst ensuring that all necessary requirements were captured and verifiable.
Looking back to my original post, I can now see that the definitions I had been given during my university studies were actually correct, and perhaps the problem stemmed from my own limited understanding surrounding functional requirements.
From now on though, if I am in a discussion over whether or not a requirement is functional or non-functional, I will simply suggest to consider whether the requirement actually ‘does’ something. If not, then it is definitely non-functional.
DW.