Rethinking Requirements Derivation By John Fitch
FEATURE ARTICLE
Rethinking Requirements Derivation – Part 1 by John Fitch Project Performance International Copyright © 2023 by Project Performance International. All rights reserved. Authored for PPI SyEN
Introduction Three prior articles in PPI SyEN have laid the foundation for this topic. In the article Introduction to Decision Patterns in PPI SyEN Edition #107 (December 2021), a decision was defined as a “fundamental question or issue that demands an answer or solution”, the Decision class (of information) was distinguished from the Alternative class, and the concept of decision-torequirements derivation traceability was introduced. In the article Decision Patterns – So What? in PPI SyEN Edition #111 (April 2022), a decision-centric information architecture (metamodel) was elaborated that explained the conceptual basis behind decision-to-requirements derivation traceability. Derived requirements were stated to be the inherent consequences that flow from the definition of the solution alternative that has been chosen in an “upstream” decision. In other words, “all requirements are derived requirements” and “decisions create requirements”. In the article Reverse Engineering Stakeholder Decisions from Their Requirements in PPI SyEN Edition #113 (June 2022) decision-to-requirements traceability was presented as the basis for the ability to reverse engineer stakeholder choices and to validate and refine a set of stakeholder requirements. A requirements derivation heuristic was introduced in the form of a question to be applied to each “upstream” decision: “How does the chosen alternative’s Structure, Behavior, Footprint, Interfaces and Lifecycle impose constraints on the rest of the system?” In the second article, four assertions were stated as “givens” based on the author’s experience with capturing decision-to-requirements traceability across 150+ customer projects: • • • •
There is a decision pattern behind any strategy or design. Decisions (through the alternative chosen) are the source of all requirements. The Decision -> chooses -> Alternative -> results in -> Requirement traceability thread may be traversed in either direction. Elaborating alternatives in the form of detailed textual descriptions and models (physical, logical, 3D, etc.) is useful in understanding their derived requirements consequences.
October 2023
[Contents]
18