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 to 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 in different ways.

Figure 1. SAFe Requirements Model

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 are also intended to 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, acceptance guidelines and testing are included to support the NFRs that are also 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 employ user stories, story 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 all works together as a system—and for 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 programs that are building world-class enterprise solutions of the highest possible quality can probably apply most of these elements.


Learn More



Last update: 10 February 2021