Add to Google
Updated Agile Requirements Metamodel (Enterprise Backlog Model)
Posted on November 29, 2010 by Dean Leffingwell in Agile and FDA, Agile Requirements, High Assurance and Regulated EnvironmentsI 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.
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”.
[...] Updated Agile Requirements Metamodel (Enterprise Backlog Model) Dieser Beitrag wurde unter Allgemein, WWW abgelegt und mit assumption, backlog, Behaviour-Driven Development, bug fixing, code review, Coding guide lines, Component-Testing, concept, Continuous Integration, enterprise, feedback, ideas, model, product owner, prototype, questions, Regression Testing, requirements, spike, status report, story points, synthesizing, Test-Driven Development, UI-Testing, Unit-Testing, User Acceptance Tests, value, Version Control, zero known defects verschlagwortet. Setze ein Lesezeichen auf den Permalink. ← Ahas on “Regression Testing with an Agile Mindset” [...]