Functional and non-functional requirements
6.1.2 Non-functional requirements
Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific functions delivered by the system. They may relate to emergent system properties such as reliability, response time and store occu-pancy. Alternatively, they may defll1e constraints on the system such as the capa-bilities ofVOdevices and the data representations used in system interfaces.
Non-functional requirements are rarely associated with individual system features.
Rather, these requirements specify or constrain the emergent properties of the sys-tem, as discussed in Chapter 2. Therefore, they may specify system performance security, availability, and other emergent properties. This means that they are often
122 Chapter 6 • Software requirements
Implementation requirements
Figure 6.3 Types of non-functional requirements
more critical than individual functional requirements. System users can usually find ways to' work around a system function that doesn't really meet their needs.
However, failing to meet a non-functional requirement can mean that the whole sys-tem is unusable. For example,ifan aircraft system does not meet its reliability require-ments, it will not be certified as safe for operation; if a real-time control system fails to meet its performance requirements, the control functions will not operate correctly.
Non-functional requirements are not just concerned with the software system to be developed. Some non-functional requirements may constrain the process that should be used to develop the system. Examples of process requirements include a speci-fication of the quality standards that should be used in the process, a specispeci-fication that the design must be produced with a particular CASE toolset and a description of the process that should be followed.
Non-functional requirements arise through user needs, because of budget con-straints, because of organisational policies, because of the need for interoperability with other software or hardware systems, or because of external factors such as safety regulations or privacy legislation. Figure 6.3 is a classification of non-functional requirements. You can see from this diagram that the non-functional requirements may come from required characteristics of the software (product requirements), the organization developing the software (organizational requirements) or from exter-nal sources.
6.1 • Functional and non-functional requirements 123
._---Productrequirement
8.1 The user interface for UBSYS shall be implementedISsimple HTML without frllmes orJIIVIL IIpplets.
Orpnlutlonal requirement
9.3.2 The system development proa!5S and deliverable documents shall conform to the process and deliverables defined in XYZCo-Sp·STAN·9S.
External requirement
10.6 The system shall not disclose any personal information about system users apart trom their name lind library reference number to the librarystaffwho use the system.
The types of non-functional requirements are:
1. Product requirements These~ requirements specify product behaviour.
Examples include performance requirements on how fast the system must exe-cute and how much memory it requires; reliability requirements that set out the acceptable failure rate; portability requirements; and usability requirements.
2. Organisational requirements These requirements are derived from policies and procedures in the customer s and developer s organisation. Examples include pro<;ess standards that must be used; implementation requirements such as the programming language or design method usedl; and delivery requirements that spedfy when the product and :Its documentation are to be delivered.
3. External requirements This broad heading coversallrequirements that are derived from factors external to the system and its development process. These may include interoperability requirements that define how the system interacts with systems in other organisations: legislative requirements that mustbefollowed to ensure that the system operates within the law; and ethical requirements. Ethical requirements are requirements placed on a system to ensure that it will be accept-able to its users and the general public.
Figure 6.4 shows examples of product, organisaLtional and external requirements taken from the library system LIBSYS whose user requirements were discussed in Section 6.1.1. The product requirement restricts the freedom of the LIBSYS designers in the implementation of the system user interface.Itsays nothing about the fum:tionality of LIBSYS and clearly identifies a system constraint rather than a function. This requirement has been included because it simplifies the problem of enswing the system works with different browsers.
The organisational requirement specifies that the system must be developed accord-ing to a company standard process defined as XYZCo-SP-STAN-95. The external requirement is derived from the need for the system to conform to privacy legisla-tion. It :>pecifies that library staff should not be allowed access to data, such as the addresses of system users, which they do not need to do their job.
Software requirements
Asystempal
The system shouldbeeasy to usebyexperienced controllers and should be organised in such a way that user errors are minimised.
A verifiable non-functionalrequirement
Experienced controllers shall be abletouse all the system functionsaftera totalof twohours' training. After this training, the average numberoferrors madeby experienced users shall not exceedtwoper day.
A common problem with non-functional requirements is that they can be diffi-cult to verify. Users or customers often state these requirements as general goals such as ease of use, the ability of the system to recover from failure or rapid user response. These vague goals cause problems for system developers as they leave scope for interpretation and subsequent dispute once the system is delivered. As an illustration of this problem, consider Figure 6.5. This shows a system goal relating to the usability of a traffic control system and is typical of how a user might express usability requirements. I have rewritten it to show how the goal can be expressed as a 'testable' non-functional requirement. While it is impossible to objectively ver-ify the system goal, you can design system tests to count the errors made by con-trollers using a system simulator.
Whenever possible, you should write non-functional requirements quantitatively so that they can be objectively tested. Figure 6.6 shows a number of possible met-rics that you can use to specify non-functional system properties. You can measure these characteristics when the system is being tested to check whether or not the system has met its non-functional requirements.
Inpractice, however, customers for a system may find it practically impossible to translate their goals into quantitative requirements. For some goals, such as main-tainability, there are no metrics that can be used. In other cases, even when quan-titative specification is possible, customers may notbeable to relate their needs to these specifications. They don't understand what some number defining the required reliability (say) means in terms of their everyday experience with com-puter systems. Furthermore, the cost of objectively verifying quantitative non-functional requirements may be very high, and the customers paying for the system may not think these costs are justified.
Therefore, requirements documents often include statements of goals mixed with requirements. These goals may be useful to developers because they give indica-tions of customer priorities. However, you should always tell customers that they are open to misinterpretation and cannot be objectively verified.
Non-functional requirements often conflict and interact with other functional or non-functional requirements. For example, it may be a requirement that the maximum memory used by a system should be no more than 4 Mbytes. Memory constraints are common for embedded systems where space or weight is limited and the number of ROM chips storing the system software must be minimised. Another requirement might be that the system should be written using Ada, a programming
6.1 Func:tional and non·,functional requirements 125
TIme tCI restart after failure Percentageofevents causing failure Probability of data corruption on failure Percentageoftarget-dependent statements Numberoftarget systems
language for critical, real-time software developmt:nt. However, it may notbe pos-sible to compile an Ada program with the required functionality into lessthat4 Mbytes.
There therefore has to be atrade-off between these l1::quirements: an alternative devel-opment language or increased memory added to the system.
Itis helpful if you can differentiate functional :and non-functional requirements in the w..quirements document. Inpractice, this is difficult to do.Ifthe non-func-tional requirements are stated separately from the funcnon-func-tional requirements, it is some-times dlfficult to see the relationships between them. Ifthey are stated with the functional requirements, you may find it difficult to separate functional and non-functional considerations and to identify requirements that relate to the system as a whole, However, you should explicitly highlight requirements that are clearly related to emergent system properties, such as performanc;e or reliability. You can do this by putting them in a separate sectlon of the requirements docUment or by distin-guishing them, in some way, from other system n:quirements.
Non- functional requirements such as safety and security requirements are par-ticularly important for critical systems. I therefore discuss dependability require-ments in more detail in Chapter 9, which covers critical systems specification.
6.1.3 Domain requirements '
-Domain requirements are derived from the application domain of the system rather than from the specific needs of system users. They Ulsually include specialised domain terminology or reference to domain concepts. They may be new functional
require-Software requirements
The deceleration of the train shallbe computed as:
Otroln- O_+ O _
where Oplientis 9.81 ms2• compensated gradient/alpha and where the valuesof 9.81 ms2/alpha are known for different types of train.