The Quality Engineering Way To Non-Functional Requirements – QE Unit
Non-functional requirements directly impact digital businesses.
It’s not just about delivering features; usability, performance and security are just a few of the constraints for Quality at Speed software.
Two seconds of delays can make you lose 32% of your users, a security breach costs you millions to get back data, or a slowing rhythm of delivery closes your company.
This article shares how to work your way through non-functional requirements to correctly identify and prioritize them.
Follow the QE Unit for more Quality Engineering from the community.
What are non-functional requirements
Non-functional requirements seem complex at first sight. They are usually referred to as NFR with words ending with “itys” (e.g. availability, security).
While functional requirements define what is expected from a system, mainly in terms of behavior, non-functional requirements focus on the how.
Non-functional requirements can be commonly defined as “constraints” (or “non-behavioral requirements” or “technical requirements”, even if less recommended for clarity).
Examples can be to define a maximum first pixel load under a 1 second for a user experience, an hour for data availability, or compliance with a standard like HIPAA or GDPR.
Even if constraints could be considered as a sub-type of non-functional requirements, it is useful to differentiate project constraints like a fixed deadline imperative.
Non-functional requirements can be mistaken with quality attributes:
- Quality attributes are necessary characteristics of a product
- Non-functional requirement is the measure and criteria of such characteristics.
One example is to define the system quality attribute “secure” while defining explicit requirements values for “security” non-functional requirements.
The list of possible non-functional requirements is quite extensive, requiring to organize them in some way.
The structuration of NFRs is well achieved with list of lists more developed than “Quality and Speed”, starting with a broad category that contain more precise requirements:
Business & user oriented NFRs
- Usability describe how the system interacts with its environment for users and other systems, including user-friendliness, interface constraints
- Evolutivity is usually named “evolutivity” as referring to the capacity to maintain, add and evolve a software, with associated effort and timing.
- Localization (exception avoiding “localizability”) represents needs to adapt the system to places like countries, regulations or other non-global needs
Technology & infrastructure NFRs
- Portability assess the degree of openness, flexibility to change, add and integrate workloads together, that can achieved with open standards
- Performance include availability, reliability, response time, throughputs, and other requirements of speed and coping with the workloads
- Elasticity refers to the ability to cope with an increasing amount of workload, users, and more deployments
Development to Operations NFRs
- Developability refers to experience of development to change and adapt the systems, also including the developer experience (i.e. DevEx) tooling, and automation
- Testability collect the need for being able to validate functional or non-functional requirements on the systems, with environments, data, APIs, etc
- Security focuses on the entire set of assets to protect on the end-to-end lifecycle, from design to operations, auditability, compliance, data, up to the application access
Operational and support NFRs
- Observability refers to the need for a data-driven approach to visualize, understand better and use more advanced data solutions for monitoring, alerting, data science
- Operationality includes physical constraints like staff availability, skill level considerations, system accessibility for maintenance
- Financial viability is a time-boxed range of costs to meet at a given time and on for the overall lifecycle of the system, found in modern “FinOps”.
You can see that the word “scalability” has been avoided as a top non-functional requirement due to its ambiguity when used too generically.
A scalable business can mean the requirement for “localization”, but also of “performance” to support more workloads, or “operationality” to support its increasing size.
That’s why it is important to work on such requirements for Quality Engineering.
Why use non-functional requirements in Quality Engineering
Quality Engineering is the paradigm to constrain the entire software lifecycle to continuously deliver Quality at Speed software.
Its outcomes enable digital organization that depends on software to survive in a context of accelerated competition and innovation.
Non-functional requirements are critical as specifying the “how” on the end-to-end perspective, from usability to data recoverability.
Its implementation can be identified at various levels, from OKRs, Definition of Done, Definition of Ready and even as a by design requirement for the entire platform.
How non-functional requirements contribute to Quality
Addressing non-functional requirements enables formalizing software quality attributes expectations to ensure their effective implementation.
The offer being higher than the demand, users have many choices of competitors for specific services where non-functional requirements do make the difference for the business.
Given two companies offer the same products and services, you are most likely to choose the one ensuring usability and performance, even if you are already a customer of the other one.
Such NFRs are not only valuable for end users. Ensuring compliance, security, or evolutivity is a requirement for profitability and survival of organizations.
Non-functional requirements checklist contributes to Quality being:
- Result-oriented applying a checklist to specific expected ranges
- Systematic being applicable to transversal or local implementation
- Scalable to more teams and all software changes in the organization.
How do non-functional requirements contribute to Speed
Like the hunt proverb, there is “good rework” and “bad rework”. Improving something you cannot have done right in the first place is good, but doing something again from poor execution is not.
Companies under the pressure to reinvent their digital offerings to generate new value streams have no time to lose. They are looking for a sustained speed of transformation.
At the same time, their reputation can be dramatically impacted if they fail to comply with privacy regulation or get their data hacked due to lack of security mechanisms.
Addressing early non-functional requirements is a concrete way to reduce risks for the organization, as well as identifying better requirements to incorporate by design.
Non-functional requirements checklist contributes to Speed with:
- Focus in identifying the most important requirements and expectations
- Rhythm by being performed jointly with rituals such as OKRs, DoR or DoD
- Asynchronicity in supporting remote collaboration process among teams
- Visibility with the explicit list and quality attributes expectations.
How to use non-functional requirements in Quality Engineering
Non-functional requirements can be hard to implement due to their transversal impacts among different stakeholders and teams.
In the book The Quest for Software Requirements, Roxanne E. Miller advocates a useful separation between requirements discovery and requirements management.
This clear separation of concerns allows us to first focus on which requirements are necessary, prioritize them, and only then switch to implementation concerns.
The described process will focus on the first part, being the most differentiating ones. Delivery practices like OKRs and DoD can be used for the implementation part.
Be aligned on what you are trying to achieve
Start by being aligned on essential NFRs characteristics:
- Business-driven: linked to a business outcome like sales, experience
- Measurable: units of measure, success and failure intervals
- Testable: how to test the measures
- Contextualized: forcing to select fine-grained components
- Bounded: identifying in and out-of-control perimeter
- Inherited: for example a legacy system limit change capability
- Standard: as possible use existing referential
These guidelines emphasize a systematic checklist first applied system-wide to identify most critical components, to then perform a detailed analysis at the components level.
For example, if you are building a new back-office system for invoices management, the usability requirement will not be the same for the partner API than for the internal portal.
Identify perimeters to apply the checklist
This list must be applied first to the larger system, and repeated for each component that is identified as critical to achieve business objectives.
Here is the non-functional requirements checklist to apply in Quality Engineering:
- Clarify business objectives and expected outcomes
- Define the perimeter of analysis
- Identify in and out-of-control perimeter, inherited limitations
- Apply the non-functional requirements checklist for discovery
- Prioritize requirements to support ranked business objectives
- See if market standard guidelines exist for your requirement
- Explicit non-functional requirements measurement and testability
- Validate implementation responsibility and timing
- Follow-up the non-functional requirements delivery plan
At that stage, you will end up with multiple NFRs backlog:
- One for the system you are working on, mainly
- One to many for the components part of your system
- One to fill the global platform backlog, if you found relevant inputs.
The first two are mainly to tackle within your product OKRs and DoD, whereas the last ones are feeding the global platform backlog, usually managed by platform teams.
Apply the non-functional requirement checklist
Your objective at this stage is to define the need for non-functional requirements by looking at the overall list.
Don’t be concerned at stage with prioritization or the level of measurements, the goal is first to reduce the list to what matters.
Business & user oriented NFRs
- Usability
- Evolutivity
- Localization
Technology & infrastructure NFRs
- Portability
- Performance
- Elasticity
Development to Operations NFRs
- Developability
- Testability
- Security
Operational and support NFRs
- Observability
- Operationality
- Financial viability
Prioritize requirements to support objectives
Your shortened list can now be developed and prioritized.
This step focuses on identifying the sub-requirements associated with the main ones and to prioritize them.
Let’s take an example on a few requirements:
Technology & infrastructure NFRs
- Portability
- Portable between major public clouds
- Performance
- Page first pixel loading, load-time
- Support peaks of traffic with sales period
Development to Operations NFRs
- Testability
- Automated testing of user interface and APIs
- Data generation
- Security
- Compliant with HIPAA, GDPR
- Data backup in separate location
Operational and support NFRs
- Operationality
- Technology chosen must be already operated by the team
- Financial viability
- Total cost of ownership per year
- Monthly recurring cost
- User acquisition cost
See if market standard guidelines exist
You can now see how to accelerate the non-functional requirements process depending on the retained requirements with standards or regulations content.
There are many cloud providers providing access to their security and compliance mechanism to quickly evaluate compatibility for your projects.
The domain of web and mobile application can be supported by Google Core Vitals, constantly evolving with the market usage.
Explicit non-functional requirements measurements
The remaining stage of preparation is to specify requirements measurement and testability.
Here are examples from our list, with explicit measurements and how the tests should be performed in parenthesis, with the technique or tool.
- Performance
- FID (first input delay) <= 100ms (Dynatrace)
- LCP (largest contentful paint) <= 2.5 seconds (Dynatrace)
- CLS (Cumulative Layout Shift) < 0.1 (Dynatrace)
- Financial viability
- Total cost of ownership per year to remain under $200k (PowerBI)
- Monthly recurring costs between $10000 and $15000 dollar (PowerBI)
- User acquisition costs must not exceed $30 (PowerBI)
Non-functional requirements within MAMOS
The mastery of non-functional requirements discovery and management are essential to deliver Quality at Speed software.
Such attributes are easily skipped in rushed implementation looking for short-term results. But with such high rework costs and associated risks, it’s worth investing upstream.
Ensuring non-functional requirements is a challenge for organizations as they require collaboration among different stakeholders and teams.
That’s where Quality Engineering leaders are needed, to ensure requirements are identified at the big picture and effectively managed into delivery units.
Where are you gonna apply your first checklist?
References
Leffingwell, and Ryan Shriver (2010). Nonfunctional Requirements (System Qualities) Agile Style. Agile.
Sameer Paradkar (2017), Mastering Non-Functional Requirements: Templates and tactics for analysis, architecture and assessment, Packt.
Lawrence Chung, Brian A. Nixon, Eric Yu, John Mylopoulos (2000), Non-Functional Requirements in Software Engineering, International Series in Software Engineering.
Roxanne E. Miller (2009), The Quest for Software Requirements, MavenMark Books.
Non-functional Requirements in Software Engineering, GeeksforGeeks.
Nonfunctional requirements: A checklist, IBM.com.
Non-functional requirements, Alexsoft.
Core Web Vitals report, Google.
