Non-Functional Requirements 101

Introduction to Non-Functional Requirements

Non-Functional Requirements represents the system and quality attributes that specifies the criteria for assessing how a product should perform.  By specifying the criteria, it identifies the constraints of the product which, in software development, is useful in guiding systems architects to strike a balance between design options and performance optimization. There is an ever-increasing awareness of Non-Functional Requirements in the world of Information Systems, as failure to fully consider Non-Functional Requirements can be considered extremely costly and time consuming, and is cited to be one of the 10 biggest risks in requirements engineering (IEEE, volume 18, 2001). 

Although many argue that it is often difficult to articulate or define Non-Functional Requirements quantitatively, these can be made more manageable by categorization, followed by defining a threshold or criteria for each.

Categories of Non-Functional Requirements with Examples

Non-Functional Requirements are generally expressed as declarative statements, or in more complex requirements, as matrices. Not all solutions will need to have all categorisations of Non-Functional Requirements. 

According to the Business Analysis Book of Knowledge (BaBoK), Non-Functional Requirements can be categorised in the following categories:

Availability

Availability refers to the extent of which the product is accessible when required for use, often expressed in terms of percent of time the solution is available.

Example: The Portal must be accessible and operational for all users for 98% of working hours throughout the calendar year.

Compatibility

Compatibility relates to whether or not a product can co-exist with another within the same environment.

Example: The cloud-based Customer Relationship Software must co-exist with the organization’s IT chosen firewall and security protection software in the production environment

Functionality

Functionality refers to the degree which the product meets users’ needs that includes aspects of suitability, accuracy and interoperability.

Example: The Portal must save the data entered on to the current user screen and navigate the user on to the next page and auto-populate the information inserted from the previous screen.

Maintainability

Maintainability refers to the ease and time required for a product or its component to be fixed or modified. This can be expressed as a probability for the fix/repair during a period of time.

Example: Each module in the Enterprise Resource Planning system must have a 70% maintainability for 48 hours.  This means that there is a 70% chance the component can be fixed/ modified in 48 hours.

Performance Efficiency

Performance Efficiency refers to the degree the product responds to certain users’ actions within minimum consumption of resources, which can be defined based on context or period such as the context or period.

Example: During the hours of 09:00-17:00, transactions must be processed under 45 seconds after submission.

Portability

Portability refers to the ability and ease with each a product or one of its components can be transferred to another environment elsewhere. When eliciting portability requirements, aspects that needs to be consider include data, programme, end user and developer documentation.

Example: Will the systems’ code run the same way on all platforms (e.g. MAC and a PC)?

Reliability

How often does the product experience critical failures?  This is a quality attribute that specifies how likely the product or its components are able to operate without failure for a predefined period of time.

Example: The website probability of failure on demand must be 0.001 (10 out of 10000 plays) when a user requests to play the embedded video.

Security

Security refers to the aspects of the product that protect its contents or components from accidental or malicious access, use modification, disclosure or destruction.

Example: The payment gateway of the retail website must be PCI DSS compliant.

Usability

Usability refers to how easily a user can learn to use the product.

Example:  90% of Finance users must be able to learn the Finance module of the Enterprise Planning System after no more 24 hours of training.

Certification

Industry-specific standards or certifications that the solution needs to comply with.

Example: The IT Service Management system must be ISO/IEC 20000-1 and ISO/IEC 20000-2 certified. 

Compliance

Refers to financial, regulatory or legal constraints which can vary depending on the context or jurisdiction.

Example: The Human Resources system must comply to the Data Protection Regulation.

Localisation

This attribute defines how well a product falls in line with the context of the market-to-be.  Refers to local languages, laws, currencies, cultures, spellings requiring attention to the context.

Example: The payroll system must be able to produce payslips in Swedish Krona.

Service Level Agreements

Service Level Agreements refers to the constraints of the organisation being served by the product that are formally agreed between the product provider and user. A breach in Service Level Agreements may result in penalties being incurred by the provider.

Example: Should the system become unavailable, the service provider will act as the primary support provider and respond to Priority 1 requests within 1 hour.

Extensibility

Refers a characteristic where the architecture, design and implementation actively caters to future business needs, i.e. whether a solution can incorporate new functionalities.

Example: The Customer Relationship Management system shall be able to interface with the Optical Character Recognition system should the organisation decide to proceed to implement this.

Differences between Functional and Non-Functional Requirements?

While non-functional requirements specify the “how” (i.e. how the system performs its tasks), functional requirements define what the system must or must not do.  Functional requirements are features built to serve the product’s users, and are often pieces of functionality that solve particular problems for users.

Example

Consider an example of a restaurant reservation system, where end users can search and make a table reservation.

Functional Requirement: A user can search for a restaurant. If a user searches for a restaurant with their desired date and time specified upon the search, the user will have 5 minutes to complete the table reservation booking once they have selected the ‘reserve’ button or the table will be released.

Non-Functional Requirement: The response time for a restaurant and table search transaction under a peak load of 15,000 users must not exceed 5 seconds. 

Documenting Non-Functional Requirements

Whilst it is possible to log and track Non-Functional Requirements in a matrix, in today’s increasingly Agile settings, Non-Functional Requirements can also be made visible by presenting each requirement as a standalone backlog item, which means that the requirement would be tested and ensure that it is fulfilled before it is considered ‘done’.

Another means of tracking Non-Functional Requirements is by weaving them in as acceptance criteria within the backlog item, so that it serves as conditions of satisfaction for that item to be accepted and closed. If there are certain Non-Functional Requirements that span across the entire product, it is also possible to include such requirements in the team’s Definition of Done which means that a consistent set of acceptance criteria may apply to all backlog items. 

Each of the approaches above can be applied depending on the complexity of the product, Non-Functional Requirements applicable and its context, which will be explained below.

Considering the Context of Non-Functional Requirements

Depending on the category of Non-Functional Requirements, the context may require consideration.  For example, an organisation with ambitions to expand to North America may have to consider localisation and scalability requirements. Determining the optimal portfolio of Non-Functional Requirements in a given organisational context is critical to delivering stakeholder value.

The assessment of a Non-Functional Requirement, such as localisation and compliance may impose contextual pressures on other Non-Functional Requirements. For example, compliance standards may be different in another country which may require additional solution components to meet the compliance requirements, which in turn may compromise its overall performance efficiency.  Therefore, the organisation may justify adjusting the quantifiable criteria of the product’s performance efficiency accordingly.

Context is dynamic by nature and Non-Functional Requirements may need to be adjusted or completely removed, depending on changing circumstances. It is therefore imperative that Business Analysts provide sufficient consideration for the relative stability of the context when evaluating Non-Functional Requirements.

Potential Challenges of Non-Functional Requirements

Whilst the consideration and implementation of Non-Functional Requirements forms part of the critical success factor of a product, there are a number of challenges around various aspects to consider:

• In software development, Non-Functional Requirements may affect the high-level subsystems and their implementation typically does not map to all subsystems. As a result, they will require special consideration during the design phase at a potentially high financial expense.  
• The degree of clarity and usefulness of Non-Functional Requirements depends on what the relevant stakeholder knows about the needs of the product and how well one is able to express such needs.
• Expectations of multiple users may vary vastly and therefore obtaining agreement on quality attributes may be difficult on stakeholders’ subjective perception of quality.  For example, what might be ‘too slow’ may be acceptable to others.
• A set of Non-Functional Requirements may incur conflicts between certain requirements and may require negotiation to arrive at a compromise. For example, security requirements may require compromises on performance requirements.
• Excessively stringent constraints can add more time and cost to the solution, which may negatively impact the product’s brand image and adversely affect user adoption.
• Some Non-Functional Requirements may be difficult to modify, especially when attempting to incorporate Quality of Service constraint changes into certain products past the high-level design phase.

Why are Non-Functional Requirements Critical?

Despite the potential challenges listed above, Non-Functional Requirements offers measurable expressions of how well the functional requirements must perform, leaving it to the functional requirements to express what the solution must do or how it must behave.  It will also have a strong influence on whether the product will be adopted by users. It is therefore imperative that definition and implementation of Non-Functional Requirements, as these clearly state the constraints on the product’s design that ultimately determines the usability and effectiveness of the entire system.

Failure to meet the critical Non-Functional Requirements can result in introducing products that cause customer dissatisfaction, failure to meet market needs, failure to meet mandatory requirements which could lead to penalties. 

Final Thoughts – Non Functional Requirements

Although stakeholders seldom provide quantitative Non-Functional requirements in the earlier phases of product development, the extent to which Non-Functional Requirements are met underpins the long-term success of the product. Without critical usability elements, there is less chance of a mass buy-in new products require. Categorization of Non-Functional Requirements means that delivery teams can easily conceptualise which aspects of the product are meeting their quality expectations, which can then be used to assess the success of projects in the context of those aspects to drive the product’s user experience and gauge the success of any project.