The influence of non-functional requirements

Don't underestimate it

As technical people, it's really easy for us to think about software as a purely technical endeavour when we should always remember that software is really about solving business problems or providing some benefit to somebody. Over the past few years, more and more emphasis has been placed on this, evident from concepts such as enhanced customer collaboration, BPMN and SOA.

Clearly the functional requirements are important because they ultimately govern what the system does. But as I've said before, the non-functional requirements are equally as important and part of the software architect's role is to balance these often competing forces to come up with a solution that meets the needs.

Sometimes, the non-functional requirements will have more of an influence on the solution definition than the functional requirements. A simple case in point is an Internet search engine. The functional requirements are conceptually very simple but it's the non-functional requirements that are the killer. Imagine building something like Google and then attempting to tack on massive scalability afterwards.

Recently, I was part of a team that was asked to put together some ballpark costs for the development of a new service within an existing service oriented architecture. Although the business requirements were exceptionally detailed, the lack of contextual information and non-functional requirements meant that putting together that ballpark cost was a near impossible task. Aspects such as performance, scalability, availability, operational impact, etc all play their part in influencing the size and complexity of the solution. Even with the best set of business requirements in the world, there's no way you can define a solution if you don't know the context of the problem. Don't underestimate the influence of non-functional requirements.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: The influence of non-functional requirements

I think that when it comes to software architecture the so-called non-functional requirements (I prefer quality attributes) are the ones that have the most influence. The "trick" is to specify them as verifiable and quantifiable scenarios (functional occurrences) within the system rather than vague statements like "we need scalability"

Re: The influence of non-functional requirements

The Non Functional requirements or the quality attributes of software should be quantifiable. The marketing folks could say "The application should perform well under any circumstances". Now this is upto the Architect to design the Non Functional Parameters for the software and give it a measure such as the system should perform well under 2ms. Performance Testing and Performance models should be used to ensure that such constraints on the system be met. The functional designer would only be concerned about the behaviour of the system but we as a Non Functional Desigers should think on the lines of putting constraints on the system as a whole (After all Non Functional design is all about putting constraints on the system).

Add a comment Send a TrackBack