I was walking through some blog posts in the requirements category today looking for a later version of the full “agile requirements metamodel”. (Some readers commented that “enterprise backlog model” might be a better descriptor, and I tend to agree). The model has evolved and been refined based on peer reviewer feedback (thanks Gabor and others….) of Agile Software Requirements. Evidently I didn’t track that evolution here on the blog, so here is the updated graphic of the final, (at least for this book version) full model as it will appear in the appendix of the book.
Full agile requirements metamodel (Enterprise backlog model)
Note: This metamodel is also integral to the work I’m currently doing with Craig Langenfeld on applying agile development to high assurance systems, so I’m tagging this post to that category as well.
Scaling Software Agility 
In this model, how does the system acquire the ability to pass the System Qualities tests? We all know that the non-functional capabilities have to be built in, not tested in. Perhaps the features & user stories are also constrained by non-functional requirements, and have to pass Qualities tests at their own level? Or do you have “features” and “stories” which are non-functional requirements rather than traditional features?
Hi Kathy,
In the big picture model, and in the book, I describe the fact that each backlog (at least team (user story) and program (feature) level) may have its own set of constraining NFRS. They must simply be identified and known to all affected team members as part of the requirements discovery process, as then the teams will have the opportunity and responsibility to design and build a system that conforms to them. The System Qualities Tests are used to assure that, but you can’t wait until such a test fails to “discover them”.