Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Socio-technical systems"]
N2["16.2 Allocating functions"]
N3["16.3 Human performance requirements"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Socio-technical systems"]
N2["16.2 Allocating functions"]
N3["16.3 Human performance requirements"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Socio-technical systems]
|
v
[16.2 Allocating functions]
|
v
[16.3 Human performance requirements]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) treat people as components of a socio-technical system; (2) allocate functions between people and machines; (3) write requirements that include human performance.
16.1 Socio-technical systems
Prof. Kerr introduces systems engineering: defining needs, requirements, architecture, verification and operation across the whole life cycle. Aiko learns that a security system at Greyford includes people, procedures and technology working together. A remote access system is not just software; it includes the engineers who use it, the help desk that resets their accounts and the manager who approves access. Treating people as part of the system, rather than as external users, makes their limits and strengths part of the design rather than an afterthought.
16.2 Allocating functions
A classic systems engineering question is which tasks machines should do and which people should do. Aiko applies it to phishing defence. Filtering known bad emails, checking sender domains and grouping duplicate reports suit machines, which are fast and consistent. Judging unusual but plausible requests, such as an unexpected vendor instruction, suits people who know the context. She allocates each function and notes that people should not be asked to do what machines do better, such as checking every link by hand.
16.3 Human performance requirements
Aiko writes requirements that include people: a field engineer must be able to report a suspicious email in under ten seconds on a phone; a help desk agent must verify a caller's identity using a procedure that takes less than two minutes; an operator must never be required to enter a password while acknowledging a critical alarm. Each requirement is measurable and testable. NIST SP 800-160 Vol. 1 Rev. 1 describes systems security engineering across the life cycle, and Aiko notes that human performance belongs in those requirements alongside technical ones.
Worked example
Aiko treats people as system components, allocates phishing defence functions between machines and people, and writes measurable human performance requirements.
Synthetic case. Requirements are synthetic; SP 800-160 Vol. 1 Rev. 1 is real.
Errors and limits
Function allocation changes as tools improve. Time limits may not suit every staff member.
Exercises
- EX046 — People as components. What does treating people as system components change? Rubric: 3 = their limits and strengths become part of the design;; 2 = design input;; 1 = vague;; 0 = none.
- EX047 — Machine functions. Which phishing defence functions suit machines? Rubric: 3 = filtering known bad mail, domain checks, grouping reports;; 2 = two;; 1 = judging context;; 0 = none.
- EX048 — Alarm requirement. What does the operator requirement forbid? Rubric: 3 = entering a password while acknowledging a critical alarm;; 2 = password at alarm;; 1 = vague;; 0 = none.
Synthesis
Systems engineering includes people as components, allocates tasks sensibly and writes testable human requirements.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →