In recent large projects I have been involved in defining an approach for capturing Non Functional Requirements, which are all quality aspects and constraints that will be required to satisfy in order to deliver the business goals, objectives or capabilities. These requirements are also necessary in a project scoping phase to evaluate project feasibility, costs and duration.
The “non functional requirements” term is often misunderstood by business users as they do not see why something would be “non-functional” in their requirements. This is why we are now rather using qualities (and constraints) to define these requirements.
In addition this is converging with the ISO 25010 that defines a model for Systems and software Quality Requirements and Evaluation (SQuaRE).
The divisions within the SQuaRE series are:
- ISO/IEC 2500n - Quality Management Division.
- ISO/IEC 2501n - Quality Model Division.
- ISO/IEC 2502n - Quality Measurement Division.
- ISO/IEC 2503n - Quality Requirements Division
- ISO/IEC 2504n - Quality Evaluation Division.
The ISO 25010 model defines the quality in use model (quality viewed from users of the system) and the product quality (intrinsic product viewpoint) models.
The “quality in use” model defines 14 characteristics and sub characteristics while the “product quality” model has 39 characteristics and sub characteristics shown in the table further below.
However not all qualities requirements will be the same for all of the architecture elements. For example the “Time behavior” quality, which could be a response time, can be different for an online account balance query versus a loan acceptance. On the other hand developing very detailed quality requirements is time and effort consuming, and there need to be a tradeoff between having enough requirements to size and cost, and spending too much time in trying to capture target measurements such as number of users, queries, locations etc.
Once defined quality requirement need to be defined with a precise measurement, such as Gigabytes per users, Screen size, response time in second, if necessary using examples from ISO/IEC 2502n - Quality Measurement Division. A verification method must be defined, so that users that see the resulting system can check that the requirement is delivered.
Some requirements are cumulative (storage, seats, physical space) so all of them need to be evaluated, for others the most constraining requirement is the one to capture (what is the most consuming user transaction on an ATM since only one at a time can be done).
Using functional decomposition to group requirements
In my projects we needed a way to group functions with similar quality requirements and we used functional decomposition to find such groupings.
For the purpose of the discussion to provide a public example on how we made this groupings I’ll use the BIAN service landscape see https://bian.org/servicelandscape/ (for telecommunication operators it could be the TAM https://www.tmforum.org/application-framework/ or a process classification such as APQC https://www.apqc.org/pcf ).
In the following picture a subset of the BIAN service landscape decomposition is on the left, and the ISO 25010 qualities are on the column headers.
As requirement groupings one can consider that all the quality requirements that relate to "collateral services" domain could be identical and captured in a single work product.
On the other hand it can make sense to have security requirements common to all of the enterprise.
Finally that does not prevent from having a specific set of requirements for a particular service, as an example the Fraud detection could be a highly restricted service and have its own requirements.
As a conclusion, the approach is to be as exhaustive as possible to avoid missing a cost factor, but also try to limit requirement capture effort by grouping as much as possible, and by only capturing requirements, that can be measured and verified.