Agile Requirements Best Practices
Content
► UML ► Agile Model ► Agile Tools
10/20/13
Ag i le Req uir ements Best Pr acti ces
My philosophy philos ophy is that project stak stakeholde eholders rs s hould be inv involv olved ed with modeling and documenting their requirements requirements,, not only do t hey provide provide information infor mation but they actively do the work as well. Yes, t his requires some training training,, mentoring, and coaching by dev developers elopers but but it is possible. I hav have seen project stakeholders s takeholders model and document their requirements requirements quite eff effectively ectively in s mall start-up s tart-up firms, large corporations, and governmen governmentt agencies. agen cies. I’ I’v ve seen it in the telecommunications industry, in i n the finan financial cial industry, in manufacturing, manufacturing, and in the military. Why is t his important? Because your project st akeholders are the require requirements ments experts. They They are the ones that know wha whatt they want and they can be taught how to model and document document require requirements ments if y ou choose to do so. Th This is makes s ense from an ag agile ile point of view view because it distributes dis tributes t he modeling effort to more people.
2. Adopt Inclusive Models To make it easier easi er for pro project ject stakeholde stak eholders rs t o be actively involv involved ed with requireme requirements nts modeling and documentation, documentation, t o reduce the barriers to entry in Tools.. Many of the re requiremen quirements ts artifacts lis ted in Table 1 1 below can be business parlance, you want to follow the practice Use the Simplest Tools 2 and Figure 3 3 present two modeled using either simple or complex tools – a column is included to list a simple tool for each artifact. Figure 2 inclusive models inclusive models created using simple tools, Post It notes and flip chart paper was used to model the requirements for a screen/page in Figure 2 (an essential UI prototype) prototype ) and index cards were used fo forr conceptual modeling in Figure 3 3 (a CRC model model). ). Whenev Whenever er you bring bring technology into the requirements requirements m odeling effort, effort, such as a draw drawing ing tool to create “clean†v versions ersions of use c ase diagrams or a full-fledged full-fledged CASE tool, y ou make it harder for your project stakeholders to participate because they now need to not only learn the modeling techniques but also the modeling tools. By keeping it simply you encourage participation and thus increase the chances of effective collaboration. Figure 2. An essential user interface prototype.
www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
2/9
10/20/13
Ag i le Req uir ements Best Pr acti ces
Figure 3. Two CRC cards.
www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
3/9
10/20/13
Ag i le Req uir ements Best Practices
Of course, the challenge with such models is t heir impermanence. impermanence. When you're a co-located o orr near near-located -located team (ev (everyone eryone is pretty much in i n the distributed ed,, finds itself same building) buildi ng) then it's viable to have have paper-based paper-based or whiteboard whiteboard based models. When your agile team is geographically distribut addressing a comp addressing complex lex domain domain,, or finds itself in a regulatory compliance compliance situation which requires more permanent artifacts, then you will need to consider capturing key information in software-based modeling tools (SBMTs) (SBMTs) as well.
3. Take a Breadth-First Approach Approach My experience is that it is better to paint a wide swath at first, first, to try to get a feel for the bigger picture, than it is to narrowly focus on one small aspect of your sys tem. By t aking a bread breadth-first th-first approach approach you quick quickly ly gain an ov overall erall unde understanding rstanding of your sy system stem and can still sti ll dive into the details details when appropriate. invest significant t ime Many organizations prefer a "big " big modeling up front (BMUF)" (BMUF)" approach to modeling where you invest gathering and documenting requiremen gathering requirements ts early in the project, rev review iew the requirements, accept ac cept and then baseline them bef before ore implementation commences. This This sounds like lik e a g great reat idea idea,, in theory, but the reality is t hat this approach approach is spect acularly ineffective. ineff ective. A 2001 study perf performed ormed by M. Thomas in the U.K. of 1,027 p projects rojects s howe howed d that scope s cope management management related to attempting waterfall practices, including detailed, up-front requirements, was cited by 82 percent of failed projects as the number one caus cause e of failure. This is backed bac ked up by other research – accordi according ng to Jim Johnson of the Standish St andish Group when requirements requ irements are specified early early in t he lifecycle t hat 80% of the ffunctionality unctionality is relatively unwan unwanted ted by the users. He reports that 45% of features features are n nev ever er used, 19% are rarely rarely used, and 16% are sometimes used. Why does this happen? Two Two reasons: When project stakeholders are told that they need to get all of their requirements down on paper early in the project, they desperately try to define as many potential requirements (things they might need but really aren't sure about right now) as they can. They know if they don't do it now then it will be too hard to get them added later becaus because e of the process s which will be put in place once the requirements document is baselined. change ma nageme nt/prevention proces Things change between the time the requirements are defined and when the software is actually delivered.
The point is that you can do a little bit of initial, high-level requirements envisioning envisioning u p front early in t he project to understand understand the overall overall s scope cope of your system sy stem without hav having ing to invest in m ounds 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.
4. Model Storm Details Just In Time (JIT) Requirements Requ irements are identified throughout throughout most of your project. Although the majority of your requ requirements irements effor efforts ts are per performe formed d at t he beginning beginning your project it is very lik likely ely that y ou will still stil l be working them just befor before e you final code ffreeze reeze bef before ore de deployment. ployment. Remember Remember the principle Embrace Change.. Agilis ts t ake an ev Change evolutionary, olutionary, iterative a and nd incremental, appr approach oach to dev development. elopment. The The implication is that you need to gather requirements requirements Parallel,, Iterate To Another Artifact, Artifact, and in exactly the same manner manner.. Luckily A AM M includes pr practic actices es such as Create Several Models in Parallel Increments which enable evolutionary modeling. Model In Small Increments
The The shorter s horter the feed feedback back cy cycle cle betwee between n model storming a requirement and implementing it, the less need there is for documenting the details.
5. Treat Requirements Like a Prioritized Stack Figure 4 requirements,, reflecting both Extreme Programming (XP)’s (XP)’s planning game and the 4 overviews the agile approach to managing requirements Scrum Scrum methodology. Your softwar software e dev developmen elopmentt team has a stack s tack of prioritized prioritized and estimated estimated r equirements equirements which needs to be iimplemented mplemented – co-located agile teams will often literally have a stack of u user ser stories written on index cards. Th The e team takes the highest priority requirements requirements from www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm 4/9
10/20/13 Ag i le Req uir ements Best Pr acti ces . current iteration it eration to prov provide ide a level of of stabili stability ty for the developers. If you do this then any change to a requirement you’re currentl currently y impl implementing ementing should be treated as jus t another new requ requirement. irement.
Figure 4. Agile requirements change change manage ment process. process.
approach to managing requirements instead of a stack, as you It's interesting to note that lean teams are starting to take a requirements pool approach see in Figure 5. 5. Figure 5. Lea n work ma nageme nt process process.
www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
5/9
10/20/13
Ag i le Req uir ements Best Pr acti ces
6. Prefer Executable Requirements R equirements Over Static Documentation Documentation During dev development it is quite common to model storm storm for several minutes and then code, following common Agile practices such as Test-First Design (TFD) (TFD) and refactoring, refactoring , for several several hours and even several several days at a ti time me to implement what y you'v ou've e just model modeled. ed. This is where your team specifications,, often customer will spend the majority majority of its t ime. Agile teams do the majority of their detailed detailed mode modeling ling in the fo form rm of exe cutable specifications tests or tests or dev development elopment tests . Why does this work? work? Because your model storming effor efforts ts enable you to think through larger larger,, cross-entity is sues whereas wher eas with TDD TDD you think through very very focused issues t ypicall ypically y pertinent to a single entity at a time. Wit h refactoring refactoring you evolv evolve e your design via via small steps to ensure that your work remains of high quality. TDD TDD promo promotes tes confirma c onfirmatory tory test ing of your a application pplication code and detailed specification of that code. Customer tests, tests , also c called alled agile acceptance tests,, can be thought of as a form of detailed requirements tests requirements and developer tests as detailed design design.. Hav Having ing tests do “d “double ouble duty†like this is information,, a practice which enables developers to travel light and reduce overall documentation. documentation. a perfect example of single sourcing information However, detailed specification is only part of the overall picture – high-level specification is also critical to your success, when it’s done effectively. This is why we need to go beyond TDD to cons consider ider AMDD.
7. Your Goal is To Effectively Implement Requirements, Not Document Them Too many projects projec ts are crushed by the overhead overhead rrequired equired to dev develop elop and maint maintain ain comprehensive comprehensi ve documentation document ation and traceabili traceability ty between it. Take an documentation and and keep it lean and effective. The most effective effect ive documentation document ation is just barely g ood e nough nough for the job at agile approach to documentation hand.. By doing this, y ou can focus more of your energy hand energy on building working software, software, and isn't that what you're really being paid to do?
The urge to write requirements documentation should be transformed into an urge to instead collaborate closely with your stakeholders and then create a consumable solution based on what they tell you.
8. Recognize That You Have a Wide Range Rang e of Stakeholders End users, either direct or indirect, aren't your only stakeholder stak eholders. s. Other stakeholders include manage managers rs of users, senior manager managers, s, operations st aff members, the "gold owner" who fu funds nds t he project, support (help desk) staff members, auditors, your progra program/portfolio m/portfolio manage manager, r, dev developers elopers working on other sys tems that integrate or interact with the one under development, development, or maintenance prof professionals essionals potentially affected by t he development development and/or deployment of a software project. To name a ffew. ew. These people ar aren't en't going to agree with one another, they're going to have have different different opinions, priorities, understandings of what they do, understandings understandings of what others do, and v visions isions for what what the sy stem s hould (or shouldn't) shouldn't) do. The implication is that you're going to need to recognize that you're in this situation and then act accordingly. Figure 6 6 shows how agile teams typically have hav e someone in a s takeholder representative representative ro role, le, this role is called product product owne r in Scrum, whom they go to as the official source of information and prioritization prioritization decisions. decis ions. Th This is works well for the dev development elopment team, but but essentiall essentially y places t he burden burden on the shoulders of this person. Anyone in this role will need to: 1. Hav Have e soli solid d business analysis analysis skills, particularly in negotiation, diplomacy, and requirements elicitation. 2. Educate the team in the complexity of their ro role. le. productt owne r s who are representing representing the stakeholder community on other dev development teams. Th This is is 3. Be prepared to work with o other ther produc particularly true at scale scale with large agile teams. 4. Recognize that they are not an expert at all aspects of the do domain. main. Theref Therefore, ore, they will need to hav have e good contacts within the st akeholder community and be prepared prepared to put the development development team in t ouch with the appropriate domain experts on an as-needed basis basis so that they can share their domain expertise with the team. Figure 6. You'll work w ith a ra nge of st stakeholders. akeholders.
www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
6/9
10/20/13
Ag i le Req uir ements Best Pr acti ces
9. Platform Independent Independent Requirements R equirements to a Point I’m a firm believer that requirements should be technology iindependent. ndependent. I cringe when I h hear ear terms suc such h as object-orient ed (OO) requirements requirements,, struct ured re requiremen quirements, ts, or componen component-based t-based requirements. requirements. The ter terms ms OO, struct ured, and compon component-based ent-based are all all c categories ategories of implementation implementation technologies, and although you may choose to constrain yourself to technology that falls within one of those categories the bottom line is that you should just be concerned about re requiremen quirements. ts. That’s That’s it, jus justt requireme requirements. nts. All of the techniques that I describe below can be used to model model the requirements for a system using any one (or more) of these categories. However, I also cringe when I hear about people talk about Platform Independent Models (PIMs), part of the doomed Model Driven Architecture (MDA) vision from (MDA) from the Object Manage Management ment Group (OMG). (OMG). Few orga organizations nizations are re ady for the MDA, MDA, so my advice is to not let the MDA foolishness foolishness distract you from becoming effective effective at requireme requirements nts modeling. Sometimes y ou must go away fro from m the ideal of identifying identifying technology-indepen technology-independent dent requirements. requirements. For example, a common constraint for most projects is to take advantage advantage of the exist ing technical infrastructure where wherev ver possible. At t his level the re requiremen quirementt is stil stilll technology independent, independent, but if you drill down into it to start listing the components of the existing infrastructure, such as your Sybase vX.Y.Z database or then need to integrate with a given given module of SAP R/3, then you'v you've e cross crossed ed the line. This This is ok okay ay as long as you know k now that you are doing so and don't don't do so ve very ry often.
10. Smaller is Better estimate and to build to than are larger Remember to think small. Smaller requir Remember requirements, ements, such suc h as fea features tures and user stories, are much e easier asier to estimate requirements, requ irements, such s uch as use c cases. ases. An av average erage use case desc ribes greater ffunctionality unctionality than the average average user story and is thus considered consi dered â prioritize and therefore manage. manage . €œlargerâ€. œlargerâ€. Th They're ey're also easier to prioritize
11. Question Traceability Think very carefully before investing in a requirements traceability matrix, or in full lifecycle traceability in general, where the traceability information is manually maintained. Traceability Traceability is the ability to relate aspects of project project artifacts to one anothe another, r, and a require requirements ments traceability matrix is the artifact that is often created to record these relations – it starts with your individual requirements and traces them through any analysis models, architecture models, design models, source code, or test cases that you maintain. My experience is that organizations with traceability cultures will often choose to update artifacts regularly, ignoring the practice Update Only When it Hurts, Hurts, so as t o achiev achieve e consist ency between the artifacts (including the matrix) that they maintain. The They y also hav have e a tendency tendency to capture c apture the same information in several places, often because they employ overly specialized people who "hand off" artifacts to other specialists in a welldefined, Tayloristic process. This is not traveling light. Often a better approach is to single source information information and to build teams of generalizing specialists.. specialists The benefits of having such a matrix is that it makes it easier to perform an impact analysis pertaining to a changed requirement because you know what aspects of your system will be potentially affected by the change. change. Howev However, er, in simple sit uations (e.g with small co-located teams addressing a fairly straightforward situation) when you have one or more people familiar with the system, then it is much easier and cheaper to simply ask them to estimate the change c hange.. Furthermo Furthermore, re, if a continuous integration strategy is in place iitt may be simple si mple enough enough to make the change and and see what you broke, if anything, anything, by rebuilding the syst em. In simple situations, which many agile teams find themselv themselves es in, my experience ex perience is that traceability matrices are highly overrated because the total cost of ownership (TCO) to maintain such matrices, even if you have specific tools to do so, far outweigh the bene benefits. fits. Make your pro project ject s takeholders awa aware re of the real costs and bene benefits fits and let them decide – – after after all, a traceability matrix is effectively effectively a document and is theref therefore ore a business business decision to be made by them. If you accept the AM principle Maximize Stakeholder ROI, ROI , if you're honest about the TCO of traceability matrices, then they often prove to be superflorous. When does maintaining traceability info i nformation rmation make sense? The quick answer is in some agility at scale scale situations and when you have proper tooling support: 1. Automated tooling support exists. exists. Some dev development elopment tools, such as those based on the Jazz platform, platform , will automatically provide most of your traceability needs as a side effect of nor normal mal dev development elopment activities. You may s till need to do a bit of extra work here and and there to achieve achiev e full traceability, but a lot of the traceability work can and should be automated. automated. Wit h automated tooling the TCO TCO of traceability drops, increasing the chance that it will provide real value to your effort. developing eloping a financial financial processing sy stem for a retail bank 2. Complex domains. domains. When you find yourself in a complex situation, perhaps you're dev or a logistics system for a manufacturer, then the need for traceability is much greater to help deal with that complexity. 3. Large teams teams or or geographically distributed distributed team s. Although team size is typically motivated by greater complexity -- domain complexity, technical complexity, or organizational complexity -- the fact is that there is often a greater need for traceability when a large team is involved www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
7/9
10/20/13
Ag i le Req uir ements Best Pr acti ces
because it will be diff difficult icult for a even even the most ex experien perienced ced of team members to comprehend the detailed nu nuances ances of the solution. The 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. compliance.. Sometimes y you ou have actual regulatory regulatory compliance needs, for e example xample the Food and Drug Administration's 4. Regulatory compliance CFR 21 Part 11 regulations 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" CCB" (it 's rarely word worded ed like that, but t hat's the gist of it), or "CMMI's Requirements Requirements Manageme Management nt process area requires requires it ". In reality reality t here's lots of really good ideas out there with muc h better ROI, surely the CCB members c could ould find something more usefu usefull t o do, and there aren't any CMMI police police s o don't worry about about it. In short, just lilike ke any other type of wor work k product, y ou should ha hav ve to justify to justify the the cre ation of a tra ceab ility matrix.. matrix
It's requirements analysis, not retentive retentive analysis analysis.. ;-)
12. Explain the Techniques Everyone should have have a basic understandi understanding ng of a modeling technique, inc luding your project stak s takeholders. eholders. They’ve They’ve nev never er seen CRC CRC cards bef before? ore? Take Take a few minutes to explain what they are, why you are using them, and how how to create them. You cannot follow the p practic ractice e Active Stakeholder Participation Participationi f y your our stakeholders are unable to work with t he appropriate appropriate modeling techniques.
13. Adopt Stakeholder Terminology Do not not force artificial, tec technical hnical jargon on onto to your project stak eholde eholders. rs. Th They ey are the ones that the sys tem is being bu built ilt for, therefore, therefore, it is their terminology that you should use to model the syst em. As Constantine and Lockwood Lockwood say, avoid geek-speak. geek-speak. An important artifact artifact on many projects is a concise glossary glossary of business terms.
14. Keep it Fun Modeling doesn’t have to be an arduous task . In fact fact,, you can always have fun doing it. Tell a few jokes , and keep your modeling efforts light. People will have a better time and will be more productive in a “fun†environment.
15. Obtain Obtain Management Support Supp ort Investing the effort to model requirements, and in particular applying agile us usage-centered age-centered de sign techniques, techniques, are new concepts to many organizations. orga nizations. An important is issue sue is that your project s takeholders are actively inv involv olved ed in the modeling ef effort, fort, a fundamental fundamental culture change for most organizations. As with any culture change, without without the suppo support rt of senior mana management gement you likely will not be succ essful. You will need need support support from from both the managers within y ou IS (information (information sy stem) department and within the us user er area area..
16. Turn Stakeholders Into Developers An implic ation of this approach is that your project st akeholders akeholders are learning fundamen fundamental tal development development skills skil ls when they are activ acti vely inv i nvolv olved ed with a software project. It is quite common to s ee users make the jump from from the business world to the technical technic al world by first becoming a business analyst and then learning further analyst further development development skills skil ls to eve eventually ntually become a full-fledged full-fledged dev developer eloper.. My expectation is that because agile s oftware oftware development efforts have a greater emphasis on stakeholder involvement than previous software development philosophies we will see this phenomena phen omena occur more often – keep a look out for pe people ople wishing to make mak e this transition and help to nurture their budding budding dev development elopment skills. ski lls. You never know, maybe some day someone will help nurture your business skills and help you to make the jump out of the technical world.
17. Recommended Resources
Act Active ive S takeholder Pa rtic rticipation ipation Agile Analysis Agile Requirements Agile Requirements Change Management Best Practices for Agile/Lean Documentation The "Ch "Change ange Prevention" Anti-Pattern Anti-Pattern www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
8/9
10/20/13
Ag i le Req uir ements Best Pr acti ces
Comparing the Various Approaches Approaches to to Modeling i n Software Development Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Se ns nse e Document Late: An Agile Best Practice The "Flexible Features Split" Pattern Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Iteration Modeling
ocumen Management Guide www.Laserfiche.com
This Free Overview Helpss You Learn Help Document Management Basics. Basics.
Look-Ahead LookAhead Model ing Overcoming Overco ming Common Requireme nts Modeling Challe nges 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 Business Analysts Analysts The Unchangeable Rules of Software Change Change (Brad Appleton, Robert Cowham, and Steve Berczuk)
The Object Prime r 3rd Edition: Edition: Agile Model Driv Driven en Developme nt with UML 2 2 is an important reference book for agile models including all 13 UML 2 diagrams. diagrams. Furthermo Furthermore, re, this b book ook modelers, describing how to develop 35 types of agile models (FLOOT) methodology to give you the describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) fundamental fundamental testing s skills kills which you require to succ succeed eed at agile software dev development. elopment. The book book also s hows how to move move from your agile models to source code (Java (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring refactoring and test-driven development (TDD). (TDD). The Object Primer also includes a chapter refactoring ing,, object/relational mapping mapping,, legacy overviewing the critical database development techniques (database (database refactor acc ess coding) from from my award-winn award-winning ing Agile Database Techniques analysis,, and database access analysis Techniques book.
Effective Practices for Agile Modeling: Effective for Extreme Programming a nd the Unified Proces Process s is the seminal book documentation.. It describes describes principles and practices describing how agile software developers approach modeling modeling and documentation XP,, the Rational Unified Process (RUP) (RUP),, or the Agile which you can tailor into your existing software process, such as XP Unified Process (AUP) (AUP),, to streamline your modeling and do documentation cumentation eff efforts. orts. Modeling and d documentation ocumentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements,, architect, requirements architect, and then design design your system in an agile manner.
The Elements of UML 2.0 Style guidelines for creating effective Style describes a collection of standards, conventions, and guidelines UML diagrams. diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand unde rstand and work work with. Th These ese conventions conventions exist as a collect ion of simple, concise c oncise guidelines that if applied applied consistently, consis tently, repre represent sent an important first first s tep in increasing your p productiv roductivity ity as a modeler. modeler. This This book is oriented toward towards s intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way way t o learn the UML (instead, c onsider 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. trainer. A full description of what what we do, and ho how w to contact us , can be foun found d at Scott W. Ambler + Associates. Associates.
Copyright © 2001-2012 Scott W. Ambler
www.ag il emodel i ng .com/essays/ag i l eR eq ui r ementsBestPr acti ces.htm
This site owned by Ambysoft Inc.
9/9
