1. Home
  2. Knowledge Base
  3. Knowledge topics
  4. Requirement Management for Sustainability

Requirement Management for Sustainability

Version PA2

Open Up before Narrow Down – and Systems Thinking

What sets sustainable software development apart from traditional methods, is that we need to take into account that “The system” does not exist in a vacuum, but interacts with the environment and other systems. This suggests that we need to have elements of “Systems thinking” from the outset. 

One such model is described in The Sustainability Analysis Diagram, where we take into consideration the direct, enabling and systemic effects a system can have in five dimensions. As described in the IEEE Article “Requirements: The Key to Sustainability” (1), we need to investigate the interests of, and sometimes negotiate with representatives for – the various dimensions. 

Consequently, we need to make sure that we have captured enough of the additional requirements resulting from such a process before we isolate and narrow down the scope of the requirements. 

System qualities that are relevant for sustainability

Requirements related to sustainability are often “Non-functional” requirements, and can be challenging to capture in a meaningful way. 

The article “Sustainability Quantification in Requirements Informing Design” (2) address the five dimensions as described in The Sustainability Analysis Diagram, and suggests how to identify Measurable and quantifiable requirements for them. 

These are the primary groups of qualities that are relevant for sustainable systems, supporting those dimensions:

IndividualPrivacy To support the right to privacy, as outlined in the European Charter of Human Rights, article 8 (4)
Individual and EconomySecurityTo support Security, and protect other values that the solution handles
IndividualUniversal Design It systems should be accessible and easy to use for all people, regardless of physical disabilities (5)
Individual and SocialEthical and non-biased algorithmsIT-systems that use AI and algorithms need to make sure that they treat people fairly
Economy, Technical and SocialMaintainabilityThe construction of new IT solutions require large investments in human and technical resources, and we need to ensure that systems can be maintained and evolved instead of replaced 
EnvironmentEnergy EfficiencyComputers, data centers and networks consume 10% of the world’s electricity. (3)

Here is an example of how we can quantify sustainability requirements, based on a table in the article “Sustainability Quantification in Requirements informing design” 2):

TechnicalBMI=Number of problems close/number of problems arrival *100Backlog Management index (BMI) is a workload statement for software maintenance. It is related to both the rate of defect arrivals and the rate at which fixes for reported problems become available.
Rework Metric The total number of functions modified per commit related to adding a new feature/function. The «extensibility» of a system is generally the ability of the system to tolerate additional features or functionality with little or no required rework.
EconomyBMI=Number of problems close/number of problems arrival *100Same as the above BMI 
Defect Density= Total defects/SizeThe value of the total defects which are known to the size of the software product calculated.
Net CostThe Budgeted Capital – Total Capital Spent
EnvironmentBMI=Number of problems closed/Number of problems arrival * 100Same as the above BMI
Defect Density=Total Defects/SizeSame as above
Energy efficiencyUseful work done/Used energy
SocialGateway metric (1=Task Success and 0=Task failure)The amount of successful tasks completed
Defect Density(see above)
Net working hoursBudgeted hours – Total working hours
IndividualGateway metric (1=Task Success and 0=Task failure)Same as the above Gateway Metric
Defect Density(see above)

Note: We may define energy efficiency as the Watt hours spent for each user story, if we can establish good enough boundaries for the energy expenditure

In agile development

Functional requirements are often captured as user stories, while non-functional requirements can be expressed in “Definition of Done”. Alternatively, one can capture non-functional requirements in user stories, by Introducing a user type that is a stakeholder for a sustainability quality. 

Here is an example focusing on maintainability: 

“As a Chief Sustainability Officer, I know that it only takes two weeks until a new programmer on the team is able to fix a bug and put the patched system into production”


  1. C. Becker et al., “Requirements: The Key to Sustainability,” IEEE Softw., vol. 2016, no. January/February, 2016. (link)
  2. Oyedeji, Shola & Seffah, Ahmed & Penzenstadler, Birgit. (2017). Sustainability Quantification in Requirements Informing Design. (link)
  3. Wikipedia: https://en.wikipedia.org/wiki/IT_energy_management
  4. Wikipedia: https://en.wikipedia.org/wiki/European_Convention_on_Human_Rights
  5. Wikipedia: https://en.wikipedia.org/wiki/Universal_design

Version log

PA128.4.2022Simen Sommerfeldt
PA216.5.2022Added article from 2), and example from agile development
Was this article helpful?

Need Support?

Can't find the answer you're looking for?
Contact Support