Escolar Documentos
Profissional Documentos
Cultura Documentos
Documentation
To be honest, I'm not very enamored with the term "best practice ". I believe that the term "contextual practice" makes far more sense because what is a "best practice" in some situations proves to be a "worst practice" in others. Having said that, people are interested in best practices so here they are when it comes to agile requirements modeling:
Stakeholders actively participate Adopt inclusive models Take a breadth-first approach Model storm details just in time (JIT) Treat requirements like a prioritized stack Prefer executable requirements over static documentation Your goal is to implement requirements, not document them Recognize that you have a wide range of stakeholders Create platform independent requirements to a point Smaller is better Question traceability Explain the techniques Adopt stakeholder terminology Keep it fun Obtain management support Turn stakeholders into developers
www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
1/9
10/20/13
My philosophy is that project stakeholders should be involved with modeling and documenting their requirements, not only do they provide information but they actively do the work as well. Yes, this requires some training, mentoring, and coaching by developers but it is possible. I have seen project stakeholders model and document their requirements quite effectively in small start-up firms, large corporations, and government agencies. Ive seen it in the telecommunications industry, in the financial industry, in manufacturing, and in the military. Why is this important? Because your project stakeholders are the requirements experts. They are the ones that know what they want and they can be taught how to model and document requirements if you choose to do so. This makes sense from an agile point of view because it distributes the modeling effort to more people.
www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
2/9
10/20/13
www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
3/9
10/20/13
Of course, the challenge with such models is their impermanence. When you're a co-located or near-located team (everyone is pretty much in the same building) then it's viable to have paper-based or whiteboard based models. When your agile team is geographically distributed, finds itself addressing a complex domain, or finds itself in a regulatory compliance situation which requires more permanent artifacts, then you will need to consider capturing key information in software-based modeling tools (SBMTs) as well.
The point is that you can do a little bit of initial, high-level requirements envisioning up front early in the project to understand the overall scope of your system without having to invest in mounds of documentation. Through initial, high-level modeling you can gain the knowledge that you need to guide the project but choose to wait to act on it.
10/20/13 Agile Requirements Best Practices the top of the stack which they believe they can implement within the current iteration. Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers. If you do this then any change to a requirement youre currently implementing should be treated as just another new requirement.
It's interesting to note that lean teams are starting to take a requirements pool approach to managing requirements instead of a stack, as you see in Figure 5. Figure 5. Lean work management process.
www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
5/9
10/20/13
www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
6/9
10/20/13
10/20/13
Agile Requirements Best Practices technical complexity, or organizational complexity -- the fact is that there is often a greater need for traceability when a large team is involved because it will be difficult for a even the most experienced of team members to comprehend the detailed nuances of the solution. The implication is that you will need the type of insight provided by traceability information to effectively assess the impact of proposed changes. Note that large team size and geographic distribution have a tendency to go hand-in-hand.
4. Regulatory compliance . Sometimes you have actual regulatory compliance needs, for example the Food and Drug Administration's CFR 21 Part 11 regulations requires it, then clearly you need to conform to those regulations. In short, I question manually maintained traceability which is solely motivated by "it's a really good idea", "we need to justify the existence of people on the CCB" (it's rarely worded like that, but that's the gist of it), or "CMMI's Requirements Management process area requires it". In reality there's lots of really good ideas out there with much better ROI, surely the CCB members could find something more useful to do, and there aren't any CMMI police so don't worry about it. In short, just like any other type of work product, you should have to justify the creation of a traceability matrix . It's requirements analysis, not retentive analysis. ;-)
Active Stakeholder Participation Agile Analysis Agile Requirements Agile Requirements Change Management Best Practices for Agile/Lean Documentation The "Change Prevention" Anti-Pattern www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
Document
8/9
10/20/13
Agile Requirements Best Practices The "Change Prevention" Anti-Pattern Comparing the Various Approaches to Modeling in Software Development Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Sense Document Late: An Agile Best Practice The "Flexible Features Split" Pattern Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Iteration Modeling Look-Ahead Modeling Overcoming Common Requirements Modeling Challenges Examining the "Big Requirements Up Front (BRUF)" Approach Prioritized Requirements: An Agile Best Practice Rethinking How You View Requirements Management Rethinking the Role of Business Analysts The Unchangeable Rules of Software Change (Brad Appleton, Robert Cowham, and Steve Berczuk)
The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development. The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation. It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts. Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with. These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler. This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer). The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.
Let Us Help
We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.
www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
9/9