Essentially, all models are wrong, but some are useful.
—George E. P. Box
SAFe Requirements Model
Note: This article is part of Extended SAFe Guidance and represents official SAFe content that cannot be accessed directly from the Big Picture.
To support bringing the benefits of Lean and Agile development to larger enterprises—or smaller businesses building more complex systems—SAFe provides a scalable requirements model that demonstrates a way to express system behaviors: Epics, Capabilities, Features, Stories, Nonfunctional Requirements (NFRs), and more. As shown in Figure 1, each of these work items is expressed differently.
For example, a Feature is described by a phrase, benefit hypothesis, and acceptance criteria; a Story is elaborated by a user-voice statement and acceptance criteria.
These artifacts mostly replace the traditional system and requirements specifications with new paradigms based on Lean-Agile development. These examples also help teams avoid focusing on a point solution too early and avoid picking specific requirements and designs at the beginning of the learning process. Instead, they encourage leaving room for an emerging understanding based on intent, not specificity.
Also, patterns and relationships for attributes, testing, and acceptance guidelines are included to support the NFRs imposed on the world’s most important systems.
Taken together, it’s a comprehensive model, as Figure 1 illustrates.
Most practitioners need only a portion of these items. For example, Agile Teams primarily use stories, acceptance tests, and NFRs. However, each element is designed to provide the right amount of expression of behavior and testing at the various levels of SAFe.
This guidance article is for those consultants and SAFe experts who need to know how it works together as a system—and those who provide tooling around SAFe, where the semantics must be unambiguous.
If the model appears complex, that’s because contemporary software and systems development at scale is complicated, even with Agile methods. If an element is not needed, then it need not be used. However, teams and ARTs building world-class enterprise solutions of the highest possible quality can probably apply most of these elements.
Last update: 13 March 2023