Non-Functional Requirements: Scalability

Non-functional requirements are extensively documented in literature. There is no shortage of definitions and examples of non-functional requirements. The International Institute of Business Analysis (IIBA) defines non-functional requirements this way:

Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.

It has been very aptly described. The key words in this definition are ‘do not directly relate to the behaviour or functionality of the solution’. They are either ‘conditions’ or ‘qualities’.

Conditions: They are external or internal constraints. Internal constraints are an organisation’s policies and self-regulations, whereas external constraints are government regulations, industry specific compliance, and other parameters that define the business environment.

Qualities: These are business requirements but are not comprised of system behaviour, nor are they process related. They are rather business demands on the quality of the solution.

a) Conditions

a. Branding
b. Data Privacy
c. PCI Compliance

b) Qualities

a. Availability
b. Performance

Even the most experienced business analyst struggles to identify non-functional requirements. The underlying reason is that these are not straightforward and there is no pre-defined process to identify them. You need to be creative and think outside of the box in order to determine them!

Inherent to all requirements types, if a requirement is missed, then it may potentially jeopardise the integrity and the completeness of the solution. Functional and non-functional requirements are tightly coupled entities with multi-dimensional inter-linkages.

The focus on the functional aspect of the requirements is over emphasised, and the significance of the non-functional requirements is under estimated.

Why are non-functional requirements underestimated?

1. The focus on functional requirements is because they produce tangible output. However, non-functional requirements contribute to the infrastructure rather than system behaviour. The business infrastructure, being intangible, appears negligible.
2. The delivery team is rewarded and measured in terms of systems functions, processes, and behaviour. Business users consider non-functional requirements to be ‘IT Requirements’, and IT considers any ‘needs’ to be business needs and not technology. Technology provides a service and the business drive the needs. In the process, IT sometimes forgets that they have an ‘advisory’ role.

Every solution derives its effectiveness from the exhaustive list of requirements gathered at inception as well as during the implementation process. Requirements can be classified into two broad categories: essential and fundamental. The essential requirements derive their analogy to ‘functional requirements’ and appear to have a direct bearing on the solution. However, the so-called fundamental requirements may not have a direct linkage to the solution, but these are fundamental to enabling a sustainable environment within which the essential, functional requirement persists. Therefore, these ‘non-functional requirements’ constitute the structure and infrastructure that support systems solutions.

Scalability is the capability of a system or process to handle an enhanced level of operations without constraints or structural bottlenecks. Every business model gives paramount importance to business generation, which leads to higher transactional volume and its consequential surge in operational activity. Scaling up the operations to handle increased business activity is inherent and built into the system design. Scalability can be classified into two categories: Physical and Intangible.

1. Physical

This refers to the parameters, which are critical to ensure that the organisation is equipped to handle scaled-up operations. It implies physical sustainability. This specifies the availability of the factors required in terms of the physical components of the process (i.e., data storage, network bandwidth, hardware, etc.) to qualify as sustainable.

What does it mean to be sustainable? It’s meeting the current requirements without jeopardizing the ability to sustain future needs. For example, if the networking solution characteristics support the current needs, then at the same time, they must be able to support the future needs of the next three to five years. In general, sustainability is specified and gauged over a spread of three to five years projections.

Why do we need to identify sustainability needs while designing the business model/solution? A sustainable business model derives its genesis in its design and structure, which is best suited to achieve the solution through stable and reliable systems, processes, and infrastructure. Physical sustainability aims at achieving two main features: stability and reliability of the business and technology solutions.

• Stability: This allows the business to remain stable. The IT infrastructure is sustainable and guaranteed to support the business operations for an estimated period into the future.\

• Reliability: If the business grows consistently over a span of five years, then the infrastructure is sustainable. Reliability permits the business to focus on its core competencies within sustainable infrastructure.

2. Intangible

This refers to the inherent ability to support non-physical growth. Business growth is critical to maintaining the market stake and competitiveness. Growth can be both intrinsic and extrinsic based upon the drivers and strategies adopted. Following are a few examples:

• New products to be hosted on same platform/solution

• Additional brands (for multi-brand organizations)

• Additional business processes

What is the difference between Physical and Intangible? Although both may sound similar, they are not identical. A solution can be sustainable physically but might not support intangible growth. For example, if the volume of operations increases, then the solution needs to be sustainable physically. If the business introduces new products, then this is categorized as intangible growth, and the solution needs to have scalable function and processes (not physical) to support the growth.

Why do we need to identify intangible scalability requirements? The significance of ascertaining intangible scalability requirements becomes necessary as it is a prerequisite that supports growth. Scalability requirements are, in essence, a reflection of the organization’s ambition to grow and the need for a solution to support the growth with minimal changes and disruption to everyday activities.

There is no straightforward explanation or methodology to ascertain scalability requirements. It is extremely subjective and relatively complex to define the conditions and features required to draw a sustainable solution. That is one of the reasons why it is referred to as an ‘analysis’. Below is an approach that always worked for me. However, it is not a fit for all situations.

Physical:

1. Identify the solution’s Physical components that need to be scalable.
2. Identify the features that would make a particular component scalable.
3. Define the parameters to measure the features.
4. Ascertain the values of each parameter defined above. These are the non-functional requirements (the definition of the parameter).

The answers to these questions must be from the business perspective and not from the IT perspective.

Example:

Situation: Your organization is a financial institution that issues credit card products to its customers. They are embarking on an endeavour to transform their technology and systems.

What questions should be asked to help initiate the analysis of identifying Physical scalability? For the purpose of simplification, we will narrow the scope. Below are some examples:

1. What is the current volume of customers, transactions, accounts, etc.?
2. As of day one, what are the volumes expected from the systems to handle?
3. What is the annual growth in volume (customers, transactions, etc.) expected in the next three to five years?

Question 1 is asked to determine the current state.

Question 2 determines the immediate requirement from the first day of going live.

Question 3 is an input into identifying the scalability requirement of the solution. For example, if the organization is forecasting a growth of 10% a year of new customers and 15% annual growth of the number of transactions, then the scalability requirements are as follows:

1. The solution shall be able to support an annual growth of 10% of new customers.
2. The solution shall be able to support an annual growth of 15% on the number of transactions.

However, in this example, I’d suggest to define further the expectations of what the requirement intends by ‘support’ (i.e., the technology does not require any changes to handle the growth)?

Intangible:

This is business growth and not technology, infrastructure, or logistics growth. This will vary from one business to another and is domain specific. Therefore business and industry knowledge developed through subject matter expertise is the key to defining the scalability parameters at a granular level. However, the high level business strategy is formulated based upon a drill down from the organization vision statement.

Example:

Situation: Your organization is a financial institution that issues credit card products to its customers. They are embarking on an endeavour to transform their technology and systems.

What questions should be asked to help initiate the analysis of identifying Intangible scalability? For the purpose of simplification, we will narrow the scope. Below are some examples:

1. Is the organization planning to release new products (i.e., mobile payments, products similar to Apple Pay or Bitcoin)?
2. Are there any future acquisitions or mergers with similar businesses?
3. What is the organization strategy (i.e., new distribution channels, reaching new markets, etc.)?

These questions help to identify the intangible growth. For example, if the organization is planning to launch a new brand of credit card products, then the scalability requirements are as follows:

1. The solution shall be able to accommodate two distinct brands, Brand A and Brand B.
2. Both brands shall be able to use the same systems and processes.

These requirements are quite high level and for example only. In a real-life scenario, they need to be explored in more detail.

There is no straightforward method to define Non-functional requirements. It is relatively complex to define the conditions and features required to draw a scalable solution.

Author: Adam Alami, PhD Fellow, IT University of Copenhagen

Adam Alami is a PhD fellow at the IT University of Copenhagen. Adam has a wealth of experience in information technology practices. He started his career as a software developer, then moved to business analysis and project management. His 20 years’ experience revolves around major business transformation projects and process improvement. He accumulated a wealth of cross industry experience in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.