Managing requirements as system properties
A structured approach that keeps the full picture in view when non-functional requirements are in scope
Most requirements methods are designed primarily for functional requirements. They work by breaking a requirement into smaller sub-requirements until each piece is concrete enough to implement. For a feature, this works well. For a non-functional requirement such as performance, usability, maintainability or regulatory compliance, the same approach creates problems.
Decomposed non-functional requirements produce fragmented specifications that are difficult to maintain and even harder to verify. The connection between a specific implementation decision and the overarching quality property it is supposed to serve becomes indirect and hard to trace. And when the project ends, the resulting system may be compliant on paper with each sub-requirement while still failing to meet the property as a whole.
Requirements as properties
The alternative is to treat non-functional requirements not as items to decompose, but as properties of the solution. A property is something the solution either has or does not have. It can be defined, measured and verified as a characteristic of the whole, not as a checklist of sub-tasks.
This shift in framing has a practical effect on how a project works. Instead of managing a pile of requirements, the team manages a solution with a defined set of properties. Every design decision, every development choice and every test activity can be evaluated against the properties. Does this change preserve the required level of availability? Does it compromise the usability properties we defined? The question is always about the solution, not about individual items in a backlog.
Using ISO9126 as a framework
The challenge with properties is knowing which ones to consider. A useful starting point was ISO9126 (its successor today is ISO 25010), an international standard that defines categories of software quality characteristics: functionality, reliability, usability, efficiency, maintainability and portability. Each category is divided into sub-characteristics.
Working through ISO9126 at the start of a project serves as a structured checklist. For each category, the team decides which sub-characteristics are relevant to this system and this context, defines how each can be measured and verified, and identifies which areas of the project are affected by each property. Not every sub-characteristic applies to every system; the standard is a prompt for structured thinking, not a mandate.
The same requirements model then serves multiple purposes throughout the project: as input during design and development, as a verification framework during testing, and as a description of the resulting system for handover and ongoing maintenance. Business analysts, developers, testers and QA work from the same source, which reduces duplication and keeps the team aligned.
In practice
Working on a business-critical clinic management platform deployed across 14 countries, IT informa applied this approach to a requirements landscape that combined regulatory requirements varying by jurisdiction, performance requirements driven by remote network conditions, usability requirements for clinical staff with limited IT familiarity, and integration requirements spanning local laboratories, payer systems and financial platforms.
Treating these as a set of system properties rather than separate requirement streams meant that verification approaches were defined early. For instance, it was clear from the outset that network behaviour at remote clinic locations would need to be simulated in test environments, reflecting real operating conditions. That decision followed directly from defining latency and reliability as required properties of the solution, not from a separate requirement item about testing.
The same documentation was used for specification, development reference and handover material. All project members worked from the same source throughout.
What changes
The properties approach does not reduce the amount of work required to define and verify requirements. What it changes is where the effort goes and how well it holds together. Requirements that are defined as properties of a solution are easier to reason about, easier to verify end-to-end, and easier to maintain as the system evolves.
For projects where non-functional requirements carry significant weight (whether through regulatory obligation, performance demands or quality standards), this approach is worth considering from the start.
