Functional

Functional and Non-functional Requirements

I have long been puzzled by this distinction between “functional” and “non-functional” requirements (did it start with Rational Unified Process, and the desire to draw Use Case Diagrams for functional requirements?).  I find it unhelpful and wonder whether it doesn’t drive architects and business analysts apart when they should be working together from a shared view of the whole.  From an architectural perspective, the focus should be on architecturally significantrequirements, irrespective of whether they are “functional” or “non-functional”.  It cannot be right to believe that only “non-functional” requirements are architecturally significant.  The functional demands of a new system are very likely to shape the solution architecture.  For example, if there is a functional need to persist customer information over time, the architecture must address this requirement with some persistent storage, such as a database.  And it surely makes sense for architects and business analysts to share the same overall view and “sing from the same hymn sheet” rather than work independently on separate agendas.

In the last blog, I proposed the use of a quality model, such as ISO 25010, to structure the most significant requirements.  The model provides a good basis for developing a 360-degree view of all requirements, and it doesn’t make an explicit distinction between “functional” and “non-functional” requirements.  One of its eight Quality Characteristics is called Functional Suitability, but then others, like Usability, might also be considered by some to be “functional”.  I propose that we abandon the “functional” and “non-functional” distinction altogether, giving business analysts and architects the chance to unite around a common view of what good looks like.  This shared starting point allows the architecture and detailed requirements to take shape in parallel, with each informing the other through continuous collaboration.

The burden placed on Functional Suitability

That unified view is a great start to addressing the problem I outlined above.  But I don’t think it is quite enough.  Start using the quality model in ISO 25010, and you quickly realise that too many of the architecturally significant requirements lie within just one characteristic: Functional Suitability.  In the insurance admin system example I used in the previous blog, more than half of the sixty-three architecturally significant requirements fell into this one characteristic, with the vast majority assigned to the Functional Completeness sub-characteristic.  Any trade-offs that occur among this group will only be apparent by comparing the risks associated with individual requirements, undermining the value of using a model to create an abstracted view.  The answer here is to amend the model to suit the profile of the requirements rather than constraining the number of requirements that fall into the Functional Suitability quality characteristic.

Introducing Business Capabilities into the quality model

An approach that I’ve found works well is to replace Functional Suitability and its sub-characteristics in the model with business capabilities.

Business capabilities are a well understood language among business architects, who use business capability maps to organise their understanding of what a business does.  But they might be rather less familiar to solution architects or business analysts.  So what is this language, and why am I asking architects and analysts to start learning it?  A business capability is commonly defined as “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”  It defines what a business does, and not where, why or how.  “Capabilities are the centrepiece of a business architecture” according to Whynde Kuhne, whose book “Strategy to Reality” explains how to develop and use a capability map.  William Ulrich and Michael Rosen have described the business capability map as “the ‘Rosetta Stone’ of Business/IT alignment”.

A business capability has something in common with a quality characteristic, which defines an exhibited or desired quality without going into how that characteristic is to be achieved.  So in the same way that we’ve used a quality model to organise architecturally significant requirements, we can use the relevant parts of a business capability map to further classify those requirements that fall into the Functional Suitability characteristic.

Our quality model has now become a Quality and Capability Model, which replaces or expands the Functional Suitability quality characteristic with those portions of the business capability map that are relevant to the business service or system under consideration.  With our expanded model, trade-offs inherent in solution options are now more clearly exposed, whether they occur among quality characteristics, capabilities or across the two.  Returning to our insurance example, our Quality and Capability Model might look like this:

This model can be used to classify architecturally significant requirements, and then to inform a risk trade-off analysis when evaluating solution architectures, as described in the previous blog.

Thinking beyond technology

The inclusion of business capabilities in the model also encourages the team to think beyond a system and consider the whole solution.  Business value is delivered by a combination of people, process, information and technology.  The architecture of the business service in which a business technology solution is deployed is as significant as the architecture of the technology solution itself, and a combined quality and capability model will help the team to consider the requirements, and assess solution options, in their wider business context.

Is there a case for broadening the field of vision even further?  Developed at Microsoft, the Perspective Based Architecture Method (PBA Method) suggests a very broad structure to promote higher quality decision making.  It divides the landscape into four “zones”: Requirements, IT Environment, Business Environment and Trends.  The author, Lewis Curtis, describes this as a way of organising “a more comprehensive frame of understanding”.  It is this “frame of understanding” that forms the context in which trade-offs can best be understood, with models such as those discussed in this blog helping architects to see the wood for the trees.

And, returning to our journeying architect and analyst, it is that “frame of understanding”, offering a multi-perspective view of capabilities and quality, that can give them the best chance of plotting the right route that they can take together to their desired destination.

In the next blog, I’ll explore how we can add further perspectives to the “frame” – those of an initiative’s stakeholders.