Requirements of Oppression - 2021 IEEE International Requirements Engineering Conference
Summary
TLDRThe speaker reflects on their journey with requirements engineering, from initial fascination to realizing its role in perpetuating social oppression. They advocate for an anti-oppressive approach, highlighting how software requirements can exclude marginalized groups and perpetuate injustice. Through personal experiences and industry insights, they urge the audience to consider the ethical implications of their work and to center humanity and resistance in requirements engineering.
Takeaways
- 🌐 The speaker emphasizes the importance of understanding the broader systems of oppression when discussing software requirements.
- 💡 The initial fascination with software engineering evolved into a realization of its potential for social harm and the need for ethical considerations.
- 👨💻 The speaker's early experiences with programming were driven by personal creativity, without a need for formal requirements.
- 🤝 A pivotal moment in understanding requirements came from a failed collaboration, highlighting the importance of stakeholder needs.
- 🎓 College and research experiences shifted the perspective on requirements from personal constraints to a necessary part of ensuring conceptual integrity in software engineering.
- 🏢 The industry experience, particularly as a CTO, underscored the socio-technical nature of requirements and the challenges in capturing them.
- 🏳️🌈 Coming to terms with a personal identity as transgender led to a profound realization of how software can exclude or harm certain groups.
- 🔍 The IEEE Digital Library's refusal to update author names exemplifies how software requirements can perpetuate oppression.
- 🖥️ The web's inaccessibility to blind people due to a lack of alt text in HTML is a direct result of requirements that disregarded their needs.
- 🚔 Facial recognition software used by police in the U.S. is biased against Black people, reflecting a requirement for arrest numbers over fairness.
- 🛠️ The speaker advocates for an anti-oppressive approach to requirements engineering that centers marginalized groups, resists oppressive norms, and prioritizes humanity.
Q & A
What is the main theme of the speaker's talk at the requirements engineering conference?
-The main theme of the speaker's talk is the impact of software requirements on marginalized groups and how these requirements reflect and reinforce broader systems of oppression.
How does the speaker's relationship with code and requirements evolve over time?
-The speaker's relationship with code and requirements evolves from seeing them as tools for personal creative expression, to realizing the need to define them based on stakeholder needs, to understanding them as socio-technical constraints, and finally to recognizing them as value judgments that can be oppressive.
What personal experience does the speaker share to illustrate the importance of understanding stakeholder needs?
-The speaker shares an experience from high school where they created a bitmap editor without consulting their friend, who was supposed to use it. The friend never used it because it didn't meet their needs, illustrating the importance of understanding and defining requirements based on stakeholder needs.
How does the speaker's perspective on requirements change after working in the industry?
-After working in the industry and co-founding a startup, the speaker begins to view requirements not purely as technical but as socio-technical constraints that must account for both technical capabilities and the state of the world.
What realization does the speaker come to after accepting their transgender identity?
-After accepting their transgender identity, the speaker realizes that software is often not designed for them and can even be designed against them, leading to experiences of misgendering, bullying, and physical harm.
What is the 'matrix of oppression' as mentioned by the speaker?
-The 'matrix of oppression' is a term coined by Patricia Hill Collins to describe the interacting social systems that create social hierarchies of power, including race, age, sex, gender, geography, nationality, religion, and more.
Can you provide an example of how the IEEE Digital Library's requirements have had a negative impact on the speaker?
-The IEEE Digital Library's requirements have resulted in the persistent use of the speaker's dead name in citations, causing emotional harm and separating them from their professional history.
What is the 'five whys' analysis mentioned by the speaker, and how is it applied in the context of the IEEE Digital Library?
-The 'five whys' analysis is a method of root cause analysis used to explore the reasons behind a problem by asking 'why' five times. The speaker applies it to understand why the IEEE Digital Library refuses to fix dead names and misgendering in citations, revealing underlying value judgments about the immutability of names and historical accuracy.
How does the speaker connect the lack of alt text in HTML to broader systems of oppression?
-The speaker connects the lack of alt text in HTML to broader systems of oppression by pointing out that this requirement failure excludes blind people from much of the web's content, reflecting a disregard for the needs of people with disabilities in the development of web standards.
What is the role of activism in changing oppressive requirements, according to the speaker?
-According to the speaker, activism plays a crucial role in changing oppressive requirements by advocating for change, organizing, and demanding inclusion and respect for marginalized groups, which can lead to the implementation of more inclusive and less harmful software requirements.
What are the three principles the speaker suggests for anti-oppressive requirements engineering?
-The three principles suggested for anti-oppressive requirements engineering are: centering the margins by focusing on people marginalized in society, centering resistance by rejecting oppressive requirements and accepting responsibility for harm, and centering humanity by prioritizing people over software creation.
Outlines

This section is available to paid users only. Please upgrade to access this part.
Upgrade NowMindmap

This section is available to paid users only. Please upgrade to access this part.
Upgrade NowKeywords

This section is available to paid users only. Please upgrade to access this part.
Upgrade NowHighlights

This section is available to paid users only. Please upgrade to access this part.
Upgrade NowTranscripts

This section is available to paid users only. Please upgrade to access this part.
Upgrade NowBrowse More Related Video

Matemática y Educación Matemática: poderosas y atrevidas | Mabel Rodríguez | TEDxParqueSanCarlos

The lie that invented racism | John Biewen

Patriarchy and Its Pillars: How We Can Crumble the System | Kudrat Chaudhary | TEDxTufts

My Systems Engineering Degree in 18 Minutes

Let's design social media that drives real change | Wael Ghonim

Requirements Engineering lecture 1: Overview
5.0 / 5 (0 votes)