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.

Responses[1]

Posted by Simon Brown on 09 July 2007 14:11:00 BST #