Username:
Password:
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:
Functional requirements will be the focus of the early design and development work. There are modelling techniques (notations) such as the UML Use Case and Activity Diagrams, extended Function Flow Block Diagrams (eFFBDs) or Behaviour Diagrams, which offer methods for depicting what operations are to be done in time sequence and the control logic that will control the flow of execution.
Treatment of the non-functional user requirements may not be so straightforward. We must first look at the basic types of NFRs:
A widely-used group of ilities is Reliability, Availability, and Maintainability (RAM) 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 lead to a system being 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, while behaviour diagrams and use cases describe the desired system operation and behaviour in functional terms (that is, 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
Back to the newsletter archive.
