What are non-functional requirements?

Non-functional requirements define system characteristics such as security, performance or reliability. They are constraints related to the designed system.

Functional requirements answer the question WHAT the system should do, while non-functional requirements answer HOW GOOD.

You can also check the definition of non-functional requirements in the dictionaries BABOK and SAFe (Scaled Agile Framework).

What is FURPS+?

One method of categorizing functional and non-functional requirements is FURPS+.

FURPS+ was developed by Robert Grady at Hewlett-Packard.

FURPS+ distinguishes the following categories of requirements:

• Functionality
• Usability
• Reliability
• Performance
• Supportability
• ‘+’ – other requirements and constraints

FURPS+ is designed to help you categorize your requirements and verify the completeness of your requirements.

In the following, I will show how I use FURPS+ to categorize non-functional requirements.

(F)unctionality

Functionality defines functional requirements. It also takes into account requirements that are not represented by specific use cases and apply to the entire system, for example, requirements related to security, logging or auditing.

The main subcategories are:

• Audit
• Licensing
• Printing
• Reporting
• Security
  • Confidentiality (e.g. only authorized users have access to the data)
  • Integrity (e.g. data is consistent and correct)
  • Availability (e.g. data is available all the time)
• Debugging
• Scheduling

Examples of non-functional requirements from the Functionality category are:

• The authentication is done on the server side
• The secure HTTPS protocol is used in the integration between the systems
• Sensitive data is encrypted
• System and business data are logged
• A list of roles with permissions is defined in the system
• A user's session is invalidated when the user logs out
• Session timeout is 10 minutes if the logged in user is inactive

(U)sability

Usability defines the requirements related to ensuring that the product is understandable, easy to learn and use.

The main subcategories are:

• Accessibility (e.g. the system supports IE, Chrome browsers)
• Consistency (e.g. all error messages look the same throughout the system)
• Navigation rules (e.g. it concerns the support of using the keyboard, mouse or keyboard shortcuts)
• Training time (e.g. the training of new users will take 2 days or 8 hours)
• Usability standards (e.g. the usability solution will be in line with company policy/standards)

Examples of non-functional requirements from the Usability category are:

• The system must be accessible from the Chrome browser
• A password policy will be introduced with guidelines on length and complexity
• Remote access to the system will be possible in accordance with the defined policy
• User training on the use of the system will be carried out

(R)eliability

Reliability defines the ability of a product to perform a function (action) under specified conditions for a specified period of time or a specified number of operations.

The main subcategories are:

• Availability
• Accuracy
• Recoverability

Examples of non-functional requirements from the Reliability category are:

• The database backup must be performed daily
• The database backup will be kept for 1 year
• The system recovery time after a failure cannot be longer than 4 hours
• The system should be available for 99.9% of the time

(P)erformance

Performance is the degree to which a system or component performs its designated functions within specified processing time and throughput constraints.

The main subcategories are:

• Capacity (e.g. the system must store 5 TB of data)
• Throughput (e.g. the system must support 100k transactions per minute or the system must support the parallel operation of 200 users)
• Response time (e.g. the system must respond in a maximum of 2 seconds, the maximum login time cannot be longer than 1 second)
• Scalability (e.g. that the system must automatically scale)

Examples of non-functional requirements from the Performance category are:

• The system response time cannot be longer than 2 seconds
• The system must support up to 100k parallel transactions
• The system must support up to 1000 concurrent users

(S)upportability

Supportability defines the ability of the system to be operated during the entire life cycle of the system.

The main subcategories are:

• Adaptability
• Auditability
• Configurability (e.g. the system is compatible with previous versions)
• Configurability
• Installability
• Testability
• Maintainability
• Compatibility
• Localization (e.g. the system supports the Polish and English languages)

Examples of non-functional requirements from the Supportability category are:

• Separated test environments will be prepared to carry out functional, integration and acceptance tests
• The system will be monitorable via the monitoring tool
• Special dashboards will be prepared in the monitoring tool

+

"+" identifies other requirements and constraints that define the design, implementation, interfaces, or physical elements of the solution.

The main subcategories are:

• Design & implementation (e.g. regarding the need to use a PostgreSQL relational database)
• Interface (e.g. the SOAP standard will be used for integration between the systems)
• Physical elements (e.g. may relate to the selection of specific servers)
• Legal information (e.g. regarding copyright)

Examples of non-functional requirements from the "+" category are:

• An high level architecture document will be prepared
• An low level design document will be prepared
• The system will use PostgreSQL relational databases
• A test and deployment plan will be prepared

If you would like to share your comment with me, write to me at marcin@marcinziemek.com

If you want to develop your knowledge of IT architecture design, check out my book available at: https://architecture.marcinziemek.com

If you want to develop your knowledge of IT systems integration design, check out my book available at: https://integration.marcinziemek.com