Chapter 16 — Systems engineering | Engineering Identity and access management

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 16 — Systems engineering

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Lifecycle"]
  N2["16.2 Requirements"]
  N3["16.3 Traceability"]
  N4["16.4 Interfaces"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Lifecycle"]
  N2["16.2 Requirements"]
  N3["16.3 Traceability"]
  N4["16.4 Interfaces"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 Lifecycle]
    |
    v
[16.2 Requirements]
    |
    v
[16.3 Traceability]
    |
    v
[16.4 Interfaces]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) apply the systems lifecycle to an identity programme; (2) write verifiable requirements; (3) maintain traceability and interfaces.

16.1 Lifecycle

Sana's project follows the systems engineering lifecycle: understanding needs, writing requirements, design, implementation, verification, operation and eventually retirement of old account stores. Each stage produces documents the next relies on. Security is considered throughout, because a flaw designed into the identity architecture, such as one shared administrator role across all applications, is far costlier to fix after 140 applications depend on it. Reviews between stages confirm that outputs are complete before work continues. Retiring old account stores is planned from the start, since leaving them running alongside the new provider keeps old weaknesses alive.

16.2 Requirements

A requirement states what the system must do or how well, in a way that can be checked. Leavers' access to all integrated applications must be removed within four working hours of their HR end date is a requirement; buy a particular identity product is a design decision. Each requirement has an identifier, a source such as an audit finding or council policy, and a planned verification method. Sana writes about sixty requirements, grouped into authentication, authorisation, lifecycle, audit and operations.

16.3 Traceability

A traceability matrix links each requirement to the design elements that satisfy it and the tests that verify it. Gaps become visible: a requirement with no test is unverified, and a design element linked to no requirement may be unnecessary. When the council changes a requirement, the links show what must be revisited. Auditors use the matrix to confirm that promises were kept. Sana keeps it in version control next to the configuration, so it changes together with the system it describes.

16.4 Interfaces

Many identity failures happen at interfaces: between HR and the directory, between the provider and each application, between the provider and the service desk tools. Each side assumes something about the other, such as when an HR end date becomes effective. Sana writes interface specifications recording what crosses each boundary, in which direction, in what format, how often and who owns each side. Agreeing them in writing prevents gaps, such as a leaver feed that runs weekly when the requirement assumes hours.

Worked example

Requirement LC-03 (leaver removal within four working hours) traces to the HR-to-directory feed, the provisioning connector and test case T-LC-03.

Synthetic case. Requirements, interfaces and tests are synthetic.

Errors and limits

Writing product choices as requirements closes off design options before alternatives are compared.

Exercises

EX046 — Requirement versus design. Which is a requirement: leaver removal within four hours, or buying a product? Rubric: 3 = leaver removal within four hours;; 2 = first;; 1 = product;; 0 = none.
EX047 — Untested requirement. What does a requirement without a linked test indicate? Rubric: 3 = it is unverified;; 2 = gap;; 1 = done;; 0 = none.
EX048 — Interface gap example. What interface gap does Sana give as an example? Rubric: 3 = weekly leaver feed when hours required;; 2 = timing;; 1 = vague;; 0 = none.

Synthesis

Lifecycle stages, verifiable requirements, traceability and written interfaces keep an identity programme coherent.

Continue studying — chapter 16 of 50

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