Requirements Engineering Processes and Techniques Authors: Gerald Kotonya and Ian Sommerville

1
Requirements Engineering Processes and Techniques
Authors Gerald Kotonya and Ian Sommerville

• Chapter Eight -
• Non-Functional RequirementsSYST510

2
Non-Functional Requirements

• Definition
• requirements which are not specifically concerned
  with the functionality of a system
• Place restrictions on the product being developed
• Specify external constraints that the product
  must meet

3
Non-Functional Requirements

• IEEE Std-830-1993, Figure 8.1 page, 189
• performance
• interface
• operational
• resource
• verification
• acceptance
• documentation

4
Non-Functional Requirements

• IEEE Std-830-1993, Figure 8.1 page, 189
  continued
• security
• portability
• quality
• reliability
• maintainability
• safety

5
(No Transcript)
6
Non-Functional Requirements

• Classification by Sommerville
• Figure 8.2, page 190
• product requirements
• process requirements
• external requirements

7
Non-Functional Product Requirements

• Specify the desired characteristics a system must
  process
• May specify constraints
• Reliability - service X shall have an
  availability of 99
• Performance - system Y shall process a minimum
  of 8 transactions per second
• Space - system Z executable code shall be
  limited to 512 Kbytes

8
Non-Functional Product Requirements

• May relate to source code
• Portability - system X shall be developed for PC
  platform
• Security - system Y shall encrypt all external
  communications using the RSA algorithm

9
Non-Functional Process Requirements

• Constraints placed upon the development process
  of the system
• the development process must conform to ISO9000
  standards
• the system must be developed using the XYZ suite
  of CASE tools

10
Non-Functional External Requirements

• Requirements which may be placed on both the
  product and process and which are derived from
  the environment
• based on application domain information
• organizational considerations
• need for the system to work with other systems
• health and safety regulations
• natural laws (e.g. laws of physics)

11
Deriving Non-Functional Requirements

• Problems with specifying non-functional
  requirements
• certain constraints are related to the design
  solution and may not be known during requirements
  (e.g. response time to failure)
• certain constraints are highly subjective and can
  only be determined via complex empirical
  evaluation (e.g. human engineering)

12
Deriving Non-Functional Requirements

• Problems with specifying non-functional
  requirements continued
• they tend to be related to functional
  requirements which may make it difficult to
  separate functional and non-functional
  considerations
• they tend to contradict each other
• no rules for determining when they are optimally
  met

13
Deriving Non-Functional Requirements

• Vaguely defined user concerns may be related to
  non-functional requirements
• Figure 8.5, page 196
• User concerns may be expressing critical
  whole-system requirements which need to be
  decomposed
• Figure 8.6, page 197

14
Measuring Non-Functional Requirements

• Measurable metrics for non-functional
  requirements
• Figure 8.8, page 199

15
Requirements for Critical Systems

• Critical systems are those whose failure causes
  significant damage
• business critical - significant economic damage
  to business (e.g. airline reservation system)
• mission critical - mission cannot be accomplished
  (e.g. control system on spacecraft)
• safety critical - endangers human life (e.g.
  control system on radiation therapy machine)

16
Non-Functional Constraints Relevant to Critical
Systems

• Reliability
• constraints on run-time behavior of the system
  (e.g. availability, failure rate)
• Performance
• constraints on speed of operation of the system
  (e.g. response, throughput, timing)
• Security
• constraints to ensure unauthorized access to the
  system is not permitted (e.g. encryption)

17
Non-Functional Constraints Relevant to Critical
Systems

• Usability
• constraints on user interface (e.g. time to learn
  system)
• Figure 8.9, page 203
• Safety
• constraints to ensure safe operation (e.g.
  operation not allowed without operator guard in
  place)

18
Requirements Engineering for Safety-Related
Systems

• System safety analysis
• ensure and certify that a system does not pose an
  unacceptable danger to its users or to the
  environment
• Process, Figure 8.11, page 208
• identify safety considerations
• identify hazards
• analyze hazards (Figure 8.12, page 209)
• assess risk and derive safety requirements

19
Requirements Engineering for Safety-Related
Systems

• Requirements derived from hazard analysis
• avoidance - hazard can not occur
• prevention - if hazard occurs, an accident does
  not result
• protection - if accident occurs, scale of damage
  is limited

20
Exercises

• Kotonya, page 211
• assigned in class