Requirements for bias consideration
The clause 4 requirements enter the profile as the first entry and are revisited at every iteration.
What clause 5.2.1 asks
The bias requirements produced by clause 4 are the first content of the profile. They set what the system is trying to preserve and what it is trying to prevent, and they carry the boundaries of acceptability. Because the clauses are iterative, these requirements are not frozen after the first pass. A stakeholder finding, a data finding or a risk finding can change them, and the profile keeps the earlier version so the change can be explained.
Why it matters
The requirements entry is the anchor for every later judgement. A data map is representative against a set of stakeholders, and those stakeholders are defined by the requirements and the clause 6 work. A risk is acceptable against a boundary, and the boundary is in this entry. If the requirements are vague, every later clause will be argued on its own terms. If they are precise, the later clauses have a test.
What good looks like
Write the requirements as a small set of statements that can be checked. Each statement should name the group or outcome it concerns, the direction of the intended difference, and the boundary. Avoid adjectives that cannot be tested, such as fair or reasonable, unless the organization defines them in the context of use. Version the entry and link each change to the finding that caused it.
Evidence an assessor asks for
The assessor will ask how a later test relates to a requirement. A requirement that cannot be mapped to a test is either untestable or unused.
- Requirement statements Each requirement with its group, intended direction and boundary
- Definitions The organization's definitions for any qualitative term used in a requirement
- Change links Each version change linked to the finding or decision that caused it
- Approval The owner's approval of the current requirement set
Where it commonly fails
- The requirements are a list of principles with no group or direction
- The requirements are changed silently to match the test results
- No one can say which finding caused a requirement change
What to do before publication
Draft the requirements with the test in mind. If the team cannot imagine the test, rewrite the requirement.
Read across
- 4.1 Purpose
- 4.3 Outputs
- 5.2 The bias profile and the system life cycle
- 6.4 Actions
- 9.2.3 Evaluation of design and outputs: outputs
← 5.2 The bias profile and the system life cycle5.2.2 Stakeholder identification in the life cycle →