Essentially, all models are wrong, but some are useful. 
—George E. P. Box
SAFe Requirements Model
In support of bringing the benefits of Lean and Agile development to the larger Enterprise—or to those smaller enterprises building more complex systems—SAFe provides a “scalable requirements” model that provides a way to express system behaviors: Epics, Capabilities, Features, Stories, Nonfunctional Requirements (NFRs), and more. Each of these work items are expressed in different ways as shown in Figure 1. For example: a feature is described by a phrase, business benefit and acceptance criteria, while a story is elaborated by a user voice statement and acceptance criteria.
These artifacts largely replace traditional system and requirements specifications with new paradigms based on lean-agile development. These newer paradigms are intended to help systems builders avoid focusing too early on a “point solution”, based on picking specific requirements and designs far too early in the learning process, but, rather, leave room for an emerging understanding based on intent, not specificity.
In addition, in support of the nonnegotiable quality requirements imposed on the world’s most important systems, patterns and relationships for attributes, acceptance criteria, and testing are also included.
Taken together, it’s not a trivial model, as Figure 1 illustrates.
Most practitioners need only a portion of these items. (For example, teams primarily use user stories, story acceptance tests, and NFRs. Also, in the “collapsed” model of SAFe, the capabilities stack disappears.) However, each element is designed to provide the right surfaces for expression of behavior and testing at the various levels.
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.
Note: If the model appears complex, that’s because contemporary software and systems development at scale are complex, even with Agile methods. If it’s not needed, it need not be used. But teams and programs that are building world-class enterprise solutions of the highest possible quality probably can use most of it.
Last update: 1 November, 2015