Reverse Engineering Stakeholder Reverse Engineering Stakeholder Decisions from Their Requirements Decisions from Their Requirements By John Fitch
by John Fitch Project Performance International Copyright © 2022 by Project Performance International. All rights reserved. Authored for PPI SyEN
Introduction When faced with a new set of needs or requirements in any form from a customer or set of stakeholders, how do you begin to attack that challenge? For the last 30 years of my career, the answer has been simple. Conduct a Decision Blitz to reverse engineer my stakeholders’ decisions from the requirements they have given me. [1, 2] Put that decision model in front of the stakeholders to validate those decisions, refining them as needed and identifying “open” decisions for which the stakeholders don’t have a chosen alternative/course of action (or don’t agree upon one). Update the system requirements (with stakeholder concurrence) by explicitly tracing the system requirements from the decisions that the stakeholders agree are “closed”. Define the boundary of the development project in terms of the open decisions for which I or my team are responsible to deliver a solution. I have done this process 100+ times across my career, found it to be an extremely efficient and effective way to gain understanding of my stakeholders’ problem and to kick start the use of more detailed and rigorous requirements analysis and modeling techniques. The method also jump starts the framing of the project’s essential thinking as a Decision Breakdown Structure (DBS) which can be used to guide, accelerate, and align the results of the solution design process. Of course, this simple process isn’t trivially simple or repeatable without some new skills. I learned it from the ground up. It’s based on a set of decision patterns that I have been actively refining across my entire career and are therefore “in my head”. It’s engine is a non-traditional view of requirements derivation and traceability.[3] Few fit-for-purpose software tools exist to facilitate the process. My goal in this article is to deliver “How to” guidance on using a decision reverse engineering method as a requirements analysis and validation tool. It may be helpful for you to first read (or re-read) two prior SyEN articles on decision patterns: • •
Introduction to Decision Patterns (SyEN edition #107, December 2021) Decision Patterns – So What? (SyEN edition #111, April 2022)
My hope for this article is that you will be sufficiently intrigued by the potential payoff of this requirements analysis and validation technique to take first steps toward mastery of this method and application of this approach to your development projects. Where do requirements come from? The simple answer – your stakeholders’ decisions. If you do a thought experiment concerning any requirement in any specification that you have ever seen, you can likely identify where an “upstream” decision by your stakeholders concerning the role of the System of Interest (SoI) in their larger world would invalidate or significantly alter the requirement.
June 2022
[Contents]
22
