A Reflection on the Importance of Non-Functional Requirements

By: Graham Hoyes

Published on: April 14, 2017

Every project has two fundamental aspects to it: functional and non-functional requirements. Functional requirements are those things that are necessary for something to be considered "working". Does the form insert into the SQL database properly? Is the server up when you need to use it? Too often, this is how many people judge the performance of a product. I confess that I, too, often fall prey to the temptation of getting something just "working", then moving onto the next exciting task.

As an example, consider my counters server. This was a fun project for me to learn how to use Node.js and socket.io, and is something that does what it is supposed to do with those tools (that is, increment a counter in a particular server whenever someone who is connected clicks the button). However, if you were to visit the page right now, there is a good chance that there is a red bar along the top that says "Could not connect to server. Retrying". That is the case because my only focus when developing it was on the functional aspect of it - making it work under the cases I needed it to. And it does that quite well, except under one case: when my web server restarts. Although it would not take me long to fix it, right now the Node.js script runs using pm2, and so it doesn't restart when the server does.

This is something I had considered to be a non-functional requirement: that is, restarting automatically isn't critical to the function of the application, since I can just start it manually whenever I need it. However, this is a metric by which I could gauge the quality of what I created on a continuous scale, rather than just the boolean of "Does it work: True or False" (or 1 or 0 for those inclined to use C).

As I progress through my career as a student Engineer and continue to practice engineering design, this is an area I strive for self-improvement in. Focusing not only making something work in as short a time as possible (the counter server only took me about a day), but in knowing why something actually works, and being able to say why I know that something works well. This improvement will involve being much more rigorous in what I do. Not only ensuring I follow my design process (as it currently stands), but also focusing on developing strict metrics and rigid test protocols to guage the effectiveness of a specific aspect of a project.