Non Functional Requirements NFRs Muzaffar Iqbal Farooqi Software

Non Functional Requirements (NFRs) Muzaffar Iqbal Farooqi

Software Qualities • Think of an everyday object, e. g. a chair – How would you measure it’s “quality”? • construction quality? (e. g. material, strength of the joints, …) • aesthetic value? (e. g. elegance, …) • fit for purpose? (e. g. comfortable, …) • All quality measures are relative, there is no absolute scale • We can sometimes say A is better than B, but it is usually hard to say how much better! Requirement Engineering: Muzaffar Iqbal Farooqi

Software Quality • Software quality is all about fitness to purpose – does it do what is needed? – does it do it in the way that its users need it to? – does it do it reliably enough? fast enough? safely enough? securely enough? – will it be affordable? will it be ready when its users need it? – can it be changed as the needs change? Requirement Engineering: Muzaffar Iqbal Farooqi

Software Quality. . . • Quality is not a measure of software in isolation • cannot measure this until you place the software into its environment • and the quality will be different in different environments • during design, we need to predict how well the software will fit its purpose • during requirements analysis, we need to understand how fitness-for-purpose will be measured Requirement Engineering: Muzaffar Iqbal Farooqi

Non Functional Requirements • Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system should behave. • Functional requirements are usually in the form of "system shall do <requirement>", an individual action of part of the system. • In contrast, non-functional requirements are in the form of "system shall be <requirement>", an overall property of the system as a whole or of a particular aspect and not a specific function. • The system's overall properties commonly mark the difference between whether the development project has succeeded or failed. Requirement Engineering: Muzaffar Iqbal Farooqi

Non Functional Requirements. . . • Non-functional requirements are often called qualities of a system. • Other terms for non-functional requirements are – – "constraints", "quality attributes", "quality goals", "quality of service requirements" and • Project management issues (costs, time, schedule) are also considered as non-functional requirements. Requirement Engineering: Muzaffar Iqbal Farooqi

An Example • A system may be required to display the number of records in a database. • This is a functional requirement. • How fast the records are displayed is a non-functional requirement. • Sufficient network bandwidth may be a non-functional requirement of a system. Requirement Engineering: Muzaffar Iqbal Farooqi

Functional vs. Non-functional requirements • Sometimes it is hard to make clear distinction between FR & NFR. • Whether or not a requirement is expressed as a functional or a non-functional requirement may depend: – on the level of detail to be included in the requirements document – the comprehension of application domain and the desired system – experience of developers Requirement Engineering: Muzaffar Iqbal Farooqi

Functional vs. Non-functional requirements • Some properties of a system may be expressed either as a functional or non-functional property. • Example. The system shall ensure that data is protected from unauthorised access. • Conventionally a non-functional requirement (security) because it does not specify specific system functionality • Expressed as functional requirement: – The system shall include a user authorisation procedure where users – must identify themselves using a login name and password. Only – users who are authorised in this way may access the system data. • Non-functional requirements may result in new functional requirements statements Requirement Engineering: Muzaffar Iqbal Farooqi

Common NFRs • • • Accessibility Availability Performance Portability Quality Response time Reusability Safety Security Usability Maintainability Requirement Engineering: Muzaffar Iqbal Farooqi

Accessibility • Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible. • Accessibility can be viewed as the "ability to access" and benefit from some system or entity. Requirement Engineering: Muzaffar Iqbal Farooqi

Availablity • Availabilty means "is the system available for service when requested by end-users" • For example, a unit of a system that is required to be used 7 days a week (24 hours a day) should have an availability of 24/7. • Availability of a system is typically measured as a factor of its reliability - as reliability increases, so does availability. • How long the system can be down for maintenance can affect the availability of the system. Requirement Engineering: Muzaffar Iqbal Farooqi

EXAMPLE • The System service X should have an availability of 999/1000 or 99%. This is an availability requirement which means that out of every 1000 requests for this service, 999 must be satisfied. Requirement Engineering: Muzaffar Iqbal Farooqi

Performance • Computer performance is characterized by the amount of useful work accomplished by a computer system or computer network compared to the time and resources used. • Depending on the context, good computer performance may involve one or more of the following: – Short response time for a given piece of work – High throughput (rate of processing work) – Low utilization of computing resource(s) – Fast (or highly compact) data compression and decompression – High bandwidth / short data transmission time Requirement Engineering: Muzaffar Iqbal Farooqi

Performance. . . • Performance requirements are mainly concerned with the speed of operation of a system. • Typical performance requirements are. . . – Response requirements (how quickly the system reacts to a user input) – Throughput requirements (how much the system can accomplish within a specified amount of time) – Availability requirements (is the system available for service when requested by end-users) • EXAMPLE: System Y should process a minimum of 8 transactions per second. This is a performance requirement. Requirement Engineering: Muzaffar Iqbal Farooqi

Usability • Usability is the ease of use and learnability of a human-made developed object/system. • Usability is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of system. • Usability requirements include: – Well-structured user manuals – Informative error messages – Help facilities – Well-formed graphical user interfaces • Usability includes considerations such as: – Who are the users, what do they know, and what can they learn? – What do users want or need to do? – What is the general background of the users? – What is the context in which the user is working? – What has to be left to the machine, What to the user? Requirement Engineering: Muzaffar Iqbal Farooqi

Usability. . . • Answers to these questions can be obtained by the following considerations. . . – Can users easily accomplish their intended tasks? For example, can users accomplish intended tasks at their intended speed? – How much training do users need? – What documentation or other supporting materials are available to help the user? – Can users find the solutions they seek in these materials? – What and how many errors do users make when interacting with the product? – Can the user recover from errors? – What do users have to do to recover from errors? – Does the product help users recover from errors; for example, does the software present informative, non-threatening error messages? Requirement Engineering: Muzaffar Iqbal Farooqi

Usability. . . • In addition to these considerations, specific usability quality requirements can be documented in terms of the following factors: – What a general screen should look like (may include templates of screens) – Special requirements regarding the ’look and feel’ of the system – How users expect to navigate between screens (may depend on the current organizational standards in order to reduce the learning curve) – Level of help required (at function level, screen level, field level etc. ) – How exceptions, errors and alerts should be shown to the user; – What kind of help the user expects, when exceptions occur during user interaction – Consistency of the user interface (to be provided both within the system and across different subsystems) Requirement Engineering: Muzaffar Iqbal Farooqi

Usability Metrics • Understandability: Capability of the software product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use. • Learnability: Capability of the software product to enable the user to learn its application • Operability: Capability of the software product to enable the user to operate and control it. • Likeability: Capability of the software product to be liked by the user. Requirement Engineering: Muzaffar Iqbal Farooqi

Portability • The capability of software to be transferred from one environment to another. • The environment may include: – organizational, – hardware or – software environment. • EXAMPLE: The system should run on Windows and Unix platforms. This is a portability requirement which affects the way in which the system may be designed. Requirement Engineering: Muzaffar Iqbal Farooqi

Robustness • Robustness is the ability to handle error while running the system. • We have to provide quality parameters for the Robustness requirements in terms of the following factors: – Define how the errors must be handled when failures occur – At a lower level of abstraction, define the kind of errors (including boundary conditions) that are implicitly taken care of (e. g. date validations, numeric validations, currency validations, etc. ) Requirement Engineering: Muzaffar Iqbal Farooqi

Extensibility • Extensibility is the ability of the solution to handle the growth of functionality. • Requirements for extensibility can be captured in terms of the following factors: – Identification of the impact of increase in the number of end users – growth of an organization – increase in the functionality of the application – Identification of the impact of an increase in data – future enhancements to different areas in the system should not result in major architecture/design changes Requirement Engineering: Muzaffar Iqbal Farooqi

Maintainability • Maintainability is the ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. • Maintainability relates to ease with which system can be repaired and components can be replaced • In some cases, maintainability involves a process of continuous improvement Requirement Engineering: Muzaffar Iqbal Farooqi

Maintainability. . . • In requirement engineering, maintainability is the ease with which a product can be maintained in order to. . . – correct defects or their cause, – repair or replace faulty components without having to replace still-working parts, – prevent unexpected breakdowns, – maximize a product's useful life, – maximize efficiency, reliability, and safety, – meet new requirements, – make future maintenance easier, or – cope with a changed environment. Requirement Engineering: Muzaffar Iqbal Farooqi

Security • • Security requirements deal with the ability of the system to: – prevent intrusion, – allow access to the right users, and – protect data integrity (while stored and during transmission). Security requirements can be captured in terms of the following factors: – Authentication: requirements for users or other systems to identify their credentials in order to access services for the system – Authorization: roles different users play and the access levels that the system provides for each of these roles – Analysis of existing mechanisms for security policies – Data exchange: kind of protection needed for data during transmission; critical data that needs to be protected when it is exchanged across the network – Data Storage: kind of protection needed for data that is stored; critical data that needs to be stored in encrypted form Requirement Engineering: Muzaffar Iqbal Farooqi

Non-Functional Requirement ISO 9126 • ISO 9126 - non-functional requirements linked to “quality in use”. • Quality in use - users experience when using the system. Requirement Engineering: Muzaffar Iqbal Farooqi

ISO 9126 Quality in use Requirement Engineering: Muzaffar Iqbal Farooqi

Classification of Non-functional requirements (Sommerville) Requirement Engineering: Muzaffar Iqbal Farooqi