cooperative-software-development
cooperative-software-development copied to clipboard
Requirements: elaborate on bias
How to avoid bias
I think one question I would like the chapter to answer is the idea of ethics in design and ways we can free designs from racist or bias ideas. In the last example given in the chapter it talks about how the design was racist towards black residents, but does not discuss ways of changing the described design. The only thing discuss was how it was not ethical and how designs are not free from racist ideas.
Overall, I thought this chapter was a bit harder to grasp content-wise compared to previous chapters. Thankfully though, the examples and layout of the chapter helped me with understanding the concepts. While I really liked how Amy mentions that “designs have many more qualities than just completeness, preciseness, feasibility, and verifiability,” and then going on to talk about how “designs must also be legal, ethical, and just,” I wish there was more information about that. There is the example of how bank software was biased against people of color, but what does it mean for design to be legal, ethical, and just? I know this is a tough question to answer, but I would like to hear it from Amy’s perspective. I took a design ethics class in the iSchool (formerly INFO 498: Designing for Evil, now INFO 466) and we went over several interpretations of how design can be ethical, but even if it’s good for the majority of people, it always excludes certain populations. Does that still make it ethical and just? Even though there could be a whole chapter on this, it would be nice to see another couple sentences on this discussing it from Amy’s point of view/experience.
One part of the I’d like to be expanded is the ethics of requirements in designs. The article states that “Designs must also be legal, ethical, and just” and “Requirements are just one of many ways that [discriminatory] ideas are manifested, and ultimately hidden in code”. It lists a few quick examples such as anti-Black political practices. I think it’s important that the article should explore in some more detail exactly how requirements can prevent these practices from occurring, or provide more examples of requirements preventing discriminatory practices. It’s clear that projects should not discriminate a person by race, gender, etc. and requirements can be steeped with racist ideas- how can we take users into consideration, and change requirements like these without compromising the quality of a project?
The last part about the importance of ethics in requirements seems to be brushed over (not intentionally). However, I feel like ethics in software engineering is an article that should be on its own. You do link to Race to Technology at the end but I can't read it unless I purchase a book so if you were to link an article or something in the same vein that would be cool. I'd like to read up on non-ethical specifications. Maybe something about the tools that are created for ICE
This is the first time I have heard about requirements engineering, the reading did a good job of differentiating it from design. Although ethics is mentioned at the very end, I do wish that the reading went into more detail about how requirements are ensured to be ethical. Just because a requirement is shaped by government and social pressure, does not necessarily make it ethical.
I like how the readings mention that designs should not just be precise and verifiable and that they have to be legal, ethical, and just. One thing I would like to be better explained is discussing how do you know if a requirement is legal, ethical, and just. Since many applications cannot be made for everyone, how do you make sure the requirements one has made is a good requirement to follow, what factors do you need to consider, and how do you create requirements without doing user testing.
I don't know if there's any historical evidence of this (I suspect there is) but the end mentions how requirements are biased and are not immune to being inherently or explicitly racist. I think it would be beneficial to increase the scope of this to also include other forms of discrimination such as sexism, homophobia or transphobia. It's a rather important point that people need to remember, and even though it's theoretically obvious I think spelling it out is useful. Also, unrelated but there are a few typos that could be fixed early on. Second paragraph, the word "opportunity" has two i's and in the third, the word "expected" is missing a p. The last line of the second paragraph probably also doesn't need the "of" before "requirements engineering".