Every business solution  aims at addressing business/customer needs. So an appropriate understanding of these needs is fundamental before proceeding with a design, a development, an implementation, … In short, everything that the adopted development methodology  requires.
Perfect, are we tempted to say, but … what about the needs which are not business i.e. not rendering directly value to the customers ? for example the capacity, robustness or resilience of the solution ? These requirements are often called “non-functional” . And finally what about the processes supporting the business solution: operation, maintenance, support, ordering, billing, … ?
|In an IT context, most of the development methodologies start by analysing the business needs (business modelling), then derive the necessary functionality to support these needs that get finally implemented in a technical solution (software/hardware). These methodologies tend to focus on the functional needs (the ones directly beneficial to the customer or expressed by him) and on software aspects. The processes and non-functional parts being less well covered.|
This is the submerged part of the iceberg which can nevertheless represent a consequent or the main part of the overall development efforts and costs. Here are some examples of non-functional aspects to take into account:
|Audit and control||Parties (dependency on other)||Efficiency|
|Deployment||Resilience||Legal and licensing|
Underestimating or ignoring these aspects induces delays, additional costs and inaccurate business cases because the reality of the implementation of the solution always demands these requirements to be addressed sooner or later. Who can for example afford to spare security or performance ?
So how to increase the chances not to miss anything ?
- By adopting a development methodology that takes into account the needs of all the actors interacting with the solution i.e. not only the business actors but also the non–business ones: back office , third-party providers, employees …
- But also by initiating the design and development of the processes associated with the business solution. This effort must be conducted simultaneoulsy to the software development effort.
What the iceberg metaphor tells us is that what is visible is anticipated and what is hidden is underestimated but this is that part that makes the whole thing float.