Non-Functional Requirements

Functional and Non-Functional Requirements are equally important for delivering the correct and complete set of functionalities. So, let’s discuss what is a Non-Functional Requirement (NFR) and why are these important.

What are Non-Functional Requirements?

Typically, users also have expectations regarding how well the software system should perform in terms of its availability, ease of use, the speed with which its functionalities execute, how often is it likely to fail, how secured is it from unauthorized access and how successfully it handles the unexpected situations if they occur.

Such characteristics or qualities of a system are termed as Non-functional Requirements Quality Attributes or Quality of Service Requirements.

Check out this video: Non-Functional Requirements

Why are Non-Functional Requirements Important?

The importance of Non-Functional Requirements stems from the fact that they can make or break the success of a software system or a product.

Users will not hesitate to outrightly reject a system even if it meets all expected functional requirements but fail to deliver the required quality outcomes.

Non-Functional Requirements serve as the source of many functional requirements which are of immense significance and need to be specified in the right level of detail in the requirements documents.

Moreover, they are essential inputs to some key architectural decisions and help ensure that some key design aspects are taken into account from the very outset rather than during the later stages of the process when the cost and risk of change get higher.

Different software systems may be expected to cater to different quality attributes based on their nature, type, and size. Some common Non-Functional Requirements categories with their descriptions are specified as under:

Availability:

Availability is the degree to which the solution is operable and accessible when required. It is a measure of time during which the system is fully operational i.e. available for use and sometimes included as a service level agreement considering its criticality to the business.

Availability aspects to be discussed during elicitation are in reference to (but not limited to) time periods for which availability is imperative to meet business objectives, impacts of the system’s unavailability, scheduled maintenance time periods, and notifications during the system unavailability.

Example – The system shall be at least 99% available on weekdays between 9:00 AM to 6:30 PM Pacific Time.



Interoperability/Compatibility:

Interoperability is the degree to which the solution is compatible with other components. It is a measure of how effectively the system interoperates with other software systems and how easily it integrates with external hardware devices.

Interoperability aspects to be discussed during elicitation are in reference to (but not limited to) software systems to be interfaced with along with data/ messages to be exchanged & any standard data formats, hardware components to be integrated with, and any standard communication protocols to be followed.

Example – Order Management system will push the order file into a secured file transfer protocol server from where it will be loaded into the system through a daily job.



Performance:

Performance is the degree to which a solution or its component performs its functions with minimal resource consumption. It is an extremely important quality attribute because it has major design implications and also affects hardware device selection.

Performance aspects to be discussed during elicitation are in reference to (but not limited to) response time (e.g. – no. of seconds to load a web page), throughput (e.g. – no. of transactions processed per second), dynamic capacity (e.g. – maximum number of concurrent users), update/refresh timings (e.g. data refresh in real-time systems).

Example – Web page displaying the usage data of a customer should be loaded in 5 seconds or less over a 30 Mb/sec or higher internet connection.



Reliability:

Reliability is the ability of a solution or its component to perform its required functions without failure under predefined conditions for a specified time period.

Reliability can possibly be specified in terms of average time system runs before failure occurs, percentage of operations completed successfully within a time period, maximum acceptable failure probability, or no. of failures within a time period.

Reliability aspects to be discussed during elicitation are in reference to (but not limited to) evaluation of the system to be considered as reliable, classification of reliability defining failures vs. regular failures, the impact of failure on business operations.

Example – No more than 1 per 1 million order placements should result in a failure if all functional conditions are met.



Security:

Security refers to essential aspects that assure solution and its components will be protected against unauthorized access or malware attacks. Important considerations related to security aspects of a system are user authentication, user authorization or access privileges, data theft, malware attacks, data encryption, maintaining audit trails.

Security aspects to be discussed during elicitation are in reference to (but not limited to) user authentication method to be used, user authorization to sensitive data by defining roles and permissions, firewall and other network security aspects, specific sensitive data to be exchanged and stored in encrypted form, operations for which audit history to be created/maintained.

Example – Only users with administrator access shall be able to create new customer accounts and assign data access privileges to them.



Usability:

Usability is about the ease with which a user can learn to start using the solution and the ease with which he/she can use the system. In addition to ease of learning and ease of use, usability also includes areas such as ease of recall, error avoidance & handling, accessibility among others.

Usability aspects to be discussed during elicitation are in reference to (but not limited to) average time needed to perform a specific task, no. of errors made in completing a task, no. of attempts made before successfully completing a task, no. of tasks completed within a specific time period, no. of human-system touchpoints needs to carry out a task.

For example – 99% of metadata entry users who have been trained for 1 hour to use the metadata management system should be able to fill the product form successfully in a single attempt.



Maintainability/Modifiability:

Maintainability refers to the ease with which a solution or its component can be fixed, enhanced to meet business needs or increase efficiency, or adapted to a changing environment.

It signifies how easily the software design and code can be understood and modified/extended. Maintainability is specifically important for systems that need to be frequently amended or enhanced. Maintainability aspects to be discussed during elicitation are in reference to (but not limited to a) percentage of fixes made correctly the first time, percentage of fixes deployment correctly the first time, the average time required to fix a problem correctly.

Example – System should be able to extend to add new product categories with some or all current functionalities extensible to the newly added product category.



Portability:

Portability is the ease with which a solution or its component can be transferred from one operating environment to another. Its importance has increased over the years considering applications are required to run across multiple environments such as Windows, Mac & Linux, and also mobile operating systems such as Android and iOS.

Portability aspects to be discussed during elicitation are in reference to (but not limited to) different platforms on which the system needs to run, system portions, and/or data elements that need to be specifically designed for higher portability.

Example – User should be able to access saved bookmarks across all compatible browsers i.e. Internet Explorer, Chrome, Safari, and Firefox.



Scalability:

Scalability refers to the degree to which a solution is able to evolve to handle increased amounts of work. The increased amount of work could be in terms of the user base, transactions, data, network traffic, or other factors.

The system should be capable of being scaled up which could mean extending hardware by means of faster processors, additional servers, additional disk space, enhanced network capacity, or using software-specific approaches like code and performance optimization, data compression, and other such techniques.

Scalability aspects to be discussed during elicitation are in reference to (but not limited to) estimation of total users that the system is likely to have over the next few months/years, estimation of size and rate of increase of data volume over next few months/years, an approximate estimation of hardware capacity (servers, data centers, etc.) needed over the next few months/years.

For example – The system should be able to handle an additional load of a maximum of 5K users every month for the next 6 months without any noticeable performance impacts.



Reusability:

Reusability refers to the ability of a software or software component to be used in other applications. It needs to be specified as to which parts/components of the system should be created in a manner that allows them to be reused across other applications.

Reusability aspects to be discussed during elicitation are in reference to (but not limited to) functionality or artifacts from other applications to be reused across applications being built; functionality or artifacts in the application being built to be reused across other present or future applications.

Example – At least 70 percent of key performance indicator reports being sent to customers through the current business support system shall be reusable in the future business support system.

Additionally, there are some other types of requirements that are essentially constraints but sometimes specified as non-functional requirements –


• Certification – Constraints on the solution that are necessary to meet certain agreed, stipulated, or generally accepted standards and norms.
• Compliance - Regulatory, financial, or legal constraints based on the context or jurisdiction that need to be mandatorily met by the solution.
• Service Level Agreements – Constraints on the solution that are formally agreed to by both the provider and the user of the solution.

Become CBAP expert and take your career to the next level and ensure continued success in the field of business analysis

Considering the significance of non-functional requirements, it is imperative that these requirements are specified correctly, completely, and without any ambiguity. These quality attributes need to be quantified in order to be measurable and testable for ensuring that the system addresses them without fail. The solution can meet the desired business goals or solve a business problem only if it meets the necessary functions as well as non-functional requirements.

More on BABOK and Business Analysis Techniques

You can read about Data Dictionary and Core concepts model.

You can also take a test comprising CBAP exam questions based on the latest pattern.

About Techcanvass

Techcanvass is an Information Technology certifications training Organization for professionals. It offers internationally recognized certifications in the fields of Project Management and Business Analysis. It is a premier Authorized training partner of Project Management Institute (PMI), USA and a premier Endorsed Education Provider (EEP) of International Institute of Business Analysis (IIBA), Canada.

About Author