Non-Functional Requirements across the full project lifecycle!

Posted by André on 2014-02-23.

It is a well known fact that bugs are the harder and the more expensive to fix the later they are discovered in the project lifecycle. The cheapest one is the bug not made of course. The most expensive one is when your business critical application crashes and can not be recovered. And everything in between.

So the focus is on avoiding bugs - but still most of the time the functional requirements, i.e. WHAT the application has to do, is much more in focus than the non-functional requirements: HOW the application has to do things. And this includes a number of qualities that you want to build into your application right from the start, just for example:

The focus on functional requirements is often so strong that non-functional requirements are almost neglected. Performance for example is often thought of being "tacked on" at the end, "we just do a load test and are done"... This is a guarantee for failure!

So it is extremely important that you think about non-functional requirements end-to-end, or full lifecycle in a project. That reaches from


In your requirements phase you need to be aware of the non-functional requirements. Even if they are not stated in the contract or statement of work, there at least is an expectation that you need to fulfill. So it's better to manage the expectation and define what you're going to do and why. This also helps deciding what to do in the later project phases.


In your implementation phase, there are many decisions you need to take to support your non-functional requirements. For example the technology or the products you are going to use must support your non-functional requirements. When you have an "always on" requirement and a product that regularly needs maintenance windows, you can't use that product - or you have additional effort to work around that.

Also the architecture you define has to support your non-functional requirements. In some cases you have to weigh different non-functional requirements against each other here. An ETL process may be best for your throughput requirements, but may not be suitable for some response time requirements. Also maintainability requires you to structure your architecture and design for reuse and refactoring (which you're doing anyway, right?)

The actual development also needs to take care in using patterns and avoiding anti-patterns for the given non-functional requirements. That includes avoiding performance anti-patterns, but also implementing security best practices (avoid SQL injections, cross-site-scripting for example). Maintainability here requires the use of code quality metrics that should be well-defined (ahead of the actual implementation that is...)


In the test phase (or even in continous testing) you not only need to test for functional qualities of the software, but also for the non-functional aspects. Some aspects of maintainability can for example be continously tested with code structure and code quality metrics tools in a continous build process.

Load tests should not only test response times, but also throughput. And especially the load tests should test the response times under high throughput conditions. Continously repeat them - later releases may easily introduce regressions that you don't want to catch in production. For this to work efficiently, automate them.

Other non-functional requirements need to be checked for as well. For availability you may need to "pull the plug" in parts of your infrastructure to see if the application survives and how.


Speaking of infrastructure - often the infrastructure and operations is not handled by the project team implementing the application. Therefore introduce the infrastructure teams or departments to the non-functional requirements early in the project. Together make sure your infrastructure supports the non-functional requirements. This is especially important for throughput and availability. Also performance plays an important role here when using infrastructure services (or services from other applications or projects). Make a throughput model to estimate what amount of data you need to transfer.

Operations and Support

As with infrastructure, operations and support are often done by separate teams. Involve them early in the project. Maybe plan in operations support functionality in your application. Make sure your operations and support teams support the availability requirements. Make sure the other relevant non-functional requirements are monitored in operations. For example monitor your number of requests over time so you'll be able to scale up once your application goes viral - maybe even automate this. Monitor the performance of your application by use case, so you can feed back this information to the development team to continously improve it.


Succesfully finishing an application development project is not all about the functional requirements. In fact as long as the focus is so much on functional qualities, I say that it's as much about non-functional requirements. Especially in today's mobile, instant-response, always-on expectation world, it's even more about non-functional requirements. If a function does not perform, it won't be used.

As a lead architect, or technical project lead, or whatever the name of the role is in your organisation or project, it is your responsibility, to make sure the non-functional requirements are implemented by the non-functional qualities of the system.

To achieve this, as shown above, make sure the non-functional requirements are considered from early on the project, and in the full lifecycle of the project!