Non-functional requirements: Scalable
By Adam Alami, PhD Fellow, IT University of Copenhagen (translated from English)
Non-functional requirements are widely represented in the literature. There is no shortage of definitions and examples of non-functional requirements. The International Institute for Business Analysis (IIBA) defines non-functional requirements as follows:
The key words in this definition are “not directly related to the behavior or functionality of the solution”. These are either “conditions” or “quality”.
Conditions : they are external or internal restrictions. Internal constraints are the organization’s policies and self-regulation, while external constraints are government regulations, industry standards and other parameters that define the business environment.
Qualities : these are business requirements that define non-systemic behavior and are not related to the process, but are requirements to the quality of the solution.
Examples:
i) Terms
a. Branding,
b. Data confidentiality,
p. Compatible with PCI;
ii) Quality
a. Availability
b. Performance.
Even the most experienced business analyst puts a lot of effort into identifying non-functional requirements. The main reason for such difficulties is that non-functional requirements are not easy to identify, and there is no predetermined process for their identification. To determine these requirements, you need to be creative and think broadly, beyond certain limits!
In accordance with all types of requirements, omitting a particular requirement could potentially jeopardize the integrity and completeness of the solution. Functional and non-functional requirements are closely interconnected by multiple relationships.
Usually the focus is on the functional aspect of the requirements, and the importance of non-functional requirements is often underestimated.
Why are non-functional requirements underestimated?
1. The focus is on functional requirements, as they provide tangible returns. Non-functional requirements contribute to the infrastructure, not to the behavior of the system. The business infrastructure, which is intangible, is insignificant.
2. The solution delivery team is rewarded and measured in terms of system functions, processes and behavior. Business users view non-functional requirements as “IT requirements”, and IT considers any “needs” as business needs, not technologies. Technology provides service, and business drives needs. During this process, IT sometimes forgets that they have only an “advisory” role.
Each solution achieves effectiveness from an exhaustive list of requirements, collected both at the beginning and during the implementation process. Requirements can be divided into two broad categories: essential and fundamental. The substantive requirements derive from their analogy with the “functional requirements” and seem to be directly related to the solution. However, the so-called fundamental requirements may not have a direct connection with the solution, but they are fundamental to creating a sustainable environment in which substantial functional requirements remain. Therefore, these “non-functional requirements” constitute the structure and infrastructure that support system solutions.
WHAT IS SCALABLE?
Scalability is the ability of a system or process to handle an increased volume of operations without restrictions or structural bottlenecks. Each business model is of paramount importance for generating a business, which leads to an increase in transaction volume and a subsequent increase in operating activity. Scaling up operations to handle expanding business activity is inherent and built into the system design. Scalability can be divided into two categories: physical and intangible.
It refers to those parameters that are crucial to ensuring that an organization is equipped with the means (possibly additional) to handle an increasing number of operations. This implies physical stability. This indicates the presence of factors that are necessary in terms of the physical components of the process to ensure resiliency (i.e., data storage, network bandwidth, hardware, etc.).
What does it mean to be sustainable? It meets current requirements without compromising the ability to support future needs. For example, if the characteristics of a network solution support current needs, then they should also be able to support future needs over the next three to five years. In general, sustainability is determined and estimated using projections for three to five years.
Why is it necessary to determine the need for sustainability when developing a business model / solution? A sustainable business model is based on its design and structure, which are best suited to achieve a solution through stable and reliable systems, processes and infrastructure. Physical stability is aimed at achieving two main characteristics: stability and reliability of business and technological solutions.
Stability : what allows business to remain stable, resistant to external influences. The IT infrastructure is sustainable and ensures support for business operations for the future.
Reliability : if the business is constantly growing for five years, while the infrastructure remains stable. Reliability allows businesses to focus on their core competencies in a sustainable infrastructure.
This refers to the inherent ability to maintain non-physical growth. Growing a business is critical to maintaining market share and competitiveness. Growth can be both internal and external, based on adopted drivers and strategies. Below are a few examples:
* New products that will be placed on one platform / solution
* Additional brands (for multi-brand organizations)
* Additional business processes
What is the difference between physical and non-material? Although both may seem similar, they are not identical. The solution may be physically stable, but may not support intangible growth. For example, if the volume of operations increases, then the solution must be physically stable. If a business introduces new products, then it is classified as intangible growth, and the solution must have scalable functions and processes (not physical) to support this growth.
Why do we need to define the requirements for non-material scalability? The need to define requirements for non-material scalability becomes necessary because it is a prerequisite that supports growth. The requirements for scalability, in fact, are a reflection of the organization's desire for growth and the need for a solution to support growth with minimal changes and disruption of daily activities.
There is no simple explanation or simple methodology for determining scalability requirements. It is extremely subjective and relatively difficult to determine the conditions and features necessary for making a sustainable decision. This is one of the reasons why this is called "analysis." Below is an approach that has always worked for the author. However, this is not suitable for all such situations.
Physical scalability:
1. Determine the physical components of the solution that need to be scaled.
2. Identify features that can make a particular component scalable.
3. Define the parameters for measuring functions.
4. Determine the values of each parameter defined above. These are non-functional requirements (parameter definition).
Answers to these questions need to be formulated from a business point of view, and not from an IT point of view.
Example:
Situation: Your organization is a financial institution that issues credit cards to customers. It makes an effort to transform its technologies and systems.
What questions should be asked to begin the physical scalability identification analysis? In order to simplify, we will narrow the scope. The following are some examples:
1. What is the current volume of customers, transactions, accounts, etc.?
2. What volumes are expected from the operation of the systems on the first day?
3. What is the annual growth in volume (customers, transactions, etc.) expected in the next three to five years?
Question 1 should be asked to determine the current state.
Question 2 defines the immediate requirement from the first day of life (exploitation).
Question 3 is an input to the definition of a solution scalability requirement. For example, if an organization predicts growth of new customers by 10% per year and annual growth in the number of transactions by 15%, then the requirements for scalability can be as follows:
1. The solution should support annual growth of 10% for new customers.
2. The solution should support an annual growth of 15% of the previous number of transactions.
However, in this example, I would suggest further defining the expectation that the requirement implies "support" (i.e., the technology does not require any changes to handle growth)?
Intangible Scalability:
This is business growth, not technology, infrastructure or logistics. This will vary from one business to another and depends on the specifics of the subject area. Therefore, knowledge of business and industry, developed through expert research, is the key to determining scalability parameters at the level of detail. However, a high-level business strategy is formulated on the basis of the detail from the definition of an organization’s vision.
Example:
Situation: Your organization is a financial institution that issues credit cards to its customers. It makes an effort to transform its technologies and systems.
What questions should be asked to begin the identification analysis of intangible scalability? In order to simplify, we will narrow the scope. The following are some examples:
1. Does the organization plan to release new products (for example, mobile payments, products like Apple Pay or Bitcoin)?
2. Are there any future acquisitions or mergers with similar enterprises?
3. What is the organization's strategy (i.e., new distribution channels, access to new markets, etc.)?
These questions help determine non-material growth. For example, if an organization plans to launch a new brand of products for credit cards, then the scalability requirements will be as follows:
1. The solution should be able to place two different brands: Brand A and Brand B.
2. Both brands should be able to use the same systems and processes.
These requirements are high enough and are given only as an example. In a real-life scenario, they should be studied in more detail.
There is no simple method for determining non-functional requirements. It is relatively difficult to define the conditions and functions necessary to create a scalable solution.
__________________________________________________________
By Adam Alami, Ph.D., Copenhagen IT University
Adam Alami is Ph.D. at the IT University of Copenhagen. Adam has extensive experience in information technology. He began his career as a software developer, then moved to business analysis and project management. His 20 years of experience is associated with large business transformation projects and process improvement. He has accumulated a wealth of best practices in large projects in the field of enterprise transformation, integration, migration, and system modernization.
He has a number of academic achievements. He holds a bachelor's degree in software engineering from the University of Quebec-Montreal (UQÀM) and a master's degree in computer engineering from the University of Technology (UTS).
Email: adamalami2016@gmail.com
Published on resourceModernanalyst.com
INTRODUCTION
Non-functional requirements are widely represented in the literature. There is no shortage of definitions and examples of non-functional requirements. The International Institute for Business Analysis (IIBA) defines non-functional requirements as follows:
Non-functional requirements capture conditions that are not directly related to the behavior or functionality of the solution, but rather describe the environmental conditions under which the solution should remain effective, or the qualities that the system should possess. They are also known as quality attributes (indicators) or additional requirements. These can include bandwidth, speed, security, availability, information architecture, and user interface presentation requirements.
The key words in this definition are “not directly related to the behavior or functionality of the solution”. These are either “conditions” or “quality”.
Conditions : they are external or internal restrictions. Internal constraints are the organization’s policies and self-regulation, while external constraints are government regulations, industry standards and other parameters that define the business environment.
Qualities : these are business requirements that define non-systemic behavior and are not related to the process, but are requirements to the quality of the solution.
Examples:
i) Terms
a. Branding,
b. Data confidentiality,
p. Compatible with PCI;
ii) Quality
a. Availability
b. Performance.
Even the most experienced business analyst puts a lot of effort into identifying non-functional requirements. The main reason for such difficulties is that non-functional requirements are not easy to identify, and there is no predetermined process for their identification. To determine these requirements, you need to be creative and think broadly, beyond certain limits!
WHY NEED "NON-FUNCTIONAL REQUIREMENTS"
In accordance with all types of requirements, omitting a particular requirement could potentially jeopardize the integrity and completeness of the solution. Functional and non-functional requirements are closely interconnected by multiple relationships.
Usually the focus is on the functional aspect of the requirements, and the importance of non-functional requirements is often underestimated.
Why are non-functional requirements underestimated?
1. The focus is on functional requirements, as they provide tangible returns. Non-functional requirements contribute to the infrastructure, not to the behavior of the system. The business infrastructure, which is intangible, is insignificant.
2. The solution delivery team is rewarded and measured in terms of system functions, processes and behavior. Business users view non-functional requirements as “IT requirements”, and IT considers any “needs” as business needs, not technologies. Technology provides service, and business drives needs. During this process, IT sometimes forgets that they have only an “advisory” role.
Each solution achieves effectiveness from an exhaustive list of requirements, collected both at the beginning and during the implementation process. Requirements can be divided into two broad categories: essential and fundamental. The substantive requirements derive from their analogy with the “functional requirements” and seem to be directly related to the solution. However, the so-called fundamental requirements may not have a direct connection with the solution, but they are fundamental to creating a sustainable environment in which substantial functional requirements remain. Therefore, these “non-functional requirements” constitute the structure and infrastructure that support system solutions.
WHAT IS SCALABLE?
Scalability is the ability of a system or process to handle an increased volume of operations without restrictions or structural bottlenecks. Each business model is of paramount importance for generating a business, which leads to an increase in transaction volume and a subsequent increase in operating activity. Scaling up operations to handle expanding business activity is inherent and built into the system design. Scalability can be divided into two categories: physical and intangible.
1. Physical scalability
It refers to those parameters that are crucial to ensuring that an organization is equipped with the means (possibly additional) to handle an increasing number of operations. This implies physical stability. This indicates the presence of factors that are necessary in terms of the physical components of the process to ensure resiliency (i.e., data storage, network bandwidth, hardware, etc.).
What does it mean to be sustainable? It meets current requirements without compromising the ability to support future needs. For example, if the characteristics of a network solution support current needs, then they should also be able to support future needs over the next three to five years. In general, sustainability is determined and estimated using projections for three to five years.
Why is it necessary to determine the need for sustainability when developing a business model / solution? A sustainable business model is based on its design and structure, which are best suited to achieve a solution through stable and reliable systems, processes and infrastructure. Physical stability is aimed at achieving two main characteristics: stability and reliability of business and technological solutions.
Stability : what allows business to remain stable, resistant to external influences. The IT infrastructure is sustainable and ensures support for business operations for the future.
Reliability : if the business is constantly growing for five years, while the infrastructure remains stable. Reliability allows businesses to focus on their core competencies in a sustainable infrastructure.
2. Intangible scalability
This refers to the inherent ability to maintain non-physical growth. Growing a business is critical to maintaining market share and competitiveness. Growth can be both internal and external, based on adopted drivers and strategies. Below are a few examples:
* New products that will be placed on one platform / solution
* Additional brands (for multi-brand organizations)
* Additional business processes
What is the difference between physical and non-material? Although both may seem similar, they are not identical. The solution may be physically stable, but may not support intangible growth. For example, if the volume of operations increases, then the solution must be physically stable. If a business introduces new products, then it is classified as intangible growth, and the solution must have scalable functions and processes (not physical) to support this growth.
Why do we need to define the requirements for non-material scalability? The need to define requirements for non-material scalability becomes necessary because it is a prerequisite that supports growth. The requirements for scalability, in fact, are a reflection of the organization's desire for growth and the need for a solution to support growth with minimal changes and disruption of daily activities.
HOW TO DETERMINE THE REQUIREMENTS FOR SCALABILITY?
There is no simple explanation or simple methodology for determining scalability requirements. It is extremely subjective and relatively difficult to determine the conditions and features necessary for making a sustainable decision. This is one of the reasons why this is called "analysis." Below is an approach that has always worked for the author. However, this is not suitable for all such situations.
Physical scalability:
1. Determine the physical components of the solution that need to be scaled.
2. Identify features that can make a particular component scalable.
3. Define the parameters for measuring functions.
4. Determine the values of each parameter defined above. These are non-functional requirements (parameter definition).
Answers to these questions need to be formulated from a business point of view, and not from an IT point of view.
Example:
Situation: Your organization is a financial institution that issues credit cards to customers. It makes an effort to transform its technologies and systems.
What questions should be asked to begin the physical scalability identification analysis? In order to simplify, we will narrow the scope. The following are some examples:
1. What is the current volume of customers, transactions, accounts, etc.?
2. What volumes are expected from the operation of the systems on the first day?
3. What is the annual growth in volume (customers, transactions, etc.) expected in the next three to five years?
Question 1 should be asked to determine the current state.
Question 2 defines the immediate requirement from the first day of life (exploitation).
Question 3 is an input to the definition of a solution scalability requirement. For example, if an organization predicts growth of new customers by 10% per year and annual growth in the number of transactions by 15%, then the requirements for scalability can be as follows:
1. The solution should support annual growth of 10% for new customers.
2. The solution should support an annual growth of 15% of the previous number of transactions.
However, in this example, I would suggest further defining the expectation that the requirement implies "support" (i.e., the technology does not require any changes to handle growth)?
Intangible Scalability:
This is business growth, not technology, infrastructure or logistics. This will vary from one business to another and depends on the specifics of the subject area. Therefore, knowledge of business and industry, developed through expert research, is the key to determining scalability parameters at the level of detail. However, a high-level business strategy is formulated on the basis of the detail from the definition of an organization’s vision.
Example:
Situation: Your organization is a financial institution that issues credit cards to its customers. It makes an effort to transform its technologies and systems.
What questions should be asked to begin the identification analysis of intangible scalability? In order to simplify, we will narrow the scope. The following are some examples:
1. Does the organization plan to release new products (for example, mobile payments, products like Apple Pay or Bitcoin)?
2. Are there any future acquisitions or mergers with similar enterprises?
3. What is the organization's strategy (i.e., new distribution channels, access to new markets, etc.)?
These questions help determine non-material growth. For example, if an organization plans to launch a new brand of products for credit cards, then the scalability requirements will be as follows:
1. The solution should be able to place two different brands: Brand A and Brand B.
2. Both brands should be able to use the same systems and processes.
These requirements are high enough and are given only as an example. In a real-life scenario, they should be studied in more detail.
There is no simple method for determining non-functional requirements. It is relatively difficult to define the conditions and functions necessary to create a scalable solution.
__________________________________________________________
By Adam Alami, Ph.D., Copenhagen IT University
Adam Alami is Ph.D. at the IT University of Copenhagen. Adam has extensive experience in information technology. He began his career as a software developer, then moved to business analysis and project management. His 20 years of experience is associated with large business transformation projects and process improvement. He has accumulated a wealth of best practices in large projects in the field of enterprise transformation, integration, migration, and system modernization.
He has a number of academic achievements. He holds a bachelor's degree in software engineering from the University of Quebec-Montreal (UQÀM) and a master's degree in computer engineering from the University of Technology (UTS).
Email: adamalami2016@gmail.com
Published on resourceModernanalyst.com