MB, ’ International Institute of Business Analysis A Guide io ts} Business Analysis Body of Knowledge (BABOK Guide) Version 2.0NBA International Institute of Business Analysis a A Guide to the Business Analysis Body of Knowledge’ (BABORK’ Guide) Version 2.0ternational Institute ef Business Analysis, Toronto, Ontar, Canada, 1200, 2006, 2008, 2009, International Institute of usines Analysis, All rights reserved, Portlons of Appendix A: Glassary are foam The Software Reuiromenes Memory Jogger: by Ellen 105 GOAL/OPC and are used with permission Gottesdiener exslon 10 and 1 published 2005, Version L6 Draft published 2006. i Jhed 2008. Voesion 2.0 published 2000, son 1.6 Final pub ISBN-13:978-0-9811292. print) ISBN-15:978-0-9811292-2-8 (PDF and EBook) This document is provided tothe business analysis comunity for educational purposes. IBA {does not warrant that i issuilable forany other pucpose ane makes nu expressed or implied ‘warranty of any kind and assumes no responsibility for errors or emissions, No liability is ‘sumed for incidental or consequential damages in connection with or arising out ofthe use of the information contained herein. TBA’, tho TBA logo, BABOK’ and Business Analysis Body af Knovled are registered trade matks owned by Interaatianal Instat af Business Analysis, CBAP" isa registered cortiieatlon mark owned by Tnternational Institute of Business Analysis. Cee Professional, EEP. anid the EP logo a Analysis. led Business Analysis 0 eadlomarks owned by International Institute of Business CMMI" is « cegistored trademark of Carnogie Mellon University ITIL" isa registered trademark ofthe Office of Government Commerce Inthe United Kingelom fand other esunteies, PMI and PMBOK are registered trademarks ofthe Project Management Institute, ine, winich are registered in the United States of America and other nations, TOGAF” is atrademark of The Open Group in the US and other countries ‘Zachman Framework for Enterprise Architecture” isa trademark of the Zachman Institute for Framework Advancentent No challenge tothe status or ownership nftheso or any ather trademarked terms contained heroin is intended by International Institute of Businoss Analysis Any inquires regacding this publication, requests for usage tights forthe material included herein, or coreections should be sent by email to bokgetheiiba.oeg oF mailed tr Professional Development International Institute of Business Analysis 250 Consumers Road, Suite 301 Toronto, Ontario, Canad My avebeeen icy | 1.1__What isthe Business Analysis Body of Knowledge? 12 What ie Business Analy? 13 Key Concepts 1.4 Knowledge Ar 5__Taks | 18 Techniques 17__Undstving Competencies 18 Other Sources of Business Analysis nformation BRB meee 21 Plan Business Analysis Approach 2.2 Conduct Stakeholder Analysis 2.3 Plan Businese Analyse Activities 24 Plan Business Analysis Communication 25 Plan Requirements Management Process 26 Manage Business Analysis Performance BEREER |1__ Prepare for lctation 32 Conduct Bictation Activity 33__Document Fictation Resulls 34 Confer Blitation Beste PBEM 41 Manage Solution Scope & Requirements 42 Manage Requirements Taceabilty 43 Maingsn Requirements for Re-use 44 Prepere equirements Package 45 Communicate Requirements bReeRB S1__Define tusiness Need, 52 Assess Capability Gaps 5.3 Determine Solution Aporoach 5:4 Define Solution Scope 55__Define Business Case a88555555 ‘Chapter 6: Requirements Analysis 0 61 Prioritize Requirements 9 52__Drganve Requirements 103 63 Specify and Model Requirements 107 64 Define Assumptions and Constraints am 55 __Vetfy Requirements 1, {56 Volcate Requirements Ww ‘chapter 7: Solution Assessment & Validation _____ an 7 hates Proposed Solution aa 12 Allocate Requiements a4 15 Asses Organizational Readiness oa 2A Define Transition Requirements "31 75__alicateSoltion 25 _—_fvaluste Solution Pesfrmance ‘Ghapter 8: Underlying Competencies at &1_ Analytical Thinking and Problem Solving ul 82__Behavbral Characteristics 3 Business Knowledge as, Ad Communications 85 Interaction Selb 85 __ Software Appletions| 182 ‘Ghapter 9: Techniques SS S1__Aeceptance and Evaluation Criteria Definition 155 92_Benchmarking 156 34 alnstorming 1s 94 Business Rules Analysis 158 25 Data Dictionary and Glossary 160 836 Data Flow Diagrams “61 82 Data Modeling 162 28 Decision Anais. 156 29 Document Anais 168 910—Estimation 911 Foeus Groups 1m ‘212 Functional Decomposition a 913 Interface Analysis 76 9a lnnewviews 95 _Lessonsleamed Process 16 Metrics and Key Performance Indicators 1 817 Nonfunctional Requirements Analysis 181 ayrighted material‘Observation rgarization Modeling Problem Tracking | Process Modeling Prototyping equiremente Workshops Fk Anais oot Cause Analysis “Scenarios and Use Cases scope Modeling Sequence Dagrams State Diagrams Srctured Wallthrough Survey/Questionnaire SOT Analysis User Stoxies Vendor Assessment BEBEEREREBERREREBE BEREERBRERBERBEBER | D2 Enterprise Anabse 249 3 Requirements Planning and Management 250 Da Requirements Eitan 251 DS Requirements Ansiyss and Danumention 251 D6 Requirements Communication 253 DZ Solution AssessmentandValiaion 3 Underlying Fundamentals 252 ayrighted materialCopyrighted materialre) ‘MB was founded in Toronto, Canad in Detober of 2003 to support the business analy- siseommamity by + Creatingand developing awareness and recognition ofthe wise and eonteihation ofthe Business Analyst. > Detiningthe tusness Analysis Rod of Keowee” (BABOK). and contribution tothe business Providing. fous foe knowledge shat profession. > Publity recognizing and certifying qualified practitioners through an internation: ally acknowledged ewetltication progea ‘The Body of Knowledge Committee was formed in October of 2004 to define and draft global sandard forthe practice of business analysis. in Jaruary of 2005, IBA released ‘otson Lilof A Gide ome tunes Anaya Bady of Knowledge’ HABOS Guide) for feedback and comment, That versun inchded an outline of the proposed content and some key definitions, Version Io was released in October of 2005 with deaf content 1 some knowledge areas, Version 16, which included detailed information regarding ros of the knowledge areas was published in draft fore n June of 2006 and updated terincorporateceratain Octuber of 008, “he publication supersedes Gude to the Business Analysis Body of Knowledge’ Vorsion 16. Following the publieation of version 1.5, LISA" sought out a numberof recognized exportsin business unelysis and relate fields and solicited thet fodback onthe eon: tent of that edition Thee comments were used to plan the scope ofthis eviaon IBN" ‘oluntoors then worked to delinea structure ur version 2.0 and developed the revised text, which was made avallableto the business analysis community fr review in 2008, During tht exposure period IRN” also solicited feedback from industry expestsund business analysis practitioners hromgh a formal review process IBA’ receved thou sands of comments during this process, and this document hasbeen vised to incor porate as many af those comments as posable The BABOK" Guide contsinn a description of generally accepted practices i the fed of business analysis The content inckided in this release hasbeen verificdtheotgh reviews by pratiio tions with reengnized experts inthe Feld. The data availaeto IA" demonstrate hat the Lasks an Lechnigues described inthis publication are ia use by majorly of business analsis practitioners. Asa test, we can have ennfidence tha the tasks and Aechagues described in the ZABOK' Guide should be applicable in me contents where bbsines analysis is performed, most the time 4 eurveys ofthe business analyse commit. and comulla- The #ABOK™ Guide should not be construed to mandate thatthe prnctiocs deseribed in {his publleston shouldbe followed under allcieunnstanices. Ang at of prac be tallored tothe specific conditions under which business analysis is beng performed audition, practices which are not geneally accepted by the business analyxs com inanity a the time publication may be cally eective, or mare eectve han thepractices described inthe BABOK” Guide Assuch practices become gonerally accepted, ‘data Is collected to very thelr effetiveness. they will be IneorPoated nto fu ture ations ofthis publication IBA encouragosall practitioners of business analysis tobe apen to new approaches and new ideas. and wishes 1 enenirage innovation in the practice ofbusiness analysts “The goal ofthis ovldon was > Complete the description ofa knowledge ateas 1 Simplify hestructue ta make it easier to understand a J apply > Tinprovethe consistency and quality of ext and illustrations, > Integrate he knowledge atcas and eliminate areasoF overlap > Innprome consistency with ler generally cepa standard relating to the pra ticeot business anal Extend the coverage ofthe #4H0%° Guide to deseribe business analyssin contexts Desordtadtlonal approaches to custom software application devclopenent, i ‘luding but not limited to agile methodologies Business Process Management and ‘commetcaot-te-shll (COTS) appliationsesessen ad implementation Clarify the relationship betwen business analysis and other disciplines. pac Jarl projet management, testing, and usability and information architecture Focus om the practice ofbusiness analyss Inthe context ofthe individual aiative with matceal on stratgic arenterprive wide business analy sepaated for incl son ina future pplication extension, ‘The major changesin this reas include Changes throughout to addres the gals described above. > Allcontent has been revised and etd, snd much oft has been rewelten, > Many ofthe asks found in version Ls have beon consolidate, resulting in a reduc > Tasksinthe Reguremcnds Planning and Manageoient Kaowldge Arca hav been reallocated to Buxiness Analysis Panning and Monitorigand Requirements Ma ‘agement and Communication. > Thceothor knowledgesreashave boon renamed tohetter reflect their punpose » Techaiques apply actoss muttiple Knowledge Ateas, > Inputs and Outputs have been defined fr alltashs [MBA wold ke to oxtend its thanks and the thanks ofthe business analysis communi ty toall those who volunteered Hii ime and elo tothe development this revision, ss woll as those wit provided informal fecdback tous nother ways. (i ete ins Aina ad of airedChapter 1: Introduction 11 12 Whats the Business Analysis Body of Knowledge? A Gut tothe Busines Amalsts Body of Kromfedge(BABOK” Gate) sa globally recog: ‘ved standard for the practice ofbusiness analysis, The BABOK" Guide describes bs ‘ess analysts areas of knowledge, thet assoclted activites and tasks, and the sills rnecensary o be effective inthe exceatinn ‘The primary purpose of the BABOK” Guide is wo define the peofession of busines anal six Itserves as aasline that practitioners can agree upon inorder to discuss the work they do and to ensure that they have the skils thes need 0 efectvely pertoem the role tnd defines the skills and knowledge that people who work with and employ business analysts slould expeet a sila practitioner to demonstrate Its a framework that dleserines the business analysis tasks that must be performed in onder to understand how a solution wil deliver value to thesponsoring organ ation. The form those tasks take the order they are performed in, the relative importance af the tasks and other things mas vury-but exeh task conteibutes in some fasion, dteetly ce indices to that overall gpl “hs chapter provides an introduction to key concepts Inthe fll of business analysis and deseribes the stuctare ofthe remainder ofthe HAOK” Guide. Chaplets? through 7Tefine the tasks that a busiaess analyst must be capable of performing, Chapter Aeserihes the competencies that support he effective performance ofbusiness nays, and Chapters deseribes a number af generally accepted techniques that support the praetie nfbusinest analy What is Business Analysis? Business analysis ts the goto tasks and techniques used to work as Halson among slaksholdersin order to understand thestructre, policies, and operations ofan orga nization, ond ro cocomencnd solutions that enable the organization to achive ts gals Business analysis tovolves understanding how organizations fanetion to accomplish their purposes. and defining the capabilities an organization requires to provide prod tucts and sereicesto external stakeholders Incest definition of organizational 00s how those goals conncet to specie objectives determining the courses of action that anorganiraton has to undertake to achieve those goalsand objectives, and def inghov the various orgenizational uails and stakeholders within and outside ofthat, foxgantzation interact [Business analysis may be performed to understand the eurent tate of an organization ot toserve asa bass fr the later klonifieation of business needs most casos, however business analysis is perlormed to define and validate soltions that meet business neds goal abjetves Business analysts must analyze and synthesize information provided by a large nun ber of pecplewho interact with thebusoess such as customers. stall. press alan excentives The hisiness analyst is responsible for elicitingthe actual noeds of Sasholders ot slply thei expressed desires. In many eases, the busiaess analystcre se will lgo work to facltate communication between organizational uals In particular business analysts often playa entea! sole ialigning the news of businessunits with thecapabilites deliver by Information techoology. and may serve w3a"translator™ between those soups, [A businese analysts any person who performs business analysis activities, no mat ter what thelr job title or organioatonerolemaybe, Busines: analysts practitioners nce not only peuple with the job title of business analyst, bul may also ila basins systems analysts, systems analyte, requirements cnlacers process analysts, praduct managers, product owners enterprisednalysts, busines architects, manage ‘mont constants or any other person who performs the tasks described inthe #AROR Grid, ialading thoxe who also perfor relate disciplines sich as project manage ‘ment, software development quality assurance, and interaction design. 13 Key Concepts 131 Domains A domainis he area undergsing nays 1 may corespond to thebondares ofa cvganiatonooraniatona nay wl ay eaksde outa those boundae 132 Solutions A solution sa set ofchonges tothe curent state af an organization tht ae made in ‘order to enable that organization ta meet x business eed, solv problem, or take ad- ‘untage ofan opportunity. The seope of The solution s usually narraser than thescope of the domnaia within which tis implemented, and willserveasthe basi fo the seope fof projet to implement fat sition o its components Mos solutions area system offateracting solution componentsyeach af which are po {entally solutions in thelr owa righ, Examples ofsokitons and olution enniponetts inchidewttware applications, web services, business processes, the business ules that ‘govern that process an Information technology application, «revised organizational Siructure outsourcing, imourcing, edefining jb ley ar anyother method of erea- Inga capabilty needed byan organization. Hstness analysts helps organtrations define the optimal solution forthe nds, gen these of constraints (including ime, budget, regulations ane thers) under which that organization operates. 133 Requirements A requirement i 1A condition or capabity neds by a stakeholder to soleea prablem or achieve an ‘objective 2. Acondition or capability that must he met or possessed by olton a scltion alt salisly a contract, standard, specification, cr other femally mnposed Timed ov BE 12-4950 Stn sr Sir age mang | Ta aR A aESete ii fo or eapabilty asin (1) 0 (2, S.A dheumented representation ofa cond led hy thi definition « equltement may he wastated pled hyo derived {row other requirements, or directly stated and managed One ol the key objectives of business analysis to ensure that requirements ar vist to and understood by all stakeholders the term "requirement is une that generates aloo discussion within the business analy comunity. Many of these debates focus on what should should not be ‘considered a cequirement. and what ae the necessary charueturstes ofa regucement. When reading the HAND Gide, howver, it is ial ht requirement” be understood Inthe broadest possiblesonse. Requirernunts inlude but arc not limited to, past. pres sand future conditions or eapabilitesin an enterprise and descriptions of opaniea- structures, roles, processes, poieles rues, and information systems. A rege nt may describe the eurrent or The future state of any aspect of the enterptae ‘Much of the existing erature on business analyse writin with the assumption that quirements onl describe an information technology system that isbeing considered for implementation. Other detiaitons may include fuse state busines Fusctons as ‘wel, oF restrict the meaning of he term to define the ens stakchoers are seins fschleveand aot the meansby which those ends are achieved. While all ofthese fer. fetuses of the torn are reasonable and defensible. nd the NAAR” Gudea of the ters includes those meatings they are sigallieanlly natrower than the way the trans od here Smilaly,wedo aot assume that requirementsare analyzed at any particular leva of ‘otal other than to say that they should he asaossedto whatever level of depth ince ‘ssicy for understanding and action, Ia the contest ofa Business Process Management Initiative the requlroments may be a description a the business prncesses currently in nen am organization. On other project, the husiness analyst may choose to develop requirements todeserine the curtent state ofthe enterprise which isin elf seating {oexsting or past business noeds) before investigation changes to that solution needed tomect changing business conditions, 1 Requirements Classification Scherne For the purposes ofthe BAFOK” Gude. Ue following classeation scheme s used to deserine requirements > Business Requirements arc higher-Lvel statements the goals objectives or rnoeds ofthe enterprise. They describe the reasons why a project has been iitated te objetives thatthe project will aeblve, and the metrics that willie use to renste its success. hisiness requirements describe noeds ofthe onganiration as {whole and not groups or stakeholders within Tey ave developed and defined theongh enterprise analy > Stakeholder Requirementsate statements ofthe nesdsof particule stake holler or lassof stakeholders. They describe the needs that given stakeholder has And how that stakeholder williteract witha soliton. Stakeholder requirements serve as a ride between business requitements anil the varios elas of soliton requirements, Iney are developed ad defined Ureugh requirements anabss a aD Eascer se > Solution Requirements describe the charectrttis of solution that meet bust ross equieements and staichoder requirements, They are desrleped and defined thcough requirements anaiyt, They ane Srequently divided lnto sub-categories, particularly when the requirments describe a software solutions 2 Functional Requirements describe the behavior and information thatthe sohtion will mange Thy describe capabilites the system willbe able ta Perform in terms of behvors or operations—specific information technology pplication actions of responses. ements capture conditions that donot directly relale tothe behavior of furetionality ofthe solution, but eather describ environ al conditions ualer which the solution must temain effective or qualities that che systems must have. They re alse known ws quality or supplementary requirements. These can include requirements relate to capacity speed, sec Fy, availability andthe information architevtutcand presentation uf the user inteoface > Transition Requirements doscttbecapabiltics that thesolution must haven “rer to flit transition from the eurrent state nftheenterprisc toa desired future state, but that will not be needed once that transition s complete. Tey are Ataskaccomplishese result in am output that creates valuct the sponsoring ‘organization~that i Ia task s performed It should produce some demonstrable positive outcome which is useful, specific visibleand measurable > Atuskis completo—in principle, successor tasks thal make use of outputs shou boahlete be performed by a diferent person o gran. > Atustisa necessary putt o the purpae othe Knowledge Area with which ts associated “The RAO” Gude doesnot prescribe a processor an order in which tasks are pee forined. Some ordering of asks's me itable, as cer ain tasks produce ouput fre required inputs for other tasks However is important to keep in mid thatthe 'BABOK*Guide only eescribesthal the Input must exist. The input may be Hpcomplete for subject to change and revision, whieh may eause the task toe performed rate tins. erative orale lees cles may require Unt tasks in all knowledge areas be performed in parallel and ieeyees wth clearly defined phases il sil require tasks — Ta aR A aESete i from multiple kunwedgeaccas te performed in every pase. Tasks nay be por formed inany order, aslong asthe neeessasy inputs toa task are present the deseription ofa task explinsin greater detailwhy the task is performed, what the taskasand the results the ask should aevonnplsh 153 Input 1 Input sopresents the information and preconditions noeissary For atask to begin, Inpatsmaybe Explicit generated outside the seope of business analysis zs construetion of u softwareappieation) > Generated by business analy task ‘Thece so assumption thatthe presence ofan input or an output means thatthe asso cited dfiverablecompletcor i it final sat, The input only nce to he stent ‘easplete to allow sueeessive work to begin. Any aumberofnstances of aa input may cvist diring the fveycle ofan initiative Figere 1-2: Tock nputvOutpr Diagrams InputjOutput D A P| Exemaly —_Prodacedbya —Producedby Produced Task|see task) Multiple Taste ‘Tasks and Knowiedge Areas i xy i Task external i i (with Section 1 Requirements Roquirements ace special ease asa input oe output, which should note suepesing sven theirimportance to business analysis, Ihey are the only input or output that ‘at produced by a single task. Roquierments can be classfed ina numberof df ‘ways and existin any af nuntber a different states. When fisted asa input or otpat inthissection of the task, the follow1ng format willie used to indicate the asf tioa and state ofa requioment or set of requirements: lasslication Requirements [State or States] Ino clasilication orstates are listed, say or al equlzements maybe used asan input o outpt or example, Requirements {stated] meses thatthe requirement may huve any clutsifiction, whereas Business a aD EsTass EE oquirements would meen that the businossrequicemeats may be i any posable state eg erited, prioritized, sated, or combinations thereat), States nay also be combined in some eases, For example, Requirements [Priritized ‘and Verified shout he read to inde thatthe reqtemeats have been both pion Aived and verified Res nll means thatthe requires ments may be prioritized, serie, or hath In general text the state wll be writen is fllowed by the classification (eg, tated requirements, verified business requirement, ete] Again ifn state oF casseaton leindicated, i means tha te requltement nol eesrcted to any parlculae sale or classification, 154 Elements "he formal end structure ofthis section is unique to each task The elements setion Aeserinos key concepts that are necded to understand how to perfarm the task. 155 Techniques ack task contains listing of relevant techniques Some techniques arespeciic to the performance of single fask, while others are relevant to the performance o lage ‘number of tasks (and are listed in Chapter 9), 1a particular ask ean use both kinds fftechaigaes, the ones und in Chaplet 9 willbe sted ander ane eal Techniques” subsection there are no subsceions, then ll techniques may be found im Chapter For ational information, see Heche (2 156 Stakeholders Fact 1s includes listing of gener stakeholders who are kel t participate tn the execution ofthat task or who will be alfected byt A genericsLakehokler represents ‘ass of people tha the hsness analyst i ike te ameraet with na specific way. the ‘BABOK" Gate does not mandate that these cokes be filled for any given initiative. Any Sakcholder ean hea sure af equitements assumptions. or constants This it sot intended to bean exhaustive i of all posible sakeholder classifica ons, ast would simply ot be possible compile sch isting Some additional amples af pple who fi into exch af these eneric ole are irked im Figure Fd ln ‘most cases there will bomultiplestakobolder ros found within euch eategory Sim lary a single individual may fill mare Una one foe 1 Business Analyst ly definition, the husiness analyst isa stakeholder in al business analysis activites, "The 2ABON" Gude is writen with the presumption tha the business analysis respon ‘ileal accountable for th execution ofthese activities. n samme cases the business analyst may alsobe responsible forthe perfarmanee of atiites hat fall under unother Stakeholder role. The most common roles to be wssgied to Business analyst, in addi 1 the busines analysis role ave the Doma Subject Matter Expert, plement ion Subject Matter Expert. Project Manager and Tester. iidance on performing these auddiional ols falls outside the seape ofthe BABOK” Guide, as these res are Hot par ofthe discipline of business analysis | Ta aR A aEThats xaplesf ene Staehalders EE Earns Business Analyst | Business Systems Analyst, Systems Analyst, Process Analyst, Consultant, Product Owes Customer, Segmented by market, geography, industry et Domain SME Broken out by organizational unit job rele et End User Broken out by rgantzational un, Job rele et. Traplementation SME | Project Librarian, Change Manager, Configuration Manager, Solution Architect, Developer, DBA, Information Architect, Usabitty Analyst Talner, Organiearional Change Consul rant et ‘Operational Support _ | Help Desk, Network Technicians flease Manager Project Manager| Scrum Master Team Leader Supalie, Providers, Consultants, ee Tester ‘ualty Assurance Analyst Regulator Government, Regulatory Bodies Auditors Sponsor Monegers, Executes, Product Manages, Process Owners 2 Customer customer isa stakeholder outside the boundary ofa sven exganleation or oxganiea nal unit Customers make use of praducts of services prociced by the arganivation ‘and ay have contractual or aioral ights that the organiatian is 3 Domain Subject Matter Expert (SME) {Adomin subject matter expert is any iadividual with in-depth knowledge of «topic televant tothe busines need or solionseope. This role selon filed by people wha willalso be end users or people wih willbe Indirect usersof ‘gers, process ow ners legal sta Gabo may act as prries for Hegulaters) constant, tnd others soliton. such as man 4 End Ulcer End users ate stakeholders who wil directly interact with the solution. Ihe term is :mostfrequeatly used ina software development context, wher=end usersare those ‘who will actualy se the software applieation that s beng developed, bat in the broader context ofa solution they can inelade al participants ina business process. 5 Implementation Subject Matter Expert (SME) Implementation subject matter experts are responsible foe designing ond implement: {ng potential soltions Ine implementation subject matter experts will provide spe- cinlst expertise an the design and construction ofthe soltion components tat fall ‘outside the scope ofbusiness anelsss. ‘While itisnot posibc to detine a sting oFlmplementatlon subject matterexpert cols hat sappropeiate forall initiatives, some f the most comnon roles ae DevelopersSoftware Engineers Developers are responsible forthe construction ofsaftware applications. Areas of a aD asexpertise among developers or software engineers include particular languages or ap [lication components, Good sofware develapment practices will iificantlyrdhce thecoat to bull a application the predictability ofthe development pet bility sesand the implement changes in the functionality sapported by an application. Organizational Change Management Professionals Organizational change manageame ‘explance and adoption of new solitons and overcoming resistance tw change. Areas fof expertise among change management professionals ined industry and cultural ‘expertise, Good change management ean help to ereate advocates for change within aa organization profesional ae responsible for felting ac- system Architects System architcets are responsible for diving software application ito components and defining the Interacts between them Areas of expertise among system acl tects inchide understanding of methodologies and of sation oer by specific ven dors: Good system architecture wil facta rapid development of sluts aad reuse of components in other solutions. Trainers ate responsible for ensurigthal the end users asain understand haw ‘s supposed to work and are able louse it effectively Areas of expertise amonatrainers ‘may lncude classroam-based or online education. Perio taining wil facta ae explance and adoption of solution. Usabily Professionals Usabilily professionals ae tesponsible for Une enkernal interaction design of technakgy slutions nd for making thoss solutions as smpleto uso esis feunble, Areas of expo Je among wsability professionals include user interlace designers and information srchitects Good usability wll nerease pendactivity customer satisfaction, and reduce fist in solution maintenance a taining 6 Project Manager Projet managers areesponsible fr managiag the work requited to delve a soatio that meets a business aced and for eneuring that tbe projets objectives are met wile balancing he project constraints incudingseape, budget, schedule, resources quality tisk and others 2 Tester Testersare responsible ede -mlnlog how to very that the solution meets the solu- tion roguiements defined by thebusiness analyst. os well as condacting Ve verifies process, Teters also seek to ensure that the solulon ieots applicable qually standardsand that the risk of efecs of fics sunderstood endl minimired. B Regulator Nogulators ace responsible forthe dofiition and enforeoment of standards. Standards nay be those that the tearm developing the solutions required to fallow standards the Satin must moet ltars may enforce letslation. corporate goveraneo Standards, audit sandards, o standards defined by organizational centers of compe (i ete ins Aina ad of aireda Tear 9 Sponsor Sponsors areresponsible for initiating the efor to define a business need and develop ‘saluton that meets that weed. They authorize work tobe performed and control The budget for theinitiative 40 Supplier Asuppllerisa stakcholder outside the Boundary ofa given organization oo tional unit Sapper provide praduersor service sta the organization and may hak ‘contractual or moralrights an obligations that must be considered, 1ST Output ‘An output is. necessary reaull ofthe work dectihed in the task. Outputs ate created, unsformod or change state as result ofthe successful completion of task, Although particular output is ereated snd maintained bya single tash task an have multiple ouput An output may bea deliverable ore a pat ofa argc deliverable The form ofan out ‘put ls dopendeat oa the rype of inialive underway, standards adopted byte organiza- tion, and hest judgment of the business analyst as oan appropriate way toaddress the Informathon needs of key stakeholders, As with inputs. an instanceof ask maybe completed without sn output eing iis inalstate The input oF entpit ly needs tobe siicenty compte to alew succes sive work to begin, Similarly, there may bo onc ot many instances ofan output ereated 2s parcof any given initiative. Finals the creation of an opt des not necessarily feqite that subsequent tasks whieh use that work product a int must ogi 16 Techniques Thus provide addins iforation on dren waystat task nay be pe ieemed or diferent forms he utp othe ack may ake Atay hee. on oF thor ltl ectskucn tech munt be aaed oa aston ac “The #40" Guide doesnot preserio a set of analysis rchniquos that must be used. The techniques described in this document ae those tht aye heen demanstented to be ofvalue and in use bya majority ofthe business analyas community. Business ana Iyate who are familiar wit these techoiquesare therefore likely tobe able tn perform teocisoly under most circumstances tha they ae kay to encauster. However. howe techniques are nol necessarily the best possible anes ase in any given siaaion, nor are they necessarily able to address evory situation effetvely. Salary ts unlikely that abusiness analyst wil beclledon to demonstcate expertise wi defined inthe RABON Gude every technique A subset of the techaiues in the HABOK "Guide can be described as being in wide spread use These todhniquesarcin regula use by a majority of business analysts and seececasional useby the vast majority of practitioners and its kel that many if not nost organizations will expect business analysts to have working Knowledge of these techniques he techniques hat fall nto thiscategory arc: a aD as164 16.2 163 > Avceptaneo and Evaluation Caterla eslltion 8.1) > Rrainstorming 02) > Dasinens les Alyn 8) > Date Dietionary and Glossary (85) > Date Plow Diagrams (96) > Data Modeling 7) Decision Analysis (8.8) » Document Analysis 9) > Interviews (2.18) Metrics and Key Porformance Indicators (816) > Non-unetional Requirements Analysts (0.47) > Orpanization Mosdling (19) Problem Tracking 20) > Process Modelling (2.21) > Requirements Workshops (9.2) > Seenarias and Use Cases (25) ‘The BABOK” Gude may In some eases group sll techniques or tehnigues that shareasingle purpose, inder a single heading. For example, the Data Nodebng (3.7) techaique covers class models and entityr lationship diagrams and couldn priacple cover eancep maps term and fact models. object role models, and ather less widely sudopted analysis techniques, ack technique in the BABOK” Gade is presented in the following forms Purpose Dofus what the techniques used fr, and theclreumstanees under whiel ts. most Ike to beappicable. Description Descelibes what the technique sau how is used. Elements ‘Tae format and steueture of ts section fs unigue to ach fechgue. The elements 8e- tion describes ky eoncepts that ate nese to understand hen to use the re Agile Development > Business ntelligence > Thusiness Process Management > Dusiness les > Decision Analysis and Game Theory Enterprise Architecture including the Zachman Framework for Entec prise Archi tecture” and TOGAL”) > Govornancennd Compliance Frameworks inluling Sarbanes-Oxley, BASEL. Il and others ois lee Management (cluding ITIL) > Lean ond Six‘igma > Organizational Change Manageenent > Projet Management > Quality Management > Servies Oriented Architecture Software Engineering (pasticulary Requirements Engineering) > Software Process Improvement fincding CMM) > Software Quality Assurance > Strategic Planing > Usability and User Experience Design “The BAO” Gude oensesom defining the bisiness analysis role across broad range of business analysis approaches and so only touches beely on much af the information ‘developed by practitioners working hee fk, Business nays wl find that a study of any f those reas willbe rewarded with a geeater wndertanding ofthe bus ress analy profession ability to collaborate with other professionals, nd an under landing of a numberof dllerent ways bat business analy can bent Ube orate tions that employ tern | Ta aR A aEChapter 2: Business Analysis Planning & Monitoring | ‘he Business Analysis Planning and Monitoring Knowledge Area defines the tasks asso- ciated with the planning and monitoring of business analysis activities, including: » identifying stakeholders » defining roles and responsibilities of stakcholders in the business analysis effort > developing estimates for business analysis tasks > planning how the business analyst will communicate with stakeholders > planninghow requirements will be approached, traced, and prioritized > determining the deliverables that the business analyst will produce » defining and determining business a alysis processes > determining the metries that will be used for monitoring business analysis work. In addition, this knowledge area describes the work involved in monitoring and report- ing on work performed to ensure that the business analysis effort produces the expect- ed outcomes. If these outcomes do not occur, the business analyst must take corrective action to meet stakeholder expectations Figure 2-1: Business Analysis Planning ond Nonitoring Input/Output Diagram inputs i Outputs 1 ma! i worm wt LPR PRL penne a ay ey fey i j ty Tanks « | i | joe eer) || eae sua as | ‘oa 3 i foot Use nolan Anant) | i andthe conduct ad = | ema 1 | Lncibtorma | [stern]; | Ae Rapa i ; i! hy hy Gy! i Dy S igi ae at fe Pa 2) | i 1°71 | ranatevies ata * ! i ii conmicatin_} | TR fequvenens sa rearaance | examen 1 communion Management Asesment | arate sagement || pe i i — ii it i i ii Lj By; i i ik i i i osetia ' onrios ! 1 Pecestsss st i 24 Plan Bu: 244 Purpose “This task describes how to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted regarding and informed of the approach, and the rationale for using it. ess Analysis ApproachFotis to 242 Description IHasinest analysis approaches deserie the aver proces tht wil he followed to perform business analysis work on a given initiative, how and when tasks will bey formed. the techniques that willbe used. andthe deliverables that shoul Be peo duced There are mpl established ways to approach business analysis wath, In soflwace ddevclopment they rang from those dictated bythe waterfall approach tothe se of [echniques, Sioiaty there are a sumer of wel Lnown business process dmprove= ‘meat methodologi. including Loan and Six Slama, as wall as many propeiotary and fachouse methoogies customs, a peactices Elements frm ifn! appecaches ‘maybe combined: however only a subsot ofall possible combinations will be viable for the parlinlar ongantzalional svitonen a which an initiative tring perorrned, In order to plan the business analysis approach the business analyst ust understand theorgantzarional process needs and ebjctives that apply to the initiative. These needs sand objcctves may include eompatibibty with other organirational processes, cot “Sraintson time-to-market, cmpliasce with teguatory and governance frameworks thedesie to evaluate new approaches to solution development, or other business ob fects Ifthe objectives are nnt know, the business analyst marhe requred a eine the requirements hal the process must sect, In many cases organizations will hae formal ot informal standardsin place rgarding bow business analysis iedonc and how its into project and other activities, this ix thecase the busines analyst roviews un oxisting organization stands, neading standards guidelines, and processes relating to the eurreat inibetiv, These may sus fest or dictate whieh upproach to use. Fen whore standard approneh exis mst betailored tothe weeds ofa specific initiative. Tailoring may be goversed by organi I staradaeds that define which approacesire permitted. whieh vlemeats iT Unise processes maybe tailored, general guidelines fr selecting process, and sofort, Ino standucds exist, the busines analyst works with the appropriate stakeholders to determine how the work willbe completed. he business analyst should he capable of Sseocting or creating an approach and working with key stakelilders, particularly the project manager and projet team, tense thal it is stable The business analysis approwch soften based on or related to the projet approsch but in sore eases they may he independently determined fr example an organization nay use a plan-deiven approach todeline its business processesand then use a cha= ‘risen approach ra bulla the supporting software appicationsh 243 Inputs Busluess Needs The business analyas approach willbe shaped by the probe or onpettanily laced by the organization Irs generally ascemary ta consider the eiks a sociated withit the timelrise in which the need austbe addressed, and how well the ‘ned ieunderstond. This wil help determine whether a plan-driven or change driven Approach is appropriate, Expert Judgment: Used to determine the optimal hasinessanalyls approach. Exper tise my be provided from x wide range of sources including stakeholders in the ita tive nganizational Centers of Competency. coagulant or asociationsand industry | Ta aR A aEStnsesinateerneinis | ra groups Prior expestences of the buslness analyst and other stakeholders should be onsdered when selecting or modifying an approach, Organisational Process Assets Include the sens of existing business alysis ap proaches to use by the organization. Organizational process assetsthat may be Yseful In defining the business analysis approach inchide methodologies for process change os software development, tools o technigues that aren use or understood by stake er, corporate governance standards (such as COBIT, SarbasesAatey, rd Basel Dad templates for deliverables. In additin ro these genera standards, the oeganiration may Ihave guidetinesin ples for ailoring the process to Kita specifi initiate, gare2-2: Plan Buses nls Approach npuOutpa Diagram f inputs 1 i ty i [ss i | usinesstleed —Epet Organizational! i Judgement — Process Assets | Pan Bus Analysis Approach Busines, Analisis Pon Requitements Mgt Process 24.4 Elements Almost all methodologe t somewhere along aspectrum between plan-dsiven and change driven approaches, Plan-driven approaches cus on minimizing up-oont uncetsinty and ensuring that thes Sflly dened before implementation egins in order to masimize conte ‘nd minimize ak, These approaches lend tobe preferred in situations where require ‘ments can effectively be dened in advance of plementation the risk of an incorrest aE aD EasFotis to Implementation fs unacceptably high, or when managing stakeholder interactions Drcarnts significant challenges. the authority to approve requirements typically rests ‘with selected stakeholdees and te projeet sponsor. The project spouse wil have the pal authority approve sclation rquitements but it common for sponsors insist that other stakeholdoes grant tele approvalbotore the sponsor wil Waterfall methods ff aftwate development and business pace re-engineering initiatives ae typical ‘examples of plan-driven approaches en 1 driven approaches focus on rapid delivery of business yale shot erations etn for acceptance higher degree of uncertainty regarding the overall deli ryt tho solaton. These approaches tond to he prefered when takingan exploratory approach to fading the best solution or for incremental improvement of existing Sslution. The authority 0 approve equieoments usualy rests with a sing individ ‘who isan active participant in the teams daly activities others may advise or be Informed but may not thhold consent and the appeoval process mst be completed within a trie Ge limit, Agile methods of software development, as wll scontinge ‘us improvement projets ar typical examples ot change-driven approche. The performance ofthis task is dependent on where the selected approach falls thisspeetrun, The descriptions blow touch on tho ends ofthe spectrum, and hybrid approaches may combine aspects of hth, Similar considerations must be taken nto ‘count whether the sings analysts selecting of asloring the approuch, 4 Timing of Business Analysts Wark Pass cbusluess anaysiforts Should occur when tas performed, and if the level of business analysis effort wil nce to vary aver time. This Includes deteemining whether enterprise analysis, requirements analysis. nd solution fssesument and valation attics wil be performed primailyn specie project phases or iteratively over the course of the lative Plan driven approaches have most hustness analyals work occur atthe eginalig of the projector during one specific project phase. he exact name of the phase varies by the pectic methodology. but the mat focus ofthe phase includes such activities es sliding, analyzing, documenting, verifying and eommanicating the requirements 8 ‘wellas reporting an the status ofthe business analysis activities work forthe project Change-driven approaches may havea busines analysisefoet conducted easly to produce an initial list of high-level requirements (also referrd t as roqurements envi Simin). This product backlog is then updated throughout the projet as new require ‘mnts emerge, Throughout the project, these requicraents will be prioritized and ce (rioritired based on the Business need. The ighea-priocly requirements wi from the backlog fer detuled regulrements analysis resources become avaluble for maplementation. and implementation will begin 3s soon as analysts iscomplete be taken 2 Fermality And Level Of Detail Of Business Analysis Deliverables Determine whether requirements will be delivered as formal dacumenttion at theough informal eommunication with stakeholders and the appropiate evel of etal that should be eantained in those documents. The expected deiverahles mst be ddetined as part of theapproach, See Chaper f equirements Management and Comm ication for exarnpes of business analysts desivershles, | Ta aR A aEStnsesinateerneinis | ra Plan -deiven approachos typically ell fora significant amount of formality and detail, Requirements are captured ina formal dociment or set af dctaments which follow standardized templates, Ths may be preceded by aaumber of vequlrsments tated Ascsments, but th increasing eves of detail, inciiding a high level vison and scope document that focuses os busines reyuiremeats, and documents deserting the feaqitement from the point at view of ape stakeholder grnups Helevant stakehold- ers must generally formally approve each of these documents hefore work beglason eqitersents ats ner levelof detail The apcite cement and formato he eee ‘ments docuriomts ean vary. depundiag on the organizational methodologies processes fl templates, Change-driven approaches lavor defining roquitements tira team interaction and through gatharing feedback on a working solution. Mandatory equitements docuren: tations often imited to. prioritized requirements Hist Additional documentation may be created at the discretion of tha toam and generally consists of model developed to chance the teams understanding ofa specific problem, An alternative appronch sto ‘document the requirements inthe form of acceptance criteria accompanied by tests oral documentation i olten produced after the solution iirsplementod to facilitate knowledge transex 3 Requirements Prsitization Determine hs roqroments wl be proetiaed and how those prortes wil ese to define the solution scope Methods of priviizing requirements are discussed in PriortiseReqatroment (61). Aso see Chapter 5 Enterprise Angee or information on Aetining the slution scope and Chapter 4: Requirements Management and Communica. ‘om or information om managing the slation scope. Prioetizatin metho wil alss be used when peforming dilate Requirentents (7.21 Change-deven approctes tend to place great des! ofemphasison offsetive requirements riritizaton methads, due tothesmall scope of each iteration or release 4 Change Management Changesto requirements may occur a anytime. Consider the expected likelihood and frequency of change and ensue thatthe change management process ksefective for those levels ot change, Cectie bsinges analysis practices ca significantly reduce the ‘mount of change required ina stable business environment but eannot eliminate Plan-driven uppraaches seok to ensure tha changes only occur hen they ae gente Inly necessary and canbe clearly jastfed. Bach change soften handled asain projet complete with requirements ebcitaton, estimates, design, ete Changed re- {quirements impact both the solution seape andthe projet seape athe change man ‘urment proces willbe incorporated int the overall project management proces. “Many organizations havea formal process which includes a request for change 8 hai ga racks the changes hl ave heen ind sn analysis the Impact ofthe change nt only tothe project, but lento other business and automated sstems Ia practice, thenumbee and impact of change requestsatten inceeasesto~ ‘wards the end of the peojct. This can he dus to any combination of facts. including leoely scoped projet lick of requirements osersip by projet takeholers,pootly performed business analysis changing management priorities business reorganiza aE aD asFotis to srogulatory change or changing busiaess requirements, Change-driven approaches presen that is dificult to dently al requirements tn advance ofthe'rimplementation. nee is generally no separate change management process distinet fem the sleeton ofrequirements for given oration. Changes ‘xiling sation capabilities are simply prortired and selected for an iteration using thesame criteria as new features andl capabilites 5 Business Analysis Planning Process ‘The businessanalyst must doteersno the process that willbe flowed 19 plan the ex: of businesses analysis wiles ln must canes this procers willbe integrated Into large project plan 5 Communication With Stakeholders Communications may he weitten of verbal formal oF informal Becsions mus be made atthe outst ofthe projet ast the applicability o such communications technologies ‘uch as email with regards to project decision-making nd approval of deliverables Plan-driven approaches tend to rely on formal communication methods, Mich f the communication ofthe actual reuirements sin writing, andolten uses pre-detived forms requiring signatory approvals, AM project documentation i normally archived ws part ofthe projeet histor ‘Change-driven approachos focus moro on frequency of communication than on for smal dacusentation. Ocal dacurnentation often i writing, but aor enn nication takes procedonce over more formal written communication. cumenttion Frequently occurs fllowing implementation J Requirements Analysis and Management Tools The usness analyst must identify any requirements analysis or managenent tools ‘at will be used. These vols may shape the selection of busines analysis tachniguess ations to be used. and the way that requirements wil be packaged. 8 Project Compleity The complerity of the project, the ma bbusinuae needs to be taken ita consideration The factor std below. among ethers, increase the complexity of business analysis forts as they increase re ofthe deliverables and the owtall isk to the > number ofstakelolders > number ofbasines areas affected > number ofbusines systems affected > amount and nature afisk > uniqueness of quirements > number of echnical resources required The level of requ | Ta aR A aE nts uncertainty is partly dependent on the dammain ofthe projetStnsesinateerneinis | ra For example, now ventusc, marketing and rexcarch projects tend to have higher ro quirements uncertainty, hie accounting and finance projets tend to hve a relatiecly lower level of requirements uncertainty Many ongantzations have a nocd for knowledge regarding asotion tobe maintained ‘over the longer, because responsibility forthe slution may be outsourced, because fof turnover within she project tam, geographical istibution of patiepants,orbe cise key personnel ar om contract and will nt emain weilable to the organization following implomentarion Formal Jacamcatation may be required to address thot sks 245 Techniques Decision Analysis (2.8): May be used ta tate aslable melbdolagies agains the rg alzatlonal needsaud objectives, Process Madeling (21) Process Mndols canbe used to define and docurment the business analysis approneh, Strnctured Walkthrough (9.20): This can ho sed asa means of validating created sclected ot tallored business analysis approach, 24.6 Stakeholders Castomer, Domain SME, End User or Uhsir availability sa plier: The approach taken may depend on wolveent with the initiative busines analysis approach taken should be compatible ‘wth the impleencntation Ufeyele used by Ue iesplemeatalion tear. Project Managers The projeet manager must ensure thatthe hustness analysis ap proach is compatible with other project activities. Tester: the business analysis approach must fcltate appropriate testing ativites Regulator: Aspects ofthe proach or decisions made in the tailoring prosess may reqhuine approval Sponsor: the approact taken may depend on tele saabiiy and involvement with theinitntve The sponsor may also have needs and objctives that apply the ap proach ts 2a7 Output ‘Business Analysis Approach:This isa definition of the approach Una willbe taken for business analysis ina given initiative. business analysisappreach may specify team role, deliverables, analysis techoiyues, the timing and fesueney of stakeholder fnieructiuns und other element ofthe business unlsss process. A methodology Is ‘formalized and repeatable businexs analysis approach, Itinchudes a decision about ‘which organizational process assets willbe applic and any dcesians made regarding lalloring ofthe process fora specific situstins. Documentation regarding the appeeaeh ‘may eventually be added tothe vegunization's repository of process asses aE aD asas 22 Conduct Stakeholder Analysis 224 Purpose “hls task covers the identification of takcholers who muy be alfcted by a proposed Initiative or who shate acommon business need, identifying appropriate stakebklers for the projet or project phase, and determining stakeholder influence andr author ty regatding the approval of project deliverables. 222 Description Stakeholer analysts porlemed as soon ass business ned fs Alenifiod and wil ‘usually bean ongoing activity uslong as business analysis continues, Stakeholder fanalysts hogins with identifying stakeholders who mayo affected by the business need ora neve slution, Stakeholders may be grouped into categories that reflect thei Invivement or interest In theists Te roles. respons and nat boty over the requirements foreach staksilder urstakeholler group mis be clearly described Stakeholder analysts also involves understandingstakcholder fluence on and atieude {towards the initiative, and assessing postive and negative attitudes and behaviors ‘which may affect the outcome ot the nitive andl acceptance ofthe sation 223 Inputs ‘Business Neod: Latif anu analy 2e the postion of te stakeholders affected by the business need. As the unserstanding of that need evolves through definition of usiness requirements, solution scope, stakehoWer requirements nd soluion requirements, that adéitional information will be used to assist in emt ifying additional stakeholders lor understanding how existing stakeholders may have changed their postion, Enterprise Arehitocture:Doseribes tho organizational units hat exit thei interac tions with other organizational units, customers, and suppliers, their tesponsibilties ‘thin the organization, andthe roles and relationships within cach prgintzational Organizational Process Assets: These Include organizational polices and procedures, fornsthal must be completed, saggested or pres bed methodologies, templates, and projet authorization guidelines. They may be mandated or expressed in the form of wiing picipen 224 Elements Stakeholder rolos must he ented early the projct in order rofl ensure tel Asivery of requirements deliverables Note that sone indivdvals ay be calle om to pla a yariory of takeholdor roles on the same project. 23 wall as on diferontraloz on {lifer projects A Identication Understanding who the sLakehollers ate and the impact of proposed change om th fs vital to understanding what needs, wants, and expoetations must be satiafied by a salution. Because roquenents are base stakeholder needs, wants, nd expectations those that are uncovered ether Isto not atl enald require revision to equiements that Es Ta aR A aE‘one Sa olde Anis ioe Dchitecture Proce Assets conduct Stakeholder Analysis stakeholder List Roles and Responstalities enn nN Won. ~ ‘Tasks Using This Output 23 2A Pan BA Activities Plan BA Prepare for i i i i ! a i Prentice i \ i i i Communication ‘kiation | | i i Requliements 1 i ‘charges or allies completed tasks or tasks already in progress, increasing costs ad decreasing stakeheldersaisfatinn. Change-driven approaches mayetter accom no- ‘date this isk, but cannot eliminate, a late stakeholder ilentfcation ean sil result In alterations tothe project roadmap and release content ‘Wha partheipates in which business analysis activites can vary belween projets methodologies. and organizations. For example. somo organizations may encourage members ofthe tecnica earn in allend requirements workshops to pride costs {coke effet ostimates nd information on technical impact eile others may ele that no lehnical discussion is peerited daring these meting aE aD Easas 2 Complexity of Stakeholder Group The complesity o interactions with a stakeholder aroup maybe affected by Factors suchas ty of divet end users in thee constituency. Dilferen aps proaches plans. reports armeuat of formality and theamount of documentation Canbe customized based onthe number ofstakeholders each subject matter ‘expert ropresents Stakeholders with ewer consltuents ay beable to represent thei stakeholder group without much dieulyStakehciderseepresention alate ‘pamuher of eonstltuents or representing those fom differen: Fusetional avcas ot Sivisions may ned to research information er enaxin requirements elation ‘themselves > Number of interfacing business processes and automated systems. Th plan ning for stakeholders whe represent those perforiing comple, interfacing, or ‘overlapping hisineesprocestoss diferent from those whose processes are more sel-cotained. Since ot all akeoldery ca o watt 0 led sl equlnernents ‘workshops they canbe mors easily persuades! ifthe workshop pertains tothe process and the associated software application. 3 Aitudeandinuence Arson stakeholder altitudes toward and influence over the initiative, Factots to com ‘ier ince > thebvsiness goals cbjetives, and solution approach Do they believe thatthe solatfon will benefit he organiza > Willthehenefits affect them direetty? & Will hebeneitsbe accrued elsewhere? © Atethe possible nogativo effets of the nltatve on ths stakeholder greater ® Dothey believe that the projet team ean successfully deliver the solution? > Attinido towards business analysis: > othey see vain defining their roquirements? © Dothey present solutions and expect the requirements tobe contained i that solution nd heleve tha tha wil enable them to aveld requtromentadefink > Atuiude towards ollaboration © Have they had suecesson previous collaborative cforts? £ Does the organization reward collaboration? | Ta aR A aEStnsesinateerneinis | ae > Isthe organization Mecarchical ta nature cather than helng team-based? &Avepersonal agendas the mae? }Atbiidetowatsthe sponse » On ecoss-functional forts, doall the SMEs support the sponsor? » Aethere SMEs who would prefer anothersponsor? Have key members ofthe project team finluding but not Hite othe bust ness analyst hile trusting relationships or heve there been prior failed pro} ets o project phases involving those peopl? uence: Understanding the nature of nflnee and the inlucnee ruetutes and thin an organization ean prove invaluable when seeking to build relation ‘hips aind work oars bung trust, Understanding the infuenee cach sikebolder ‘may have, as wells their atituds, can help develop strategies for obtaining buy-in and eallabration Some factors ating to nlvence tn condor ae chants » Influence om the project low ranch influence does the stakeholder haven the projet? Furinstance because spoasors obtala funding, Including resources. amd make vital decisions, theysally exer! more than ond -users > Influence in the organization, There are vsaly formal ana inforoalstrvetres ‘within organizations, and ones tite a ob rate, while t ean provide what is called Zulhority or positional power dacs nt alwaystellecttheaclual importance or futhortya stakeholder has. > Influence needed forthe good ofthe project, Thelusiness analyst should ana Jyae how much influence s needed wo make the project sueceed eompared with the mount ufintience the key stakeholers, such as the project sponsct have, Fat ex fmm, una large, complex project requiring many internal end external resuurces the projet will need a sponsor whs has eectve relationships with funding groups ‘wensure that adequate resources are available for project work. Projets that are smaller may require sponsors vith less nflaenes,H there is aimismatch between tinlucnee required and the araount of afluere the stakhokler as o sper ceived to have, develop risk plans und responses a ther strategies hat might be nooded to obiuin the required level of suppor > Influence with other stakcholders Within most organizations theres an infor ‘mal way influence ecu. Its best tobe aware of this informal influence structure. For example, there ate sakehalders who eonsier themselves project champions they ean be helptalin converting those wit are ss enthusasticor even outwaly hostile to the project purpese and designated outcomes. 4 Authorty Levels For Business Analysis Work dentify wach stakeholders will have authority over business analy activities, nr Iation to both business analysis work snd product deliverables Stakeholders may have aE aD Esas authority > Approvethe deliverables > Inspect and apron the reaements Request and approve changes > Approve the requiremonts process that willbe nse Review and approve the tecesbilty structure > Yolo proposed requirements or solitons (individually orn « group) idioma information anauthority levels ean be found in Plan Regutroments Manage ment Process(2.3. 225 Techniques 1 General Techniques Aveeptance and Evaluation Criteria Definition (.1: Tc business analyst soald, es part ofthe sakenolsler analysis entity which stakeholders have sufficient authority twaceept oF reject the solution. Uieainstorming(9.3): May assist in klebifying needs and qieements thot lead to possible stakelolers, or in eeatng listing of possible stakeholder tues. Interviews (4): faterviewous say be alee kntify other stakubolders, Organization Modeling (9.19) Assess to determino he organizational units ae people fisted have any unigaeneeds and interests that shoul be considered It will de Senhe the oles and functions in the organization and the ways in which stakeholders Interact and so will help to entify stakeholders who ure lect bya change, Process Madeling (0:20: Any person invalend inthe exvention of business processes allected by the solution will bea slaksholder Paces mendes ean bea scutee oder Uitying additional stakeholders, sine related pracossesrmay be affects. In addition categorizing stakeholders by thesystems that suppor thie business processes ean be tusefl een changse ned ta he mad to those processes an ystems Roquitements Workshops (2.23): During requirements workshops, the business ana Iystmay ask parioipants they can suggest other stakeholers isk Analysis (9.24): hisks ro the initiative may result from stakeholder attitudes or the ability ot key stakeholders o participate the vitiative Scenarios and Uso Cases (9.26), and Usor Stories (9.33) Identified stakeholder ros ‘ay serve ana uselulstarting point for identifying setoes and Yolen Scope Modeling (9.27):Scope moxels sould show stakebwolders that fall outside the scope of the sotlon ut sil interact within some ay Survey/(uestionnaire ($1): Useful foridentifyingshared characteristics ofa stake Ss] Ta aR A aEStnsesinateerneinis | ae boker group. 2 RAC Matre The RACL matrix doseribes the coks of thosv ivolved in busines alysis aetivitis. I describes srakcholders as having one oe mote of the fllosng Fespansibiliis fora sven taskordslverabie > Rfsponsibledsosthe wore > [Mfocountattesthe decision maker only ene) > [Clonsuted must be euosled pri to the work and givesiopat Informed mcansthat they mus: be noted af the otoome ‘An example ofa RACI Matrix may be scen below: Figure 2-8 Sample RAC Mati tel Executive Sponsor Business Analyst, Project Manager Developer ester rainer Applicaton Archive Dita Modeler Database Analyst OBA) Tnfrasvcture Analyst Business frenitact Information Arehkect Solution Owner End User Subject Matter Beper (sme) [Other Sakeholders cr varies 3 Stakeholder Map Stakcholier maps are visual diagrams that depict the relationship of stakeholders to thesolutio and to one another, Tere are many focmsof stakeholder ap, but wo ‘common ones cide > Amatcismupping the level of stakeholder inflance against the level ofstakshokler aE aD Esas > Anonion diagram indicating how tvolvedthestakeboldert wit the sola (Gehich stakeholders wil disci internet with the solution or participate in a bus ress process which ate putt ofthe lager oeganlzation, and which ar outside the organization) Stakeholder maps often incude lines uf communication between stakeholders, Figae2-s Stoked Matic Hoh ork closely with takeholderto ensure hat they ae n ageeement wth and suppertthe change Ensue stakeholder remains ated, Inftuence ot Stakeholder Keep informed stakcholder is likely toe very concemed and ‘may fee amsios about cof onto} lnterestorinfuencedo not tow Impacton ich Stakeholder ‘igure2-6 Stakeholder Onn Diagram [ Sima regulators and ars ‘poncors, veces, mat SHES and others ho tract wth the ‘fected group ‘tected External Stakeholders ‘Organization or Enterprise Ti ses ep den ai ers whose wexk hongeshenthe = [Froyctteamand thei? irc invoies with creating the salute. ‘ected Organizational Unit | Ta aR A aEStnsesinateerneinis | ra 226 Stakeholders Domain SME May be abe to fecommensl other Business experts to assist in defining eguitecents {Implementation SME: Maybe able to Meaty and roeommend stakeholders ‘Project Manager: May be able to identi'yand recommend stakeholders Inthe context, ‘of projct with a designated projet manager, esponsibility fr staksholder ietifiew tom and management must be shared with the profect manager. The business analyst, sand project maser should collaborate on perorming this ask. The project an tiger isaccountable for ensuringthat the project team meets commitments made to thestakcholders, managing the assignment of stakeholders to project tasks rd thei Involvement in theexceution ofthe project, an ensuring thar changes that impact the prijet scope are appropriately mange and approved. The business ans wll also sis the project manager in defining which project team members shouldbe invatved in developing, ceviewingor approving business analysis daiverables ‘Testor May beable ro identify and recommend staksholiers. Regulator: Mey roquire that specific stakeholder representatives re Inthe process Sponsor: May beable to entity domain sioet matter experts to elp with require ments deinit 227 4, Roles, and Responsibilities this may include information such es > List ofrequired roles > Names nd ites ofstakeholdens > Category of stakcholder > Location of stakeholders > Spovial needs Number of indivdustsinthisstaksholder role » Description stakeholder influence and interest > Documentation of stakeholder authority levels 23 Plan Business Analysis Activities 231 Purpose Determine the activitiesthat mast he perormed and the duce estimate the efort required to perform that work, took eited fo messtre the progress af thowe activities and deliverables, levers that must be pr: wide the maagemen aE aD asonteinsnons tae 232 Description the businessanelyst determines which activities arc equieed for. ven initiative, how ‘hose activities willbe curred ou, the work efor involved, and an estimate of how Joagthe activities wil ako. This task inludes atisites to: > entify business analysis deliverables > Determine the scope of work forthe business analysisactvities > Dotormine whieh a toe the business aly wil perform ale » Develop estimates forbusiness analysis work ‘he activities that are executed ad how they are executed will determine the quality ‘and timeliness ofthe bsness analyas deliverables and ukimately ofthe solution, The business analysis plan) idemtityand schedule the wtivitios and resources required 10 produoe a clea. coneise sot ofoquieements that support development of the sakitlon Take planning setvity wil ypicallynccur mote thar unto give initiative oe projet as plans frequently must be updated to address changing busine:s cnditions [eaves encountered By the business salyato ther teasn members, easons learned through the performance ofbusiness analysis aetiviie, or uther elunging ereum ‘One way of accommodating change ona largerInltlaive isto pla on an inremental ‘orrolling wave has. This approach to planning erates a high lve plan forthe long, teri and detailed plans co address near-term aetvties with th understanding thar the ng-term plans il change as more information Recomtes avilable. An alternative, wed in change-driven methodologies Isto follow a well-defined, thn-linlted process for developing roquiements and limit cach iteration to the work that eon be completed Jn the Lime allotted. A loagtern roadmap may be used to set expectations, but Le contents ofthe roadmap are constantly revisited as priorities change 233 Input Business Analysis Approacks: Defines the lifecycle, deliverables, tempat, and tasks {hal should be infuded Plate appronchex seck to define requirements eat ‘5 possible to reduce uncertain. while change-driven approaches encourage regu ents ta be defined os close toimplementation as posable These differences will lead to dilfecont deliverables and tasks being Montifed as well s different sequences and Aepondencies oftasks, The approach willalw determine how the planning process performed asiness Analysis Performance Assessment Ihe bsiness analyst must ise prior experlences on thls lnitave or ou others to detective the effort lnvlved in polar Ingtusiness analysis work Organizational Process Assets The organizations standards and process asset i place may mandate corain deliverables. Lesions learned from previons itanves ‘wells rom current ongoing business analysis activities, may be use in the develop tment of busines analysis plans, | Ta aR A aEStnsesinateerneinis | ra Figwe 2-7: Pon snes Anays's cites npat/Outpat Bagram Inputs \ i i i) BES 4 Analysis Performance —ProcessAssets List, Roles, and | | Approach Assessment Responsibilities | 23 Pian BA fctivites ¥ ") Business ralysisPlan() 1 ReguirementsMgt ) | and Communication | i i i 25 i Menage BA ! Peformance ! ! i Solution Assessment ‘and Validation ! Fl i \ 2 Stakcholder behaviorsan 41 oles, and Responsibilities Stakcholders will exhibit individ! Defrences that may wed tobe met. For example onekeystaksholdet say prefrthe eof process maps which cold influence the planing of business finals tasks related to ths stakeholder Another stakebolder may have some expert nec using particular technology and bein fvor ofits choice for the current projec, whlch night also Influenee th business analysts deliverables tasks and estimates. Un derstanding tee roles and responsistis on the projet willhelp to determine how eh thoxeprefrenees wll shape the plan addtlon, e will have to beset aside tovwork with stacholders to clieit and analyze requiremientsand for those stakhold cers wlth Jetson-making authority to approve cequirements Th ole of each stake aE aD asonteinsnons tae Ihoklr must be understood o that the appropriate activites can be seeded and the necessary time alloted, 23.4 Elements 1 Geographic Diswiburion of Stakeholders ‘The business snalyst must consider the physical lycatlon of ey stakeuoders on the projet, Some projects il have the stakcholerslneatel in single loeston while bothers willhave some of thelr key staksholdersdispersed over a wide area. These at- ter projects may wel involve increased complexity. which will hive an impact onthe estate of some activitis and tasks in the project. Staketolders may be collocated or dispersed Collocated: All key stakeholders are located in the same local geographic area There ‘ro no special location rolared planning consideration forthe business actly in vole in these projects, Dispersed Those more complex projects hasesume key stakeholders located in dite sent geographic regions or countries, The fctors of stance, possible hve differences nl cultural and language difterences increase the complexity for business analysis snd will equiteeffrt to identi and aecouat for these differences and how they will ‘alles requirements planning ard volation development seletio, testing an imple ‘mentation. stakeholders ate dispersed, it may be necessary to have more teleanter ‘nes or iMdeonferenees rather Tae face to face meetings Another common situation insoles an outsoureed development project where the de ‘lopment team is physically loeated many'time zones away. Thi ype ofsituation, for example. willbe acesanted fir diving business nals planning and might he beter served with more detalled requirements documentation wad sceeplanee criteria, mre frequent review sessions more detaled docimentation, 2 Typeof Project or itiative The typeof project er initiative to which the business analysts assigned may have a significant impact onthe activibies thal need! to be performed. Far example, na project tw purchase new software package, the work willbe dierent roman efor to devel ‘op anew business process Diflerent kinds of busines analysis iniatives che but treat limited wo > Feasby studies > Procesimproveme > Organizational change > New software development (in-house) > Outsourced new software development > Soltwaremaininanceor enhancement > Sofware package selection | Ta aR A aEStnsesinateerneinis | ra 3 Business Analysts Deliverables Als of deliverables is useful as a basis fr activity demtficaton, Methods for Ment {ngdelverabes ined. bu re not limited Review projet documentation » Review organizational process asset, stich as methodolagis and templates. which nay dictate which deliverables ane required, {An organization may havea standard set of deliverables or multiple sets that are use to support dtirent approved methodologies. The breakdown of deliverables may aso bbe dependent oa the techniques selected bythe busiiess analysand may include Aeivcrable sch nsinterviewe questions. meeting mines usecase diagrams id deseriptions and as-y0 be business process models. The hustness sais ss approseh frequentivmandates the use of ertain techniques Mast agile methods assume that tuer stories willbe used to document stakeholder requirements, and a Buslaess Po ‘est Management init ative wil equine pracess modeling, Frequently, additonal techniques may be selected on an alco basis during execution ‘of usiness analysis the business analyst eneounterssituations for which they are west approptat, For exanpl, the business analyst may decide foci requcements tusinga requirements orks. and then termine In that workshop thal particular staksholder has aiional requirement which are best identified through an tere ‘iow or obsorving that stakeholder on the jo, eli are Requirements Package (1). Tho slection end format of requlrements packages is kely to be mandated by the business analysis approach, es will often take the forum of a equlrement package, as descr in Pre A Determine Business Analysis Activities {An important tol in defining the scape of work andin developing estiniatesis the work breakdowa struetuce (WS). The WBS decompose the projet scope lato salle and smaller pieces, eating hicrarchy of work, WHS may break dos the peek nto Aeration releases oc phases break deliverables Into work packagesor Deak aetlvitdes into smaller asks, ‘Work packages include at leyat one and sally my activities, which can be further broker into smaller and salle tasks. This decors of ativities and asks exe ses the Activity List, “he tity List can be ercated i different ways such as by > Taking each deliverable, aslgning the atiitlesraquited to complete the deliver: able and breaking each activity into tasks Dividing the projct into phases erations increments. or Fleas Kontiying the deliverables foreach, ad adding activites and tasks accaedingly aE aD asonteinsnons tae > Uninga presiousstinila projet asan outline and expanding t with detailed tasks unique lor the business analis phase of the curont project ‘Une chments entific foreach ativity and task may include » Unique Number to uniquely idem each task Activity description labeled with « verb anda now, and deseribina the detiled tasks that comprise each aetlvly For example, an getivit night be tabled “Up date Requirements Document” In addition, it may include other information such as: Assumptions: For cach task thore may be factorsor conditions which are considered tobe trie. the business analyst ean document these factors, and where present eat ‘mates willbe developed using these assumptions Dependencies dentfy logical relationships, suchas which nettles aveto be com pleted before subsequent tasks cs bean Milestones Represent sgniieantewons in the progr of project Miletus are used to measuce the progress of he project and compate actual progress to earlier ‘estimates: Milestones ean he used asa ime to celebrate the competion delivery of ‘major deliverable or ection of project work. An example of amajor milestones the akoholdets? and sponsor’ firma approval of equieents doeamee 235 Techniques Estimation (210): varot of estimation techniques ca he used to produce an over allassesament ofthe amount ofbisiness analysis work required. In sie cases mah ple teobniques may be used to validate one anothet. Estimates are norally developed fm cenjnction with the project manager and ather team members, and make nse othe ‘rgaulzatlonal methodology and templates or developlagestimates. Functional Decompo ition (.12}: Decomposition othe tasks na project (using a ‘work breakdown structure) o product (using a solution teakdowa structure) can be wc to faeiiate an understanding ofthe work ata feent evel of deta to enable sstination of tase, [Risk Analysis (9.24): Identify isks that mat impact the business analsis plans 236 Stakeholders All stakeholders listed here may potentially participate in the verification snd vaidae aflusinessanalsis deliverable Castomer, Domain SME, End User, nd Sepplier: Domain Siew eelyhea mar sourev of equlzoments and thelr availability (critical when planning activities Tale inderatanding of bisinest analysis techniques may shape the selection of technics ‘or require that the business analyst dovote some time to asst them in understanding Tow the requirements are defined Customers and auppiers maybe eapecally dieu toschodule electives Ss Ta aR A aEsine Aa Coma e Implementation SMEs may participate business analysts sctviies in ones to fnciitate understanding of stakeholder needs. They will ced to {Know in what form aud when deliverables willbe produced as inputs into thelr ows sctiviy planning, Operational Support May use business analysis deliverables usa basis fr planing ‘operational suppor aetiities or developing appropriate dacumentaton, Project Manager: ta project, the business analysis plan integrated with and component ofthe overall proeet pun, The projet manayer should purtcipaten bust snes aly planning aed i esponsible for ensuring that howe plans ae integrated with the work peeformed by other project personne. n addition, the scope of business alysis work within a projets managed a pat ofthe oveeallpreect sen hares to that scope of work (or example, as new stabchelders arent snes equitements change) may require approval fa project seope change. The projet ‘manager will also play akey rele in identifying resources to perform tasks, scheduling theselvities and developing cot estimates Testers Will aged to now in what fora an to their om activity planning when deliverables willbe produced as Sponsor: Must paticipateia the approval of busiaess analysis deliverables 237 Output ‘Business Analysis Plan(s): The businessanalyis plan(s) mer inclade information sch ssa deseriptlon f the scope of work, the dlivrabie Work Breabdowa Structure, 3m Activity List,and estimates for each activity and task. It should also deseribewiten ane how the plan should he changed in response to changing condilons. The level of deta fssnciated wth the plan(s is determined bythe business analy approach and the ‘overall methodology tasks tn lather knowledge areas have business analysis plans asan imple The plan) determine when an bow any taskis performed 24 Plan Business Analysis 241 Purpose business auayss communications plan dserbes the proposed structure and sched tue for communications regarding business analysis setvities,lecord and organize the setvities to provides bast for setting expectations farbusiness analysis work, moet ings, walkthroughs and other communications. Communication 242 Description Planning business naysiseommunientions includes determining howe best te recive isteibute, access, update, and escalate information fram project stakeholders, and Astorrining hw best to commanicate with each stakehold quirements can he presented in varinns formats his task describes the work ‘quired to deide which format) areappcopriate fora particule init and its stakeholders. Requirements should be presented in formats that arc understandable aE aD asotis onan forthe reviewer: they mustbe dea, conse, accurate, and athe approprate level of ‘Considerations lor the business unalysis communications plan include what novds tobe communicate > what isthe appropriate delivery method; > who sthe appropriate audience > and when the communication should ace. Stakeholiter needs and constraints relevant 9 cnmountcation inch: > Physical nation/time zane ofthe stakeholders, > Communication spprouch fr the stakeholder > Whattypes of communications wal be required (eg, status. enoriates sues and ‘heir esclution, risks meeting results, action tems el) > What types ofroqulroments willbe elitted (busines, stukcholer sutton, or {wansitions high level vs detailed) and how best fo elicit them (se the Beatin KA for uptions) > Hlowehest to communicate reuitements conelnsionsipackages, including thority evel sgnoll authori, veto auth ‘review onl), > Tineand resouses av 243 Input Business Analysts Approach: May include standards and templates used for commu nication, and expectations regarding when and how communication should occur ysis Plan(a): Detsrmines when work will be performed and the deliver ables that wil be produced, and which need tobe commsantcated Organiaational Procens Assets May ich a defined set of templates fuse ta bus alysis communication, inluding presuntation formats, requirements documen- on templates and others, Stakcholder wil oles, and esponsibilitien: Use to identify the stukeholes who ets infermation garding businoss:inayss wrk, determine when ioe needs tobe provid, ard how stakelolder s expected towne tha information, | Ta aR A aEsine Aa Coma Figure 2-8: Pan Bess Anas Communion Inpu/Outpt Bagram, feo A Business BusinossAnalysss Organizational Stakeholder Arabs Panis) ProcessAsees Ust Roles and 24 FlanBA om nieation ay 3 {communication Pan y Prepare Reqs Package 244 Elements 1 Geography ‘The communicatiois neve fra team thats collocated will he dite ‘munications required fra projet with geographically dispersed stakcholders For example, itis more ficult to have short, daily team meetings when the participants liv in vastly diferent time zones. when techulogy is not readily accesible, and where ‘multiple, complex deliverables with complex interfaces are being developed sim ‘ously i differen ocatons from com 2 Cultwe Cultural diversity should uso be taken into uccount when planning communtestoas, Cultural eonsiderations are important regardless of where the team members are Jcated, In addition 1 the obvious language barriers there may be more subtle difer- ‘nes that shod he planes nsdn aE aD asotis onan Relationship te time, Some cultures view deadlines as fm comoltments, whl thors may sew deadlines o#a youl tobe balanced againatathor concer and interest > Relationship to task completion. Some eulturos completo tasks hecause they have committed tothe plated ativiies Others complete tasks prt trust an he human relationship have heen bat > Relationship te contenets. Some cultures believe in the letter of the ly, others the pirt ofthe contrat. This diference might surface when excting Requests for Proposal: fa example > Relationship to formal and informal authority, Sono cultures peter a centeuk ied povser structure where decisions are made by a small group. while others pref to involve all affected stakeholders in approving deesions. > Theuse of mols fllowinga standardized notation enn help avcreome language barriers by eliminating the need for many textual deseriptons, 3 ProjectType Ditlrent projects will necessitate diffrent deliverables, and theestent of document tion that is needed in requirements package willvary depending. th projet. Some Anew, customized in-house software develepment project. ie this seen, all quirements may nced tobe include. Upgrading the technology or infrastructure ofa current system, this scenario, only the technical requirements may nee tbe inelded in he package, (Change in a business process o new data for an existing application. In this sconario the proeess and data rogurements, business rules functional and teeopleal fequitements willbe needed, Purchase ofa software package. This ip of projet will likely require a Request For Proposal andthe package will od to nchide the hustnes requtterment, echneal requirersents limited funitionsl requtements and other vendor specifications. sho: focused. agile style iterattons of software development, Ihe projects muy specify aay oF very tle formal requirements documentation, Whiteboard ty ats, and user stories may sulle. Alle focuses on ereting the minimum neces sary nfdeeumentation to deliver the requirements and many agile teams willpeeferto ncument the solution aftr thas been delivered 4 Communion Frequency Investigates the frequency required by varlous stakeholders for each type of eoammunt tation, Note the frequency of reporting can vary frm stakeholder to stakeholder For ‘example, the feaquency of reporting business analyse status canbe biweekly fr the sponsor. weekly or the Domain Subject Matter Experts and bieerkl forthe technical | Ta aR A aEStnsesinateerneinis | aeRO 5 Communications Formalty Planning communications requires taking inte consideration the lve of formality that fsneded, This could vary from stakeholder ta slakcholder,prokct phase to project phase, work within a projet phase, and requirements preschtation Communteaton tends tobe more formal under tho fllowing cleuunstances: > Theprojet is unusually large (by oegpntzationa standards) and willbe deivered inphases The level of communications formality tends to increase as the seal of fa pojectincceases. Tiss hecause more stakeholders are typically nvabyed and ‘nore communication ie sequied. > Thedomuin involved isvory complex. Note that the domsin aed by the projec say span departmental ad divisional boundaries within the ensanization Foe ‘xample the domain of engineering employes reerultment cou lve the ng human resources payroll marketing aed benefits administration depart sont Those groups willl bo key stakeholders forthe projeet and it deliverables > Thetechnology employed, if wn, willbe new. or new to the organization > theproject is considered tobe mission critical, in that is ind dieetly to strategie objectives > Theexecutive sponsor and/or key stakeholders require formality The requlrements are likely tobe subject to regulatory review. > Therequitements willbe presented to suppliers in an RFQ/RFU/ACP. 245 Techniques Seo Prepare Requirements Package (:1)and Communicate Requirement (3.5 for ad ional information, Communication techniques are described in Coramunization Skits 9. Structured Walkthrough (9.80 One ofthe ment common apprisehes to rogue nts commuicaton. Tie to conduct each walkthrough al address theese ‘ised during the walkthrough must be cluded in the pla 246 Stakeholders ‘Customer and Sup lier: Aor customers ofan organtvation or suppers wo tat oe znnization (partic ilory institutional customers) may nese ta be informed of planned ‘hangs wellin advance of lnplementation, ‘bomain SME Mey be valved in revisw and approval L3kelyto foeuson matters of paricularinterest oro the areason which they are an SME; Domain SME often bave Invluence aver the approvers. evn thelr approval sno formally esque {end Users May be involved in review and approval Nay ay have camsiderable ne fucose upproverseven if thelr approvals ot formally required. ‘Implementation SME: Yay bo lassived in reviewand approval aE aD as‘Plan Requirements Managemen Process 247 25 2.51 25.2 253 Operational Support: May be involved in vevkw and approval Wl pelmarlly focus om the requirements te support the soliton, Project Manager: Ina project, the business analysis communication plan will gener. allybe integrated into the averal projet eominuneations plan. Cn smal projets the plan may be vers brief and may not be formally acumented. Orn large aid complex projets an projcets with many stakeholders, it may be included as part af the project Initiation documentation and is essential as pact ofthe overall project communications plan Teale: Wil primarily he involved in eficahon and validation ofthe eguleements, Regulator: Regulators may roguve that cequlrements decllons. and other infor tion rozmding the execution of basiness analysis processes or the definition ofthe sol {lon beretalned and made available to the for review Sponsor: Communication needs for the sponsor ate ikelyto focus on busines require ‘ments ai high-level stakeholder and soliton requirements Output ‘asiness Analysis Communication Plan: Descrihes how, when and why the business analyst will work dieetly with stakcholders, Components ea include > Thestakcholder communications requirements forbusiness analysis etviies > Forsal, content, mein, belo deta > Responsibility for collecting dstibuling. aeeesing, and updating information. Plan Requirements Management Process Purpose tino the process that will bo used to approve requirements for implementation an manag changes tothe sultion or requirements spe Description Thisrask determines the appropriate requleements management proces for a pat ticular initiative. It includes determining the proces for requirements change, whieh Sakcheldersieed fo approve change who willbe conslted oF informed of ehangcs. and by extension, who does at need ta be involved. The task slaofacludesussesing the ned fr fequeements teaceablity and deterring which requirements attributes willbe capture. Input [usiness Analysis Approach: The selected approach may include a definition of ap propriate requirements management processes. ‘Business Analysis Plan(s): The business analy pani) define which deliverables ate tobe produced and when, Deliverables cannol be aunaged wali they are created (i ete ins Aina ad of airedStnsesinateerneinis | TAT Organizational Process Assets Standard tomplates oe processes for rogulroments rranageotont within the organization may exist he business analyst must be kao fedgcable about the organlzatio’s approach to requirements dbl as it wil gr in lence the process steps tasks em deliverables egnired orexpeeted during the equlremons planalng and monitoring activites. Figure 2-8: i i | i ! i i Basess oxgantatonal Analyss — Process assets | 1 lenis) i Ve = - Requirements Management Plan 1 i i at i i | managesa Manage tition | | iL Paremance Seopeaeg’s | | i i i i | i i i a2 Manage Ree's aceabilty Vo AS 25.4 Elements A Repostory A requirements repository ia method of string requirements, inchiding thote un dee development those under review. and approved requirements Repositories may Incde whiteboard ‘word prucessing documents cagrams and models, wikis, re (quirements managerncnt tools and applications or anyother method of recording aE aD as‘Plan Requirements Managemen Process Sn Sin itoring Jnformathon tat allows equlrements to be single sourced and avallable to stakcholdersfor slongasthey are ceded. approved reqvicements shouldbe found Ina repository (es opposed to using toolssuch as emall which may not reach all re tran stakeholders and may not be rtaines and staksholdcesnoed the abl to locate requirement In that repualory. “The system for adding, changingand deleting roquirements should be consistent and clearly understood bythe tear, File ar eomponentsacning standards will assis ith feategoetaing and malntainingrequlrements 2 Wacesbilty DDotermine whether and how ta trace roquiromentshased on the complexity ofthe domain, the number of views of requirements that wil be produced, potential pacts from risk, and an uinderstancting of the ests and benefits involved, Tracing requir. nents ads considerable overhead t business analysis work and mun be dons or rectly and consistent to have val, Soe Manage Requirements Taceahity (2) for additional information 3 Select Requirements Atibutes Requirements attributes providetnformation about equ of the requirement, theimportanee of the requirement, and other metadata. Attributes tid in the ongoing management ofthe requirements throughout the prjeetHfeyels “They need tobe planned for and determined. along with the requicement themselves, but arenot in themalves part the solution definition, ents seh as the source Requirements tributes allow the requirements tenes to assctate information with ie dividual or rated geoups of regairemonts and faltate the requirements analysis po teas hy expressing such things an which requirements may add project tskor eaite fedditional analysis Theinformation dacurtented by th atebutes ilps the tearn ‘licintly an ellectively make lraden!f between requirements identify stakeholders ffected by potential changes. and understand tho impact of a proposed change Some commonty used requirements attributesinchnde: > Absolute referenceiss unique numeri preferted or text identifi: The elar- ‘nce isnot Pa he altered or eos ithe requirement ts moved, change ar deleted, Author ofthe requirement If he requicement i ater found to be wnbiguows the ‘autor may be consulted for clarification. > Complexity naicates how dificut the requirements willbe to implement. Tiss ‘often indicated through qualitative scales based on sumber of interlace, complex ity afessental processes or the number and autre ofthe resources requ > Ownership indicates the individual or group that needs the requitenient or willbe thebusiness owner altar the projet teloassd into the target environment > Priority indicates which roquirements ced to be implemented est. See belo for further diseussion on pelriiag and managing rogulrements — Ta aR A aEStnsesinateerneinis | TAT > Risks associated with meting > Source ofthe requirement. Every requirement must originate rom a souteethat thas the authority to define this particular set of requiem, The source mis be consulted ifthe requirement changes oF If mare information regarding the require mentor the need that drove the requirement has a be obtained, > Stability s used to indicate how mature the requirement Tiss usd te deter ‘mine whether the requirement firm enough tastart work on. Nate that the ng- ing presence of lange number of unslabe core requirements may indicate signi «ant risk to project entice > Status ofthe requicement, indicating seh Uhings as whether its proposed, ae cepted, verified, postponed, canceled or implemented » Uegeney indicates how soon the requirements needed. I-isusually only necessary tn specify this sopararely fom the prioety when a deadline exists For implementa tion > Additional tributes may include information such as cost, resource wsigament, land revision nusnber,tracedrom anal traced, A Requirements Pristization Process Requirements donot all deve the same valieto stakeholders Requirements poet sath focuses effort on determing which requivements should e investigated ts bas om the risk associate! with them, the coat to deliv then, the benefit they wi produce, o ther factors, Timelines, dependeneles, resource astral, and oer fectorsinfluence how requitements are prontzedPlamning the requirement prort ‘ation process helps onsite that stakeholders deternie and uerstand howe rege ‘ments will he promtizedthroughont anda the end of the business analsis efor Formality The formality rigor of the requireaentspricitization process de termined partlyhy the methodology chosen, and hy the characteris ofthe project ‘sell. Differences wll le in the level of deta the amount of formal sewelure inthe pristiation process (he. formal meetings versus inforaal eonsersations) and the ‘amount of documentation needed to support the prioetization process. Establishing The Process And Technique, The process to plan how requlrenouts pe ortiation will oecur needs toinclade which prieritization techniqua(s) willbe nse, Plan The Participation. the business anslys, in conjunction with the project manager fand sponsor should work together determine the parteipants needed for the prio tivation process ‘Whom 1 aviteand who dous the inviting depends un organizational norms and best practices Sinee sponsors are ultimately aecoantable or the solution efieetiveness and naj prooet decisions. they need ta botavited to partieipate i the discussion, even LMthey delegate the participation to subject matter experts Anather key stkeholder Js the project manage, whose project plan is dependeat on which roquiomments ere feleased and when, The invitees depend on methodologies, organizational norms, ad tocrgigement ofthe sponsor. When there ure ulkiple imitng feetors, invite parti aE aD a‘Plan Requirements Managemen Process pants accordingly 5 Change Management ‘Some considerations when planning fr handing changes are Determine the process for requesting changes Te process ean, but dacs not hese {ejsel aullorisalion loves for approving changes Por example, -amay be decked Usa if change ietimate to take less than a certain numberof hous or dollars ther: ‘questo and project manager ean approre the chaage a predebied tne or cot Kit Is excoeded, the sponsor has to appraveit Determine who will authorize changes. The planning activity needste inchade ‘designation of who can approve changes fterragutements have been approved. Plan-driven methods sally havea formal Change Contcol ard (CCB) or Change Authority which eousiersthe requested change. and provides iil judgment an the merits ofthat request, The CCiban consist of any numer of people im any nmr af psitions may or may not inclode the sponsor the project manager. the business ana Inst, subject matter experts or other parties. Change-deiven methods are more kel to allow the project texan or angle product owner to lave direct control over eanges Impact Analysis. Specify who will perform the analysis of sich mpactsasbusiness processes, information requirements, system and hardware interlaces, ter software prodets. other requirements test stearegs nd plans.ro name a fe lan the wording ofthe request. It simpottant to set the expectation atthe begin ning ofthehusiness analy activities that although the amin of documentation esquire to feques! changes project and oncthudology dependent, le wording of the quest must be clear. The requcsted change must be expressed in unambiguous orms. Therefore. it willhe necessary to discuss the natu te requesl with the queso and other intersstedstaksholders. The requirements pracess needs to splot the nature ofthe components within 8 request for change, These might include: > Gostand tine eatimates of ch nee © Fat each item, work pend, or technical product affected, a brief antecement ofthe expected eost of change isto be estimated, As u matter of govd prac fice, reusability wil ye improrements to the change: peocessby limiting the ‘eatent and scope of changes to otter components. The goal shouldbe w ensure responsiveness to change, ot easing unlimited objections and impediments to the change proces, © Thoestimaro ill provide an intgrated vow ofthe costs resources needed, implementation Helrame, and any dependencies, > Benefits \risks ofthe change oye the change aligns wit the project ond usiness cjeetivesto help ensie allehanges add business value | Ta aR A aEStnsesinateerneinis | TAT > Since there ate often uniatended consequences to what svems ike a fvorable change the request should inlude a well-structured change analysts form (writen or verbal) statomentsof the cxpeeted risks Including both negative tnd postive influence on project objectives, Hencfty considered may include not daly Snancal bref, but alo the teclcal aspocts of product features inluensen om prnject scone, time oat quality, reaontees, and Ue bunt course of action far ch ne & ‘The course faction foe the change neds be explained withthe understand- Ing of beavis and risks inthe provioussoeton. Several alirnative cursos can Deconsketed, including those recommended hy the requestor and by ober stakeholders. By weighing the roative benefits risks und uthoe cetera foreach ‘option, the decision maker, designated by the approval process, cam make a choige that wil best serve the needs ofthe projec The yartos options considered and the reasoning forthe eption finally selected reds to he reooeded ® Therecommended course of actan needs to be enmplete enough to permit clear coordination ofthe partiesulfected by the change. For larger changes, this course faction might be asuprojct within the context of the overall proect, including elements tt need tobe put inte the overall pest plan > Updateste the communications plan and the method for communication of tie change to affected stakeholders, > Conlgutstion management an teaceability dscplines should eeablih produc baselines and version antrol practices tha il eleey identify which boseine i allected by the cag, Cooedinate Priritization Of Change. The prionity athe proposed cnge must be ‘established eelative to other competingintereats within the current projet phos, The fequestor shoul provide a peority ag doseetbed i the tection above, Project dessin ‘makers will need to consider the priority 9s well any jotentil risk of deterringimple sation unt late i ‘Change-Drven Methods ‘Change driven methodologies tn particular. agllo software development methods) do fot typically havea change: contrat process that fexeparate frm the reqjarement fortiaation process ll oyurements,incuding"new” andehanged” requzements are ‘recorded in the product backlog and prioritized. At the beginning each eration, the bighest priority requlrements ae selacted from the backlog and estimated, and these fstimatesareused as input te determine whether the roqurement willbe implemented hat eration, 5 Tailoring the Requirements Management Process {An organizations requirements management process ay nee tobe tailored to mest theneedsafa specific nitive or projet. Factors in thetalloring process inchide aE aD as‘Plan Requirements Managemen Process Sn 25.5 256 Sin itoring > Organizational culture. In organizations where the culture dues not support formality, but where inform lity oopardize the ond product, fille necessary to work with th stakeboldersto ngetlate an appropriate proces > Stakeholder preferonces Some stakcholdorsmay require mote oe oss formal: A spor ma} for example, waa formal approval but may nat want a documented processor eliitng requirement, As aor, ill he neceseary a ecommmend | themest appropriate approach to hand Ippactaus needs ing requirements, pointing oul risks snd service, or rent) ange > Complesty of project, projeel phase, ar product (pres being delivered. Formal processes for configuration managginent and ‘management ate morelikely tobe used fo > Projects that have many interfaces, many business and/or system Lmpacts or span variety offanetional areas Products that are built with many components and suboonsponents, have con Dex imterfaces willbe used bya variety and number of stakeholders, of have ther complexities, > Orgunteational maturity Less mature organizations tnd to bole ikly co want Aapend Lime or money eteatings requ resistancctotholdea ofhavinga process to define requirements ment proce, ana Here maybe tight » Availability of resourcesneeded to support the effort of erating such a processis taj cntshlratin. Internal {ternal sores atch as consting ims and exon vendors maybe able to ‘onl organizational rites, cups, such asa Peaject Management Otic and Techniques Decision A sand assess areas uncertain, ysis (0.8): Cane used to assess the possible value delivered bya change Problem Tracking (9.20): Used to track possible changes an ensure that a decision is reached, [isk Analysis (0.24): Used to kent possible risks assocTated with the change mar ‘agement process and possible risks associated with making or choosngnot to make thechange Stakeholders Domain SME: Consulted in order to determine the Importance of requ assess the value of change requests sents and to {End Usert Consulted inorder to determine the importanes of requirements and tows sess the value afchange requests {moplemontation SMEs Consulted in onde ta dctermins the ditfieutyafimplementing ‘requirement or proposed change (i ete ins Aina ad of airedStnsesinateerneinis | a ST Operational Supports Informed ofchangestorequirementsto ensure thatthe sol fiom can operate ctestvey, Project Manager: Responsible for managing changes to the projet scope: eourtable far dover ofthe project seope. Changes tthe slution and requ scope are atmos certain to impact the project scope. Similarly, changes to the project Scope may impact the slotion and requirements seope. Most projets se single ‘hanige management process to handle bot an describe the pacts to selon and project scope in astngle change requcat Ts will requir the ivalvemicnt af the project ‘anager in this ask and agreement onthe perso responsible for the change mate: ment prooess Teter: info ned of changes to eequieements to ensute that les plans ae elective Sponsor: Accountable for the solution scope and must approse prortizatlon of aqurements and changes to requirements. 257 Output Roquirements Management Plan. \ requirements management plan describes the > Approach to he taken to structure traceability > Definition of requirements atributes tu be use > Roquiroments proetization process. Tequleements change process including how changes wil be requested, analyzed, approved, and implemented 26 Manage Business Analysis Performance 261 Purpose ‘To manage the performance of business analysis activities to ensure that they are ex: cuted aseffectively as possible, 26.2 Description Tisrask covers determining which motes willbe sed to measure the work per formed bythe business analyst. I includes how to teach assess, and report on tte qual ayo the work and take steps o creeet any probleme that may rie, This may feed Jno the dev lopment of future business analysis plans The selected releies are defined fad deseribed inthe organizational proeess assets ot the business analyse plans. This task alo describeshow organizational process sels governing business analysis activities aromanaged and updated 26.3 Input Business Analysis Performance Metrics: Actusl petfurmance measures are captured, analyzed and become the bss fr taking carectve or prevent ke actlon. Capturing actual performance metriesisa proces that occur through the business anelsss of fort and vsimplletly «potential output from every business analy tak aE aD Es‘Nanage Busnes Anais Performonce 264 ‘Business AualystsPlan(s): These plans deseribe deliverables set ties tasks and es timates forall business analysis work, Conformance ta these plans maybe the primary mets used to judge perforatanc Organizational Performance Standard: May include mandated performance met: rics or expectations for business analysis work Requirements Management Plan: Te royulrements management plan may also sot expectations forthe frequency of changes to tequltementsand the wark involved it ‘managing that chang gue Mange ues nt Performa pap Dg AAD A Bosness —Bustness Organaaional Requirements Analysis Analysis Performance Management Performance ‘Planis) Standards Plan = Metres epee 26 Manage BA Performance 4 #4 petomance an ows sist sets Vann, =. YW ‘Tasks Using This Output | 04 (Output is Used By { i i (“= | i ! face | i | i [ =") i i= Elements 1 Pestrmance Messe Performance measures are use to sot expectations regarding what constitutes fee tive businessanalysis work inthe enntex! of paricilar organization or initit¥we Perfortance messures may be bused on deliverable dus dates ax specified ia the bush snes plan. metrics such as The frequency of changes to requirments oF the ‘numberof review eyclesrequired, or qualitative feedback Irom stakeholders and peers (i ete ins Aina ad of aired CeStnsesinateerneinis | a ST of the business analyst. Appropriate perfarmanee measures should enable the business finals to determine when prablems ac occurring thet may affect the performanceat business analysis or other aetivities or dently opportuniis for provement 2 Performance Reparting Reports can by in written format to provide for archival tnd tracking oc they can be fren andl verbal based om the needs of The projec. Sone teporte may be ade fo ‘mally und orally as presentations to various ovelsofstakshoklers and mangement 3 Preventive And Contective Acton The business analyst should assess he perfor problems in exciting business mnalyssactivtiesre ceenrringar opportunities for Improving the business analysis process exist. Once this assessment ik completethe bbsinese analyst should engage tne necessary sakcholers to kdentify the correct preventative or corwetive ations. Feeventative or erzectiveactioa is Mkely to result ‘changes tothe business analysis plan nce measures to determine where 265 Techniques General Techniques Interviews (014) Stakeholders maybe interviewed to gather aswessenent of snes analysis performance elps identity changes to business analysis processes and deliverables that can be aerated into future work Metrics and Key Performance indicators (9.1! Can be sed to determing what tmelris are appropeiate for assessing business analysis performance and how they may be tracked Peublem Tracking (9-20) May bevased to tack ses hs cee during the peor ‘mance ofbasiness nays for later resolution, Process Modeling (0:21): Cane used to define business analysis processes and un derstand how to improve those processes bo reduce problems om handotfs improve tescle simes, or alter howrbusincs analysis work s performed tosppoet improvements in dowistreum procosss, Root Cause Analysis (0:25}-Can help identify the underlying eause of failures dif ficulties in accorsplishing business analysis work. Survey/Questionnaize (9.81): Cane used 1 gather Ibedback from large number of staksholders 2 Vatance Analysis ‘The purpose ofthis techalque sto analyze dlseropancts between planned and actual performance determine the magnitide of those discrepancies, and recommend cot fective and provenlive ation aa tequleed. Varlanees can he related to planned versa actual estimates cust, scope, produet expectations, or any measures ht have been ‘established duringthe planning process aE aD EsHop tose ‘When variances betweon the aetual work and the plan ae found, varlanee analysis imaszes the magnitude ofthe variation Varin analysislso ncindes studying the fuses ofthe warlanee 1 detormine corrective ar preventive etions ane requlred to bringthe businese analyte work inline with the hasinese nels plane 2866 Stakeholders Domain SME and Fin User: Shold be informed of the pefee mance of busnessanaly sisactivtis inorder 1o set expectations for ther involvement ‘plementation SME, Operational Support, und Tester: Dependent on the elective peviormance of business analysis setvittes to perform ther sole, Should be eonsalied ‘when assess those activition Project Manager Tho project manager ls accountable for the suecoss ofa projet and must be kept infra ofthe current satus of business analysis work. potential, problems or opportunities for improvement are Mdentifed the project manager mast be ‘consulted before changes are implemented to assess whether tbove changes wil have fam impaeton th project. he project manager may alse dalvcr eports cn business ‘alysis performanoe to the sponsor aad other staksholders Sponsor: May require reportson business analyse performance to aden problems sstheyateidentified. \ manager ofbusiness analysts ay alto sponsor initiatives to Improve the performance of lsinoss analy et 267 Output Business Analysis Performance Assessment his includes a comparon of planned versusactaal performance. understanding the rot eanse of variances from the pl snd other inforanation to help uridertand the lve olfot required to complete bus ness analysis wark ‘Business Analysis Process Assets: When the analysis ofthe performance of thebusi- wt analyse work yields ows tha saifvetory eesti help o eve not wal the cesullsthemseW es, bul ake the proces that produced thove reall, This process ‘analysis ten results n commendations [or improvement 1 the business analyse process. The revised process and templates for business analysis deliverables should Doe analyze anil dacumented and lessons earned should he recorded These may bo Incorporated into Organizational Process Assets S| Ta aR A aECQ eM area) “eting requirements fs akey task in business analysis, ecause the requirements serve ns the foundation fo the slution to the business necls ifs esventa ha the requirements be complete, cle nd consistea Leveraging provea means to ‘li eer il hep mect these quality goal, The word ect is deine: 1. to draw forth bring out something latent or potential) 1w call forth or deaw out (a information ura response) these definitions highlight the need to actively engage the stakcholersin defining sequlrements “Ths chapter includes details olcting hustness.stakoholder, olution. or transition requirements. The business analyst should nderstand the commonly aoe techniques tweliit requirements, should beable select appropriate techniques) fora gwen sit ation, and be knowledgeable ofthe tasks needed to prepare execute and complete exch technique, ‘ieting requirements fe not an tplated oF compartmentalized activity Typlealy. ‘equirements areidentifed throughout the elletaton, analysis verlication and val: dation activities. For example, regulrements may be eleitad ia interviews of requie= ‘ments workshops. Later, when those requirements are used to buld and verity models) fepsin the requirements nay be discovered. This will then require eliciting detail of those newly dented rogulremeats, using techniques outlined in thls chapto, ‘To ully examine and define the requirements a combination of complementary elicits ‘ion techniques typically used. A numberof factors (lke businers domain, the corpo rate entire and envionment, the skis ofthe analyst and the requirements deliver ables that willbe created) guide which tecinques ll bused Figure 21: General cepted Eitan Techniques and Spronjns CEs ‘Synonym Brainstorming (93) Document Anaiysis (99) Review existing documentation Focus Group (9.11) Interface Analysis 13) External Interface Analysis Interviews (9.14) [Observation (918) Job Shadoving Prototyping (922), ‘Storyboarding, Navigation Flow Paper rototyping, Seteen Flows Requirements Workshops (8.23) [Eleitation Workshop, Falitated Workshop Survey/ Questionnaire (931)ra ee Fdtaton deliverables depend on the ection techniques used. es interview woes survey responses, glossary term, and so forth, Its expocted that at some point while purforming elicitation that suit materia wall have bean eleited rom the business axports 0 allow analysis attest begin. The combined results ofall the clictationtechnigues used wil verve as inpat to bul- Ingthe selected analytical modes. Missing, neornpots oF incorrect requirements will ieally beexposeddising the analysis wetivtes, thus requiring additional elicitation Note performance ofall leation activities are governed by thebusinesé analysis plans we 2-9) and busines analy perlormance meries should he lacked (see 2) gue 3-2 Etaton Ipuoutput Diagram 31 Prepare for Elicitation 34 Purpose Logue all ceded esoures ae onanize and schedule for conducting heaton 312 Description Build detailed schedule fora paticularellitation activity, defining the speife xe tivities nd the planned dates 313 Input Business Neod: Required to ensure hat the business analyst undorstunls what infor ‘mation shouldbe elicited fmm the stakeholers. This inp s sel when elit ‘nes requirements (ith the ception ofthe business nevd tse Solution Seope and Business Case: Required to ensure that the business analyst un derstands what lnforaatlon should beelcited from the stakeholders, These inputs are tus when citing staksholder,solatin, and transition quirement, Slakcholder List, Roles, and Responsibilities: Used to identity the stakeholders who should participate n cbettation activities, | Ta aR A aEa aa Figure 3-2: Prperefr cation InpuvOuput Diagram i y i rs ! ils 5a wy) i i i ' usiness Case SusinessNeed Sclution —_stakefolder | teeetext) —(seetext) Scope List Roles and i (see text) Responsibilities | eee esponsbaite B BF Propane For cation 4 ia scheduled Supporting Resouces Materials, =—-3. Kn. ‘Tasks Using This Output 32 onde Etaton ati f 1 ! i i i i i 314 Elements + Clay the specific seope for the selected elictaion technique and gathers any necessary supporting materials + Schedule allresources {people ilies, equipment) 1+ Notify sppropriate parts ofthe pao, For event based olistaton (brainstorming, focus group. aterview observation. ro totyping, equicements workshop) ground rleust beestablihed. Agreements sched with te sakehnidersastn the form and frequency of feedback during the citation process ax wells Hie meelaenr for verifying ana signing off the elite results 345 Techniques Additional laformation onthe performanee of thistask can be found in the description fol the rlevant techniques. aE aD EsConduct Bletavon Navy 3.2 3.21 3.22 3.23 > Bralnstorm 3) > Docuient Anais) Foca Groups (1) > Invests Analyt 62) > Interviews 2.10) > Observation 8) > Prototyping’@22) > oguieements Workshops (928) > Surveyquestionnsie (33) Stakeholders All Stakeholders Depenslng onthe requirements ofthe elicitation activity. any take bolder maybe a participant Project Manayer: The project manager will assist in ensuring that the need cesouse~ coate avaiable ed Resources this nclules the participant, he locaton i which the elite ‘activity willcour and any lier resources thal may be eulred Supporting Materials perform ther, Conduct Elicitation Activity Purpose Meet with stakehioldr(s)t eit itorm ny materials regulred to help expla the techniques used or ogurding their needs Description The elicitation event takes place (brainstorming, focus groups, interviews, observation, prototyping, requirements workshops) or lietations performed deumentunalssis, Interface analysis or distbted (urveyiquestionnaire) Input Businoss Need: Required th ensure tha the business analyst understands what infor mation shouldbe elicited frm the stakchollers. Ths inp x sel when elt bk ‘ness equitements (ith the cxception af the husiness neod ise. Organiaational Process Assets May inch templates or processes fr these activ tis. (i ete ins Aina ad of aireda aaa Requirements Management Plan: Determines what information needs tobe record fd and tracked as anontcome cf he ati. in particu, many requirements ate Dbutes must belied and captured whlle performing this ask. Scheduled Reseutees: The relevant stakehalders location, andl other resources must be wail Solution Seope und Business Case aro required to ensure that the business analyst vlerstands wha information shouldbe elicited from the stakeholders. These inputs aroused when elletting stakeholder, solution, and transition requirements. Supporting Materials: Whiteboards fincharts, documents and other materials mist, be available while the acusity is eonducted, ‘ i i i i ! ! i i j usinessCase Business Need Organizational | | teeta een) Process Assets | i i i i i i i i A A Requzerients Scheduled Soluion Supporting j Management Resources Scope’ Materials Plan (eetan) Conduct citation ‘etn aa lekaton Rests monn “Tasks Using This Output | Document litation Results aE aD EsET ee 324 Elements Tracing requirements: Whil eliciting he requirementsit Important to guard atainst scope creep. Tracing requirements back othe business goulsfbjectiveshelps tovahdate whether a requirement should be included. Caplucing requirement altsibutes: While eiiting the requirements documenting requirements attributes such asthe requirements source, value and priority will in ‘managingeach requirement throng hot its lie cycle Metrics: Tracking the slicilaion participants and the atual time spent eliciting the requirements provides abastsfor future planning, For event-based elicitation techniques eliciting requltements is highly dependent ow ‘hekeowledge of th stakeholders, thei willingness to participate in defining rere ‘cal, and the group's ably to reach consensus. It is mportan that all defined stake Tkdors are hoard during litt of ruirerments He may be noes to fue her clarify and possibly restate the requirements toeicompass all stakeholders perspec: 3.25 Techniques Data Dictionary and Glossary (2.5) business glossary is an essential ase forall elletarion techniques. The glossery should contain key domain terms along with their busines definitions General Techniques: Heer to enc Lechniqueelow for anique elements of eonducting that particular technique > Brainstormingi9) > Document Amal (9 > Focus Groups 10) > Interface Analy (928) > merous 0.10) > Omervaton oa) > Prototyping(922) Requirements Workshops 923) > SurveyQuestionnaire (9) 3.26 Stakeholders Customer, Domain SME, End User, task asa source of requirements, plier and Sponsors May participate in this lemeutation SME. Operatioual Support, Project Manager, Supplier and Tes- ters May participate to improve their understandingofthe stakeholder needs dt os | Ta aR A aEa aT sid stakcholders in understanding the tradeoffs faced bythe projet tea, equator: May partietpatedireetly (aso soutee of requirements) and mayalue detate that aspect proces be followed or that certain records be kept 3.27 Output licitation Results: May inchade dacusnenistion appropriate to the tebnique snd feaplare the Information provided by thestakeholder, 33 Document Elicitation Results 3.30 Purpose eee the information provided hy stakeholders or use in analysis 332 Description For un liitation vent (branstu typing, requirements workshop) a summary 6 Issues produced, ng focus groups interviews, cbservation, proto he output fom theeventineding 333 Input licitation Results: Includes the inforstion proved by stakeholders that wile recorded and structed, 334 Elements Documentation can take number of forms, including Written documents desertbing the auteomes, sich as meeting mints > Visualor audio recordings > Whiteboards eitheractual or virtual) where notes are retained unl they are transterzed to nother median, ‘he technique use for ebctation, aswell as the business analysis approach, will deter ‘mine what kind of documentation s possible and desirable 335 Techniques. Bealnstorming (9.3) The atiity gonorally produces the noessary documentation Document Analysts (99). report ofthe findings should be produced, acts Groups (011) The results of facus group ate collated and summarized, Interface Analysis (219): report ofthe findings shouldbe produced, Interviews 044}: Reslts of the interview are documented, ober 14 (0.8) Results of chseevaton are documented Peublen Tracking 9.20): Plicitation may produce save is need tobe racked to aE aD EsPrototyping (9.22): The results of letaton may undergo requirements analysed rectly. without the weed for an inerraediate tep to document ther Roquirements Workshops (9.28): The results of elicitation may underge requirements analysis directs, without the ned for an itermediaestep to dactument them, narized, Survey/uostionnaice (9.1): The resuls ofa survey are collated ands Figure3-5 Docent fain Reus InpuvOutut Bagram fequvemens Ssokehoier Isttes Concerns 3a 3a confirm Ebataton confirm Elation ese Rewuite ea 5 peat and ede Define Assumptions Reculemen ‘nd Constant Define ransion | Ta aR A aEa a 336 Stakeholders ‘usiness Analysts Other stakeholders do not nee to pateipa in this task 337 Output Roguirements [Stated Described from the peespective ofthe stakeholder Stated reqiements deserihe the stakchners need trom the takholder’s perspective Stakeholder Concerns: Includes ssuesienlifed by the taker risks, assump toms, constraints and athe relevant information 34 Confirm Elicitation Results 34a Purpose Validate that thestated requirements expressed bythe stakeholder match the stake Io's underst uling othe problem and the stakeholders needs 342 Description Some siclation techniques benelit fos seviewing the documenta outs with the ‘takaholdersto onsare thatthe analysts anderstanding conforms to Uho actual desires ‘or intentions the stakeholder, 343 Input Requirements [Stated, Unconfirmed Repte Ingo the stakeholders intentions Stakcholder Concerns Unconfirmed Represent the business analyst's understand ingot issues Mentiied by Ue stakeholder, icky, assump ions, constants end other felevant information that may he used in business analysis 344 Elements efor to the deserip tin af the relevant tecinique for unique aspoets of confirming the tesulls ofthe interview anu Observation techniques, 345 Techniques > Interviews 210) > Observation 18) 346 Stakeholders Any stakeholder who as participated in othr eletation tasksmay partietpat in this task 347 Output Roquirements [Stated, Confirmed identical to Requirements [Stated for oll rect cal purposes. including use asa input teother tasks Stakeholder Concerns Confirmed Identical to Stakeholder Concerns forall pract cal purposes including vse ear input toother tasks aE aD as£22 Roqaarvents Stakeholder (ate Conceras { Waconfimed} (Unconfmed) 5 “+ ad Reqarements stakeholder oreds Concerns onfimed {Confirmed ea 6s Define Busnes Prone Define Assumptions Need Requirements ‘and Constraints 6a 74 SpeeityanaModel | | Define tansiion Requirements Requirements Se] Ta aR A aEChapter 4; Requirements Management & Communication ‘he Requirements Management and Communication Knowledge Area describes the activities and considerations for managing and expressing requirements to a broad and diverse audience, These tasks are performed to ensure that all stakeholders have a shared understanding of the nature of a solution and to ensure that those stakeholders with approval authority are in agreement as to the requirements that the solution shall meet, Communicating re standing of the requirements, Because the stakeholders represent people from different backgrounds and business domains, this communication is both challenging and criti- cal to the success of any initiative. It involves determining which sets of requirements are relevant to a particular stakeholder group and presenting those requirements in an. appropriate format for that audience. ‘ements helps to bring the stakeholders to a common under. Management of requirements assists with understanding the effects of change and linking business goals and objectives to the actual solution that is constructed and ampact An review allo rts When a requiroment fe changed the business analyst can easly related requirements and software components jn order to under= stand the “impact” ofthe chang. ‘ments such as busines rules data clement and use eases iceur ow they will, bbe accomplished. Each business objective ean be review to make sate that wll bbo dressed ly the appropriate solution components, Ifa businessobjecivets net tied toanything thas aot heen analyzed and included ie the solution. Additional Snformation can be found in dates Proposed Soliton (22h > Requirements Allocation, Soe Allocate Requirements (72 423 Input Requirements: Allroquirementsmay potentially be traced to ater rogues and allstakeholder and solution requirements must be traceable ta a asness requirement Requirements Management Plan: Defines iw and whether tracabilty is being per formed the tools tht wil be uscd to support traceability and the pencesses tha wil be ‘used to manageit 424 Elements 1 Relationships After examining and organizing the sot of rqitements, record the dependencies and felatlonships for eaeh ofthe reyulrements. Knowing the dependencies a ato ships between requirements helps when determining the sequence in which require ‘ments are to be addressed, Common relationships include: > Necessity: Ths relationship exists when only makes sense to implement a par ticular requirement ifarelated requitement is alsnimplemented, this relationship may be unidirectional oe bi-directional. > forts thiseolationship exists when a requirement ixcasirto mplement a rolated requirement is als implemented Subset: When the rooalrement is the decomposed outcome of another require > Covers When tne requirement fall nchides the other requirement. Tiss a special case of subset. where the top evel requiremtent isthe sur ofthe suib-equirements > Value: When including a requirement affects the desirability ofa related require: rent (ithe increasing oF doreasing Ths may dee because the relate) quires isonly uecessary ithe fist requirement isimplemented, or beause ‘only one ofthe roquitements shouldbe implemented (fr instanet, when discussing {we featuresthatpolentally mt a busines reyulrement a aD EsTanase 2 Impact Analysis Impact analysis is performed to assessor evulute the Impact ofa change. Traceability {sa usefal fool fer porlorming impact analysis. When a requirement change its rel onships to other requirements or system components ean be reviewed. Each related requirement ar component may also require change to suppor the new teneemtet. These cumpunents cua also be traced o their elated components und those compo rents reviewed for needed changes. Knowing the Impact ofa change helps business cision makers evaluate their options with facts, 3 Configuration Management System A specialized eequirements mannaxement tools generally needed to Lace large bers nf requirements. 425 Techniques 1 Coverage Matrix A coverage matrix ita able or apreadsheet used to manage lacing is typcally weed ‘whos there are rolativly few cogulrments or when tracings mite to hahlevel requirement (eg featresor model) 426 Stakeholders lementatton SME: They must be able 0 link she requirements the sutton eo poneats that willimplement them. Project Manager: Tuceabillty supports projet change management Teste: Testrs need ro undeestand how andl where requirements are implemented whe creating test plans and tent cases andy race ten canes to requires 427 Output Requirements [Traced]: Traced requirements have clearly defined relationships to other regulremouts witha th solution seope such tha Its elatively easy to dontly theclfectsom other requirement ola change 43 Maintain Requirements for Re-use 43 Purpose To muenage nowldge of coqurements following thelr implementation, 432 Description dentify requirements that eve candidates fr long-term usage bythe orgpnizaton. These may include coqulrements that an veganization must meet on an ongoing bast, ss well as requirements that are implemented as pat ofa solation. ‘To re-use quirements they must be dearly named and defined end easily avallableto otheranalyss. these requirementsmaybe shred in repository nd a person shot be identified to manage the repository, When an existing regulrment mus be :0di= fied it con beaccessed from the repository or re-use | Ta aR A aEMaintain quieres for Ree Maintonance of ogultemeats can faite impact analy oF new, proposed changes tothchusiness,redace analysis ime and effort assist in maintenance of previonsy Implemented solutions end support othr aetsites lnuding ralning, corporate gov frnance, and standards compliance, Figure 4-4 Mafotain Reqeraments for Rese np Output Diagram ! i i i | I jOrsaraonal Reqremens Proce Asets i a3 Mabsrain Regt for Re-use Requlements (Waintaned & Reusable) ‘Output Aiso Used By ! 1 i (Enterprise i i | arehteceore i iL om i 433° Input Crganicaionl Pence Ansel: Theses slandand regain how and when ie tents shold bo mataralnd fo vous ogvirments:Reqirements maybe mintaine for e-nseas ges they doseise invotion of wetothe ignition bend telnet a indie Regul nents wil sully he eandhtes fr mntenance oni the esrb teat eae 434 Elements 1) Ongoing Requirements foes tamecton setinnows bts These nce cotartv sl or coe NeenPr nee ‘quality standards service level agreements, busines rules, business process ofr “quirements describing the work products the secu predecs, 2 Satisfied Requirements ren though a requirement hasbecn sls ti sila requirement as angas the bbsinese stakeholders needit. Maintaining thess eguirements helps with product, fehancements and fare system changes Existing tegultements may also be e-ased ‘on related business projets 435 Techniques None 436 Stakeholders asiness Analyst: ie‘nsed requirements are very likes to housed hy a diferent bust fae analyat than theauthor af some unkaow future date. kay be mocessary to ‘se andupdate the roquitements docimmentoion tact that ities explanetory Domain SME: Ongoing tequitements are likely tobe eferencd by Domain SMES oa | gular basis to ensure chat work produetsmcet them. hese requirements ae key the used fora warety of purpos cs Including developrnent of regression fests anal impact analysis of eahancements 437 Output oquirements [Maintained and teasablef The ouput of his ask ae requirements that ate expressed tn a form thet makes them suitable fo longterm usage by tho oF pmization [even in the absence ofthe stakeholders who originally dined her ‘ments They may become organizational process asots or be used in futuroinitiatves ‘or projets In some cases requirement that was not approved orimplemented maybe ‘maintalnod fora posable future inti. 44 Prepare Requirements Package 441 Purpose Toselect ania set requirementsin an appropriate fashion to ensure that terulemonteaeciitily cmnnicatdto-undertood yan uae Shel group ooups. 4a2 Description quirements shouldbe presented in formats thot are vndervtandableby the take Ioldet: this task describes the work tequited to decide whieh forenal() ate appropiate fora particular project and itsstakeholders. They mus! be elenr. concise, aceurie,and atthe appropriate level of detail Requirements documentation shouldbe created only totheestent needed tw assure clear nderstundinghy the tam equieements packages may he pecpared fr a number nf reasons, ieliding but aot Timid o early assesinent of quality and planning, evaluation of posible alternatives, form reviews and approvals, ampats to solution design, conformance to contractual and royulstory obligations, and maintenance or re-use | Ta aR A aESbsirnmionienticnraninn | Fae ‘Te primary goal if developnga requirements package sto convey information clay tnd imam understandable fashion To lp decile how to present requirements, ask the lowing types of questions: > Mow detailed da the requirements ced tobe? What infor ation i detail to include? portant to communicate? What isthe appropiate level of > What will the particilor stakeholder understand hased onthe typeof audience they eepresentand oo that stakeholders preferred syle of egmmuneation or lea ing? > Acethe requirements package presentation and fort, and the requirements eo toined othe package. appropriate for the type of andience that needs ta review i? How does the reuiesents package support the previews and sues (Ge. testing, implementation) or projct activities and deliverables? phases Misunderstandingof requirments wil adversely affect solution implementation. leads to rework and cosl overruns, particularly if deiieacin are uncovered late in the process. Possible forms for requirements packages may'iclade » Formal Documentation: Formal documentations usually based ona template ws by the organization, sich asa Visi Document or Softrate quirements Specification > Presentation: Delivers high-level ocrviw ofthe funetionalitydlivored bythe solution > Models the roquirements muy be prosented only nthe form ofa mod suck asa process map, oF caphured ona whiteboard, 443 Input ‘Business Analysts Communication Plan: This will typically describe the stakeoldor groups thciecommunication weeds and define whether a single rurements package ‘or makple requirements packages are required. The business analysis enmmunication plan will ase define th level of formality that appropriate or the requirements Organizational Process Assets: May include templates at can be used to package Requirements: The business analyst ust understand which requirements willbe Inches inthe package, Requirements may be package a any point i thet Heyl oguirements Structare: A package shold eo cent st of requirements a aD asPr nee 44a Figo 4-5: Paper Requirements Package npa/Outpit Dag i Inputs i i i i |e 2) | | “BR” organatonal Requlemments Requirements | | communication Process Assets Structure | i Plan i aa Prepare Rett Package ¥ “ Requvenents Package Communicate Requvements Elements 1 Work Products and Deliverables WorkFreduct A workprndic fea documento callecton of notes or diagrams used by the business analyst during the eequltements development process. Te work product may bay rot become n deliverable although during different phases ofthe requitements clic Ing process, the business snalist may need to share this information with stakeholders Inorder to clarify requirements. elit alton esqurements, or assess the feasibility ofthe solution approach, Examples of work products might be > Mostingagendas.ad minutes > Intorviow questions and notes session agendas and notes > Tssusstog (i ete ins Aina ad of airedSbsirnmionienticnraninn | Fae > Work plan, satus eeports Presentation sides use during the project > Teacenility matrices Deliverables Adiverabieisa specific output of the business analysis process that the business ‘analyst has agreed vo produce Arequlrement deliverable Is used asa bask for sok tion design and implementation, The business analyst must understand the diference between these two concepts and usc the deliverables as communication mechanioms. The businessanalyst will sees the needs ofthe audience, determine the level of etl that neds tobe comtmunleated, an ascertain which dliverabl presentation package 2 Format Depending on the type of equitement, the presentation technique may vary and spe cific Formats aay have been slzeted during development of the business analysis eom- ‘atnleation plan. There will Hhely ea combination afmany formatain one requ nents package. Culderthe best way tu combine and present the materials so that they convey a eahoalve effective menaagete one cr mate audiences whe will participate he requirements review process, This may result in mure than use requirements package Bong created forthe xame psec. Give careful consideration to what types oftnfrmation should be included in are= ‘quirements package and that the content may wary botween dffeent projects The best formal choices thee that best communicates the specific cantent of ‘equirertont. Each organization may have standards thatthe business analyst will be tested to follow, andthe project team will ullze the techniques approptiate for User project. sally, cach orgenieaton also hasan approved ste of tons that arc used for Socumentation Ive packages ercated with the nteotion ofebtaining formal approval: the eegwite ‘ments docamentation must be complete in order to prepare the requirements package Additonal Considerations for Requirements Documentation ach equtements package may have a Tuble of Contents outlining what sinha In the puchage- Grouping ofthe requlrements into eategories should be larly Ment fied inthe Tahleof Contents for ease of navigation, Itmay ala incinde a revision lox Aocument changes between versions and hep stakeholders verify tat they have the 44s Techniques 1 Requirements Documentation Requirements are requont}y captured informal docurtent Many templates for requirements document exist and rein common use. While selestinm of templates and documentss dependent on the business analyais ap prouch chosen, sme ofthe nost cummin types of reuieements documents ned: > tsinesstequitements Document (ante: many “Thusiness Requirements Doe a aD aaPr nee ak eogulterents) ment” templates alse Include stake > Product Roadmap > Software/System Regs crsents Speciation > Supplementary Requirements Specification 2 Requirements for Vendor Selection the solution tear thinks that a potontial solution is available from an outside party thebusiness analyst may eaplate the equitementsin the orm ofa Reyuest ht Ine ‘mation (RFD, Request for Quote (RF), or Request for Proposal (RFP) ‘hil these terms are sometimes used intershangeably they are tend to reflect, aifring level f formality inte vendor selection proces. Te organization purchas ing gent legal department or pracurentent organization is usally the owner ofthis process. An mBFTisgencrally used whn the issuing organization is open toa number a {rnative Solutions ands secking information to evaluate possible wptions AB RFQ or RFP is used when the issulng orguataution understands the natuee ot thesolution option available to tand is secking vendors who ean implement an ‘option, An RFQ goncrally follows less formal revew and selection proccss th ‘he solution team should carey consider how each vendor solution willbe evalu sted. Ofron stakeholders can he impressed by a product demo when the underlying product does not truly mest the busnessneed, ‘Business analysts must develop evaluation criteria based on the business requirements before looking at available products In patticular an REP typieally includes 3 deseri the soletion uriterie and provest The evaluation exleea used may be based fncoa af the implementation oc total cost ofonaership An sbjecive measaeement (eighting criteria of how well he proposed soliton moots the requirements my also be incl ‘When developing REP questions, avold using closed ended questions (those requiring onlyshort answers). The gost stimulate the Yendars to provide extensive informa ‘on regarding thee produet and sesiceoeings, ‘Mog RFPs tncuce many seetlons or components. Examples include Business stakeholder requirements forthe particular prublen/solution area > Business steategy or busineysacchitcture deyeription > Textinioal environment constesits/imitattons > Legal regulatory of government requlcements | Ta aR A aESbsirnmionienticnraninn | Fae ‘The supplier may bo asked 10 subatspediielaformatlon, Examples include > Solution cost or ttl cost of ownership Alignment with anetl ba > Solution atchitoeture, perormanes, quality, sad support > Solutions extensibility and abi y to Integrate with other applications > Supplies sustainability, and/or suppliers profile and reputation 446 Stakeholders Domain SMEs and tnd tserst Nev requirements that ar writen using far teriinology and that are eos to understand an review. They must lly understand feaeh requirement, sine it sthis group that wl be most affected by the solution mplemented This group willbe primarily eonceraed how operational processes ace a= fected by the implementation of he projet, and will be intrested in ensaring thatthe requirements they provided to the business unalyst during the requirements elicitation fareachioved 1 SMEs: Need to obtain an understanding ofthe averall reuters forthe projet, and will feus on requirements they will use to design the solution. External customers and sapplers will ned detailed technica interface requirements toorder to constrict the proper network end security protocols in accordance with saeperale pices Project Managers: clade deliverables including specs regulrements packages) the projet plan and typically tack them as milestones to asses project progress, The ddlivcrable ats as “eonteact” forthe project dining the agreed upon work, I dlis- erable becomes project asset beeaus it fepresents a project curpat Regulators: May have spocficlgal, contractual of governancerequirements regard Ing what Isineie na equirementsdocument. Sponsors (and othcr managers tthe execs level Often want summaries and igh-lovel requirements. Tels priwary goalie to understand that thesoltion will meet the returmon investment expectationsin accordance with heir business plan nd ‘mininize the ime required for them to ake an elfetive decision, The project scope ‘a sieeinclading the HOI (Hetuen om Investment) atsesment, business benef projet cust apd target implementation dat) Testers: Focus on undorstanding th critical suceoss factors ofthe rojestbasod on the esol the businessusers They must acquit thorough understating of the fan tonal and non-anctional requirements in onder ta hui un effective resting strategy. 4ar Output Requirements Packages The result ofthis task sa requirements document, presenta oe package of requirements ready ta he reviewed by stakeholders. A package may ‘contain al othe projet requirements or may be brokun int several eub- packages a aD EsComa n 45 Communicate Requirements asa Purpose Commnunteating requ derstanding eeqatemsents ots isesentlal for budnging stakeholders to common un 452 Description Commmunienting requirements inludes conversations, notes, dacuments, presenta tons, and discussions. Concise, appropriate, effective comonunication requires that thebusiness analyst possess asghicant st of sills, hath soft commueation) and Acchnical requirements). See Communication Skis). Figure 4 Communicate Requirements npuv Output Diagram i Inputs y ] (A FB 1 ou Requirements Requivements | Requirements (Commuricated) Tasks Using This Output | i i aT Manage Solution 1 Lsepeand eats 453 Input ‘Business Analysis Communication Plan: Defines what information sto be comrns= scat, which stakcholdersnced to receive, when communication show neon and the foren it should aceuein, Requirements: Any requirement maybe communicated. | Ta aR A aESbsirnmionienticnraninn | ER Requirements Packages Requirements may be communicated without being ina requirements package, butil a package: has been assembled, must be dstibuted, revlewed, and the contents must be communicated to stakeholders 45a Elements 1 General Communication equitementscommniction is performed iteratively and in eonjenetion with most of thetasksin Une other knowledge aceis, ‘Notall ommunication can or shina be planned, and informal communication of requirements likely be needed during Ue pestrmasce a ios! business aalyss ts In many eases oquieements comimunicstion may lead to ciation nr adation alrequirements > Enterprise Anulysis Tasha: usiness case an solution seoping information ks connnnnicated > Blicitation Dasha: Each clcitstion technique requices specific comamunica sills Comminiention of reqitements maybe sel diringeieitation ac ‘a may help atakebolders to iden aller related requitement, > Requirements Analysis Tasks Requirements re tefoed, endif, laid and finalized Uhrough clcctive commbniention > Solution Assessment und Validation Tasks: Assessments of the solution, slluca- hinn of requirements to solution components ofganteational readiness nd trans tion quirements all must be communicated. 2 Presemtations Before making any presentations of requirements oan audience, deteresine an ap propriate format for the presentation Te formality ofthe presentation is driven fy theabjectiveaf the communication and the andieace needs Far example, Une business analyst may be rogulted to present key points using «formal presentation using pre Station slides an handouts Tisanay be desirable when presenting bo senior bus nese representotives who ars not actively in ths deaf the prejct bt need Ao understand requirements a higher level, A presentation may be use > twensucerhat internal profet quality standards have been adhered to 1» toemurecrostfunctional fit with other business process areas within the same projoct » toebtain business acceptance and sign-off > to ebtain delivery tea sga-otl > tooblain testing team siga-off asa precursor to delivery. (eg examining solution options witha delivery tearm) a aD EasComa n > tn priortizea set of requirements before proceeding to next project stage > to make decisions regarding anton scope Formal Presentation Formal proseatationstypially disseminate information in. well organived, true tated formal Audience members may he given supporling materia before or due, the presentation. Audienes petiinatinn questions may he enesiraged Informal Peseneation ‘Nn iniemal peso aye use san informal statis check of eequirement (eg completeneas correetnent empact ‘nother areas. > t0-commanicate rquizemontsto the delivry team or testing tam ro ensure there isnoambiuity, > to communicate requirements to affotest business areas those rot having sano authority but where knowledge of changes require) > to communicate requisements to other project teams asa facilitation exercise to enhance requirement clarity. For example-by bringing business users and techni cealteams toyeter, «common understanding can be reached on the relevance? Importance of nalvidval requirements as wel asthe feosbity of delivering ind idaalrequiremes 455 Techniques Requirements Workshops (9.28) Hequirements maybe presented as part ofa ee ‘quirements workshop to failaeize al partis with Ue existing luton seope aed th Structured Walkthrough (9.24): structured walkthtougl often begins with are iw ofthe requirements toe dsenssed 456 Stakeholders al 457 Output Communicated Requirements: Slakeholders should unaerstend what the require sents are and Ptr cnr tae, | Ta aR A aEChapter 5: Enterprise Analysis tenet The Enterprise Anas Knowhedge Ares describes the business analysis activities necessary to identify a business need, peablem, or opportunity define the natuee ara solution that meets that ned, ad justify the om ton, Enterprise analysis ‘on Mdeatiication fora given intativeo for long-term planning. Enterpese analysis often the sarting point forinitiating a new projcet and s eontinied as changes occur ‘und moreinformistion becomes availabe. is through enterprise analysis activities "hat business requirementsare identified and dcumente. IM describes the business analysis ativitos that take place for organizations tor Analyze the busines situation inorder to filly understand business problems and fepportunites Assess the eapabilties of the enterprise in order to understand the change needed tw meet business needs and ahve strategie goals > Determine the most feasible business solution approach > Define the solution seope ad develop the business case fora propose solation » Define and document business requirements (including the business nee. required capabilites solution seape, and business ease) Note: the perlorrance ofall enterprise analysis activities are governed by the business tanalysis plans (sce 2), and business analysis performace metrics shouldbe tacked (eee? Figure Etrprise Anos input Outpt Diagram suiaon hae ioe meme Define Business Need Purpose entfy and define whys change to organizational systems or capabilities required,cn teste 5A2 Description the dfniion ofthe business need is frequently the most eetical step in any business analysis fort. The business need defines the problem tha the business analysis "Uyingto find solution fr. The way the business ned s defined determines whch al ternative solutions willbe considered, which stakeholders will be consulted and which solution approaches wil be evaluated. Figure 5-2:Define Bans eed npcutput Diagram Inputs iO i i i ' buses Goals Reaurements | i | and objectives rated] Ba Define husiness Need 2a 3a Pan Business Prepare for ‘Analysts Approach Fiction aa Conclet lctation ‘atvty ea Prince Requirerer Sn | Ta aR A aESerine aT An issue encountered in the organization, such as customer complaat, los of re fie, ates mart opportunsty, shally triggces te evasion ofa hasinogs need, Wiscommon or organizations to aet ta resolve the Isue without investigating the tunderiing business nced, Thebusiness analyst showld question the assumptions and ‘straints tht are generally buried lathe statement ofthe issu to ensure that the oetect problem ilheing solved snd the widest poatblerangeafaltemative solutions reconsidered. Newbusiness needs can be gencrted in several different ways: Fenn the top dinvn=the need tn achieves stale gal From the bottom up - problem with the current state of proces function or system > From middle mangement 9 manager needsadditional information to make sound decisions er must perfarm adltanelfunetians ro meat business aeetves > From external driver driven hy custorner demand ot business competition in the marketplace 513 Input Business Goals and Objectives: Business goals and objectives usually have tobe tefloelim order tn define the husinews need In some cases the goal or objective may be exploratory—thebusines need may be tounderstand fa methodology o business model can work Requirements [Stated Elicitation must be performed in onerto assist take rs n dafining tele perceived novds, Ensure tht they role aetual business require nents, as opposed to desenbing soltions 514 Elements 1 Business Goals and Objectives Basiness goals and objectives deseribethe ends that the organization is weckinu to schicve. Goals and objectives car teate to ehangosthal the organization warts to ae eomplish, or eurcent conditions that it wants to maiatain, ialsare longer term. ongoing, and qualitative statements ofa state or condition that Uheorganization i seeking to establish and maintain High-level goalscan be decom posed to brcak down the general strategy into distinct focus areas that may lead to ‘sired result, sich as increaued customer salifacton, operational excellence ade bbusinss growth, Foeus areas are usually dseribed in bret statements, For exumple. sal may be to “increase ighcvene customers snd thea farther reine into x yoal {oineroase high reverts custorers through mergers and acquisitions” As goals are analyze they are eonverted into more descriptive, granular and specific ‘objectives, and linked to measures that wake it possible ts objectively asses ob jective has been achieved. common tes for assessingojcctves ie ena that they mreSMART a aD ascn teste > Specie desertbing something thut hasan observable outcome > Monsurable tracking and measuring the outcome b Actievable = esting the eiity af the oe > Relevant = inatig eat with the organizations key vislon, nso goals > Time bounded theabjctive hasa defined timefeame that is consstent withthe busines eed 2 Business Problem or Opportunity Inter to den business need, an issue must be investigated Yo ensue that there Jsin fet an opportunity for improvement ifthe issue is esoved, Factors the business saat may consider includ > Adverse impacts the problem fs eausing within the organization end quantity those impacts (eg, potential lost revenue, ineBciencies, dissatisfied customers low em ployeo morale > Eypeeted bends fom any potential soliton (eg increased revenue, reduced costs, nereased market sre) > How quickly the problem could potentially be solved or Aaken.and the coat of ding nothing, ‘opportualty could be > Theundesyng source of the problem 3 Desked Outcome desired outcomeis ota solution t desesbes the business benefits al will result from meating the business nced and the end state dosited by stakeholders, Propasea solutions mua be evaluated syainal desied outcomes enaurethat they ean deliver ‘hows outcomes, Fyamples include » Create anew capability sch asa new product or service, addressing a competitive disadvantage ot erestinga new competitive advantage: > Improve revenue. by increasing sakes oF reducing cost: > Increase customer satisfaction; > Increase employee satisfaction > Comply with new regulations > Improve safety > Reduce time to delivera product or service Desired outeomes should address a problem or opportunity and suport the business pnts and objectives, | Ta aR A aESerine TE 5A5 Techniques. benchmarking(9.2} Understanding what competing organizations nl peers ae doing llows the organization to cemaim at a comparable evel of seview ot eaiy op portunities to increase eficeney eainstorming 9.3) Gone te insghts nd options. Businoss Males Analysis (91): Identify changes nthe policies that guide the organiza tion towardsachievingts goals and objectives, ocus Groups (911) Fodeutfy and discuss problems Functional Decomposition (0.12) Convert business goals into achlevable objectives sind measures Root Cause Analysis (@.25) Determine the undeying source o problem. 516 Stakeholders Customer or Supplier A business need! may aris rom actions taken by or needs of customer or suppller. New oppartuniics offen arise aan unmet customer needs Mente, Domain SME and End User Likely toiwve the sist direct awareness of problems oF limitations thot oxst n curontsystomsand the eects those have. ME: Maybe awareafcapabiltieseurtently present in orea audded to existing systems that may provide now opportunities. Regulator: May impose new regulatory or governance requirements om the organiza Sponsor: sponsor must he ented within the onganzaton who ks responsible for ‘aking sure thal the business need is met an who ean authorize action to meet Say output Business Need: A business need deserbesa problem tha he organization sors likly to face, oF an opportunity that thas wot Laken. and the desiced outenee. The business need will gle the denteation and definition of possible salts, 52 Assess Capability Gaps 52.1 Purpose Ta identify new capabilities requee by the enterprise lo meet the business need 522 Description Assos the current eapabltics ofthe enterprise and Mlnty the gap that poveat I {rom mostng business ncos and achiving desired outcomes, Determine ts pos: Mle forthe organteation to meet the business net using existing structure, people, processes and techulogy. the urganization can mos the business now with existing feapablite, the resulting change is Mkely 10 heelatvely small a aD aseee 523 apabilities are inadequate, tt will probably benecessary 1 launch project to reat that capability Change mayhe needed to anycomponent ofthe em {erprls, including but ot linited to} business processes functions, Hes of bslies, organization strctres, taf competencies, knenledge and il, training, facilites, desktop 100 urgantzation locations date and Information application systemsand) for technology infrastructure, Figure 5-2: ses Copal Gop np Output Diagram i Inputs y ! ifs | usinassNeod —Enierprse Solution j i scene pertrmance 1 ‘Assessment | Assess Capability Gaps sa Required Capabites a We . Tasks Using This Output ry a Determine Sout | | Define Solution ‘Approach Scope 5 Requirements Mg Verity Requlements |_| and Communication ‘Business Need: Capabilities are assessed against the business ed to identify gaps Input Enterprise Architecture: The enterprise arettectre defines the current capabilities ofan ganization (i ete ins Aina ad of airedSerine TE Solution Performance Assessment: Mentiisshorteoanlngs,peublems.orUeatatons ‘fon existing solution. In some cases a aation may have capabilities hat an ong flzatlon snot using (most often, this occurs with a package solutlon or with out Sourced services) which can alsa be gaseased agains! a business need 524 Elements 1 Current Capaity Analysis {Gathoras mutt ontorprise arehitectuse information as avallableabout the eutcent state of the areas of the enterprise affected by the business need. the gol is touinder Stand the organization’ business and how the business and technology architecture fresupnorting that bisiness, foot information ft available, il bene ‘essary to develop the models and other doserptivetaformation about the are ofthe fnterpeiethat finder reve Once the curtenteapabiiticso the enterprise are fully ‘eseribed, they must be assesoed against the desired objectives to deleramine whether "hectganization curently basthe capabibty tomes the hosinest es 2 —_ssessmentf New Capabitty Requirements Ieurrent capablinis are insurficiet to moet the business need, the husiness analyst sms identity the capabilites tht need to be added. The business analy il develop thomodelsand other descripnvo information about the future vison and describe the fuucestate ofthe organization. A comparison of thecurcent aod desied future states ‘will dentifygapsin organizational capabiitics that acc tobe filed ro suppest tie business vision, atratouy, goals and objectives Some examples of eapubilitsinelude > thusiness processes > Features of software upplication > Tasksth end user may perform > Events that «solution 1 bo ablero respond to Products that an organization creates > Secviews that an organization delivers > Goals thata solution will allow stakeholders to accomplish 3 Resumptions ill often be difeult ot impossible prove that the dulivery af new capability will ‘meet a business need, even cases where it appears reasonableto assume tha the ‘now capability will have the desird lfc, These assumptions must be dented and clearly understood, so that apprapeate decisions canbe made ifthe sumption lee provesinvaid. 525 Techniques Document Analysis (9): Useful to understand the current state ofthe enterprise, it fsmich as that current state s documented, a aD asi SWOT Analysis (0.32): Kentiy how custent capabilities and Hinttations (Strengths fad Wenlscsace) natch up againet the influencing factors (Opportunities nd threats 526 Stakeholders Customer and Supplier: Customen and suppliers may e impacted ithe business de ‘eloped or change the capabilities thas, Zhey may also bein postion to provide or suport new capabilities themselves, rather than reqiring the organization te change wonder to provide them. Domain SME, Ead User, Implementation SME, and Sponsor: Wil provide inform: onthe strengtisand wesknesses af eurtent capabilities, 527 slerstanding of the curren capabilities ofthe organ ina ton and the new capabilites (processes, stall, eaturesin an application, te) that may be requted tome the business need 53 Determine Solution Approach 53a Purpose ne the mot viable solution approach to meet the business need in enaigh detail wo allow for definition of solution scope and prepuce the business case 532 Description The solution approach describes the general approsch Usa will be Laken to create or que the new espabiltes required to meet the business need. a determine the olition approach, x nccestary to identify posible approaches, determi the means by which thosoation may be delivered (including the mathodoogy and fete tobe ted) and asexs wheter the organization ix capable o implementing ad ellectivey ‘using soliton of hae nara Some possible approaches include > Uiiliz addtional capabilites o existing software(hardwvare that already avail able within the nganation > Patchase or lease software/harrare from a supplier > Design andl develop custom soware Adi rsourees io thebusiness or make organizational changes > Change the business procedures processes Partner with other organizations or outsource work te suppliers 533 Input ‘asiness Neods Possible solutions willbe evaated against the business nee ton sure that Icon be met by the aslcted approach Ss Ta aR A aE