No comprende the non-functional requirements: Part 1

During my relatively short career so far, I have experienced what must be the full range of industry practices regarding requirements engineering. From working in organisations where requirements simply did not exist, through to my current role developing safety critical systems where massive resources are dedicated to ensuring requirements are accurate, verifiable and traceable.

I really enjoy the requirements engineering process, and am finding it becomes even more fun as my experience and confidence grows. There is however one concept that I have so far struggled to fully comprehend: non-functional requirements.

During one of my undergraduate modules, non-functional requirements were introduced as ‘constraints’. These were described as being a limitation on the system or its development; relating to the style of a graphical user interface for example, or possibly imposing rules on the development tools that could be used.

The point was also made that constraints could either arise from internal concerns, such as a requirement to follow an organisational coding standard, or external sources, for example a requirement to meet government imposed security or safety targets.

Later on during my postgraduate study, non-functional requirements were re-introduced as ‘quality requirements’. This time around, quality requirements were described as being constraints placed on the functional requirements and, while functional requirements are elicited from the user and are also typically project specific, quality requirements supposedly fit into well recognised categories.

This second definition feels like the academics are starting to pin down exactly what they expect of a non-functional requirement, however it still seems quite vague. Furthermore, when studying the module, I had a niggling feeling in my mind that this new definition appears to be more restrictive in that quality requirements are used only to quantify or clarify functional requirements. Where would constraints on the operating system or development tools used fit in this scheme of ‘quality requirements’?

While the idea of specifying constraints on the system is not actually very difficult to grasp, what I am struggling to comprehend is how this could be of benefit in the real world.

When I have worked in organisations that do have some form of requirements documentation, I cannot recall ever seeing non-functional requirements being included. Indeed, in my current role, constraints regarding time sensitive operations, data integrity and other ‘quality based’ aspects are simply treated as functional requirements.

As this gap in my understanding has bothered me for a while now, I was pleased to see that my local branch of the Chartered Institute for IT is providing a free lecture next week entitled ‘The Importance of Non-Functional Requirements’.

After attending, hopefully things will be more clear and I will be able to return here and provide a summary in part 2.

DW.