Requirement Management for Sustainability
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:
|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):
|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”
- C. Becker et al., “Requirements: The Key to Sustainability,” IEEE Softw., vol. 2016, no. January/February, 2016. (link)
- Oyedeji, Shola & Seffah, Ahmed & Penzenstadler, Birgit. (2017). Sustainability Quantification in Requirements Informing Design. (link)
- Wikipedia: https://en.wikipedia.org/wiki/IT_energy_management
- Wikipedia: https://en.wikipedia.org/wiki/European_Convention_on_Human_Rights
- Wikipedia: https://en.wikipedia.org/wiki/Universal_design
|PA2||16.5.2022||Added article from 2), and example from agile development|