What the Heck are Non-Functional Requirements?
Join the DZone community and get the full member experience.Join For Free
simply put, if functional requirements create code that will address the needs of the end-users (customers), then non-functional requirements address the needs of the people who install, operate, and configure the code.
those people are the operations personnel and help desk personnel in whatever organization that uses your software. every developer needs to be aware of what those non-functional requirements are and why operations personnel and help desk personnel are customers that are just as important as the end-users.
functional requirementsfunctional requirements are baked into the code that developers deliver (interpreted or compiled). events from input devices (network, keyboard, devices) trigger functions to convert input into output -- all functions have the form:
this is true whether you use an object-oriented language or not. non-functional requirements involve everything that surrounds a functional code unit. non-functional requirements concern things that involve time, memory, access, and location:
if you have any knowledge of itil you will recognize that the last 4 items deal with the warranty of a service. in fact, the functional requirements involve the utility of a service, the non-functional requirements involve the warranty of a service.
developer's need to be aware of the difficulty of creating the ci for the operations personnel. if a ci is manually created then there will always be a potential for an error when the service is installed or updated. the requirement to create a ci is a non-functional requirement and the ability to minimize errors is another non-functional requirement.
developer's need to be aware of single-points of failure (i.e. services hard-coded to a specific ip) which causes fits in operations that are not running virtual machines (vm) that can have virtual ips . the requirement to create code that is not reliant on static ips or specific machines is a non-functional requirement. availability is simplified in operations if the code is resilient enough to allow itself to easily move (or be replicated) among servers.
availability non-functional requirements include:
- ability to easily make the ci
- automatic installation of ci or mechanisms
- ability to detect and prevent manual errors for a ci
- ability to easily move code between servers
internet services almost always can't provide enough capacity with a single machine and operations personnel need to be able to run multiple servers with the same software to meet capacity requirements. the ability to run multiple servers without conflicts is a non-functional requirement. the ability to take a failing node and restart it on another machine or vm is a non-functional requirement.
capacity non-functional requirements include:
- ability to run multiple instances of code easily
- ability to easily move a running code instance to another server
where availability and capacity often involve redundancy inside a single operation center, continuity involves geographic and network redundancy. continuity at best involves having multiple servers that can work in geographically distributed operation centers. at worst, you need to be able to have a master-slave fail over model with the ability to journal transactions and eventually bring the master back up.
where access is concerned, how difficult will it be for operations personnel or help desks to set up security for users? developer's build in different levels of access into their applications without considering how difficult it will be for a 3rd party (help desk or operations) to set-up end users. the ease of setting up security is a non-functional requirement.
data integrity is another non-functional requirement. developer's need to consider how their applications will behave if the program encounters corrupted data due to machine or network failures. this is not as important an issue in environments using raid or redundant databases.
when you forget non-functional requirements...
for example, it is easy to be fooled into building software that is tied to a single machine, however, this will not scale in operations and cause problems later on. one of the start-ups i was with built a server for processing credit/debit card transactions without considering non-functional requirements (capacity, continuity).
it cost more to add the non-functional requirements than it cost to develop the software!
every non-functional requirement that is not thought through at the inception of a project will often represent significant work to add later on. every such project is a 0 function point project that will require non zero cost !
generally availability, capacity, and continuity is not a problem for services developed with cloud computing in mind. however, there are thousands of legacy services that were developed before cloud computing was even possible.
if you are developing a new service then make sure it is cloud enabled!
operations people are people too
hardware and os solutions exist for making up for poorly written software that assumes single machines or does not take into account the environment that the code is running in, but that can come at a fairly steep cost in infrastructure.
the world has moved to services and it is no longer possible for developers to ignore the non-functional requirements involved with the code that they are developing. developer's that think through the non-functional requirements can reduce costs dramatically on the bottom line and quality of service being delivered.
the guys that run operational centers and help desks are customers that are only slightly less important than the end-user. early consideration of the non-functional requirements makes their lives easier and makes it much easier to sell your software/services. it is no longer possible for competent developers to be unaware of non-functional requirements.
Published at DZone with permission of Dalip Mahal, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.