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:

Category	Quality	Relevance
Individual	Privacy	To support the right to privacy, as outlined in the European Charter of Human Rights, article 8 (4)
Individual and Economy	Security	To support Security, and protect other values that the solution handles
Individual	Universal Design	It systems should be accessible and easy to use for all people, regardless of physical disabilities (5)
Individual and Social	Ethical and non-biased algorithms	IT-systems that use AI and algorithms need to make sure that they treat people fairly
Economy, Technical and Social	Maintainability	The 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
Environment	Energy Efficiency	Computers, 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):

Category	Metric	Description
Technical	BMI=Number of problems close/number of problems arrival *100	Backlog 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.
Economy	BMI=Number of problems close/number of problems arrival *100	Same as the above BMI
Defect Density= Total defects/Size	The value of the total defects which are known to the size of the software product calculated.
Net Cost	The Budgeted Capital – Total Capital Spent
Environment	BMI=Number of problems closed/Number of problems arrival * 100	Same as the above BMI
Defect Density=Total Defects/Size	Same as above
Energy efficiency	Useful work done/Used energy
Social	Gateway metric (1=Task Success and 0=Task failure)	The amount of successful tasks completed
Defect Density	(see above)
Net working hours	Budgeted hours – Total working hours
Individual	Gateway 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”

References

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

Version	Date	Changes/Contributors
PA1	28.4.2022	Simen Sommerfeldt
PA2	16.5.2022	Added article from 2), and example from agile development