Non functional Requirements as an afterthought
Have you been on a project where non functional requirements are an afterthought?
I dislike the terms functional and non functional requirements (NFRs) because it starts to divide requirements discussions into two parts. This is why in my opinion, using this terminology is a cause of NFRs becoming an afterthought.
I much prefer something like quality criteria or system quality characteristics. However, this terminology of functional and non-functional is not going away any time soon. It is used by stakeholders in most businesses, so it’s a waste of energy fighting an uphill battle. So as we’re stuck with it, how do we solve this problem?
What I believe what we could do is explain why we need to consider non functionals early.
- Non functional criteria like a product being secure, performant accessible, usable etc is going to drive the shape of your architecture (note this post where I got this from. A great read guide on non functionals https://www.boxuk.com/insight/guide-to-non-functional-requirements-types-and-examples/ )
- The priorty of non functionals like security is more important than the functional aspect. This is a fact of morals in my opinion — protecting your user’s data for example, is more important than the capabilities of your product. This is why security first mindset is so important.
- Prevent big amounts of rework — If non functional criteria drives the shape of your architecture and you miss important information that shapes it, then you are at risk of rework driving costs, time and effort on your project.
Those are the thoughts that I have to date — have you got any explanations to why we need to consider them early?
