User requirements are statements of user need, as expressed by the groups of stakeholders concerned with the system being developed. They address many aspects of the system, some behavioural and some not.
In general, behavioural user requirements are of one of two types: those that specify what is to be accomplished ( functional requirements), and those that specify how well the functions are to be accomplished ( performance requirements).
Non-functional requirements (NFRs), on the other hand, are often simply a catch-all term for all user requirements that are not explicitly functional. NFRs are sometimes referred to as non-behavioural rather than non-functional to more closely suit the process (e.g. OO-UML).
NFRs occur in many forms, including contractual or commercial statements, compliance with standards, environmental factors to be considered (such as temperature ranges, radiation levels or gradients to be climbed) and perhaps the most intangible (or difficult to address of all), the ilities. The ilities are typically expressions of the emergent properties of the system, the characteristics that its users desire that the system should exhibit once it is complete but which its component parts do not necessarily exhibit, or exhibit differently.
They include characteristics such as:
Treatment of the non-functional user requirements may not be so straightforward. We must first look at the basic types of NFRs:
Environment – requirements defining the physical environment (natural and induced) for system operation. In some cases, they may also address the political or economic setting in which the work is done or the system performs
Physical – requirements describing the form of the product or system. Examples include specifying the size, shape, paint finish, weight or other similar properties of products or systems.
Interface – requirements defining the data, structure and physical form of interfaces between components (hardware, software and people). There may also be a need to interface to existing systems or provide certain standard interfaces. Some requirements analysts classify interface requirements as a separate group, not as a type of NFR.
Constraints – requirements prescribing stipulations or limitations on how the system can be built, or how and in what context should other requirements apply. Non-technical aspects such as timeline and budget can also constrain development projects.
Quality Factors (Emergent Properties) – requirements that address other quality factors of the product or process, the ilities mentioned above.
A widely-used group of ilities is Reliability, Availability, and Maintainability (RAM) that arise in real-time defence, aerospace, process control, telecommunications and transport systems where the continual correct functioning of the product is important. RAM requirements are threatened by many kinds of risk or circumstance, such as design errors, operator overload or confusion, under-sized hardware and environmental factors (wind, rain, temperature variations, dust storms). These can cause hardware failures, software crashes, and human errors in judgement.
Other NFR ilities include testability, portability/mobility, usability, scalability, flexibility and supportability. Degradation in these or other quality factors incorporated as requirements will lead to system underperformance or failure. Usability can be compromised by an operator pushing the wrong button. Poor (or no) storability requirements lead to damage of delicate components; non-adherence to portability requirements may leave the system at the base and not in the field, and so on.
Not all quality factors are ilities in the strictest sense of the word. Requirements addressing security, system integrity and workmanship are important NFRs as well.
It is interesting to note that, whereas the behaviour diagrams and use cases describe the desired system operation and behaviour in functional terms (that is, to do this and then do that), the potential negative behaviour or misuses of the system lead to Non-Functional Requirements for protection and endurance.
Note also that NFRs at a high (entire system) level may lead to functions at the lower levels (subsystems or components). For example, a system-level safety requirement to suppress unwanted flames or burning material within a laboratory may lead to a sprinkler subsystem to protect the laboratory as a whole.
A key activity to address NFRs is the defining the physical architecture. One develops the system architecture by:
Defining the product structure (i.e. the component parts)
Allocating the required characteristics (e.g. colour, size, weight, MTBF, COTS equipment features) to the components
Specifying the interfaces between the component parts
This activity ensures that you address both functional and non-functional requirements during the system modelling and design process.
The aim for all analysis of user NFRs is to produce corresponding system NFRs that can be measured and tested and allocated into the system architecture. That is, the aim is to derive a collection of non-functional system requirements that:
Can be measured
Can be tested
Can be allocated to (that is, linked to) the system architecture
Non Functional Requirement Graphs
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 have 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:
NFRG Approach
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.
NFRG Relationships
There are four types of relationship shown in a NFRG:
The meanings of these are:
Ensures. This relationship means that achieving B will, of itself, ensure that A is satisfied, irrespective of whether any other NFS linked to A is or is not achieved
Assists. This relationship means that achieving B will help to achieve A but achieving B does not, of itself, ensure that A is achieved
Impairs. This relationship means that achieving B will reduce the likelihood of achieving A but does not, of itself, mean that A cannot be achieved
Prevents. This relationship means that achieving B will, of itself, ensure that A cannot be achieved, irrespective of whether any other NFR linked to A is or is not achieved
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 to say 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.
Benefits of Using NFRGs
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.
NFRG Example
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 non-functional system requirements “Use customkeypad” and “Use plasma display” satisfy the non-functional user requirement “Thesystem shall be easy to use”.
NFRGs in Cradle
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 solution 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:
Create appropriate item types in your schema, based on the suggestions above
Create appropriate link types in your schema, based on the suggestions above
Create the URs from your stakeholders, as you would do normally
Create the goals from these URs
Create the sub-goals and link them to the goals using the appropriate link type from those that you have just created, normally by drag-and-drop in WorkBench between trees showing the URs, the goals, the sub-goals and their evolution so far
Proceed in the same way to evolve the sub-goals through as many levels as you need
Proceed in the same way to create potential candidate solutions and evolve them
Proceed in the same way to create solution constraints
Link the solution constraints to non-functional SRs, unless you have decided that the solution constraints are the non-functional SRs themselves (which they certainly could be)
At any time, you produce a NFRG by simply displaying a Hierarchy Diagram starting at any of the URs, the goals or sub-goals.
In general, behavioural user requirements are of one of two types: those that specify what is to be accomplished ( functional requirements), and those that specify how well the functions are to be accomplished ( performance requirements).
Non-functional requirements (NFRs), on the other hand, are often simply a catch-all term for all user requirements that are not explicitly functional. NFRs are sometimes referred to as non-behavioural rather than non-functional to more closely suit the process (e.g. OO-UML).
NFRs occur in many forms, including contractual or commercial statements, compliance with standards, environmental factors to be considered (such as temperature ranges, radiation levels or gradients to be climbed) and perhaps the most intangible (or difficult to address of all), the ilities. The ilities are typically expressions of the emergent properties of the system, the characteristics that its users desire that the system should exhibit once it is complete but which its component parts do not necessarily exhibit, or exhibit differently.
They include characteristics such as:
- Usability
- Reliability
- Maintainability
- Availability
- Survivability (for combat systems)
- Flexibility
- Adaptability
Treatment of the non-functional user requirements may not be so straightforward. We must first look at the basic types of NFRs:
Environment – requirements defining the physical environment (natural and induced) for system operation. In some cases, they may also address the political or economic setting in which the work is done or the system performs
Physical – requirements describing the form of the product or system. Examples include specifying the size, shape, paint finish, weight or other similar properties of products or systems.
Interface – requirements defining the data, structure and physical form of interfaces between components (hardware, software and people). There may also be a need to interface to existing systems or provide certain standard interfaces. Some requirements analysts classify interface requirements as a separate group, not as a type of NFR.
Constraints – requirements prescribing stipulations or limitations on how the system can be built, or how and in what context should other requirements apply. Non-technical aspects such as timeline and budget can also constrain development projects.
Quality Factors (Emergent Properties) – requirements that address other quality factors of the product or process, the ilities mentioned above.
A widely-used group of ilities is Reliability, Availability, and Maintainability (RAM) that arise in real-time defence, aerospace, process control, telecommunications and transport systems where the continual correct functioning of the product is important. RAM requirements are threatened by many kinds of risk or circumstance, such as design errors, operator overload or confusion, under-sized hardware and environmental factors (wind, rain, temperature variations, dust storms). These can cause hardware failures, software crashes, and human errors in judgement.
Other NFR ilities include testability, portability/mobility, usability, scalability, flexibility and supportability. Degradation in these or other quality factors incorporated as requirements will lead to system underperformance or failure. Usability can be compromised by an operator pushing the wrong button. Poor (or no) storability requirements lead to damage of delicate components; non-adherence to portability requirements may leave the system at the base and not in the field, and so on.
Not all quality factors are ilities in the strictest sense of the word. Requirements addressing security, system integrity and workmanship are important NFRs as well.
It is interesting to note that, whereas the behaviour diagrams and use cases describe the desired system operation and behaviour in functional terms (that is, to do this and then do that), the potential negative behaviour or misuses of the system lead to Non-Functional Requirements for protection and endurance.
Note also that NFRs at a high (entire system) level may lead to functions at the lower levels (subsystems or components). For example, a system-level safety requirement to suppress unwanted flames or burning material within a laboratory may lead to a sprinkler subsystem to protect the laboratory as a whole.
A key activity to address NFRs is the defining the physical architecture. One develops the system architecture by:
Defining the product structure (i.e. the component parts)
Allocating the required characteristics (e.g. colour, size, weight, MTBF, COTS equipment features) to the components
Specifying the interfaces between the component parts
This activity ensures that you address both functional and non-functional requirements during the system modelling and design process.
The aim for all analysis of user NFRs is to produce corresponding system NFRs that can be measured and tested and allocated into the system architecture. That is, the aim is to derive a collection of non-functional system requirements that:
Can be measured
Can be tested
Can be allocated to (that is, linked to) the system architecture
Non Functional Requirement Graphs
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 have 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:
NFRG Approach
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.
NFRG Relationships
There are four types of relationship shown in a NFRG:
The meanings of these are:
Ensures. This relationship means that achieving B will, of itself, ensure that A is satisfied, irrespective of whether any other NFS linked to A is or is not achieved
Assists. This relationship means that achieving B will help to achieve A but achieving B does not, of itself, ensure that A is achieved
Impairs. This relationship means that achieving B will reduce the likelihood of achieving A but does not, of itself, mean that A cannot be achieved
Prevents. This relationship means that achieving B will, of itself, ensure that A cannot be achieved, irrespective of whether any other NFR linked to A is or is not achieved
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 to say 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.
Benefits of Using NFRGs
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.
NFRG Example
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 non-functional system requirements “Use customkeypad” and “Use plasma display” satisfy the non-functional user requirement “Thesystem shall be easy to use”.
NFRGs in Cradle
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 solution 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:
Create appropriate item types in your schema, based on the suggestions above
Create appropriate link types in your schema, based on the suggestions above
Create the URs from your stakeholders, as you would do normally
Create the goals from these URs
Create the sub-goals and link them to the goals using the appropriate link type from those that you have just created, normally by drag-and-drop in WorkBench between trees showing the URs, the goals, the sub-goals and their evolution so far
Proceed in the same way to evolve the sub-goals through as many levels as you need
Proceed in the same way to create potential candidate solutions and evolve them
Proceed in the same way to create solution constraints
Link the solution constraints to non-functional SRs, unless you have decided that the solution constraints are the non-functional SRs themselves (which they certainly could be)
At any time, you produce a NFRG by simply displaying a Hierarchy Diagram starting at any of the URs, the goals or sub-goals.
No comments:
Post a Comment