Non-Functional Requirements in Software Engineering: Classification and Testability, Schemes and Mind Maps of Software Engineering

Download Non-Functional Requirements in Software Engineering: Classification and Testability and more Schemes and Mind Maps Software Engineering in PDF only on Docsity!

Introduction Classification of NFRs  Some NFRs  Deriving NFRs  Stakeholder Concerns  Goal-based derivation  Testable NFRs

Non-functional Requirements

Contents

Non-functional requirements (NFR) define the overall qualities of the resulting system that enhance its functionality;  They are global constraints on a software system , on the development process or external constrains outside the enterprise.  Importance  All functional requirements may be satisfied, but if nonfunctional requirements are overlooked, the system will fail.  Non-functional properties may be the difference between an accepted, well-liked product & unused one.  Though all NFRs are important their relative importance differs from stakeholder to stakeholder and from system to system.  Reliability, Performance, Security, Usability, Safety NFRs are more important than others for critical systems  Non-functional requirements like Usability, efficiency, accuracy , … are more important for end users than other stakeholders

Introduction

NFR-Definitions

Classification of NFRS

 Different ways classifying NFRs have been proposed  NFRs may be classified in terms of qualities that a software must exhibit ( Boehm )

Classification of NFRs…

 McCall factor model is derived from user concerns

Classification of NFRs…

 Evans and Marciniak ( 1987 ) – defined 12 factors  Correctness, Reliability, Integrity, Usability, Efficiency, Maintainability, Flexibility, Portability, Reusability, Expandability, Interoperability, Verifiability Deutsch & Willis( 1988 ) factor model consists of 15 factors that are classified into four categories  Functional- Reliability, Integrity, Usability, Survivability  Performance - Correctness, Efficiency, Interoperability, Safety  Change - Maintainability, Flexibility, Portability, Reusability, Expandability  Management - Verifiability, Manageability

Classification of NFRs…

Classification of NFRs…

A more general classification distinguishes between product, process and external requirements is recently proposed by Sommerville [2007]  Product requirements  Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.  Organisational/process requirements  Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.  External requirements  Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Examples of nonfunctional requirements in the Mental Health Care- Patient Management System (MHC-PMS)  Product requirement  The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830 – 17. 30 ). Downtime within normal working hours shall not exceed 5 seconds in any one day.  Organizational requirement Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.  External requirement The system shall implement patient privacy provisions as set out in HStan- 03 - 2006 - priv.

 Specify the desired characteristics that a system or subsystem must possess.  Most NFRs are concerned with specifying constraints on the behaviour of the executing system.  Some product requirements can be formulated precisely, and thus easily quantified: e.g. Performance, Capacity  Others are more difficult to quantify and, consequently, are often stated informally (use fit-criterion): e.g. Usability  Examples  The System service X shall have an availability of 999 / 1000 or 99 %.  SystemY shall process a minimum of 8 transactions per second.  The executable code of System Z shall be limited to 512 Kbytes.  The system shall be user friendly.  New users shall be able to view their grades within 5 minutes of their first attempt at using the system.

Product requirements

14

 Process requirements are constraints placed upon the development process of the system  Process requirements include:  Requirements on development standards and methods which must be followed  CASE tools which should be used  The management reports which must be provided  Examples  The development process to be used must be explicitly defined and must be conformant with ISO 9000 standards  The system must be developed using the XYZ suite of CASE tools  Management reports setting out the effort expended on each identified system component must be produced every two weeks  A disaster recovery plan for the system development must be specified

Process requirements

 These types of requirements may be placed on both the product and the process and they are derived from the environment in which the system is developed.  External requirements are based on:  application domain information  organisational considerations  the need for the system to work with other systems  health and safety or data protection regulations  or even basic natural laws such as the laws of physics  Examples  Medical data system - The organisation’s data protection officer must certify that all data is maintained according to data protection legislation before the system is put into operation.

External requirements

 Efficiency  Definition - the extent to which the software system handles capacity, throughput, and response time.  Example - The system must download the new rate parameters within ten minutes of a non-scheduled rate change.  Integrity  Definition - the degree to which the data maintained by the software system is accurate, authentic, and without corruption.  Example - The integrity of the system data area must be checked by the internal audit system twice per second; if inconsistencies in the data are detected, the system operation should be disabled.

 Reliability  Definition - the extent to which the software system consistently performs the specified functions without failure.  Example - The software shall have no more than X bugs per

thousand lines of code.

 Survivability  Definition - the extent to which the software system continues to function and recovers in the presence of a system failure.  Example - All policy statement parameters shall have default values specified, which the Report Writer system shall use if a parameter’s input data is missing or invalid.