Chapter 21 — Human factors and cyber policy: requirements | Engineering Human factors and cyber policy

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 21 — Human factors and cyber policy: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Eliciting requirements"]
  N2["21.2 Testable requirements"]
  N3["21.3 Prioritising"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Eliciting requirements"]
  N2["21.2 Testable requirements"]
  N3["21.3 Prioritising"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Eliciting requirements]
    |
    v
[21.2 Testable requirements]
    |
    v
[21.3 Prioritising]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) elicit human factors requirements from staff; (2) write them in testable form; (3) prioritise requirements with stakeholders.

21.1 Eliciting requirements

Aiko runs short workshops with operators, field engineers and office staff to learn what the awareness and reporting programme must achieve for them. She asks about recent suspicious emails, what made them hard to judge and what stopped them reporting. Operators say they cannot leave consoles to read long training. Engineers say they read email on phones in vans. Office staff say they fear looking foolish if they report a genuine email. Each statement becomes a candidate requirement grounded in real experience rather than assumptions made in the security office.

21.2 Testable requirements

Aiko rewrites each need as a testable requirement. Training modules for operators must take no more than five minutes and be usable during quiet periods. Reporting must work on phones in one tap. Every report, including those that turn out to be safe, must receive a thank-you within one minute. No simulation result may be shared with line managers by name. Each has a measure and a test. She avoids vague phrases such as staff should be aware, which cannot be verified and therefore cannot guide design.

21.3 Prioritising

With twenty candidate requirements and limited budget, Aiko holds a prioritisation session with representatives of each group and the security team. They rank requirements by risk reduced, staff benefit and cost. One-tap mobile reporting and fast thank-you messages rank highest because they are cheap and address the most common barrier. A full simulation platform ranks lower because the existing tool can be configured. She records the ranking and reasons so later decisions can refer back to them. The ranking is shared with all staff in a short note so that people can see their concerns were heard.

Worked example

Aiko elicits needs from three staff groups, rewrites them as testable requirements and prioritises twenty with stakeholders.

Synthetic case. Workshops and requirements are synthetic.

Errors and limits

Workshop participants may not represent quieter staff. Rankings reflect who attends.

Exercises

EX061 — Office fear. What barrier did office staff describe? Rubric: 3 = fear of looking foolish if they report a genuine email;; 2 = embarrassment;; 1 = vague;; 0 = none.
EX062 — Vague requirement. Why avoid "staff should be aware" as a requirement? Rubric: 3 = it cannot be verified;; 2 = untestable;; 1 = vague;; 0 = none.
EX063 — Top priorities. Which requirements ranked highest? Rubric: 3 = one-tap mobile reporting and fast thank-you messages;; 2 = both;; 1 = platform;; 0 = none.

Synthesis

Human factors requirements come from staff experience and must be testable and prioritised openly.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →