SAFe Knowledge Base » Solution Intent
Quality begins with the intent.
—W. Edwards Deming, Out of the Crisis [1]
Solution Intent
Definition: Solution Intent is the repository for storing, managing, and communicating the knowledge of current and intended solution behavior and design.
Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, functional and nonfunctional tests; and support for traceability.
The reason for solution intent is obvious. Building large-scale software and cyber-physical systems is one of the most complex and challenging endeavors in the industry today. This requires alignment on two central questions:
- What exactly is this thing we are going to build?
- How will we build it?
What’s more, these two questions are interrelated. If one doesn’t know ‘how’ to build something in an economically or technically feasible way, then ‘what’ is being built must be reconsidered. SAFe labels this critical knowledge pool Solution Intent. It provides a basic understanding of the current and evolving requirements, design, and intent—that is, the larger purpose of the solution.
Some solution intent is fixed, with non-negotiable requirements for what it must do, or already does. Some solution intent is variable, subject to further discussion and exploration as facts surface. Understanding and navigating these differences, and allowing variability to proceed (even late into the timeline), are vital to unlocking agility in large-scale solution development.
Details
When building systems with a high potential cost of failure, the need for a more rigorous definition and validation of system behavior can be a significant barrier to Agile adoption. Although many practitioners resonate with the Agile Manifesto [2] value statement of “working software over comprehensive documentation,” that concept can generate conflicting priorities for enterprises that need both.
Engineering complex and highly reliable solutions require and create large amounts of technical information. Much of it reflects the solution requirements and design—Features and Capabilities, Stories, Nonfunctional Requirements (NFRs), system architecture, domain-level models and designs (e.g., electrical and mechanical), system interfaces, customer specifications, tests and test results, and traceability. Other relevant information records some of the critical decisions and findings of the system. This may include information from trade studies, results of experiments, the reasoning for design choices, and other items. In many cases, this information must become part of the official record, whether by necessity or regulation.