Non-functional requirements and system qualities - closing the chasm

In my architecture consulting and training assignments, software developers and architects often tell me that the non-functional requirements they receive are not usable.  The main gripes they have are that the NFRs are sweeping statements not specific to particular transactions, they aren’t credibly traceable to real business needs, or some important categories of NFRs are missing altogether.

Likewise a number of business analysts tell me that they find it difficult to define NFRs; they feel that these are so “technical” that they should be defined by developers, architects or infrastructure specialists.

If this is the situation that you face – a chasm cutting through the team’s understanding, take heart: it doesn’t have to be this difficult!  The first step towards closing the chasm is for members of the team to shift their expectations and take on a bit more work:

• Developers or architects: recognise that you will always have to engineer the system quality requirements when you engineer the system.  Don’t expect comprehensive non-functional requirements to be handed to you on a plate – they are unlikely to be adequate, and you need the opportunity to explore and negotiate them and understand the real drivers behind them.
• Business analysts: work with the stakeholders to envisage the business context in which the IT solution will be used, and what will drive the need to change the solution over time. Learn which quality characteristics the architects and developers are most influenced by, and which aspects of the business context and IT context typically drive these characteristics.  
  
  For example, to support a particular business function, the value required for the system security characteristic Confidentiality will depend on the intra-business and inter-business environment in which the system is used, particularly the trust relationships and the business requirements for privacy.  Instead of wondering about encryption standards the business analyst is now dealing with trust and privacy, well within their ability.

The second step towards closing the chasm is already hinted at above.  It starts with the team recognising the different types of quality or non-functional or requirements and design decisions, whether they are desired properties of the business or of the system’s externals or its internals, so which sort of stakeholder is entitled to assert these requirements or make these decisions.  Then when you understand the drives / supports relationship between the levels it is much easier to derive or create requirements that are clearly justified and traceable.

In my experience, many teams don’t give enough thought to the types (or levels) of quality requirements and decisions.  In dealing with the requirements and decisions they inadvertently work with a mix of levels without realising it.  For example they try to elicit detailed technical requirements from business people, or write technical decisions into business analysis deliverables.  It doesn’t help that the business stakeholders often state some very specific design decisions such as “the customer data must be stored on the salesperson’s PC”.

What are these different levels of quality requirements and decisions?  How do they differ in the domain that they concern, or the types of stakeholder immediately impacted by them being met?

Usually I find that the non-functional requiremetns provided to the developers and architect are really just a survey, partially covering levels 1, 2 and 3, with “requirements” that are arbitrary rather than strictly required, not tempered with enough reality.  At this point it is best for the architect to take responsibility for the NFRs, and engineer the NFRs so that they are usable by the people who depend on them, i.e. the developers, architects and testers. Engineering the system includes the usual trade-offs between the design parameters in order to achieve the required properties and qualities in the appropriate balance.

However, engineering the system is not a one-way process, working down through the levels.  It involves querying and challenging the functional and non-functional requirements, and zig-zagging between making design choices and negotiating the requirements.  The requirements cease being arbitrary and reach the right balance because they are both necessary and achievable.

OK, you have accepted the mission, but what resources are available to base your quality analysis and design on?  The two leading organisations providing frameworks for organising system quality specifications are the International Organisation for Standardisation (ISO) and the Software Engineering Institute (SEI).

The ISO 25010 standard replaces ISO 9126 and defines sets of quality characteristics, for which you define measures and target values. The ISO equivalents to my levels above are:

• Level 3: Quality In Use Characteristic, e.g. Efficiency.
• Level 4: External Quality Sub-Characteristic, e.g. Time Behaviour.
• Level 5: Internal Quality Sub-Characteristic, e.g. Time Behaviour

SEI uses an equivalent set of terminology, and provides process guidance in the Architecture Tradeoff Analysis Method (ATAM). This includes the Quality Attribute Scenario technique for quantifying the NFRs and tracing them up the levels to real business needs.