Chapter 14 — Software engineering | 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 14 — Software engineering

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 User-centred design"]
  N2["14.2 Usability testing"]
  N3["14.3 Tracking usability defects"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 User-centred design"]
  N2["14.2 Usability testing"]
  N3["14.3 Tracking usability defects"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 User-centred design]
    |
    v
[14.2 Usability testing]
    |
    v
[14.3 Tracking usability defects]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) apply user-centred design to a security feature; (2) run usability tests; (3) track usability defects like other defects.

14.1 User-centred design

Greyford wants a new report button in its email system. Aiko follows a user-centred process: interview users, sketch options, test prototypes and refine. Interviews show field engineers read email mostly on phones, often with gloves or in bright light. A small icon hidden in a menu would fail them. Her design places a large report button at the top of each message on both desktop and mobile. Software engineering practices apply to security features just as they do to any other feature.

14.2 Usability testing

Aiko tests the prototype with eight staff from different roles. Each is asked to report a suspicious email while she watches without helping. She records time taken and errors. Desktop users report in under five seconds; two mobile users struggle because the button scrolls off screen. She fixes the button so it stays visible. Small tests with real users find problems that designers cannot see because they already know how the feature works. She repeats the mobile test after the fix, and all eight participants succeed quickly.

14.3 Tracking usability defects

Aiko logs usability problems in the same defect tracker as functional bugs, with severity based on how many users fail and how important the task is. The scrolling button is a high-severity defect because reporting is the feature's main purpose. Treating usability problems as defects ensures they are fixed before release, rather than being left as matters of taste. Sasse, Brostoff and Weirich (2001) argued that security which people cannot use effectively is not effective security. The defect is fixed before release.

Worked example

Aiko designs a report button through interviews and prototypes, tests it with eight users, fixes a mobile defect and tracks usability as defects.

Synthetic case. Tests are synthetic; Sasse et al. (2001) is real.

Errors and limits

Eight testers miss rare issues. Lab tests differ from real field conditions.

Exercises

EX040 — Field conditions. What conditions affect field engineers' email use? Rubric: 3 = phones, gloves and bright light;; 2 = conditions;; 1 = vague;; 0 = none.
EX041 — Mobile defect. What usability defect did testing find? Rubric: 3 = the mobile report button scrolled off screen;; 2 = scrolling;; 1 = vague;; 0 = none.
EX042 — Defect severity. Why was the scrolling problem high severity? Rubric: 3 = reporting is the feature's main purpose;; 2 = core task;; 1 = cosmetic;; 0 = none.

Synthesis

Security features need user-centred design, usability testing and defect tracking like any other software.

Continue studying — chapter 14 of 50

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →