By Charles Wasson, Principal Consultant, Instructor, and Coach/Mentor at Wasson Strategics, LLC
Vitech guest Charles Wasson presented a webinar on States and Modes a few weeks ago, and here is a response to one of the questions he received: Do you have any advice for defining modes and states during requirements elicitation?
My suggestion is to AVOID discussing Modes & States with the Acquirer / User during requirements elicitation UNLESS there is a compelling reason to do otherwise. The suggestion is based on my experiences performing SE as a System Developer, evaluating work of other System Developers, and private consulting with medical, aerospace and defense, transportation, and energy sector organizations. Since every system has its own unique differences, those experiences may be as well.
In many cases, preliminary Modes and States should be explored analytically via working papers internal to the Specification Developer as the System / Entity Specification requirements evolve and mature. In this context, Modes & States serve as one of several analytical tools for assessing the completeness of the evolving set of specification requirements. Attempting to engage direct discussions with the Acquirer and Users, who may or may not be well-informed about Modes & States implementation, is premature and inappropriate during requirements elicitation; it only complicates and fogs System Development decision–making.
A key principle of SE states that each specification requirement should specify and bound: 1) WHAT has to be accomplished and 2) HOW WELL. From my perspective, specifying Modes & States requirements in a specification constitutes mandating a conceptual design solution, which violates the SE principle. If Acquirers choose to do this, which is their prerogative, they OWN the risk of mandating the WRONG solution or UNNECESSARILY constraining the set of viable candidate Modes & States and other options, especially if the deliverable system fails to meet their operational needs – validation.
In general, Modes & States development should be based on a:
- Thorough Stakeholder Analysis chain consisting of User Stories (Agile Development) ==> Use Cases ==> UC Scenarios ==> System Capabilities ==> System Specification requirements. The assumption here is that User Stories, Use Cases, and Scenarios are documented EARLY in collaboration with the User via the Acquirer and serve as the originating or source requirements for the System Specification development and its requirements traceability.
- Preponderance of the specification requirements via Requirements Analysis, which enables Modes & States development. The resulting Modes & States serve as an analytical Conceptual Design framework for Command & Control (C2) of the selected System Architecture and its capabilities to enable accomplishment of the requirements.
Please note that despite the implied “waterfall” sequence above, this is the initial progression through the SE process. The process iterates and loopbacks until all decision artifacts – specification requirements, Modes & States, System Architecture, and System Design – are harmonized consistently, and balanced with each other. Supporting the SE Process decision-making are the requisite decision support, specification requirements allocations and flowdown, V&V, et al. activities.
In summary, the approach above enables a true “black box” performance specification development without mandating a specific solution via Modes & States specification requirements. This complies with the SE specification principle, provides a cleaner set of specification requirements that avoids mandating a specific solution that may constrain System Development options, and should produce a system that meets the User(s)’ operational needs – validation – and expectations – customer satisfaction.
Great question … thanks for asking!
