Username:
Password:
There are techniques and notations to address functional user requirements, both to produce functional system requirements and to develop architectural and behavioural models that support the system design. There are also graphical techniques to assist the development of non-functional system requirements from the non-functional user requirements.
One technique is the Non Functional Requirement Graph (NFRG) that has been discussed in the requirements literature for some years.
NFRGs start with non-functional user requirements and provide assistance to evolve these into corresponding non-functional system requirements that can be directly and meaningfully related to the system architecture:
In this approach, we start with the non-functional user requirements and express these as goals. That is, we start with the stakeholders’ statements in the original non-functional user requirements and create new derived requirements linked to these original statements that re-express the original statement as a goal, something that is to be achieved. An example is the classic (and possibly infamous!) goal “The system shall be easy to use”.
The aim of the NFRG is to help us to evolve these stakeholder goals into declarations held in the non-functional system requirements. These declarations are not detailed statements of what the system will be or what it will contain, but are expressions of the form of the solution to be described in the architecture. The declarations are consequently constraints on the form of the solution to the goal that will be built into the system.
The NFRG shows the transition between the goals and the solution constraints that satisfy them. This transition is shown as interlinking intermediate stages, which are initially sub-goals of the goals and become candidate solutions at we progress:
The intermediate goals and solutions are linked by lines that show the relationships between these intermediate NFRs.
There are four types of relationship shown in a NFRG:
The meanings of these are:
The names of these relationships may change between different authors of NFRGs, but the concept of the relationships does not change. So, some authors may use a Guarantees relationship instead of Ensures, or Inhibits instead of Impairs.
The meanings of the relationships in the NFRG are deliberately imprecise. For example, there is nothing arithmetic about them, so that, for example:
It is not true to say that many Assists relationships are equal to an Ensures relationship. Neither is it true that if there are more Assists relationships than Impairs relationships then the net result is an Assists relationship. In this latter case, the NFRG is simply showing part of our decision making process, that some declarations assist achieving the goal and some impair it.
There are points of style here too. For example, having two sub-goals where one Ensures the goal and the other Prevents the goal may, or may not make sense. It may not make sense because if you achieve both sub-goals then achievement of the main goal is indeterminate. It may make sense if the aim of the NFRG is to document all aspects of the decision making process, and, in practice, both of the sub-goals cannot be achieved with the solution constraint that is ultimately shown in the NFRG.
The NFRG is a graph, not a hierarchy. Any sub-goal or candidate solution can be linked to more than one higher-level goal, sub-goal or candidate solution if that is what we want to show.
Collectively the NFRG is a graphical justification for the assertion that the non functional system requirements do indeed satisfy and express the non functional user requirements.
Such justifications are always needed and always valuable. This justification is particularly valuable in connection with non-functional requirements since non-functional requirements are often inherently less precise and more subjective that the functional requirements. In turn, this means that the justification that a given set of non-functional system requirements is the best way to satisfy non-functional requirements (goals, desires and so on) from stakeholders is very much more difficult without NFRGs as an explanatory technique.
Finally, by being graphical, NFRGs are an ideal means to present the chains of decisions and reasoning that has produced the non-functional system requirements.
For an example, we consider the goal “The system shall be easy to use” for a system that receives user inputs in response to questions and messages shown by the system, such as a car park ticket machine, or an airline ticket dispenser.
The non-functional user requirement, the goal, is shown at the top of the NFRG shaded in green, and the resulting solution constraints, the non-functional system requirements, are shown at the bottom of the NFRG shaded in blue.
The NFRG shows the justification that the two non-functional system requirements “Use custom keypad” and “Use plasma display” satisfy the non-functional user requirement “The system shall be easy to use”.
These will be the system requirements that are to be carried into the system design process.
Cradle fully supports NFRs and NFRGs. The manner in which the NFRs, goals, constraints and so on are actually represented in your project is your decision.
We can, however, offer some suggestions.
The non-functional requirements will usually be appropriately marked user requirements (URs) in the same way as the functional URs. The top-level goals can then either be user requirements (URs) as well, or they can be items of a new type, such as a new item type GOAL. The sub-goals would be implemented in the same way as the goals. The candidate solutions and constraints could also be items of a new type, such as CONSTRAINT, or they could be system requirements (SRs) in the same manner as functional (behavioural) SRs. As a final choice, you could choose to have a single new item type, such as NFR, for all of the goals, sub-goals, candidate solutions and solution constraints that you would represent in your NFRGs.
The relationships shown in the NFRG are cross references in the Cradle database with link types ENSURES, ASSISTS, IMPAIRS and PREVENTS.
The NFRG itself is a Hierarchy Diagram (HID). These diagrams are generated dynamically on demand by Cradle, both within the UIs of the Cradle tools and also when included in a document generated from the Cradle database by the Document Publisher tool.
To use NFRs in Cradle you will:
At any time, you produce a NFRG by simply displaying a Hierarchy Diagram starting at any of the URs, the goals or sub-goals.
Back to the newsletter archive.
