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Serine aR Organisational Process Assets The orgenizaton may require thst specie approach cesbe taken to solutions ofa iron typ (eichar specie metiodologies. Required Capabilities: Metifes the new capabilities that any solution must support Diagram Inputs Put ; ct ausinsstleed Organizational Reguled | Process Assets Capsbilties | sohion Approach v. i i i u 534 Elements 1 ternative Generation entity as many potential options as posible to meet the business objectives and ‘eniied gaps in capabilities The list of possible aternanives should ined the option of doing nothing as wll as investigating allernatives That ay allow the organization tobuyi While there ino har alfa lethal cam be use te dlerimine when enon natives have been instigated, some indicators are: er Atlcast one ofthe alternative approaches is acceptable to key stakcholdcrs: a aD asi > Atloast some ofthe approaches aro distinctly diferent fromone another > Thecffor to investigate alternatives ts producing diminishing returns, 2 Assumptionsand Constraints Assumptions thet ma affect the chosen soktin shold be ential Certain so Won may beewkd oul because they ate believed ol lobe viable technically ot for cosh, reasons chile other approaches maybe believed tobe easier to exseute then they ro ally sre. Similarly, the organization maybe constrined fem pursuing certain solution ‘options fr eontractiaensons or because they do tft withthe iniractrctre ofthe ‘teanzalion,Assurptions and consteaints shoul! be queeLined Lo ensate Ura ey srevalia 3 Ranking and Selection of Approaches In order w asiss am approach, eco availa and aaalyre the oper tional, economic technica, schedule-based organizational, cultural, gal and mar oting feasiity. Capture consistent infnrmation fr exe option to make easier to ‘compare them and vie results to entre accuracy and completeness Insc eases aparticularsolution approach may prove tobe sel-evidently superior {otheallernatives. this tno the case solution approaches ust he asacsaed an ranked. there are only afew critical dillerenoss between solution options it may be sable to make qualitative antenement ofthe dilferencenin order ta male nclee ton, For more complex decision problems, aseoring syst must be use elated requirements assigned 4 weighing a eflect thei telatveimportanc ‘organization. Each solution fs seored und the top-rated solution o solutions are then Investigated in greater deta fetaof othe 535 Techniques 4 General Techniques arking(9.2) Kdentify sultion approaches that have proven sective organizations. Resinstorming(9.3): Used asa method of generating alternatives Decision A is (.9) ask and select possible sltion approaches, (@.10}:Deveop initial cost comparisons of possible solution approaches SWOT Analysis (9.28): Usefl method of comparing possible aproaches. 2 Feasibility Analysis or small relatively atraightforward efforts, he slut approach can be deterined by the business analyst alone or with asmall team of expertsexamining the approach: {man informal working session. Fr lange ehange initatves requiring significant investment more formal fensibilit sucly may asist with determiningthe most vic slo solution option, feasibility study is 2 pretiminary analyie af saltion alternatives options ta deter ‘mine whothor and low each option ean provide an expocted business benalt to met S| Ta aR A aE53.6 537 54 Serine aR thebusinew need A fossil study may addresselther a business problem tobe re solved ge hasiness oppaetunity tobe expleted arma easbity studies lable ‘lta and apply tastes aud market research to identity and analyas potential solution options The feasibility analysis is an integral pact offoraolating a major business transform ton projec, eg, reengineering a core business process and sporting tschnnlogs estulishinga new ine of business, iacreosing market share thrgh aequisitinn, oF developing now product ae series Abbreviated studies may also he conducted for charge initiatives equiring lower investments Stakeholders Customer, Domain SME, Ed User und Supplier May beable to provide suggested spproaches and ilenty assueaptions and eonstralts {Implementation SME: Wil be nese to assess the feosbility of possible approaches. Sponsor: May be the source afcunstraints onthe solution options and wl key be required to approve the recommended approach Output Solution Approach: A description oftheapproach tha wil be tsken to implement 3 new st of capabilities, Solution approaches deserine the types of salton components {hat wil be deliered (new processes, a new software application. ete) ad may also ddeserihe the methodology that will he used to delle those components. Define Solution Scope aa Purpose To define which new capabilities projector iteration wil deliver, 542 Description The purpose ofthis task sto conceptualize the recommended solution iv enoweh deta to enable stakeiokers to understand which new business capabilities un initia: tivewill deliver. thosolion scope will ehange threnghout «project. based on changes Inthe business environment or asthe project seope is ciauged to mest budget, ie ‘quality orother entrain. The sition seape inelides > Thescope of analysis (the organizational unit or process for whick requirements arobeing developed) which provides the ontextin which the solution is imple sented > thecapabittes sypported by solution components, suc us business processes, organiational units and software applications, > Thecapabilites tobe suppoeted by inisidual eleases or ierations > Theenabling capabilites that are requlred ia order forthe argantzatlon to develop the capabilities required to meet the business need, BinOrGade Neier 29EE ‘Notes Ths task describes haw business requirements ae allocated fr inplomentation bya project. Sce-AlacateHaquirements (7) for a discussion of how stakeholder and salutlon coqultements av allocated to solation components und releases, Figure S-s:DeineSoatn Spe puvOutput Diagram \ inputs i i i “ al 2) a) i i i jasumpieand Sushenleed segues Son | Constante Cenaiies Anne | 54 Define Solution Scope 5a SetuTon Scope a Conduct Bictation | | Define businesscase cation Aatity i i i i i i i i ! 6a ez os ! i Prone ‘organize Vat Requirements | | 1 [Requirements Roquirerments i i i i i i i i i 72 locate Requirements 73 Assess Org Peadiness 543 Input Assumptions and Constraints: Relevant assumptions and constsuints nay inchide ‘estumptionsabout how stakeholders wll respond ta a nes product oe service or about {he availability of technology. Constraints may include imitations un what may be Included inthe solution scope. Include any seheduleo funding imitatonsand signi cant standards, policies, regulations tobe followed and supporting data required Sn] Ta aR A aESerine aR 54a 545 BinOrGade Neier 29 Business Need The goals, objectives and desired outenmes ofthe organization oquieed Capabilities: escebes the new capabilites required to moet the business weed, which serve us the basis forthe solution scope. Solution Approach: The general approach taken to delivery ofthe new capabilites tequited by the business will be used when assessing options for the implementation of solution components Elements A Solution Scope Definition The solution i described 1n terms the major featuresand functions that are tobe ‘luded.and Ue iterections that thesolatian wall have with people and systems outside ofits scope. State n-seopeand out-of seope components ofthe solution. Deserve the business units that will boinglved, business provesses 10 Beimproved or resigned process owners and IT systems and other technology tht will key be affected 2 Implementation Approach The implementation approach describeshove the chosen solation approach wil deliver (He solution seope. For example, I the soliton approach lnvlves partiuonlng the pro pos projet fo releases hat wil dliver use snbsets of functionality tothe bas es, the implementation approach wll deseribe the functionality in each release and the timeframe that tisexpected to he delivered in. the soktion approach involves jutsourcing key prveesses the implementation approach wil define Which processes frecandidates for ontsourcing, or the process hat willie asc to dent those cand ‘tes The nuplementation speach may break delivery down into specific releases ot ‘rode roacimap that indicates the timeframe sn which « eapabslty can he expected 3 Dependencies Define major business and rochniealdependencles that wil impose constraints tothe sllort to deploy the solution, including dependencies that may exist botween solution feomponents Techniques 1 General Techniques Functional ecamposition (9.12): To understand the seope of work and to break the ‘otto seope ito smaller work prods ar deliverables Interface Analysis 21}: epic the scans of work required to integrate the nes sl to the busines and technical envirouments Scope Modeling (9. dontfy appropriate boundaries fr the olution scope {User Stories (9.88)-Deseribe stakeholers and the gals the system supports and as such ean also be used to defi the solution seapecx nes 2 Problem or Vision Statement A problem or vision slatement states the busines nee, identifies ay stakeholders and brety describes the postive impact that-mecting the business need will have on those sfakehulders Figure 5-6 Example Problem Statement The problem of Describe the problem. Atfects The staksholders affected by the problem. The impactof which is | Whats the impact of the problem - on each stakeholdet ‘Reuccorsfal solution Asuces List some key benafts of asuccessful olution 546 Stakeholders Domain $M Wil patieipate in demtitying the affected organizational units, model Ing the scope ofposiblesolutions and determining the rative prioitics of the re ‘quired capabilites, pate the allocation of capabilites to solution eompoments and in determing the time and effort reguteed to deliver new apa Project Manager: May ait wit the development of the overall solution sone, yet willbe used ae input ito the Projet Charter he projet manager is esponsble for the detiikon of the project scope, whic is the work cqulted to deliver te slution scope ors poetice aft The project manager wil playa major role i alloca exp bilities to components and wll be primary responsible for determining the time and lle tonite ta deliver xexpabilty Sponsor: Will participste in sating priorities and approving the solution seope SAT Output Salution Scope: Defines what mua he delivered in oder to meet the business ned, tnd the effect ofthe proposed change nititive on the business and technology oer tions ad infeateuclare 55 Define Business Case 55a Purpose To determine fun organization can justify theuvestment reguiced to deliver aprox posed sation 552 Description ‘Te husinesscasedesertbes th }usieation fr the projet in terms the vale io bbe added tothe business asa resal ofthe deployed solution as eompared to the cost S| Ta aR A aESerine cre todevclop and operate the soluthon, The busines case may also incu qualitative and quantitative enc its estimates ofeost and time to break even, profit expects {Hons and fallow on opportunities, The busltiss case may present expected cashflow consequences ofthe action oer time, and the methods and entionale that were used for quaotyiag bevels und cust. This provides framework to deraonstrate how the Initiative expected ta achioee business ahjcctive. In addition thr business case lists theconstraints ussoctated with the proposed project along withthe estimated budge, and alignment with strategies established by the organization, Figwe57:efn urns Core InpetOtput Bagram Fe | Assumptions usinessNeed Solution Stakeholder Constraints Seope Cancers 55 Define Business Case busineecase v a 32 Prepare for Conduct Bictation Pelee Elation etry Requirements or er Requirements ge ery Requlements valcate and Communication Requirements 553 Input Asoumptions and Constraints: Include assumptions about tho roveaue generated ot etiind bythe soliton ur pon-inancial improvement will delve: ‘Business Neods Defines the value that solution will diver to the organiation and a aD asDefine Busines Case 534 535 wow italigna with the business goals and abjctives. Salution Scope: Defines the capabilites that will he Implemented, the methods that will used to deliver thom, and the areas ofthe organization that willbe affected Stakeholder Concerns May include rsks or asues that must be aecousted for inthe business case Elements 1 fenefite Meusure the bonelt of the recommended solution in terms ofboth qualitative ‘quantitative gains o the enterprise. Where possible, beneftsshould he quantied. Ben sis ofa non financial natuce (sel asimproved staff morale. Increase exiblity core spond to change. improved customer satisfaction, o¢ reduced exposure risk) are also Important and add significant value tothe organization, even If they must be assessed qualltatvely. Benefit estimates should relate back to strategie goals a objectives 2 Costs timate the tatal net cost ofthe solution. Thisrequirs estimates the made of cap {al expenditures fur the new lnvestment, costs of developing and laplementing the change. opportunity costs af not investing in ther oping, costs related to changing the won. and practice othe organlaation, total eos of ownership to support the mee solution and consequential eostsborne by others. 3 Risk Assessment The pnrpose ofthe nti rsk assessmont Is to determine ifthe proposed inate car es more isk than the organizations willing to bear, “Tis inital ak assessment focuses men on solution feasibility risks, andi revisit throughout the project. The risk asessment should consider technical sks Goethe ne chosen technology and suppliers can delve the roquicd fanctionality. finan fal risks (whether cont my exteed levels that make the slition viable or potential bbenlits may disappear) and business change and organizational risks (whether the organization will ae the changes necessary to benefit fom the new slution), A Results Measurement The husinessense articulates aot only the projected costs and benefits to be realired, but also how thasveests and benetits wil by assessed and evaluated Techniques Decision Analysis (3.8): Cost-hencht analysis compares the cotsaf implementing « solution agaist tho honsits tobe guined, Financial analysis includes the uso of finan Sal model that estimate the market value of an organizational agse orveast he sas ofthe investment regulted fo deploy the proposed solution. Wl operate Metrics and Key Performance Indicators (9.16) Assessed tosupport benefit anage- ‘meni. measurement and reporting, inehiding where realignment af internal measures (i ete ins Aina ad of aired55.6 587 ness Case ‘oc systems Ismoded to ensue that the behaviors we aro seeking can be sou, eval sted, and realized. [isk Analysis (9.24): Used to assoss potential iss that mayimpactthesoluion and thecosts and benefits assoclated witht. SWOT Analysis (2.32) Demonsteate how the solution will help the organization aa ‘mize strengths and minimize weaknesses. Vendor Assessment (9.89): Ifpurchase or outsourcing toa third party isin consider- alla, un assessment of the vendor may be performed ss pao the business cas, Stakeholders Sponsor: Approves the business case and authorizes funding. Domain SME; Assists Jn estimating business benefits expected fom the ew initiative {Implementation SMU: Assists n estlmating eos projections forthe teehnalogy nee to support the ne slation. Project Manager: Participatosin developing time and cost estimates and may develop preliminary project plan or Work Breakdown Structure in eollabortion withthe projet team, The projcet managor will use the business easeasun input for a project sharter Output ‘Business Case: Presentsthe information necesary to support a go/no on decison to invest and move forward with proposed projec.Copyrighted materialCOE tea ee UE is | The Requirements Anatsts Knowledge Area deserbes the tasks and techniques used by sbusinessanalyst to analyze stated requirements ordet to define the required esp bilities ofa potential solution thet will fulfill stakeholder needs 1 covers te definition of stakeholder requirements. which desribe what a soliton must be capable of doing tomeet the needs of ane or more stakeholder groups, and solution requirements, which ddeserie the behavior of solution components in enough etal to allow them tobe feonstrueted, The tasks in thisknowkedgeares apply to both stakeholder and solution quirements Inaaldtio, requirements analysis may he performed to develop models ofthe eu teal state ofan organization, These domain model s useful fr valldating the solution scope with busines arel technical akcholder for analyzing the current sate ofan ‘organization to kentiy opportunites for inpeaveaent or for assisting stakeholders in understanding that current state, Note: the performance ofall requiremets analysis activities are governed byt business analysis plans (see 2.8}, and business analysis performance metrics should be tracked (see 2.6) 64 Prioritize Requirements 611 Purpose Priortzaton ofrequirements easures that analysis ad implernenttlon efforts focus ‘onthe most critical requirements, 612 Description Requirement priaitzatin it decision process used ta determine the relative impor: tance af requirements, The importance of requirements may be based on thei relative ‘valu rsh difeulty ofimplementation, or un other erteria, These priorities ate used to determine which equiterents shouldbe tatges for further analsis and to detorinive which requirementsshould beimplemented fist613 Busines ace BushessNeed Requirements Requirements Stakeholder Management List Roles and Plan Responses 4 ») an ar Prottice Requlrements et Rogakarients [Priore Requizements Mat and Communication Input Business Cane The usin case tates thekey gvalsand measures of succes fora projet or otganiration, and priorities shold be aligned with those goalsand objce ‘Business New Servesasan been define, ebusiness easel no business cases Requirements: Any requirement maybe priortized st any point ints lifecycle Re- ‘quiementspeiontization require that requirements have been stated by stakeholders however, the cequiements may not have been fully analyzed orn ther final form Requirements Management Plan: Defines th process that will beused to prcitie requitements (i ete ins Aina ad of airedStsinniii Fa 614 BinOrGade Neier 29 Stakcholder List, Roles, and Responsibilities: The ist ofstaksholders annotated with their eeclsof anthorty and infizence is usd to determine which stakeholders ‘edt participate in prfdtization. Elements 1 Bass for Prioritization equitements may be prioritized using a ube of tilferet ecteia,snekuding Business Value: This approach preritizs tequircments based on cost-bencit analy sisof their relative value tothe organization. The most valuable requirements willbe targeted for development first, This approach iscommon when ealaneiny an exiting solution that already meets speciied minimal requirements or witen delivering the slain increta Business or Technical Risk: This approach selects roguiroments that preset the igh cst isk of project fatlare. Those requirements are investigated and implemented Mrs to ‘ensure tht ithe project fallst docs so after astiilcexpendliture as possible Implementation Difficulty: This approach selects rusements that are easiest to mplemeat. This approach is olten selected dung «plo of new development process ‘or tonisorwhen rlling outa packoged slatinn, ast allo the project team to pain family with those hinge ik working on loer-ish vequirements. Likelihood of Success This approach fous on the requivements that are Bhat produce quick and relatively certain successes, Its common when a project is contro ‘eral and ently signs of progress are needed to gain support forthe egulatory of Policy Complianees Thisapproach prortizes requleements that mast be implemented in order to meet repulatoryur policy demands imposed un the organ ‘aton, which may fake procedence ar other stakeholder interests A requirement may nal be high vale in and but may support other high-priority requirements andas such may be candi Ade for early implementation, Stakcholder Ageeomonts This approach requires the stakeholders to each conven suson which requirements are most usefl or valuable. tis often used in combination ‘withone or mote u the other approaches descred sbove. Uegeney:Thisapproach prioritizes requirements based on tine senstsity 2 challenges CChallonges in facilitating aroquirements prioritization session include Non-megotlable Demands: Stakcholders attempt to avoid dicot chetes flo recognize the neces or waking tradeots oF deste fo rank all exulzemnts as high Jeol The solution development team may intentionally wninter nally tp to influence the ress othe preritivation processby overestimating the Aliculty oe compleity of lplerentng certain seulProne Requirements 615 Techniques 1 General Techniques Dechton Analyals (9.8: Decision analysis maybe used todentifyhigh-alue require- sents isk Analysis (9.24) Hesjirements thal ane considered risky may need fae invest gated orinplemonted fist, s0 that ifrisks caus the projec to fall, the organization ha pveste as itl as posible a that pont 2 Moscow Analysis MoSCoW analysis dives requirements into four categories: Must, Should, Cul, and ‘Wom. Category deseriptions ares follows Must: Describes requirement that mist hesatisfied in the final soition fr the sol wo be considered success, Should Represents ohigh-prorty tem that should e incladed in the solution Fibs possible. Ihsisoftn critical requirement but one which cum be stise! in other ‘ways stretly neces Could: Describes a requiement which isconshered desirable but not necessary. ville included if time and resources peril, ‘Won't Represents. quirement that staksholders have agreed ill not bosmplemont: cel a given solease, bul may be considered fr the future 3 Timeboxing/Budgeting ‘Linebexing ot budgting priottios requirements for iavestigation and ienplementa- based on alloition a fxed resource. tis used whem the solution approach has bbeen determined, Timeboxing pisitzes requirements based on the amount of work that he project teams capable of delivcring iw set period oP By eonttast. bud stingis used when the project team has been allocated axed amount of money. The proach is mos! often sed when a fixe deadline mast be met or fr solutions that ate ‘enhanced on regular and frequen! basis There area nuuber of approucies thal ean Doe taken to determine whieh requirements en hetnelade in atrnchoxed erations » Allta: Begin with ll he ligible requirements with esagned Duration oF Cos Remove the requirements in order to meet the etlendar dates or budget lm, > All Out: Bogin with adding the requirements) with assigned duration or cnt to Iiecalenar or dye Stop when the caer dates ace mel ot budget reached Selective: egin by identifying high privity requirements edded tothe calendar or ‘budget, Add or remove eogurements in order to meet he clendue date or budge. int A Voting Yoting methodsallacote a fixed amnint of resources fotes play money. rather {okets) to each parlelpant for hem tu distribute aniong proposed features or eegulre (i ete ins Aina ad of airedStsinniii ce The requirements that receive the most-resources are the ones that willbe investigated or devcloped sh, Domain subject matter experts nay be iwied to parteipate inthe pe lative business need and to egetiute their cortization of requirements, to assess th Importance SIE: importation subjet matter experts may be asked to ye complexity or rak asociated with the implementation of certain Project Manager: The projget managers responsible for th solution and will use the priosty of requlecments as an ig implementation ofthe nto the project plan. ely accountable forthe business solution and nae discussion Sponsor: Since spunsors ae Joe prajet decisions, hy ned oe invited to participate fn 617 Output Roquiroments [Prloritized|: prioritized requirement hus an attribute tat deseribes its relative importance a stakeholders and theorzanization.Atthe completion of this task, cach requirement should have an assigned priority The priorities may apply toa fequitement ar oa gron or related requitements 62 Organize Requirements 621 Purpose ‘The purpose of organizing requirements to create a st of views ofthe requirements for tho new business solution that are comprehensive complets. cnnsistnt. and under stool rom all stakeholder perspectives. 622 Description There are two key ebjeetives when organizing requirements Understand which models are appropriate for the business domain and solution seops. > dentiy model interelationships and dependencies. euremets alone are not complet she eltionships and fterdependencies among tequiterens that fda the elementof complexity. Therefore, the organized requitement ist al ‘leat depict thetherentrlatanships beeen eequitements 62.3 Input Organizational Process Assets Des {information tht stakoholdersexpcct. the structures nd types of requirements Requirements [Stated equirements are stated in various forms as an output orn slistation activities, Stated requirements are the expressed desis of stakeholders, ‘which must be aalyzed toenstre that they fuflect a genuine need a aD a(roi Ressirenents 624 Solution Seope: Tho sleted requirements models must he sullelent to fly deseebe the sption seope fom all ceded perspectives igure 6-3Orgent eqements Input/Output Diagram 0 62 | cxosnzaona Requemmots —SoaionScape {reese ets 6a Requirements Struct nen nw We. “Tasks Using This Output Prepare Reats Elements “The following levelof quality !delines will asain promoting consistency. epeatabilityand a high Follow onganizational standards that describe the types of requirements that will De used consistently on profcts Maw standard exits the business analyst solet an appeopriate seta techniques > Usesimple,consstone definitions foreach af the types ofrequircmentsdeseribed jnnatusal language and using he buss terminology thal prevalent im the enterprise. > Document dependencies an interelaionships among requirements » Produce consistent set of models and vemplates to document the requirements, fs described In Specify and Bode quirement (63) (i ete ins Aina ad of airedStsinniii ce “Tho various levels of abstraction and models used are not mutually exclusive Twill tasolly hehonrfial to creste mile mls and perspoctivoron tha reqwirements Inonder to ensure understanding hough any given reqlement should any appear jnone mndelin order to avoid confusion or contradictions. 1 Levels of Abstraction Requirements un be artlevated ona aumber of different levels af astracton, Re ‘auirements ae requently described as needing to say wha nevus to be done, not ha do it. Ths formulation can be peablematie, as whether something ia “What” ora “ho” deen the pspective the su, or tance sn to ple nl htenens procera minagernent ve what we are doing (rom the perspective ofthe projet team) and how we ure improving our process agility (fom the perspective af the entcrpese azchitecture group), When peacticingbusincssanaly- ss, wecan distinguish between what and how by understanding that our perspective ‘onthe difference hetween those terms needs tobe aligned with fhe peespoctive of out business stakeolers ‘Tere are a amber of formal structures or loves of abstraction including those out line in enterpeine chitecture frameworks Allertivey the business sralyat may informally designate aset of requiremonts as “high” of “Tow” love based an te leva of dletall included. While euitements often hecrme les abtract asthe business analyst defines business requirements, stakeholder requirements, and solution requirement, this is pot mandatory—any category of requirement can be exprased at whatever evel of abstraction ‘sappropriste forthe sudienos. Mothologies may alsa determine the evel of abstraction used whe defining requirements 2 Model Selection The husinessanalyst must deteemine which typesiof models willhe requieed to de serie the soliton scope and meet the informational aveds of stakeholders. These ‘aces may vary overtime Models abstract and simplify ality. No madelean be complete description of wea: theabjectieo® developing « modesto simplify eality ina way that suse Each ‘model representa ferent view ito the reality ofthe business domain tis usually necessary Io develop mliple models using different modeling techniques to caryplte Iyanalyze and document requirewents ‘Models do not have any inherent hierarchy effective analysis can potentially tart rthany aspect the model and reach out {encompass the others: For enaimpl, ust faseanalyts ean start with goals r events and cate peneessand relevant rules. osiness Process Management starts by ientfying wocesses end then derive roles ‘venta and rules from th processes. There area number of general modeling concepts that are rlevant to business analysis User Classes, Prolles, or Roles. these models categorize ad describe the people who ivetly tert vith a slat. Fach ole groups gether people with similar needs, fexpecttiuns and yoals. Each roles likely Lo cotrespund to astakcholder and should be investigated 9s source of requirements. Thesrate silly Memtied by poeforming Conduct Stakeholder Analysts 2.2) aula used ina numberof analysts models, par tlomlals i organ made (29) process madels (220). and se eases (220) a aD Pi(roi Ressirenents 625 Concepts and Relationships. Concepts usually correspond to something i the eal ‘world place a person, a thing, am organization, They define th objects entities or facts that ace elevant to the business domain and what relationships they have with other concepts Data madels 2:7) expand on thst alan desribe the attributes arson ‘ted with u cont Events. request toa business system or organization to do something, stich asa cus tomer placing order, or + manager requesting a report can bedeseribed as an ever The arganization must spond ton cveat, and in most cases an event will trlager at fect x business process, Events can come From outside the business area, from within A oroecur ar scheduled times. vents can serve as thelats fora segpe adel (2.27) and nay e described in other models, inching process models (921 stab digas (229 find ee cates 2.26, Processes Processes ate a sequence of vepeatabe atvites executed within an or nization, Process canbe simple tnvalving one peson and asyatem).or complex (involving many people, deparlments organizations and systems) Processes describe ‘who und whet hus 10 beineoved in fully responding toan event oF how peopl in the enter prisecllaborate to achieve a pal. Processes are normally describe it process ‘modele(9.20.ait\ough wsetul information may ak be eaptueed in organization models (49), state diagrams (2.2, oF we eases (2.26) ‘Rules. Rules ar used ly the enterprise enfore goals and gulde decsioa-maklng They determine hen information associated with an entity may change. what values ofliformation are valk, how decisions ave made ina process and what the gatas tions prortic are Isines les are normally described ax sch altho they may lve be embedded In process models (9.20, state dlagrams (229) and use cases (2.26), (Choose aset of modeling techniques that meet the informational neds afstakeholdors and allow description of ll ive concepts te ensure fll coverageot «business domain (assuming thar full coverage is equiee), Techniques Business Rules Analysis (0.4: Busines rules may be separate from other require ments forimplementation und management ina tusines lex engine or similar. Data Flow Diagrams (9.6) Shows how information Hes through asystern Each function that midis the data shoald be decomposed into lower levasuatll thes Aeon is licen deserted Data Modeling (937: Deseribes the concepts and vationships relevant to the solution orbusiness domain Functlonal Decomposition (12): Breaks down an orguntzatonal unl, produet scope. or smilarinto ts component parts. Each part ean have its own sc of require: Organiaation Modeling (9.19): Describes the various organizational units, stakehold «sand ther relationships Requirements can be structured around the needs of exch stakeholder or group, (i ete ins Aina ad of airedStsinniii Een Process Medeling 0.21}: Reguiements may be ongantzed around relevant processes Drocesses themselves can cmbei! subprocesses and deseribe hicrachy from the top level end tend procesiesto the lowest level Individual ucivties, Scenarios and Use Cases (9.36) Describe the nqultements that support the individ al gouls ofeach actor or the response tothe triggering Scope Modeling (9.27): Requirements may be organized based om the solution compo ‘ents they ate elated to User Stories (9.88) Describe the stakeholder objectives that the solution wil 626 Stakeholders Domain SME, End User, tps twelinges ws nani req fequitements. the husivess analyst tailors tbe appreac t met the 8 Ilor group and mist determine whieh meds wil ho useful 1 one, ation SME, ad Spomnne:Allected by analysis ments since they need toworify and validate the eis okey stake Project Manager: Usesthe organired set of requirements to verify the sane the lution aad assess the work that needs tae daneln Ube project 627 ructre: The out pul of this taskis an organized struct forthe requirements andl dacumented sc of lationship een them. Thissteuetare is Aisne from tracing, which links elated requirereats athe, this structure used so that the analyst anil staketlers know where specific euirement shouldbe found Each eodel or sel of requivements within the structure should bave clear imple ‘oper that, shoul he ear ta stukeholdees ehat a pars oie wil and will pol describ, 63 Specify and Model Requirements 631 Purpose Te analyze expressed stakeholder desicos andr the current state ofthe organization tuangacomblnation of textual statements, matrices, dagrants and fermal modes 632 Description Specification and models ae created so analyze the fuctioning ofan organization and provide insight into opportunites for improvement. They alo supports number of other objctves, including development and implementation of solutions facia Ingcommunieation song stakehollers, supporting training activities and knowledge ‘managoment. and ensuring eompliance with contractsand regulations The speciisof this task are highly dependent on the techniques used fr specifying sand emaeling requirements 633 Input oguirements [Stated Specification or madeling uf equicements is performed to structure und improve our undcrstanding ofneeds as expressed by stakeholders a aD Pi‘Spey a Mode Requirements Requirements Requirements [stated] Stuctue Sprcty and Model oqulremens 8 Stakeholder or Solution Requirements ea Prine i ! i Aogulrements i 634 Elements 1 Test textual quirement must descebe the capabilities of th solution. any conditions {at mas eis for the requitement to operate, and any enstraints al may prevent thesoution feom fulfilling tho requirement. Guidelines for writing textual require mts inches > Express ened only one requirement at a Une > dvold complex conditional clanses, » Donotsssime mr eae has domain knowl >Use terminology that is consistent > Eyprossreguicemenis asa verb or ver pi ws] Ta aR A aEStsinniii Een > Witteia the active von, clearly deserting whe what Is response fr Fulfing the requirement. > Use terminology familiar tothe stakeholders who must review or use the require 2 Matos Documentation _ tables thosimpes! form ofa matrix. tablets uted when thebusiness analyst is Ihoking to conver set of requirements that have a compl ‘which ean hrakn down int clement that appytosvery entry the table, bat user structure Requirements attributes and data dictionaries are often expresso in tabular form, Ma les are ofa usd for traceability of vequeements to each other fa requirements totestcascs.and fr gan analyse, Matrices are also used for prvmtizing requirements bby mapping thew agains project objectives. ‘Amore complex matrix ill als express information inthe ows ofthe table. Rather {hao presenting repeating information, this orm o atta is satallyintended to i dicate that to clement ze related in Some fashion (for tastanee. that a requirement allects a particular data clement) 32 Modes Modeling Formats A model is any simplified represenation ofa complex reality that Is usefal for under standing that reality and making decisions regarding it, Nodelemay beithertetaal for graphical, or some enmbination af hoth, Graphical modelsare often referred 0.98 Miggrains The choiew of whieh mois) 1 wse fora particular sot of requirementsis determined bythe type oftaformation to be communicated, aswell as the audience who willeon ‘ime the fnformation, Modlsean > Deserihea situation or defines problem > Define boundaries for business domainsand sub-doris, and describe the com Ponents within each defined boundary > Deseribethought processes and action Hows > Categorize and erate hlerarcles of tems Show components and their relationships Show business lagi Whether or ao «diagram ic used in place ofr in addition to a textual description x often determined by the sudienes fr the information, a ells the level of detail ina paricularmodel Modis may be used not only to document requiternts that Anal form, but also as ‘tool while pecformingeliitation activities. a aD Pi‘Spey a Mode Requirements 635 Notations DDescebe say synol or notation used. On diagrams, tlsoften means Including akey that ais in the intespetation of the symbols and/or colors used or eefeering tam external stud Formal versusinformal Models Moral mode flows se snd iconegraphy that are defined in standaed to Indicate the mcaning ofeach model element. A formal rode ean often convey a great deal of meaning, bat smcof the subtleties of the model mas not he propery conveyed toan audionce that fsunfemlia with the specie notation, Aa normal model doesnot have af ‘ements in ways that are meaningful forthe analyst and te audione, While the model ‘maybe les expressive requires no special tuning to lnterpret. onl semantic definitn and insteud connects 4 Caprue Requirements Attributes Ascach requirement nrset of requirementsisspovifid and modeled, the relevant at: lbutes sy sleeted when Pan Aagulrements Management Process 25) pvToraed mast he caphired 5 Improvement Opportunities AAnelyss should work ta etify opportunist lmpenve the opertion ofthe bust ess Some coramon examples of opportunities that a business analysts likely to ‘enti nee Automate Or Simplify The Work People Perform: teat vely simple tasks, where decisions are made on the bass of strict or inlexblerules, are prime candidates fo Improve Access To Information: Prove gree simounts onormation bo al who interface direst or indiretty with costomers thus rhicing the need fr special fats. Decision makers may not roquite this evel of detail but should be made aeare of ‘where and fom whom they may gett required. Normally. deesion makers need ta be provided with relevance ofthe data sequired and used by operational personne. weaning Reduce Complexity Of Interfaces: lnterfaces are needed whenever works transferred between syste or het¥oen pepe Reducing thelr complexity ean improve under standing Increase Consistency Of Behavior Dilfrent workers may handle similar cases ia ¢ sory difernt fashion, eatsinzeustomerdissatitnction and istration, ndanes:Dilferentstaksholder groups may have common needs that ‘anne met witha single solution reducing the cost of mmpleentation, Techniques 1 General Techniques Techniques that ean be ws to specify or mouel sequirements inch: (i ete ins Aina ad of airedStsinniii i > Acceptance and Evaluation Criteria Deflation (0) > Business tues Analyte 1) > Data Diets and oes (8.5) > Date Flow Diagrams 9.6) > Date Modeling > Functional Decomposition (212) > Interoes As (99) Metrics and key Performance indietors (0.16) > Nonunctional Requirements Analysis. > Oranization Modeling 19) > Process Modeting(@.21) > Prototyping(922) > Scenarios and Use Cases (9.25) > Sequence Diagrams (9.28) > StateDiograms(9.20) > User Stories (08) 636 Stakeholders Ang Stakchalder: Tho business analyst may ehoose to perform this task alone and then separately pickage sad communicate the requirements to stakeholder for thee review tndior approval. or ite som oa stachelders ra pacticipate in thistask depend ingon which requirementsare being analyzed the bus preferences ofthe businessanalyst and other futons analysis appro the 637 Output Reguiements [alyzed Modeled nd spose ruiementsare produced by this in 64 Define Assumptions and Constraints 641 Purpose let factors other than requiremer that may affect which solutions are viable 642 Description Assumptions ae actors that are believed to etre, ut have nt heen confirmed. ‘unptions may alfet all aspects ofthe prot and pose ertain degsee af risk they a aD aDaim ni «do not prove wo be tue. Thebusiness analyst dentin and dacuments assumptions, tttemptsto confirm the accuracy o the assumptions, and identifies and manages risks felated tothe ability ofa solution to aeut the business ned, Constraints re defined 4 testretions o imitations on posiblesotlans. The bustness analyst x responsiblefor documenting any restrictions limitations to the solution design, construction esting, validation and deployment. Soktion constraints deserihe asneteof the curren state or plained future state that may nat be changed. They fre not requirements, since they aes not Implemented in any form by the peoject team. Constraints are provided to the project team toons thes hat options they would normally be allowed to consider are not available, Assumptions and constraints are generally dacumented with associated attributes (eg date iduntted, ever impact, asuctated risk ad other explanatory informa {on} They ae defined and daiied as requitementsare understood. In many eases, lower love quirements may be dependent on and therefore traced back to, the pres fence ofa assenption ot constzaint and so may be alloced if the ssurmption proves {also th eonsteaint changed 643 Input Stakcholder Comeerns: Assumptions and constraints are dented through lst tion from stale, 64a Elements 1 Assumptions An assurnption is anything that is belived to be true but that has not aetually been ‘ified. Assumptions eon relate to somethingin the present onthe future. Assim ‘ons need to be dacurnented. and fan assumption found to be falseit will usually Impact the project in somemannes, Asstimptions are therfore a soce of potenti projet rsh Assumptions may aso reflec: an understanding of how desired outeomes frelikely tobe achieved, For instance. stakeholders may believe That customers wll re spond ia certain way to aliange in how a product is doivered, but there may be oaly fineciltalevkdence to snort hat belek. 2 Business Constraints asinessconstiints describe initations on avaiable ylation, or an aypect ofthe ed by the deployment ofthe new solution. They may teflectbudyelatyteteetions, Hime estietions, lite on the mumher of Fesotces available restletonshased on the sills ofthe projet team and the stakeholders. ae {urement that certain stakeholders not be affected bythe implementation of the soe ‘orany other organtzatlonalresretlon, Constraints nved tabs carefully exam foensuse that they ae aceutate and justified, " 3 Technical Constraints Technical constraints include any architecture decisions tha are ade tha may ime pr the deslgn othe solution These may inlude development languages, hardware {software platforms, and application yltware that must be use. Techneal cone Straints may also deseribe restrictions such as resogceutlizaton, message ire and | Ta aR A aEStsinniii i ting, software siz, maximus Technical eanstrants include any enterprise architecture standards that mst bef dowel urnber of and size of fle, records and data sleme Technical constraints may crate a situation where a requirement cannot be met using thecurrent solution approach orby a soliton component and the business analyst mst ork with the project tam to enti other ways to meet the associated basins sed Fique 65: Define sumptions and Const npatOuput iagrans i i i ssakehalder | i Define Assumptions ‘and Constraints Assumptions and Constraints a Define Solution Seope 7A Requirements gt assessPropesed | | and Communication ‘Solution a aD arene 64s Techniques Problem Teacking (9-20): thot assumptions.and constraints aren Wentifed re viewed and managed using the ongoing planning, monitoring, andssue risk manage- ‘ment activities of the projet team. Risk Analysis (9.24): Asses the ssh (bot positive al segativ) an assumplion proves invalid, ora constraint sremoved. 646 Stakeholders Tmplementation SME: Must take the assumptions and const designing a solution, DPeaject Mansyer Must asses asutnptions and consteaintsto identify potential ike that may impact project delivery. end manage agains schedule, cost and resource All Stakeholders: Ihestakeboldee who is responsible for defining partielar as ‘mption or eousteatat shouldbe volved in any discussion that involves changing Sines assumptions and constraints can originate Irom and/or affect any stakeholler all Stakeholders maybe nvoved i the Mentfeation of assumptions or constraints, 6Aa7 Output Assumptions and Constraints: Assumptions and constrain wil limit potential sol {ion uplions and willbe monitored fr potential changes. While they are not techni cally requirements thoy can be managed and communicated by performing thotasks in Chapler Requirements Management and Communication 65 Verify Requirements 65: Purpose Requirements verfleation ensures thal requirements specications and models moet thenecossary standart quality to allow thems to he used effectively to guide farther work 652 Description Verifying rquieements ensures that the requirements have Been defined corteety that fs tharthay areof acceptable quality. Roquleersents that donot meet quality standaeds sredelectveand must be revised. Requirement verification constitutes a al check by the business analyst und key takehalders to determine thatthe requirements are > ready for formal review and validation by the customers and users and provide ll the information ede fr furthee work based on the requirements to be porfrmos. 653 Input Requirements [Any Except Stated]: Any equirement may be verified [including bust ‘nea stakeholder, salution, and transition requirements) Verifeation ia quality heck performed following analysis ofa requirement Sn Ta aR A aEStsinniii ears Figure 6-6: Verity Requirements inp Output Diagram i Inputs) i i [* “i i i i 1 regents 1 Dy cept i Stated | 65 Verify Requirements aqakarments erie) Requirements Mgt ee and Commenization Wada equierents 654 Elements The businessanalya verifies that require sequitementsstatoments shaveeon specified ia wellsweiten 1 Characteristics ofRequitements Quality ‘ALA minitwum, high quality equcermen: exhibits the folowing characerstes: Cohesive: A cohesive st of requirements relates to only one thing whether that i business process, busiss rule, organizational unt, or so forth All requirements ina set oF adel shoul support is averall purse and sep. Completes The entire set af requirements should repreyent all elevamtrequisements Also each individual requzement should be complete Ensure each roqulrement nal: ‘contained without any enssing information. Consistent: Ensuee thal individual requirements do no contradict exch other or deseribe the same requirement using diferent wording. In addition the eel of detail suprlied fr each requirement ina set o aa! showld be the same. a aD aiy Reena 655 (Corrects Detects in seguleements willed to dofees inthe resulting slut, ach requirement must be tmplemestabe within the exiting infrastructure, with the existing budget, imsline and resources available to the tear (or the project ‘mast develop the eapabilt to implement the requirement) The business analyst noeds Aa work with the project team to make these determinations Modiflable: Related requirements must be grouped together in oder for eoqurerents tobe modifiable. This characteristic exhibited by logealstrueturing ofthe requive- Unambiguous individal requirements must never he vncleat requirement must ot allo for eat divergent valid iater pretation ofthe requirement Testable: There must hea way to prove that a requirement hasbeen filled. Each quirement shouldbe testablo—tha st must be possible to design a ost that canbe sed to determine Ifa sation has met the requlremeat or kane othr means of deter agobethertoaccept x soltion that meets the requirement. 2 Verification Actives Verification activities re typically pelormed iteratively throughout the requirements analysis process. Verification activities include: Check forcompletoness within each requirements model, For example, data se Compare each prepared requirements model teatual or graphical) agains all ‘thor prepared reuitements ides Check for element sthat are mentioned in on rod that are missingin the ower medels, Also cheek thatthe sume eomponent Is referenced the same way’ all mavdels~ for example use of consistent lingo 4, ‘eustome’and'elient” Resolve all discrepancies, correcting terminclogy. oF teding!leting componcats as nceded Make sure allvarationste the documented processes have beem identified and Business pollckssand business cules > Business pencesses ta be performed and managed > People who operate snd maintain the solute, including ther job faretions nd osponsibiltos Software applications and application camponcnts used inthe solution, Structure othe oqnization, including interactions bat wee the organization, its feustomets and te suppliers During solution design, maybecume necessary to fev the initial alse of fane= onality between components as defined in te slution scope asthe cst to kmplement tesclicomponest becomes belies understood, ad to delesmine which allaeations have thebost cost/benefit ats, a aD Esaa Sc Ascoats and effort are understood for each solution component the business analyst will need to assess whctherthe allocation represents the most fective tradeatisbe ‘beecn dlivery pons. Considerations ae key to Ineude: > Available resourees: Tho suppers vl be iced eth limitations regaeding the amount of requirements they ea implement based on the allocsted resources. by Some instances the business analyst may be able to devalop a business. case that justifies additional incestinent » Constraints onthe solution: Regulatory requirements or business deeisions may requite that certain regutements belandled manly or automatically, o thal certain requirements must be priertized above all thers » Dependencies hetwecn requirements: Same capabilities may and of them selves proside ited value to th organization, Dut need to be delivered in order to support ether high-eaue requirements 2 Release Planing "elitate the docions abou which requirements willbe inchidod in each eekease! phase/iteration ofthe project. There are many lacturs thal will gue these decisions, ‘ichas the overall project budget, the need to implement a seltion oF part ofthe ‘lution bya certain date, resource constraints, training schedule and ability forthe business to absorb changis within a defined tmeffame. Ensurcal partes understand theconsequences tothe organization based onthe planned schedule of releases and ‘tify the solution eapabiiis that will deliver the greatest business sai. There may be oaganizationsl restcaints or polices that must be adhered to 2 plementation, ieluding constraint such as feozepeciods fr implementation, fmpany polices, and any phased-in activities nines analats ein pli ing of the implementation within «business eyele in order to cause minimal dsrup of busine activities. 728 Techniques Aceeptance and bvaluation Criteria Definition (1 criteria may eed to be mel by a particular release Amnimal set of acceptance Business Rules Analysis Business rules eat he managed and monitored by people or automated bya software application, Deciston Analysis (2.8 Con be used to esthnate the value associated with difereat allocation decisions and optimize those decisions rnctional Decomposition (9.12) Can be used to break down solution seope into smaller components for allgction Process Made (9.21) tivities the process model ay be allocated te different ‘es, or outaourced toa supplier A soutlot can be developed that inereanentally sup Scenarios and Use Cases (9.26) Alternative laws can be sepacate from the base uss caseand inchded nn extension tobe moved into a later release a Ta aR A aESoiintnnmititn | ae 726 Stakeholders Customers and Suppliers: Willbe nected by how and when requiements ake imple ‘mented and may have tebe consulted about, or agree to theallaeation decisions. Domain SME: May have recommendations regarding the sot ofoquirements tobe a located tox ylation component or boa release End Usere May requice minimal defied set of requirements tobe implemented before a release can he accepted. requirements are reallocated toa maria] process, theadditional workload nity seriously affect thie ob performance and satislaction, Fd users may have concerns about the Feequency ofchange that they aze prepared to accept and will nod tube awarvo reallocation {Implementation SMF: Wil be responsible for the design anid construction nif some oral solution componsuts and the estimation ofthe work required Will make ree- weregnrding the allocation uf requreaenis and may take ownership of the decision regarding. particule allocati sigaiiceat Impact on thosbility ofthe slit tomoot business or stakeholder requirements Fn particnlat allocation of requirements betweca the individual sltwateapplicabien ‘eompoments ie sally the responsibility of a system atehitoet oe devant does ot have a Operational Support: Will be affected by the allncation of requirements to com ponents and releases and need tobe aware of when and where requirements are allocated Project Manager: Responsible forthe work being done bythe project tear and will ‘eed to participate in equtemsents allocation in ender to manage the project scope ‘and work, May nee to request reallocation in order to rece project work or seek ‘Adjustments tothe seope oF budget ofthe project. Teter: Responsible fr vertylag rl ned to knw how requirements have buen allocated, nase and solution components and will therefore Sponsor: tesponsible fr funding ofthe project and therfore required to approve the allocation of soquitemens 1 components and leases based oathe recommendation ‘ofthe hitsness analyst and the projec team, 727 Output Requirements (Allocated: Allocated reguirements are assoetated with solution smpoment that will implement her, 73 Assess Organizational Readiness 734 Purpose Asses whether the orgunization is ready to make effective wae of anew solution. 73.2 Description An organizational readiness assessment deserihes the cet neve soltion wil hae ‘onan organlzation aud whether the organization is prepared for the oxgunzational ‘ange thatthe solution implementation will ease. fective communeation of a aD asIR Sc solution pacts assists n enabling necessary ofganizationsl change management practices and identifying taining requirements for solution implementation. In order to identifyimpacts the business analyst should understand what changes wil ‘eeu the business area, rochnical infrastructure peoedssca and how thes effect other business units oF operations faa Eniipie Solan Solution Seope Stakeholder drchectire (Designed) CConceme eed) Asses Ora Readiness ‘organizational Feaciness Assessment (Fas Using Tis Ouapa 1 1 1 1 { etnetaston | i i {Cmawerens J | i 733 Input Enterprise Areditceture:Deserbes the eurreat slate of he enterprise ineuding the ‘organizational structure business processes spstems, information ec. Solution Scope: used to determine which componsnts ofthe business architecture ate fected Salution [Designed} Used in pace ofthe solution scope, available Stakchalder Comveras Used ta assess potential peclems orfsues, os Ta aR A aESoiintnnmititn | ae 73.4 Elements 1 Cultural Assessment DDotermine whether stakeholder groups aenuinely want the changeto besuceessiu ‘Asso thebeliefs atures and feelings common to key stakeholder geoups and the willingness of those stuksholer groups o accept a chug Determine whether stake Ioders derstand the reasons tht new soliton s being implemented whether they view that solution as someting that willbe beneficial, and they understand he reasons why a new slition required, 2 Operetional Technical Assessment Determine whether the organization isabl to take advantage ofthe capablitispro- Vide by the new solstion, and eluate whether stakeholders are prepared to make use of the newsolution.Dereemine Htzaining has heen porformed.whthor new plies and procedures have own defined, whether IT systemerequired to support it arco plac. and whethr the solution s capable of perfrming a a required level 3 Stakeholderimpact Analysie Understand how change wil affct a parsinlar stakeholder grou. Some things thot nay De considered in an impact snaltssinclnde Functions: What processes involve the stakeholder and what applieationsdoes the stakeholder nse Location: re the stakehoklers located in a single place orin a distributed team? they are distbuted,willthe change afer thir communteations? Taka: What tasks ate petformed by people assuciated with that stakeholder group? Will the change alter how those tasks are performed a affect the skill ves required Ao peviorn then? Will sakellers have sore le Sexi in pon asks? Concerns: What ar this gronp'susshility quirements, preferences and thet pro Aelency level regarding interaction with computer systems? Will the work become oreo ess demanling? Are any members ofthe group a ik of losing thet fobs? Wl thechanges affect thls work satisfctlon? 73.5 Techniques 1 Ganera Techniques Acceptance and Evaluation Criteria Definition (9.1: Aceoptancoeiteria must ro Acts nee levels that would allow the argunization te haveconfidence fn solutions that moet thoae criteria ata Flow Diageans (2.6) and Process Madels (9:21: Useful for identifying the sotivitis that are ikely to change with the (mplermentaion of new slutfon and the Sakcholderswho performed those activities, Focus Groups (911), luterviows (9.14) ond Survey/Questlonuatre @.31):Can assist, with Wdentfyingstakeholder concerns saucy. a aD asIR Sc Organization Modeling (9.19): Used t dently stakeholders or stakeholder groups that may be tmpacted bythe new solution, robles Tracking (9.20); Used to ensure that issues identified by the organizational readiness assossno are tesaved [Risk Analysis (9.24); Used to assess potential problems that ae Menlied using the ‘organizational readinese sessment, deteriine which possible problems ate the mast Important to deal with, ard develop a mization steateay. SWOT Analysis (9.32): Used to assess stateyles developed to respond to Meatled 2 ForceField Analysis Force ed analysis grapheol method for depleting the forces that support and op pose chan. [Lineulves identifying te forces that support and oppose change, de- plting then on opposite sdesafa line, and then estimating thestrength ofeach force order to assess which st of forces are stronger. Once this analysis is complete the ‘ext step ta lnk for ways to strengthen the forees tht suppor the desired outeome or gonurate no frees Figure 7-5: Force ed Anayis iar Strength ot Forces Supporting Fores Opposing Strength of Force ‘change ‘change Foce Proposed Changeto Business system 2 suppers toes. Crpsemaions2 1 ‘otk? Toa 736 Stakeholders Domain SME: Provides information on the likely impact to staeholdees and the cape bilities ofthe enterprise lemeutatlon SME: Supplies information on the skills and capabilites necessary to successfully operate the now soliton, There area number nf Implementation SMES that can haves signiicant effec on the ability of an ocganization ty implement change, Inching but not limited to > Organisational Change Management SMEs asst onganinations with eommunical= {ngehenge to thelr stakeholders and creating support among those stakeholdcrs for the change: on Ta aR A aESoiintnnmititn | Se > Usability SMEs assist with the evaluation and design of saftwarc application that Training SMEs assist withthe creation uf traning plan to help stakeholders de wlopthoskills that they need to ceetvely use the now solution. Opecational sport: Provides information om thee ability to support the operation ofthe solution, Willngod to understand the nature of thesolution inorder tobe able to Requires the organizational readiness assessment to deters I fadditiona project wrk ieroquited for nsecesfa| plementation ofthe soko. An Implemearation plan should be created to outline the steps to betaken aad the order ‘which they mast be execute to resolve any ssuesidentified in the organizational reaulnessassessaent Sponsor: Authorizes an champions action 1 resolve problomatdentified in the orga ‘rational reudiness ussessnent 737 Output Organizational Readiness Assessment: Describes whether stakeholders are prepared socept the change associated with asoluion and are ableto uselt effectively. Mey load fo reisions in soliton or prajet scone. 14 Define Transition Requirements 2aa Purpose Ta define reguitements for capable needed a eansition fom an existing sation to new solution, a2 Description ‘mnmest cases solution s implomented within an eater prise oder to euhanes oF replace anexisting solution. During the tzansition perlod tthe time whea both the old ul aow solutions are operational te enterprise may need fo uperate but solutions {n parae, ove information between the new and old solution, conduct training ta ‘ble stalshollers to elfetively aperate tke new solution, and s forth. In. adition to Adevloping the solution Isl, the implementation team islikely to have to develop ad ditional eapoblities tu suppoct this transition “Those capabilities ae roqtiremonts, as tokchoers need to bo able ta make this tran sito sacceeslly—bul ey ae llr in abure Kom sthee Minds of require, fstheyeannot ho dafined until solution has hoon designed, These requiemets 80 bhavea dlfeentfespan fom othertypen of requirements they remain relevsat oly Arn he tunsition pried tween soln Transition roqwirements ar elicited analyzed, managed, and communicated by por (orining the same tasks as fr other requirements, The difference fs natn the methods for defining them, but inthe inputs the natureof transition requirements, andin that they cease tobe relevant once he exstng solution is elinated, a aD =aR Sc In instances where there io existing olution, and the now solution Is adding ae tirly new capubilityto the enterprise rather thon extending and improving am existing fapabilt. then transition requtementsdo aot need tobe analyzed Figure 7-Dfioe Pans Requirements Inpt/Otpat Dagan, r Inputs + i 3 a3 i i 1 | organizational Requirements Solution Solution | {Resins “Titel Deplged) eked) | i Asesment 7a Define transition Requkenens v 4) Tonion Reuierents nooo: Wen ~ i “Tasks Using This Output i i ei i Lf pint | 1 [ecules \ ! 743 Input Organizational Keadiness Assessment: Used toientityrcas where the organira ton needs to add new cupabilties th manage and operate the new solution, es t [Stated Stakeholders will demtify the information and processes they ned during transition Solution [Depleyed} The deployed or existing) solution will belavecigated to under sand what needs to he transitioned tothe new solution. I amay be necessary to elicit desertion ofthe capabilities othe solution und perform som analysis tasksin order toensure tha eurest capabilities are fully understood, Solution [Designed The desigu or the new solution must be sullcenty defined to allow major diferences to he Went on Ta aR A aESoiintnnmititn | Se 744 Elements "Examine the soltion euecenttyin place to entity fstares ha aee implemented in x substantially diferent fashion in the new solution, information thal neds tu be transferred tothe now solution, and other ateas of signfieant change. Likely sonteesof transition requicemeats include 1 Data The acta dat and metadata managed by thea sytem needs to be evaluated to de termine whether to azchive the information or transfer ito the new soliton, Rules or ‘comversion of this information wll need tbe developed, and business rules nay need tobe dtined to sure chat the new solution interrots the converted date correctly. 2 Ongoing Work 1Wisiikly that work willbv ongoing inthe old yersion ofthe solution at the me the ‘new version is implemented, Options fr managing this ongoing work my Inetude finishing existing work using th current solution an stating sew work nthe now lution, hokdng the processing of neve work fra period of ine, or converting all work ‘tthe tine of implementation 3 Organizational Change ‘Te business analyst may e lnvolsed in developing a process fr mats sideofchange related tothe solution. Organizational change management generally {efers to a process and set of tok fr managing hange at an organizational level. The bosinese analyst may help to develop recommendations for changes to the organiza tional structure personnel as job fusetions may change significantly asters! of ‘work being automated. Near information may he made avslahito stakeholders. ané ‘ew shill may be required to operate the solution 2A5S Techniques Business ules Analysis @.} Additonal business rules maybe defined to assist nigroting date, orto manage work migrated from the exiting soliton (ats possible {hat diferent cules may apply dependingon when the work was performed). Data Flow Diagrams (2.6), Process Madoting (921) und Organization Mode (0.19) These maybe analyze to identify the differences between the existing and new salutions. ‘Data Medeling (9:7): Physeal data models ofthe extstingand new solutions will be compared tenable mapping between the two 746 Stakeholders Customer: Slayhe negatively affected during the tansition based om the tamer of ‘ongcing work, o Ifafizmation ls inorsectly wansfrze ‘Domain SME Will provide information on the existing solution and assist tn vefica. tion and elidation the transition requirments End sere the existing and the mew solution are beth in use fr period, dey will ‘need to know how to comordinate het ween ther. BinOrGade Neier 29Por Sc ll be the source for many ofthe transition requirements, Operational Support: May need te aperaterwo solutions smultancously er: Will nce to pla fue the work require to lmplenent the tral requirerents, This may aoc the projastseope Regulator: May require that rocards ofthe transition requirements and pracess he nine for long tren ceview and compliance with regulations. Tester: Wil verify thatthe transition as heen performed corrects imeluding rhe de ‘elopment of tet plans Sponsor: Will nood 19 be informed ofthe potential elfests of thetranstion on the ests an eneits of the now sti a7 Output Transition Hequirements: Transition raqultements dexertbe ca be developed inorder for an organization to succenstully transit Transition requirements ane analyzod by this task gn must stil be verified, validated, smanaged and eomnunicated, ve that must between sclutions, is Validate Solution 754 Purpose Validate tht a solution meets the business need and deteemiae the mest appropriate response to identified derets 752 Description Solution vlidation isroguired ro ensure that a delivers sition meets the businoss ongoing basin Problems thal sre dented through slat validation ‘ill reported and petoritizd fr rosoation. Whom a prablem = Went with the ‘lution (he. failure to meet astakebokler need, whether or not the requirement was tnerectly specified) the businsanalyst sil heals to help tho tam determine the seeds on 753 Input Solution [Constructed Validation can only be ‘wally exists, The solution enay or may nt be in atu use by Uke ctcrpse. formed agalost a solution that ac- oquirements [rioritived and Valkdated: The provi are needed a determine ‘which soquirameats ar candidates for acceptance criteria. Thereguirementsare used todetermine whether outpitsof the sation fall within acceptable parameters on Ta aR A aEaaa Seen i ! i ! i | Requivements Solan | eroraized and (Constructed) | i Vaidateat i 75 Vatidete Solution 3 .s dented Mitigating Solution Detects ‘Actions Validation Aesesement ¥ Mw Tasks ising Taig Output | (Outputs Used sy | Ealuate Solution Implementation Performance 754 Elements 1 Investigate Defective Soltion Outputs entity defects a solution o solution component by looking a casos where the ‘ouiputs from the solution ure below a acceptable level of quality. Lis necessary to ‘define what considered to a deetive nurput. For exartple. 0 reqaigement might be sidered tobe lefective it is chung more than once before is nplemente ri tts rojected by reviewers after the second round of rovcws, When itean be detcrmined thatthe solution isconsistntly producing detective outputs root cause analysis should be performed tn oar to identity the ease ofthe problem Some solution componenls software applicationsboeing the most Bhe ‘require an implementation SME to investigate the foot cause of problems. 2 ssess Defects ana isues Wentifed defects are reviewed to asses the effet tha they wil haven the operation ‘ofthe organization, This requires determining the severity ofthe defect, the probabil ly af the occurrence of thedefet the severity ofthebusness impact, aad the capac ity ofthe business to absorb the impact ofthe defects. Ihe business analyst maybe a aD aPor Sc segulred to idem whieh defets must be resolved, which ea be mitigated theouglk ‘workarounds or other approaches, and which ean be accepted until resaeces cx ‘adress tht Ita deeet cannot be reseed in a timeframe that ceptable from a busines po. spective (due to complesity, because the cause cannct be identified, boeauseit snot ficiently high pri, or forany other reason}, end stakeholder cannot accep the defect, the business analyst may investigte options for mitigating the effets, These ‘ay inchide additonal quality contol checks: new manual processca revel of sup. port for certain exception cases, or other menses, 755 Techniques Acceptance and Evaluation Criteria Definition (9.1: Determine the el of ete ‘ments tht the solution must meetin order tobe comldered vali Root Cause Analysis 0.25} Used to ensure that thounderiying reason fora defect js identiid rather than simply correcting the output which may be wsymptos ofa Aeapoeundoeying prior) Problem Teaching 9.20) Lise to tack Wdentifed dfeclsto ensute thal they ate resolve 756 Stakeholders Domain SME: Will provide inpt into the development of acceptance ad evaluation End Unecs May aasat nthe development of acceptance and evaluation criteria and partieipate in acceptance test {mplementation SME: Wil spnort thevrlidation process, investigate defects, correct Wenbitied defects and participate inthe defect prioritization and resolution proces, Operational Support: Will support the deployment of defet resolutions Project Manager: Responsible for o9-oedination of work between the partcs involved he validation races ‘ester: Solution verieation (at verlsing tha the solution behaves in accordance with the solution requirements} s the responsibilty af the testcr. Testers will develop ‘and execute fests to dentify defects which may need to beassessed and Vsliated by thebusiness analyst. Tes plans may he reviewed to ensure thatthe planned sct of fest, sctivies willbe suficlent to assure the organtzation that he solution sn confor ‘mance withthe requirements egutator: May review the results of acceptance testing and require hat records be opt regarding the process and outeomen. Sponsor: the sponser (or desgnate) must accept the a Ta aR A aESoiintnnmititn | a 787 Output Mentifid Defeets Known problems thot exis in. sol der Mitigating Actions: Steps that ca be taken, or processes reduce or climate the effect an identified defect has on stakeholder or stake sroup. Solution Validation Assessment: An assessment of whether th solution sable imeet the business nce at an acceptable evel of qualty 1.6 Evaluate Solution Performance 761 Purpose valaate fanetioning solutions tounderstand the value they deliver anal id tte for improvorent 7.6.2 Description Solution evaluation avolves investigating how a solution is actually used at deployed, and assessing the elect thas had, heth postiveand negative. It may also be ‘referred tu as postdplerentation assessment when performed immediately following thecompletion ofa project. Solutions maybe adapted and mealfed iret by end users mchaing use a maa ‘workarounds reeneding of acitonal information. and adoption of nara policies fd procedures in orderta resolve problems that have accarred ortosllow mew uses (of th solution. tn ordce to propery cvaluate the solution is also necessary to under Sand when, whese and why this has occured andl assess the benefit that Urese changes hhago brought to the organization. 763 Input [Business Requirements: The porformance ofthe solution will be measured against "hetuisines equitements, Without ear hnsness equitements fs impasuleto ssses the solution’ pecformaneselfectivly, since there are no defined uoals hat Is Supposed to meet. Defects: Any knovn defects must be considered in assessing the quality of Salution Performance Metrics: There repreuet the ritetiaby which the performance of the solution sto be assessed. hey may be yuatative [measures of ime, volume, ‘revenue, errors fond, or other forenation for which hard numbers are avaiable) or ‘qualitaive (user or customer satistucton, recommendations oF other measures whieh | ‘Sinimarie the apinions af stakeholders). Solution [Deplayed} tis task cannot be performed uatithe solution isin use 26.4 Elements 1 Understand Value Delivered fy Solution Gather the wetual metres that describe the performance of a aD a solution. Applieationsae Sc Figure 7- Fate Solution Performance Int/Otpat Diagram BA OD! Business entifed Solution Solution Requirements Defects (Deployed) Perfomance Metis j 4 Evaluate Slaton Peformance [*) sofation Performance Assessment (Tasting Tis Output | i a i 1 [ asessinanny |i i XM Q ‘ay automaticaly report on some oral of the defined metrics, but where they do not, ‘awillbe necessary to athe qualitative and quantitative performance information icant over or under-perlirmance against targets moy be investigated to identity a root cause ordeterstine un appropriate response Ihe root cause for under performances a factor thats potentially under the contol ‘ofthe enterprise. addessigit ey become a business nea Significant orer- performance may indicate thal resontces devoted ta the slain © bbe sod clearer orth tho ele ofthe slat ta the business wssndorestimated, Wisely that (hat there are swims thal can be learned and applied eluewhere 2 Validate Solution Metrics Insoave case, the performance of solution wil be considered excellent, based on the defined perfaronanve metrics fy that saluting but Ie busines goals and objestves that those metre ae sipposed to be aligned with ae not being ict. An analysis effort todlentifyand define more appropriate metic, including nwadifcaton of the soution a Ta aR A aESoiintnnmititn | a 165 BinOrGade Neier 29 tw elect and report on tase me ea, may be equlte 3 Solution Replacement or Elimination “Eventually it willbe noossucy to consider the replacement of solution ur solution mpoment. This may ent because an IT system oF ater technology camponeat has reacted the end ots was life servicosare bing sourced or outsourced, the sol {Hom snot falling the business goals set for it of for any number of other reasons Issues that may inluence the replacement o elimination decision muy chide > Ongoing Cost versus Initia! Investment: Its common forthe existingsaition to Ihave increasing cons ver Lime, while aernalives haves higher investanel cook ‘upfront but ower maintenance costs » Opportunity Cost: Opportunity cost represents the potential vali that could he teallzad by pursuing alternative causes of acon. Rejlacemeat of an exting sl tion ssunkikely ta prndce high ntl rturnson investment ins wil keh rep Tate visting epithe. least inital: rather than ereate many new anes). As theetfor to develop a replacment will pal resources aay fom other initiatives the organization may be considering, the potential benef from those initiatives need to he conscered to determine i they aregreater than the benefit af replace ‘ment (thisis generally not a cous deration when eonskedingemlnation). Necessity: Nos solution componcnts havo a limited Mespan (ne to obsolescence hanging market conditions, and other causes) Alter acertain point in the ifevele ici eeamcimposible ta maintain the existing compunent > Sank Cas: Sunk cost de tistive. Tho psychological impacto sunk costs may make difeult for stakeold ‘rsto objectively ansenatheratinaletor replacement of elitsnation, ss they may feo eluctan to "wast" the effort or money alrcady invested. As this investment cannot be recovered, its elfectvely relevant when considering future action. De ‘sionsstould Bebased on the future investment required andthe future bens Ms cam be gained ives the money an lot already coms Techniques Decision Analysts (2. A coat benefit analysis typically used to determine the financial impact ofthe soltion onthe organization, While critica. itisimportant to ‘ensure that non nanctal costs (including opportunity cost) and benefits evaluated acus Groups (011) Useful to gain a detailed qualitative understanding ofthe value of ‘solution ta group of staksholders. It canbe used to uneovar new information boyond scape a previously defined m Observation (9.418): May reveal uses ox prblems that ate not belay reported. Survey/(uestionnaice (9.1) Finale gathering quantitaise and qualtative itor ation foe lange numbers ofstuksholders. [3 survey is properly desiged and is tesponded toby stat stcaly significant and ropreseative sample ofthe stakehodcr population, ows acewrsely reflect the opinions uf the entire population, Surveys are ‘ol espectlly effective at ellelting unexpected information766 Stakeholders Customer, Domain 8M, and Supplier: May provide recommendations fr Improvements End User: responsible forthe day -day operation ofthe solution anda major source of nfoesation ms prablems or detects Operational Support: Will be involved in monitoring the performance und effetive= nessa sition nits components Regulator: May have requitemeats regarding the performance of solution that must bbemet onan ongoinghesis. Sponsor: The person responsible for the operation of the sotion from a business pet~ ‘spective will exponsble for deciding ithe solutan evaluation warrants the initia tom ofa change initiative 767 output Solution Performance Assesses tion to business goal t:Deseribes haw the seluton is perorming in rl iad ubjectivesChapter 8: Underlying Competencies | the Underiing Competencies Knowledge Area provides a deseription of te bevior, charaeteristies, knowledgennd personal qualities that support the pruetice of husiness ali ‘The underlying competencies are, ofcourse, not unlque to the business analyls pros sion. they are deseibed here to enmitecendersare wate ofthe range of fundamental shill required, and provide a buss for thom to nvestigate further into the skills and Inowldge that willenable them tale accomplished and adaplable business analyte. 84 Analytical Thinking and Problem Solving 811 Creative Thinking 1 Pupose asiness analysts must he effective ing solvingand in generating alternative sol rating new ideas for appronchesto problem 2 Definition {Creative thinking involves generating new ideas and concepts as well as finding new ssaoelattons between oF new applications of existing leasand concepts. Thess eon ‘xpts should beinnovative end appropriate to the situation. In adlition to identifying, ‘and proposing altematives thehusiness analyst eam be efetive in promringeretive thinking in others by asking questions and challenging assumptions 3 Effectiveness Measures Mesutesof success seat hinkinginelude > Thesseeessful generation and produetive consideration of me > Application ofmew ideasto reslwe existing problems. > Willagpessof takeholler to accept new approaches Baz Decision Making 1 Purpose ‘Business analysts must be effective ln understanding the celteria involved In making a decision, n making decisions. and in assisting others to make better decisions, 2 Definition ‘A decision s requised whenever ithecomes necessary t select an alternative or ap proach from two or more options, Decision analyse includes gathering information televant toa deetsion. breaking down the information relevant to. deesion. making ‘comparisons and tradeoflsbetween similar and dissimilar options, and identifying, thecption that is most desirable. Business analyst must be awaro ofthe traps that ‘can impede successful decision-making, chiding the tendency to accept the nits) framing of problem, the sunk cas fallacy. and th tendency to place greater weight on ‘evidence that confirms existing impressionsaaa ETI so 3 Bifectiveness Measures Measures of uecessul deciso include: > Confidence of the particpants in the decsion-analyls process that a decision bs Now information or alternatives that cause a decision tobe revisited ar Ke now ancl not simply overlooked. inely Decisions are elective in addeeasing the underlying problem, > Theimpact ofuncertaaty and new lnormation when maklng desilons canbe of fectively assessed 813 Learning 1 Purpose ‘Business analysts must be effective at Learning aout business domains and how they fonetion, and then translate that learning ino an understanding of how te hen an ovganlzation 2 Definition Learnings the process of gaining knowledge o sil Learning about domain passes through a ser of tages. fom ital aogulttion and learning of raw Tact, rough ‘comprehension oftheir meaning. to applsng the knowledge day-to-day work, and finally analysts synthesls and evaluation business analyst ust be abe to deserine their lve of understanding of the business domain and be capable of appl evel ofunderstandinato determine which analysisaetiities new te petfrmed in ‘given situation, nce learning about x domain has reached the point where analysis 's complete. he business analyst mast be able o synthesize the information to Identity ‘opportunites to crette new solutions and evaluate thove solutions tensure that th srecffetive 3 fffectiveness Messures Measures of succesful learning include: Agreement hy stakcholersthat analysis models effectively and completely de see the domain, > Wemtiticationofrclated problems ar issues from malliple areas in the domain + Mapid absorption new information o sew domains. 844 Problem Solving 1 Purpose Business analysts must be lfectiveat defining and solving problems in order to ensure "hat fhe real underiing problem Isunderstood and that solutions etaliyaddeess that problem. | Ta aR A aEcs aA 2 Definition DDotning a problem involves ensuring tht the nature ofthe problem is elearly under stool by all parties nd that underlying issues ate ssble, Confit between the goals and objectives ofthestukchokders ed to be articulates and addressed Underlying ‘Smptions mus be Went anid ested. The objectives that wl be met once the po Jean solved ave to be ceatyspeetied an alternative solutions should be developed, ‘Altermatives ate measure aginst the objeetves to determine whlch pose solution {sbest and idemiy the radeots that may enlst between solutions. Ihe business analyst, should hesware ofa numberof problem solving techniques that may be apple 3 Effectiveness Meesures ‘Mossures of suocesfal decision analysts include Confidence af he partilpantsin rhe problem solving proces that «selected sol tion iseoreet. New solution options ean beevaluated effectively wsing he problem solving frame woth Selected solutions meet the defined objeetives and solve the underlying problem, > theprabler solving process asos making decisions based on preenneetved no tions, organizational polities or oer traps that may cause a sub-optcnal soluion tobe selected als ‘Systems Thinking 1 Purpose Hosnessavalyats must be effective understanding how the people, processes ad technology within an ofganiration interact in teationshipsand patterns to reste a 2 Definition Sates theory ad sytem thinking sugges! tha the system asa whole will hae properios Uehaviors anu characterises that emerge rom the interaction ofthe fomponents of Thesyatem, and which ren ject frm ae understanding ofthe ‘components alone In tho context of systems theory, th term “system ismuch broader thao.an fl system it alsoineludes the peuple involved, the interactions between them thocxtormal foreos affecting their behavior. anda ther relovant clementsand fatars 3 Effectiveness Measures Measures of effective use of systems thinking includ > Understonding of hows change toa component affects the system asa whole > ldentication ofscinecing and compensating feck loops > Understanding othow systoms adapt to eternal pressuresund changes a aD asa so 82 Behavioral Characteristics 82a Ethics 1 Purpose A business analy nant beable to behave tically spect ofstakehnlers and be able to recognize when a proposed solution or coqults tment may preset ties ileal. ddr earn the Lust an 2 Definition Fthiesrequites an understanding of moral and immoral behavior, the standards that ‘should govern ones Deavio, ad the willingness to act to esr that one’s behave is moral or meets thoae standards. Business analysts need to consider the pact that ‘proposed solution wil haven allstakeholler groupsand work to ensure that those sroupsare treated fat Fair treatment does wot require tat the outcome belenctiial {wa particular stakeholder geoup, but it does require thatthe affected stakeholders understand the reasonsfor the decision, that they are not deceived about the outesine sd that decisions whiah are rade ate made te best interest ofthe organization The husinese analyst shouldbe able to identity when an ethical dilemma occursand tuverstand how uh dilemmas may be reslve 3 Effectiveness Measures Messures of etheal behavior Include: > Decisions aro made with duc nnsideration to the interests fal stakeholders, 1 Reasoas fra decision are clearly articulated and understood > Prompt and full disclosure! potential confit of intereat Honesty regarding one obilitks the performance of ons work. and acepting responsibilty for tates or errors. 822 Personal Organization 1 Purpose: Personal organtation sills assist the business analyst effectively managing tasks find information. 2 Description Personal organization insoles the ability to readily find 8lesor information, melt res, macuyement of outstanding (asks, and appropriate handling of piorite.Infor- ‘mation should ho stated or filed ina way that cables the business ans to retrleve at alater date. Eetive time management requires elective prior lization, eliaation ‘of procrastination and clarityof zonlsand expectations. Standard techniques sich as ction plans to-do ists and setting priorities are among the common approuches to filets time management. 3 Effectiveness Messures ‘Measures of personal organiration include | Ta aR A aEcs ae > Theablty ofthe business analyst to find information, > Regular on-tlne completion oftasks ficiency in the completion of woth > Thesbiliy to easly Memtiy al outstanding work and the status of each work iver 8.23 Trustworthiness 1 Purpose’ arning the tras of key stakshoklerss neessary to ensues that she hsiness analyst fn ableto elicit requirements aroun weusitive inson and to ensure thal recommentla- tions are eraated property 2 Dehntion A trustworthy business analyst aust. constantl demonstrate to stakeholders that hey deserve the sakelolders confidence and are concerted with that stakeholders best interests Siakehoers must eust the business analy to behave cthially and perform business analysis work effectively, inorder toolset the iaerentcistrast bases pon the posable effects of erangeto vested incerta he satis que or snp fear ‘of change, Trastorthiness requires hat the business analyst engage with the stake= kde’ neds ot the stakebokler' desires and thatthe businessanalyst must hon ‘tly address sues whe they occu, 3 Effectiveness Messures Measures of tustworthiness inlade: Stakeholders involving the business analyst in decision making > Stakeholder aoseptanes ofthe business analyst's recommendations, > Willingnessof tekeholders to diseuse difficult or controversial topics with the busines analyst > Willingnessof stakeholders to supporto defend the business analyst whon prob: lems ove 83 Business Knowledge 33a Business Principles and Practices 1 Purpose Itusineseavalysts require an understandingof fundamental business principles and best practices inorder to ensure that they are Incorporated into and supported by 2 Definition ‘asineys principles are those characteristics that ute common to all organizations with sesimilar purpose and structure whether or ot they arc the same Industry. Almost sllorqentzations aced certain furetionsecapabilies in neder to eperate Buses ‘reas within and across industri often have u omaton set of business process and a aD aSe so sswociated systems, Common functions! areas include Finance > Information Teelinoloay > Supply Chain Management While thesearcas have common proconte, they ean also wary widely ated on the Industry and sie of an organization (og, Human Resources willbo guid by itr sl regulatory and cullaral influences, but there ane universal commonalities in rolex suchas finding retaining, counseling, compensating. and removing staf) Other acas, suchas production, tend to have fundamentally diferent dersaeds el ween diferent Industrivs(. rieulture and sollare) Understanding how other orgunteations have solved sie challenges ean be net when Mentifying possible soltions: 2 Effectiveness Measures “Measures of knowledge of busines practices and principles may include > Understanding of business environments, operations process and practices a Inge: © Common business management and decision making concepts, peiciples sctvtlesund practies. © Typleel orgunlzaon structures jh functions and work activities. © Complex business functions and operations Understanding of relevant regulatory, compliance, and gysernance frameworks, Understanding of auditing and security issues 33.2 Industry Knowledge 1 Purpose Uosiness analysts shoul haven understanding othe industry tha thir organization {sin so ha they may understand nev challengs that maybe peril By competitive ‘moves and which solitons have proven efetive elsteber, 2 Definition Industry knowledge ie the understanding ofthe competitive frees that shape an in- dustry requires that thebusiness analst understand the various customer segments thatthe industey services nd the demographic a other chatastersticscomanon ta hat seginent Aa understanding of major tends impacting the industry wil lp shopehusinew requirements, Competitors wil hemaking changes a their product, ineup and business operations ia response to these changes, and thebusiness analyst ‘ay need to recommend changes tan ongcing change initiative in order to respond to competitor's action iw Ta aR A aEcs ae 3 Bifectiveness Measures Measures of eectiveindustry knowledge may include: > Understanding of industry related matertal and keeps abroas of what i taking place the industry the ability to dontty key tends shaping theiadustry > Knowledge fmajor competitors and periners for the crga nization, > Knowledae ofmajor customer scements. = Knowledae of common products and product types. > Knowledge ofsoutees of information about the industry, including alone rade crganiralionsoejoutvals > Understanding of industey specie resnuree and provessdocumets Understanding of industry standard processes ind methodologies > Understanding of the industeyregalatary environment 333 Organization Knowledge 4 Purpose Business analysis fs ignlicantly assisted by aa understanding ofthe organization for which isheing nerfed, 2 Definition Organtzation owledge ian uederstanding ofthe husnessaechiteture of the orga niration thas bing analyzed Includes an understanding of the business models thatthe organization that s how the organization generates proftsor othersise accomplishes its goal) the organizational structure tht isin plac, the relationships that exist borwoon business units andthe persons wh oecupy key stakeholder post tions, Understanding of an onganeation requires understanding! the informal ines ‘of communteation and authority that usually exist tn parallel with the femal ones and theinternal politics that governor ilfuence decision-making, 3 Effectiveness Measures Measures ofa busines analyst's organitational knowledge may include Understanding of terminology oF jgyoa use in the organi > Understanding ofthe products oF services affred bythe onganization, > Abily ta identify subjeet matter experts inthe oegantzstion, > Organizational elationsipsand polities BinOrGade Neier 29aS so 334 Solution Knowledge 1 Purpose Business analysts can use their understanding of existing solutions order toi the most effective means of implementing a chang 2 Definition ‘Business analysts frequently work on projects that involve enhancing existing oli- tion, purchasing » commercially available sation, rather than developing entirely ‘ew custom solutons. In these efreumtances tts kel that the method of implemen {ation chosen will make wsigriicant dillerence in the time and flot required, Abus ‘oss analyst who sfarilar with the workings ofa salution maybe ableto more cally ‘entify and recomend changes thst can be implemented easly hile il providing enncrete benefits Familiarity with th range of commercially available solutions or supers ean asset with the entiation of posible alternatives. 3 Bffeciveness Measures Mesyutesof usefal solution kamwledge can inclu: > Reduced me or ust to Implement a required charge > Shortened time on requirements analysis and/orsclution design. Understanding when a anger changes justified based on business benefit Understanding how adlitional expabiitis present, but Nat eusrently used, a solution ean be deployed to provide business value 84 Communication Skills 34a ral Communications 1 Purpose (Oral communication skills enable business analysts to effectively expres eas inways that areappropsate tothe target audience 2 Definition cation sills are used to verbally expressideas, information, o eter ‘matiers. Oral communications area ich charinl tha ellos foe the lflcen transfer of information, incloding emotional and other noo-verbal eves Elective otal eosuunica- ton skills include bath the ability to make oneself understood und the wetive listening bill that ensire thal the statements of lhersare sceurately wndersond The business ‘analyst must have an understanding of vone and how it eun positively or {gence the listener Oral communication is most effective when 1 ‘communieated will be used in the short ter 3 Effectiveness Measures Effective oral communication skills can be demonstrated though > Fieetwely parapheasing statements 1 ensure understanding | Ta aR A aEcs ni > rectively facilitating sesslons, ensuring success through preparedness and eo > Developing and delivering powerful presentations by positioning content and ab Jectivos appropriately (Le positive verace negative tone). > Can communicate theeritcaity or urgeney of situation na eal, rational man ‘er wih propused solutions a2 Teaching A Purpose Teaching shlls are req iced to ensure that business analysts can effectively comma ate issgsarid requirements und to ensue thatthe information communicated is inderstood und retained 2 Defnition Teaching requires an understanding ofhow people learn and the ability to use this understanding to effectively fallitate the learning experlence, Efvtive communi tiom af requirements reqaites teaching skills. asi frequently requies thatthe business ‘analyst educate implementation SMEs about the contest tha a solution wll be imple- ‘mented in. business analyst must he aarar of diferent learning styles, nchading, visual earners (who larn bist Unrough the presentation of visual ides. and mod: ch auditory learners ha lontn bo une hrongh orl communication and written lan- 1 inesthorie earners who lara mast ffeetively through doing The business analyst should naderstand hoxe different learning tyes may determine thoform of requirements eommunication. The busines analst may aso teach the wse ‘of analyse techniques to stakeholders n arr to allow them to participate more fly ‘nd digcetly in thesnalysts process, Efetive teaching als requires a understanding ‘t methods that may be used to confit thatthe student has learned and ean apply ‘what they have Fearned. 3 Bffeciveness Measures Effective teaching sil ean be demonstrated throughs > Yerifying tha earners have acquired information that has eon imparted to them. Ability of earners touse new ails or demonstrate new knowledge 843 Written Communications 1 Purpose: Written communication sis are nocessiy for business analysts to document elck tation results requlrements, and other information fe whch medium to-long form records are required. a aD asRE so 2 Definition ‘Written communication ivolves the use of symbols to communicate inforastion. Inches the ability ta write electives fr various contexts and audiences. Weiten frequived when information willbe used at ime or place thats ‘mote fom the tine and place it wes created. fective writen cammmieation equltes hat the busines analyst have broad vocabulary strong grasp of grammar and style, fad an understanding of whieh lions and torms wl be readily wnderstid by the a dence. Written communications are capable of recording a great deal of ifurmat but it fequenlychallenging.to ens that the writen text s correctly understood. 3 Effectiveness Meesures Esfoetive written communication skills ean be demonst sod through 1 Absiyta adjust the stple of writing forthe needs of the andince > Properuse of grammar and sive. > Appropriate ehotoe ot wonls > Ability fhe reader so paraphrase and desert the content ofthe weitem coment 85 Interaction Skills asa Facilitation and Negotiation 1 Purpose ‘Dasiness analysts faiitate interactions between stakeholders in order 0 help resolvednngreements regarding the priority and natuee af equitements 2 Definition Facilitation s the skill of moderating discussions umong a group to enable all parte pants o efcctvely articulate their views on tpt under discon, and th frtber ‘ensure tht participants inthe discussion arc abo 9 recognize and appreciate the fering viewpoints that sre articulated. namaey cases, at elective faeitated discs help partiipantsto recognize that they hae differing views ona topic undcr Aiscussin, The business analyst maybe reise to super ney tatan bel ween ppartioson how best to fecave those differences. The businoss analyst must ho able to nti the undestying interes'sof the pa tes stings those interests Srv the stated positions. ond Help the partesta identity selutionsthat eatisly these underiying 3 Effectiveness Measures [ffctve facilitation and negotiation skills are demonstrated through Ensuring iat purtlelpants ina discussion corrcetly understan one another's post > Use ot meeting management kills and tools incuding agendas an the use of meting minutesto keep discussions focused and organized es Ta aR A aEcs ii > Prevent Hacussions frm being sldetracked onto trelovant topic, > entiying common areas of agreement > ifective use oder suegolstion styles. > Ability ro iendty eaportan sues, > Understanding and consideringall parties interests motlvatns and cbectives. Encouraging stakeholders to exch win/win outcomeson a exlar basis > Understanding of palticalmplicationsin conflicts and negotiates na politically sensitive manner > Understanding the impact of tne and Uening on negotiations 352 Leadership and Influencing 1 Purpose Business analysts need to be ableCo be effovtive in fren and infarmal leadership ‘oles, in one to guide othersinestatingrequitements an to help encourage stake- older suppoxt foe a necessary change 2 Definition “The business analysts responsibilty for dafiaing and communeating equlrements olace hiro he in key leadership eolein any group ar project tam whether oF sot there sre people formally reporting to the business analyst ‘Leadership involves motivating people to aet in ways that enahle thom to work together toachicveshared goals and objectives, The busisess analyst must wnderstad the nd vidual neds and capabilities ofeach tram member and stakeholder and haw those can beinosteh ship therefore requires hat the business analyst beable todevelopa vision ofa desired futucestate that people can be motivated to work towards and the interpersonal skills necessary to aneouraze them 10 40 50. “tively channcled inrder to reach ibe shared objectives fective leader 3 Effectiveness Messures Esfetve leadership und in luenving sills are demonstcated though: > Meduced existance to nccessary changes > Team members and stakshoklers demonstratinga willie tose aside personal objectives when necessary 1 Asticulation ofa clear and inspiring vision ofa desired flute state, 353 Teamwork 1 Purpose Business analysts must be able to work closely with other team members to effectively suport hele work so tha solutions con be fete implemented a aD =Sa ei so 2 Definition ‘Business analysts customarily work as part of team with other business analysis ojeet managers other stakeholders and implementation SMES. lationship within hie eum ste important part ofthe succes of any profs! or urguniustion ‘Thece area numer of eam devslopmeat medels tha attempt to explain how teams form and fanctins. These models outline how the fear progresses ad wht ix wre at Yarous stages ofthe team level. Recogatuing th sage ofthe team’ progress ean loner the sires of lean relationship development by allowing meaber a recognize Ibchavlorsas normal cxpected, anda stage tobe worked through, Communications and trust cam also beenhanced through understanding ad arareness of facet seh 9s the proces setting ofrules or the tau, tum decison-making, formal and informal team klership and management le. Team conict-isquite common. Ithandled wel the resolution of conflict ean aetaally benoRtthe ream The basletypesofennfit ure cmotinnal and eogaltive, Eniational conic stem rom personal interactions, while engaitive conflicts are haved upos ds fgreenents on matters of substantive valu or impact onthe projet oF organiPation Resolton of cognitive culo: regares the team to focus on examining the promis, sssumptions ohservationsand expectations ofthe team memhers. Working through such problems cam have the beneficial effect of strengtheningHhe foundation of the finals andthe soliton, any eonflicstwatins encompass both emotional and engritive ements 3 Bifeciveness Measures [Elfetive tanworkskills are demoasteated though Fostering collaborative working envizonment > rtetive resolution ofeoamet > Developing nual among lesen esnbers Support wniong the tam fr shaved high standards of achievement > Team members havea shared sense of oe ncrship of th 86 Software Applications 8.6.1 General-Purpose Applications 1 Purpose Business analysis use ofee productivity applications to document and track requite eam goals 2 Definition These applications generals eonsist of three components ina suite of tons word pro: cessing spreadsheets and priveatation software, Te documents produced by these tools are the primary way which information is sored anal distributed in many a ations and business analysts need oe prlielent withthe use even where tore specialized toolsare available. They have the aévantage of bing laweost or even fre, a Ta aR A aEcs a x willhave acces to them, ‘and almost every stake ‘Word processors are commonly used ta develop and malntatn requirements doci- rats Tey allow a great deal of conteol over the formatting ad presentation of ‘document Standaed requirements documentation templates ine widely aval for ‘word processors. Most word processing tools havea limited capability to track changes fand record comments and are not designed fr eollaboratie authoring Spreadsheets are often used to maintain lists (sue 2s atomle requirements feaes, actos, Issues, oF defects Spreadshuetsuce the tol of ehoie forthe eapturv and ud nenlaty algorithm eanipulation of mumetiedsta. They ean alo heused to support decision analysis and are very effstive at summarizing complex seenarios. Spread Sheetsalse support liited change tracking and eam be shated among multiple users Jn muck the same way usu word processing document. Drosontation software is eommoaly sed to support trsiningortaintrodice topes for discussion among stakeholders While some of these applestions eat be used Ina very ited way to capture requirements or simwlatca Infidelity prototype. their primary purpose sto support the structuring and dlivery of erbal information, Collaboration and knowledge management tools ate used 0 support the capturing of Knowledge distributed throughout an organization and make tas widely availabe as posable. They enabledacumentstobe made aallableto an ene team and facitate ollaboration on taneously ad generally supper’ comtenting on or discussion about the doctments for ther content aswell These tole nay take the form of document repositories which Inograre with office productivity sofware). wikis (which allow easy eteation sd ink ng of web pages) discussion foruins, or other web-based tools, They can wary widely in hose documents, enable multiple users to work on adc onent simul Commmuntestion tots, such a etal and instante aging ss needed! 0 communicate with stakeholders why are remutelylvcated who cannot {espond to queres immediately or who may need a lnger-term record of«discusslon. ‘hey ate generally avilable to almost all stakeholders and ar very easy to 58 How ever they ate generally not effective for longterm storage ot rel Thele primary we 0 failitale communication over time or distance. 3 Effectiveness Mesures Measures of kill with gencral-purpove applications ncude: Ability to apply an understanding of one tool to other sinar rots, > Abloto identify major tools inthe marketplace and deserthehow they areused in ‘any given situa Understands andlis abloro use most f tho major features ofthe 19 Abletouse the toolsto compete requirements-related activities more rapidly than Js possible without them Ableto track changes othe equitements mad through the tools a aD asSa ei so 36.2 Specialized Applications 1 Purpose Business analysts use modeling tous to support the development of formal models, and Im some eases, thelr validation and iflementtion as wel 2 Definition Diagramming tots are designe! to support rhe rap drawing ancl documentation ofa model, typically by providing. set of templates ora partiewlar notation which are used tedexciop dlagramshasod an. Tacy gonerally do nor enfore oF verity compliance ‘wth the notation sandard or do sofa ieite ashion. They are generally low-cost ely easy to use, and the resulta dlagrams ean he Integrated into aword yedocurnent ‘Modeling tools facitate the conversion of the mode! ino an execubleform, etherby tse of proprietary enginefor exeenting the model oe by generating aplication code ‘which ean be enbaneed by a developer. The too wll erty complianee withthe nota tion, Some modeling tools support the creation ofexecutable del, sich as bs ness process management sjstems (which allow forthe ercation ofexceutable process ‘models and business rules managenicn!sysiens wil allow forthe enforeement of ‘aplared business rule) They are medium to high est and often require some special ued trainingto ase Requirements managesnent tos are used to support change contol, traccabilt, and configuration management of reqirementsandteitement artifacts Some tals srealo eapablecflinking requirements to software code, Thy are designed to ensure thata reason is recorded for any changesto the requirements and to help to rap ‘ny any impacts from those change. hey are medium to high-cost and often te ‘gute spccialit taining, Theyare most commonly sed by large andice geographically disperse teams. 3 ectiveness Measures “Measures of sil with specialized apolicationsinelude > Abiltytoupply an understanding of one oul ty eter similar Looks, Able to idenvty major tools the marketplace and deseihehave they are ase in any give situation 1 Unversandsandlis abe use ms of the major festares af the io + Able tous: the tools tocomplterequisements-rlatd activities more rapidly them Js posible without tha. > Abloto track éhangesto th roquiroments made through the tools a Ta aR A aEChapter 9: Techniques 91 oa The Techniques Chapter provides a high-level overview of thetechalques referenced in the Knowledge Areas the BADOK" Gude, Technigucsalter the saya busines analy sib asks performed or describe aspeeiie form the output ofa task may take ‘The techniques sted here are only a subset of the tachalques used by practitioners business analysis The ones sted here ate applicable to cnongh diffrent situations and business domains, and have been adopted by enough business analyts practitioners, ‘hata skilled generalist should reasonably expected to befailise with the exis tenee and purpose of the techalyue. Business analysts who speealize ina perticlar methodology or business domain may need to nderstand a smaller sct of techniques Ingreater depth or may ned to dovelop expertise la techniques not described here, Ina numberof eases we have gronpeda set of conceptually simile techniques nto a single entry, This was daneto indicate that any one ofthe variant techaiques that are Tisted in that entry or even variants that are not specifically mentioned) maybe usable for that purpose, While there are certainly important theoretical and practical difer- feneos heticen these variants, most practitaners wil find that expertise slngle ‘asian is slfcinl in any particular environment. Acceptance and Evaluation Criteria Definition Purpose ‘To define tho requirements that must be acceptable hey stakcholders, et n order fora solution tobe considered Description Determine which requirements ean most effeetvely he used as acceptance a evalua > Acceptance criteria deseribe the minimal set of requirements that aust be et loner fora particular solution ta be worth implementing valuation criteria ae thesot of roguicements that willbe used to choose between ‘multiple salutions ‘ther acceptance and evaluation eriteria may be used to determine fa sotion or s0- Jution component can be shown to abjctively moot a requirement. Acceptance extern are typically used when only ane possible soliton i beingevaluted and ate generally fexpresed aa pass or fale valuation eteria ate used to compute miltpl solutions tr slution components and allow for a range of pomsble scores Elements 1 Testability Acexplance and evsluation criteria, even moreso than other reguitements, must be ox pressed ina testable fore, This may require breaking them dowi into an atone oem ‘ich that eat eases ean be written lo verify the solution against the criti.2 Determine Ranking and Scoring ‘Rankingsthe process of determining the order of importance or all egulrements, as Aeserine in Prise leqaaremente (a) The WeSCaNY technique is setal for hs pit pose, A°Must Have rier sone Una will remove a proposed solution fom consid- fraton fot met, Lower level of peionty wil ecelss lower aking Scoringis the process determining how wells solution meets requisement, A seal sould be established fr seoting el requirement and multiple possible scoring Levels ete In bots cases staksholders must agree not only on the eitera, but how the solution willbe rate against them, 14 Usage Considerations 1 Advantages > Agile methodologies may require that all requreents be expressed in the form of testable sceoptanes eran, > Acceptance criteria are also ‘obligations, essary when the requirements express contractual Dhadvantages > Aveeptance and evaluation crteria may express contractual obligations and as sch maybe dificult ta change fr legalorpotitcal reasons 9.2 Benchmarking 921 Purpose Benchmark studies are pecform! to compatethesengths and weakwesscs af organization axainstitspeors and eompetitors 922 Description Benchmark tudes are conducted to compare organizational practices against the best in-lass practews hat exis within compertta enterprises government or dustry, The objective of bench muck studies to deterinin how cormpanies achieve theirsuperior performance levels aad use that information to design pejects to Improve operations ofthe enterprise, Henebmarkings usually focused on strategies, operations and proccases 923 Elements Benchmarking requires thatthe business analyst > Wnty theatea tobe studied > entifyonganirations thal are leadersin the sector > Conducta survey ofsclcted organizations to understand thelr peatiens -Aerange or vss to bes-4n-class organizations Ss] Ta aR A aESn | Poi > Develop proet proposal to implement the Dost praetons 924 Usage Considerations 1 Advantages enchmarking provides organizations with information about newand diferent meth ods, ess, and tool to nprove organizational performance 2 Disdvantages Benchmarking ime consuming In addition, organizations may not havethe exper- tise conduct the analysand acquire or inorprct useful competi Information Because tineolves assessing solutions that have been showa te woekelsewhere, with the goal ofrepraducing them, benchmarking eennot produce innovative solutions ot solutions that wil peoduces sustainable competitive slvantage 93 Brainstorming 9.3 Purpose Brainstormingis an excellent way to foster creative thinking bout a problem. The aie ‘of brainstormingis to peodice numerous new deas.and to clrive fom them themes for fucther analysis 932 Description Drsinstormingisa technique i Brainstorms hep anvwer specie questionssuch a (but ded to produce a broad or diverse st of options anid to > What options are available to resale the sae at hand? What fctors are const ception? ning the group from moving abead with an approach oF What couldbe causinga delay in activity 8? What can the group do to suve problem 8? Brainstorming works by focusing ona topic a problem, and thea conuing up with many posable solutions toi, This techniques bev! applied in «group weit draws on the fexparience and creativity all members ofthe group. 1a theabsonce of group, one ‘ould heanatoren cn ones own Lo aptck new Wena To heighten crenlvily,paricipante srecnouraged to use new ways oflooking a things and fiveassodiate it any diction, Taeiitated properly, brainstorming eam bef, engaging proactive 933 Elements 1 Preparstion > Develop a leur and concise definition ofthe area of iatecest > Determine. time limit for the group th generate seas the lange tho group. the son time requieed a aD Easie eg Went faetitetoe and partelpantsia session, es for parthelpants (ideally 61 8) ‘who representa range a ackgronnd and experience with the topic Set expectations wit participants and got their buyin to the process tablish criteciafor evaluating and eating the ideas. Session > Share new i without any discussion, etiam ar evahation, > Visly recon aliens Encourage pusticipants tobe creative, share exaggerated tens andl the does of thers. > Don't mit the number ofideasasthe goals to clit as many es possible within the toe period, 3 Wap-up > Oncethetime Init is reached, usiag the pre-determined evaluation eitecia dls ‘nse and evaluate the eas Create a condensed it ofdeas corine eas where ajprapriats nd climinat daplicaes. fate the Meus Distribute he fal ist of Meus to appropeate parties 934 Usage Considerations 1 vantages > Ability to elicit many dessin a short ine period Non Judumentl eavironment enables erative thinking. > Canbe useful during workshop ta reduec tension between participants Disadvantages > Dependent on participants eteatsity and willingness pattleipate- Organization ald interpersonal polities may eso > Group participants must agroo to evaid debating the ideas raised during brain 94 Business Rules Analysis 94a Purpose To define the rubs that govern decisionsin an organization and that define, constrain, corenable organizational operations | Ta aR A aESn | aa 942 Description Policies an rales direct and eonsteain the organieation and operation of an organiza tion, A business policy isa non-aetionable directive that supports a business goal A business rales specie setionable. testable dieective that Istundr the eon of a ‘organization and that supports. business policy. Particularly complex ule, o rules ‘witha nurnber of interrelated dependcncies, may be exprested aa dees tahioar Ascision tree, asdencrbed in Delon Alps (2). A number ofbaste principles gue the business analyst when steting and manag busines rales, Te busines cules shoul ie > Stated in appropriate tor SMEs to validate theres nology toonable domain » Document independently a have they wil enforced > Stated atthe atomic evel and in delaraiveFrmat, > Sepurated frum processes that therule supports orconmstrains » Maintained ina manner that enables the organization to monitor and adapt the rules the business polices change 943 Elements Business tes require a defined glossary of termsansan understanding ofthe rela tionships between ther, knawn as a"teray and fet moe (oe Date Ditionay and Glossary (25) vd Dara Node g (97) for farther iatoemation. tn order insure that they are independent of us plementation, rule should not depend on anyother Jformation, oF include assumptions about hove they willbe enforced 1 Operstive Rules Operative rules arerules thatthe organization chooses to enforce asa matter of poi They ate intended to guide the actcns of pople working thin the oeganization, “They may shige poap ts take ertainactons, prevent people fom taking prescribe the conditions under whic an action may be taken. Oy definition, must bbe possible for poopke 1 velatewn operate rule even there are necireumstancos tuner which the ongasization would yppeove of them doing wo. Ar example of an oper tive raisi= An order must nt be placed when the billing adress providedthy the customer doesnot ‘maeh the address on file with he ered card provider Because s possible to violate an operative rule. farther analy mayhe conducted ta detecmine what kinds of sanctions should be imposed when «rues iolated, allow & tobe oerridden (before oF ate the fact) ot the eicumstances when an exceptlan toa rules appropriate These may lead to the definition of additonal rules. 2 Structural Rules erie whe Structural rulesace intended ia help something soris nol teu, oF ‘who things fallinto a spoeifc catozors They are vxprassed as rules because they Aeveribe categorizations that may change ave ime, Hecause they sinucture the knowh a aD asaA eg 944 95 9.5. 952 953 edgeof the organtation, rather than the behvlor of persons they cannot be vokted (hat thoy can hemiaipplied) An exaraple os structral rile Anvorder must have one cond only ome assoctoted payment msthod. Structural rulesmay also describe lov information may be inferod or ealeulated based om offer dat available ta the business Acaleulaion maybe the res of the sppliction of many fdivklual ules. inference rules ear alsa be used to evaluate dost Shans daring process. Far example An order's location tax amin i calculates (sum af pve ofall w: tter'staable ordered tems) local yarsdeton lax rate wnout Usage Considerations A Stengths (Clearly defining and structuring cules allows organizations to make changes to policy ‘without altering processes. The impact of changes obsess rules eam he assed smoce cai hen they are documented separately Ir the procenves they detailor the rans sed to enforce theres 2 Wesknesses Orguntzations may produc lengthy Hat of business rules, Business rks ean con tradiet one another or produce unantie)pated results when combined. I ray aso be Jmportaat to question existing busines ules foe contin ing relevance te enrent ed projected modes of organizational operations andsteucture Data Dictionary and Glossary Purpose Adata diet 1 or glossary dellnes key terms and data relevant to business dows, Description Data dictionaries or glossaries ate used to formally identify and define al terminology used by the organization or orgaatzational unit. For example an organizational unit say diferente between a cheat anid customer were cen! i party with whom thebusiness has an enforceable professional service agroemeat, whercas a customer ay havea mich mote casual rassaction base relationship wit the business. ba 2 Inealtheare organization, suet asa hospital the term patient maybe used, along with Its unique definition, rather than either cient o customer Elements 1 Glocsary Aglossury documents terms wnigue tu the domain. is created ip order to ensure that allstakeholders undersiood what is meant when certain words are used. A glossary {onsiss ofa term relevant tothe domainand a unique definition foreach, us wells stontrelerencing allses. 2 DsteDictionary Dota dictionaries include standard definitions of data clement their meenings, and (i ete ins Aina ad of airedSn | ca 954 96 allowable values. A data ditionary contains definitions of each primitive data element fan indicates how those clement combine nto composite data slements Primitive Dot lems ‘he following Information must be recorded about each data clement inthe datadie: tionary Names uniguoname fr the data element which willbe rferenced by the eam posited elements Aliases alternate nanos for tho data element used by various takeholers > Yalues/Meanings ist of acceptable vlus forthe data clement. This may be ‘expressed as ut enumerated list oras description of allowed formats forthe data (including information such as the mumiber of eharaeters the vals arc abbeev: ated this will include an explanation ofthe meaning. > Description: thedofiniton ofthe data element in che context ofthe soliton Compost Data ements Composite date is asermbled from primitive data elements, Composite structures incu Sequences: show primitive data ements in ordat. Te prlaltve eents must lye nent in the specified order > Repetitions: show that one or more priitive dat cements occur multiple tisies Intho composite element. > Optional elements: may or may act occur ina particular instanceof the dat ee ment. Usage Considerations Adatadictionary or glossary i useful for ensuring that all stkeholders rein agree ‘ent on the format and content af relcvaat information. Capturing these definitions in ‘single model ensures that these terme will heed consistently Data Flow Diagrams 964 Purpose ‘To show how Information s input, processed, stored, and output fom a system, 96.2 Description The Data Flow Diagram (DFD) provides a vial presentation of how inftmation be mow thrgh a wpm, shows the External Entities that provide data to or recive data from. a system > theProcesses ofthe system that transform dat BinOrGade Neier 29TE eg > TheDataStores in which data selected fr sounepertod of ane The Data Flows by which data moves between External Entities, Processes and Data Stores 96.3 Elements A External Enttles Anexternal entity isa source or a destination of data, ts represented a3 labeled rec: ale 2 Datastore Adatastore represents location where data isnot moving or transforning, but is be- ing stored passively for future use Data stores ere represented as alabel between two parallel linesora labeled veetangle with a square 3 DataProcess A data process isa process that transforms thedata in some wap ther combining the data, ordering th data, converting the dats filtering the data or athe such active ties, An asterisk within the process is sed to identify cata processes that have Further decomposition modes, Date Processes are represented as a labeled eve or a oetanghe with curved comers Standard iaheting isto use a Verh-bject structure 4 Dataflow ‘Adata flow identifies where dataishelng moved between «data processand an exter ‘al oatty a data store or another data proces. The abe! should hea uoun phrase that ‘enifies dato being mad ean he further species into results, contr flows and update ows. Data lows are represented by singe or forked line with an atrow ines mat belated with a deserter ofthe data being moved. 96.4 Usage Considerations Data Flu Diggramsareusod as part af structueed analysis approach. hey ate ws togst an understandingof the range of data within the domain, Theyare typically sed sfter a context diagram has been completed and as a prerequsite or concurrent eet ityto data modeling A Strengths » May beused asa discovery technique for processes and date, ora technique for veteation ofa Functional Decomposition (2.12) u¢ Data Model(2.7) vat have sltendylbeen complete > Most users find these diagrams quite easy to understand, > Gonurlly considered auseful analysis deliverable to developers in astructaced 2 Wesknesses [PDs cannot casi shove who is responsible for performing the work. They cannot ‘Shay alternative pas trough thesame process es Ta aR A aEota Medeting rece Lig) casione Figure 9-2: Data Few Diagram Yourdon Notation) External Entity [7 InputData output Data D8 Store Data Process 97 Data Modeling 971 Purpose The purpose ofa data models to deserbe he concepts relevant to domain. the rl tonships between those concepts, and information asseiated with them 972 Description ‘Adata move! usually takes the form ofa diagram supported by textual descriptions. It visually represents the types ofpeopke places, things and concepts that are portaat tothebusiness attributes associated with them, and the significant business etn ‘hips among them. Data models ate aen supported by a Date Dictionary end Glossary (25)and by Busines Rules Anais). ‘The two most widely used types of data model are the entiy-relatlonship diagram (EtD} and theelassdingram, although other modeling notations remninin ise the ne {ation used is often determined bythe technology platform ofthe organization, ERDs ste generally preferred when the model willbe ised as the basis or relational data base, while class diagrams are preferred for supporting object-oriented development Business analysts who may have rouse those models shoul understand the nnique characteristics of each type ofdata model—they serve similar purposesbut havesome Important eonceptol diferenees that emerge i practice snake ee PsSRG eg 973 Elements ‘ogeal data models desertbe the information relewant to an organization. High Sevel Jogical data models may focussolely on describing the entities, attributes and relation ships of most Importance, Detailed loglcal data models communieate comprehensive descriptions of ll elites attributes and relationships Physical data models describe Iho dara stored and managed ina anftvare application, a concep Acoacopts something ofsignificance to the domatn being described, about which the ‘oxyanization nerds data act type of concept should have # unique Mlentifir a type of tribute) that dfeeen tates heticen actual instances ofthe concept, Concepts are refered to as entities in RDS and as classes in lass diagrams 2 Aabutes An attribute defines a particular plsoe of information assoetated with sconcept—how "mich information can be captured int, allowable values, and the typeof nfarmation Figures-3Emty Relationship Diagram Crow's Foe Netatin] Bien ent shown a2 The unique iene te recangletitn neers enaty seven unr the rene entity name Entity T Entity? ! ‘Unique Wdentifier ,eationship eft to Oht, sigue Wlentifer let snes iearonsip ghia ef pe rags wiv Trae center True enter ait F Foren fey sated : Tae r 1 Fesubesof meen] : itonshps nena Protons bow hove 1a] Sratne men samotee sonar hw cay. cardnabty oa en] a CE) fea Ayrunberawo FeoeOw Davo Ayamiom cnn ‘une es Ta aR A aESn | inate ed a aliases . forthe attbute. Other names used by stakeholders may be exp val 5/ Meanings «list ofacceptablovalies for thesttribute. This may becxprossed umevaed Ist ort description of llawed formats for the dat inca Information such as thc numer of chatacters If the values arcabbrevfated this will Inchde anexplanatio of th Deseription: the dotaition ofthe atte inthe eoatext ofthe solution, 3 Relationship Relationships are significant business associations between concepts The example ‘Shaves the relationships etwoon Business Analyst and Requirement asain annotated Tine, The Wbels expan the natuce ofthe elalionsbip from the perspective af each cnt. Relationships define how infor ation sed inthe eperation ofthe busines, ad cate the important linkages that nced tobe managed and maintained inthe solution, Relationships may also indicate the cardinality” or "mult" of The Go. the mumier of rlationships alowed or required), 4 Metadata Metadataisdofined as "Jata about dat Metadata deseribes the context, ust and va Fig 9-4 ls Diagram (UML) Trenaneotinedaschtedhes ] [ton psare hae] Trmapoptanay hws erecype bys wana ab ‘hen eerste owns ¥ i Thevalues, goals and objetives that arerelovant to the decison problem > he nature ofthe decision that must he made > Theareas uncertainty that afet the decision; And the consequences of each passble doesn, ‘The tasks in the Enterprise Analysts Knewledge Area describe much of what required to effectively structure adeision problems This technique deseribes he particular tools used to analyze outeames, uncortainty and tado's.Deeison analysis can vole the usec very complex models and specialized wllware applications we Ta aR A aESn | Ses 983 Elements 1 Outcomes Decision analysis generally requires thatthe business analyst use some form of math- ‘matte madel to asses possible outcomes Financial Anais Financkal mols estate the market value of an organirticnal esse for example, estimating the value ot anew business soliton or acquisition Commonly use ane! valuation techniques includes > Discounted Cash How: futurevaluc ona specific dats > Net Present Vi Future view of costs and benefits converted to today's vale > Inter Rate of Return: te nterest rater discount) when the net presoat value equal tera > Average late of etura: estimate ofzate of retuen on an icventment Pay Back Periods the ams ‘of time takes for an ivestment to pa fr ise > Cost tenefit Analysis: quantifestionofcostsond henefits fr « propored new solution on Fhandal Outcomes Not all decision outcomes ean be expressed in Financial tras. However: effective dec son analyssstill requires that outcomes be diectty comparable, In some cases there ville metric that is applicable elects per thoussed, percentage uptime customer satisfetion rating). When there no.a relative scoring of posible euteomes el have tobe determined, 2 Uncertainty Uncertainty becomes relevant toa decison pre when itis imposuleto know which oiteome will our This maybe dc to missing information. or heenuse the ot cme depends on how others respond. A canes method of dealing with uneeetaint'y indecision problems st9 caleulate the expceted vl of cuteomes.Thsinvales svlimating the percentage chance of each malcome ocent ting ana then emliplying the ‘meric wlio associated with rhat outcome hy that percentage A decision rec is amethod of assessing the prefered outeome whece multiple sonrces of uncertainty may exist 3 Tradeoffs ‘Trade-ollsbecome relevant whenever 2 decision problem inolves snultiple, possibly conflicting, objectives. Boeause mors than ane ohelive is elevant. tis na suiicent {simply find the maxim valve for one variable uch asthe Sancta benefit ar the ‘organization. When making tales effective methods ned a aD asaE eg > Elimination of dominated alternatives A dominated alternative ls any option thot sclears internet some ater option. Han option ts qa to worse than soute other option when rated agalust the cbjectives the other aptlon cus be stk {o dominate In some cases, an option may also be dominated iit ony affers very small udvantages but has igniicandindvantages, > Ranking objectives on a similar scale One mcthod of converting rankingsto 4 Similar sesleis proportional coring, Using this method. the best outcomes as signed a rating of 100, the worst ratingof and al ther outeomesare given 8 ratingbased on where they fll between those wo scores Ihe atcomes are then ‘assigned welghtabased on their altive importance, ascore canbe asianed to ‘ach ontome and the best alternative assigned usinga decision tree Fiaure9-5:DecsionTree famine [nes] 217 Sere ® } —<] outcome, robetiiy beer] prea 984 Usage Considerations 1 Advantages Decision analysis provides an effective technique to determine the expected value cof alternative seen to the organization > Using consistent financial justfeaton fechniquesin all business eases provides decision makers with quantitative meusurse upon which to make project invest Decision analysis may force stakeliolders to honestly assess the importance they Place on diferent alternatives. Disscvantages > Decision analysis roquiresspecialired knowledge and skills nlucingmshemt cealknotledge, an undetstanding ef probabil and similar concept, > Theres of decision analysis may be ueated as more certain than they actually are if decision makers do not understand the imitations ofthe model und the as Sumptions had I Ts Ta aR A aESn | tei > Decision makers nay be reluctant to revs deesions even when more information fs valle om arcas of nccetsnty that might change the optional dctson 99 Document Analysis 991 Purpose Document analysts tsa meu to elit requlrements by studying avaiable documents tion on existinzand comparable slitions and identifyingelevemt infarmaten, 99.2 Description Document analysis may include analysis of business plans market studies, contimets texquests for proposal, statements of wath, menos, existing guidelines, procedures, {taining guides compoting produet literature, published comparative product reviews, problem reperts customer suggestion logs an existing system specifications. aman, ‘others Kdemtifying and consulting al likely sources of requirements wll est proved requirements coverage, assimning the documentation ip to date, Document analysis used ifthe objective ito gather details of existing solutions, Inching business roles entities nd attiutes that need tobe inelded in ne sa {Hon or need to be updated forthe eurvent soliton Ths techaljue also apples in situ tions here the subject matter experts forthe existing sot ianeaceno longer wit the organization, or are not going to Deavallable throughout the duration ofthe clcttion process 993 Elements A Preparation yaluate which existing system end business documentation s relevant available and sppropriate firstly 2 Document Review > Study the material and kdentify relevant busines deals > Docunent business details as wells questions for follow-up with subject matter expects Wrap-up } Heview and eoufiens the sleet deta wth jest > Oxganize information into requirements foe > Obtain answers to follow-up questions 994 Usage Considerations A Rdvancages + Notstarting from a blank page > Leveraging existing materials to discover and/or confirm requirements. a aD as‘nn eg > Ancansto eros chock rogulzamnt from other oleltation teatgues such as interviews, jb shadowing surveys or focus group. Dhracvantages > limited to “aes” perspective. Existing documentation may nol be up-to-date or vl > Canbea time-consuming and even tedlous proces tolocate the relevant informa- ton 9.10 Estimation 910. Purpose Estimating tehnigus forecast the cost and effort involved in pursuing course of ue 910.2 Description Estimation techniques arc used fo develop abetter understanding ofthe possible range ‘cous and effort asvctated with any initiative. Estimation tuned when tts impose ‘bloto determin enact costs. Estimation cannot and doesnot eliminate uncer. father, the purpose of estimation inter gets reasonable asaeament.f likey coats or ior roquire. ‘The less formation that is available othe estimator, the greater therange afuncer tainty willbe Estimates sald herevisited axe information becoence available ‘Many estimation techniques ely on histericperformenec records rom tte organiza to calibrate thes auginst actual performance, Estimates should include an sens rent ofthe range of wneertaintyaswicated with tha etimate 910.3 Elements Analogous Estimation Use ofa similaepeojct ss the basis for developingelimates forthe current project. his used wher ites known, Analogous estimating is ofan used to develop a fangh ordcr ‘St mayeitude (HOM) estimate, and ial knows as"apdowe? estimates ally done a the beginning of the projector project phase and more detalles estimates follow aoc i kann, 2 Paramevic Estimation The use ofparameters, multiplied by the number af hours. For parametric estimating to bbe useable, enough story has tobe available to bo used as basi of comparison With this type of estimating the business analyst has done enough work to dctermine which parameters can heused and how many there willbe For example. the business anal has determined that there willhe ten use cases deveined, The business analyst en Ins history that indicates foreach use ease the (otal hous that wl be spat hn ais ease will be 29 hours Using this technique, the business analyst can mutiply 10x20 ta sot atetal oF 200 hours. Anumborof well-defined methods for parametric estimation exit for satware de | Ta aR A aESn | tn ‘lopment, such as COCOMO IL Funetion Pent Counting. Use Case Ponts ad Story 3 Bottermup Estimation {sing thisrechnigue the business analyst has collected the deliverables activites, tusks, and estimates from all theinvolved stakeholders acd rolls therm wp to got a otal forall he actvittes snd tasks Because is normally eases to estimate sale tems thas larger tems bottow-up estimating ean produce the most yecurate und defensible 4 Raling Wave “Thisisa technique invalving refinement of estimates Estimate the details for activites Jn the cuetent eration ot increment und provide an analogous estate fo the entire scope of work. Asthe end ofthe Werstion approaches estimates for the next eration fun madeand the initia estimate for all gti is reine, 5 Thywe-point Estimation Uses scenarios for > Themost optimistic estimate ce best-case seenario > Themost pessimistic estimate, oF worst-case scenario The most likely estimate ‘Note thatthe most kely estimates not an average of best and worst case scenarios I reqitesin depth knowledge ofthe situation, Under the right citumstanecs, the best faye somarlo may also be the most lkly, 5 Historic Analysis Uses history ts «basis ir estimating, Ite similar to analogous estimation, but is wsed ‘not only for the top-down estimate but for the detailed tasksas well. Historie estimates ‘require poe projet records, whether maintained formally in a project repository or Informally in individu proce! documentation. 7 Expert audgment Estimating relies on the expertise of hose eho have performed he workin the past: These experls can be inlecmal or external athe project team ot tothe orgatzathon, 8 —_Delphiéstimation This technique uses a combination of expert judgment and history. here ate several ‘ieiationson this procs, bul theyll includ individual estimates shaeing the es sates with experts and having several rounds uot consenans isreached. i average ‘ofthe tre estimates used, Sometincs the average le weighted by taking the opt ste pessimisticand four times the most likely dividing by site get the average. 9.10.4 Usage Considerations 1 Advantages Estimates can help stakeholders make better deci a aD = based onan improved under:ra eg sanding of the likey outcomes from an i 2 Diksdvantages Stakeholders frequvmtly real estimates as commitments and expect that once an est vate fgien the solution tearm will meet the tote and cost estimate. Estimates a often contciousy or anconseiously alLered to match tl Inflontal stakehnisers beeans the estimators or otherssre coneorned Ut higher ests woul cause project tbe rejected or be seen as demonatrating a lack o desien of 9.11 Focus Groups 911 Purpose focus group ina means to elit wleas and altitudes about a specie product service ‘or opportunity i an interactive group ensironment. he partieipants share tht in pressions, preferences and needs gulded by a moderaton om Description ‘foes geonp iseomposed of pre-qualified individuals whose objective Isto diseuss fand coment on atic, This fs an opportunity for individuals to share their own per spoctives and discuss hem ina groap setting, This could lad participants ro r-eval ate their own perapective igh of others experiences trained moderator manages theadministmtive pre sear, fetitates the session and produces the report servers nay cord or monitor the foes arp but bo not participate As thiseliitation wehnigue i considered a form of qualitative researeb, the session tesulls ave analyzed and Yeported as themes and peespectives, rather than numerical findings, he report may aio Include selected quotations to support the themes. A traditional focus ron gathersin the same physea! room. An online focus group ab lowes mnemivers to Belcabed remotely while participating vis network connection. Bach ‘approach has prosan consin terms of ingles and expenses, focus group can be utilized dsing any ife-cyoe state: exploratory under develop at ead to lunch or bn production, ithe groups topes a product under develo neat the geups ideas are analyzed i relationship tothe stated requirements This ay Testo updating exiting requirements or uncovering new requirements Ithe {opie ia complete product that ready tobe launched, the aroups report could Inflence how to position the product in the market. Ithetaple isa product in produc thon, the group's report muy provide direction on the revisions te the next release of segulremens. focus geoup witha produet or service, nay also serve asa meansto assess customer salsfictlon ‘The work of focus group may be similar to that done abralastorming session, One Aiferonee that a focus group is typically more stractuced, Another dieence that ‘brainstorming sessio's wal sto delvely ovek broad, realive, even exaggerated eos. | Ta aR A aESn | ra oma Elements 1 Preparation Recrit Participants A focus groip typically has 12 attendecs, I may be necessaryto ewite additional Individuals inorder tallow for those wh do nol atend the sealon duet sehedullng conflicts emergencies or fr other easons. Ifmany people necd to participate, may bbenecessary to rua more than one focus ero. ‘The tople ofthe focus aroup will infhenes who should be reeruited Ifthe topic sa new product, itis ely that existing users (experts and novies) should be included. There fre pros and cons that should be consMered when using hornogencous hetero fects composition > Homoguncous~ individual with similar charsctristies, Caution: Differing pee spective will not be shared. Possible solution conduct separate sessions fo dif at homogenous groupe to cllect difeing perspectives, > Hetesogencous -indvidale with diverse hackgrownds anor perspoctives, Cat tow: Tadividualsmas sel-2ensorIfnot comfortable with others backgrounds ‘opinions resting in lower quality of data collect. Assan The Moderator And Recorder The modorator should be experienced in fcitating geoups. Typical skills Include the ability te > promote discussion »askopen questions these requiring ar promoting an extended response) » facilitateintractions between group members > engage all members op session fused ral > bedaptableand exible Create Discussion Guide The discussion guide includes gouls/objctives ofthe session and five tu sx open ques tio Reserve Ste And Services Solct the location fr the session, (Arrange for technical support to transcribe the ss ‘om and, if used sudivideo taping equipment 2 Run The Focus Group Session The moderator guides the group discussion, folknrsa preplanned script of specific Issues and ensures the objectives are met, However, the group diseusfon should appear a aD asFa eg {rve-fowlng and relatively unstructured for the partilpants. A session i typlally 1 to ‘Dhoussin length A recorder captures the group's comments, 3 Produce Report The moderator analyzes and documents the participants’ agreements and disagree sand synthesizes them into themes 9.114 Usage Considerations A Advantages Abii to tii data from a group of people ina single season saves time and cost ‘a compared (o conducting individual interviews with the same numberof people, » sfetive for learning peopl’ attitudes, experiences and desires Actvediscussion and the ability to ask others questions creates an environment ‘whose participants can consider thelr personal vew in relation to ter perspec tives Disadvantages > Intho group serting.parrtelpants may he concerned about snes of trust, maybe unwilling to diseuss sensitive or personal topics Dare colleted (what people sas) may not be conslsten with how people actually behave Ifthe group is too homogeneous their responses may nat represent the complete et of requirements > Astilled moderator is aceded to manage group interactions and discussions > Temaybe ditt to schedule the group fr the same dateand tine Ifthe oat nfthe feus group Isto eli Meas ona new or changing produ. a focus rap is aot an efcetive wa to evaluate usability. 9.12 Functional Decomposition 9121 Purpose ‘To decompose processes, functional areas. or deliverables nto thelr crmponent parts find allow enh part tobe analyred independently, 912.2 Description ‘Funetional decomposition involves breaking down a lrge problem into smaller fare u primaty gal of functional deceenpostion bts ensue th the problem is separated into suh-problems that are asindcpendent as possible, that work eanbe asigned to dilleren! groups. his provides the ability to seale nd manage Ineger projets ot deliverables. | Ta aR A aESn | Sr Figure 9-6: Functional Decmpain Bagram saan Sones ee | Gresieyraa] [reves Vesa? 9.12.3, 912.4 BinOrGade Neier 29 Elements Fnetional decom postion identities the high-level funetions of an ganization ot solu- ‘om and then breeks those aetions into smallepieees, sc us sub proses and stv, ‘When decomposing a oxganlzational function, models start with a top-level neon, tspieally corresponding with an organizational unit and continue to dill down into sib-unetions representing the processes eared! oa by thal uni, and beneath Unose sub-procesees and individ activites the namesfor exch level arc eanvrntionsonl And do aot mpl tht decomposition suis halt ater te fourth lvl ie veached) These cane represente bya hlearchieal diagram u tee diagram, ory murbering each ‘ub-tupetion. Fae function s wholly comprised ofthe sub-Sunctions beneuth tke proces of anctlonal decomposition continues nila sb function canna bebroken| Alowa lato two or uote lower level functions, Asieilar process can he caried out forthe wark involved ina projet. This decompos 'n(known asa Work Breakdown Structare or WHS) breaks the projet scope down phases work packages and dliverables, Decomposition ean alo be performed to Aesorihe a product oF process Usage Considerations 1 Advantages > Creatas conceptual model oftte work that new hsnesssoutin wis tobe completed to deliver the > Provides taksholders with a consistent view of the scope of the ear Assists estimating in that estimates ean be made for smallor, and therfore more teadily unerstandable, subset the wholeaT eg 2 Dhadvantages > Thereis no way tobe certain that allcomponents have beet caplused > Decomposing « problum without fully understanding the rolationship between piecesol the problem say create an dmaypropsate sr welure that impedes sal 913 Interface Analysis 9134 Purpose Te dently interfaces between solutions and/or solution components and define re quirements that describe how they wl interac. 913.2 Description {An interaee is connection between two components, Mos! software applications ‘exquite one or mate interfaces, Interface ty pen includes > Use faces fncluding human users directly Interacting withthe ysten, as well fas reports provide tothe ser > Interfaces toad te ternal applications > Interfaces to and from external hardware devices Interface snelyss olpst clarify the hotndaes of the interfacing applitions 1 distinguishes whic application provides epee functionality long with theimpat fad output data needs By clearly and carcallysopareting the requirments foreach pplication while deiningtheshared interlace requtement, a basiforsueeesslal interoperability is ostobished ntfying what interfaces are necessary ta support an application sets the stage for slliting a wide varity of requirements Early identiation a interfaces uncovers land confirmsthe interfacing stakeholders and provides. framevsork Frsubseqient ‘nays the detalled requirements for each interface. laerFave analysis certalnly necessary fora sftwareslitinn or soliton comporient it can also he wsful fr ‘non-softare sation suchas when defiatng requirements for deliverables that willbe produced by third partes 913.3 Elements 1 Prepare for interface Identification ‘Revi eutreat dovumentation or any indications of tere eaultem ample, a Context Diagram, as described in Spe Modeling (227}ean provide an fe {Uvevisuallzstlon of the Interfaces to aud trom external partes. 6 Forex 2 Conduct Interface Wentifcation For each sakebolder ur system that interacts with the system ide sre needed, Far each interface > Describe the purpone ofthe interbee | Ta aR A aESn | ve > Evaluate which type of interface may be appropriate: user intertce. ystem-to system interface, and/or external hardware device iterfaces > lic high-level details bout the interface, depending on its type Foran interface whore thouscr diretly engages the application, so Fromiyping or a applicaton:to-appicstion interface or an interface ethan external hardware device, outline the content and nametherelated events. 3 Define interfaces Requirements for an interfaceare primarily feused on describing the inputs and out pts from that interface, any valation rales Yh govern those inputs and ont pats, and ‘vents that might trigger interactions There may bea large aumnber of possible terac- tom typesthat may each need tobe specie. 913.4 Usage Considerations 1 Advantages arly identification ofinterTaces provides aneaty high-level view oF interoperability for planning > Impmet on delivery date. Knowing what interfaces are needed, as well ue Ui a ticipated compleaity and testing needs enables more accurate project planning and potentiolsivingsia time and east, > Collaboration with ther systems or projects ftheinterZace toa existing system, procict or devies and the interface alteady ons, t may nat he changed asl the interface new, thea the ownership, development ana testing of the Interface ness ta headrest forbath applieations Im ease, eeiting and an Ipaing the interlace sesuicements wll key require negotiation and cooperation brseeen those respomathe for hoth plications Specification ofthe interfaces should prevent diffeutties in integrating multiple components 2 Disadvantages ‘Does uot provide insight into other aspects ofthe solution snes the analysis does not fssess the internal components 914 Interviews 94a Purpose Aninterviw is 2 8ystematic approach designed 1 ele! information from a person or froup of pooplkn am inform fem setting by talking ta ntarecwoe, ashing, felevant questions and documenting th responses 9142 Description In an interview, the interviewer formally or informally drcets questions toa stakehold «rior 1 obtain answers that will beused to etete formal requirements. Oneon ‘one interviews are yplcily mast cam on na group interview Orth mote than one a aD Esverte eg Interviews tn attendance) the Interviewer must bo careful to elcit responses from all For the purpose of ecting requirements interviews ar of two base types > Structured Interview: whore the interviewor has a pre-defined set of questions and i looking or answers > Unstructured intervie tere, without any predefined questions theterview- erandithe interviewee discuss tpiesaf interest n an open-ended wa. Successful interviewing depends on several factors inching, but not Limited to » Love ofunderstanding of te domainby he interviower. > Fyperionce of the interviewer in conducting interviews Skill of the interviewer in documenting the discussions > Readiness ofinterviewee to provide the relevant information. > ogre of clarity im intervieweo's mind about what thebusinos equines of the {seg system Rapport ofthtaterviewor with tho nteriesee 9143 Elements 1 Prepare For The interview Define the interviews focus or goal before procseding, ey Ptertialnteriewees ‘The husinessannlyst considers the follwing questions when kentifying who shoul be interviewed Who holds the most authentic an most current information on the subject of > Whats ther sake i the initiative? What is the relative importance oftnformation hold by one person clativeto that Ield by another person? This information's hela when analyzing conlitiog, comments sctossinterviws Design the Interview The interviewer may need ty custom design theIntersiew fr each Mdentiied interie ‘wee. Ihe interviewee’ ability to participate and the desied outcome of an interview govern the dese aan intervie. fv aditon, these factors are also considered > Theformat forthe incrviow: structured vs nstructuned, Ka structuced interview thetype of questions: es Ta aR A aESn | ve > Closed ended questions: Questions that ate used ele angle response sel ts yes. no, ora specific mamber. Example itowmany hours dacs it take for the lal process tobe completed? Open-ended questions: Questions tha aroused to elt dlalngo series of steps ancl earnol be answered in 3 yes oF no fashion bt need explaining, Ese mpl: What does a ela processor do on receipt of «claim for? > Organization ofthe questions: use alagieal order or an order of potty ‘cance, Examples of order would be general quostons to specie questions star to Finish, detail tosusnmary ete The actual organization x hase on faetors sich as theintrviowes level of hnowiedse and the subject ofthe interviw The goal ste follow logial order rather Ihe amp around when asking questions. > Location of participants An interview eat be conducted in-person or via telephone ‘veh conference, er other renate cammuinication methods > Theinterview time and site are convenient to the interviewee > Determine ifs serbe is newded and ifs, inlude that person in the sheduling pe cess Determine ifthe interview needs tobe recorded, so, diacusa the ecordings purpose and usage wit the interview, Contaet Potent Intervewces ‘he interviewer contacts the selected interviewees an expla to them why thelr assistanceis needed. The purposes to explain the objective ofthe interview to the potentialiaterviewes 2 Conduct The interview > Opening the interview. Theinterviewer states the purpose ofthe ftsrvlew, a dresses ny initiol concerns rascal by the interviewee, aril explains that notes wil betakon and shared withthe inerviewes after the ltervies. > During the interview 2 The interviewer malntains fcus onthe established goals and pre-defined ques = Alleonoeens raised hy the interviowne are addressed during the interviow oF documented for follow-up alter ths lterview ova subseque > Theloterviower practies aetve lstenlng to confi what has been understood from the information ofered a varings times duringthe interview > Closing the interview, Ihe interviewer asks the interviewoe for areas thal may Ihave been nvetoukel inthe selon Lost. the interviewer summarize se son, reminds the nterviewev of te upcoming review processand thanks the Anerviewee forthe time, 3 Pest Interview Follow-Up And Confirmation After the interview is complete, the interviewer organizes the informatkon and sends a aD Esverte eg he ust n the Interviewee for review. Documenting the dlscussin fr review alls theinteriewecto se all ofthe sfcemation n context, Thi vie may point ot tems that are Incorrect or mislng because the interviowes (r sere} missed deunienta thom, of hecasse the interviewer for srib) dacumented them sncorretly or Beeatise theinterviewoe missed discussing them. This eview i not intendod to address whet srornol the requirements arevalid nor chether they will ultimatsy he approved for Inclusion int the deliverables ut solely to deter the interview has Deen ad quately documented 914.4 Usage Considerations 1 Advantages » Encourayes participation and establishes rapport with the stakeholder > Simple dire technique thar can be used in varying skuations > Allowsthe interviewer and parteipit to have full dixcusslons and explanations of ‘hequestions and answers. Enables chsermtions of nom verbal behave > Theiterviewer can ask falowap and probing questionste confiem their own understanding > Maintains fous through the wse of lear chjetives for th interview that ste agyeed upon by all participants and car bemet i Le ime alloted > Allowsintervieweesto express opinionsin private that they may be reluctant to express in pe Disadvantages Interviews acest an ideal means of zeaching consensus across a group ofstako Tokers. > Hoguieesconsiderable commitment and involvement ofthe participants > Tesiningisroquired to conduct elective intersicws, In partiolag anstructared Antorviews require spoeial kis neludingfallitation/ virtual facilitation and ac livelisening Depth offolaw-on questions may be dependent an thetntersiower’s knowledge of the business domain Transcription and analysis of interview data canbe comples snd expensive 1» Bawod on the level of clarity provided during the interview, the resulting documen: tation may be subject to interviewer's interpretation » Thetwis ask of unintentionally leading thofatervewee. es Ta aR A aESn | aaa 915 9454 915.2 9.15.3 915.4 BinOrGade Neier 29 Lessons Learned Process Purpose ‘The purpose ofthe lessons leared process to cumple and document successes. 0p- portunities for improvement flutes, and recomemendations for improving the perfa ‘manee of future projets or project pases Description Lessons learsed sessions ean Include any format or vee that works forthe key stake= Ilders dentin) as parteipant n these sessons Elements Sessious cum include review of > fastnessanatjss activities > Husiness analysis deliverables > thefinal product > Thebusiness analysts process > Automation snd technology used or mot used Managerial concer or eaves Mow organizational provess assets help or hindered the business analysts and requltement processes > Peri nce against plan © Myot eames forthe variances > Whether the varianees were rine rsgnifcant anomalies > Cortootive and/or proventiso aetionroeommendad approved or tuoi and taken “Lessons learned sessions may take place Informal, faeltated meetings with set agen das and mecting roles fora informal working sessions or informal xet-toethers, any of whieh may or may not includes edebration. Usage Considerations 1 Revantages Use or identifying opportunities fe peovess improvement » Can helpbuild team morale aftr dificult perio.Ta eg 2 Dhadvantages » Allpartclpants must be prepared o void any urge to assign blame during these session of hones! diseusson may not occu May ik becoming a “grips” session and improvemes lected ‘opportunities may bene 9.16 Metrics and Key Performance Indicators 9161 Purpose The purpose ofmetrics and key perlormace indicators ae to measure the perfor mance nfsolutions solution components, and other matters of interest stakebolders 916.2 Description Alri ls a quantifiable level ofan indicator that an organization uses to meusure progress, An indicator Wentifies a specific mimerical measurement that represents the Aegre of progress toward achieving » aval, objective, outpa,setsty or further pal A Key Performance indicator tone that measures progress owieds 4 statceie goal ot objective. Reporting isthe process ofinforming stakeholders of metrics ofiadicatorsin speciied formats at speetied intervals Metrics and reporting are key components of monitoring and evaluation, Monitoring ‘sacontinuons proces fellecting data tn determine haw wella solution hasheen implemented compared to expected resis Evaluation i the systematic and objective fssessmont ofa soliton to determine is stats and sficacy in meeting objectives over time, aa to dently ways to improve the solution tobeiter mect objectives The top Priorities ofe monitoring and evaluation system are the Intended goalsand efoct of Solution, a wellsinpty actives and cepts 916.3 Elements A Inleators Anindicatoridentifies«speeltie numerical measurement fora goal. impaet, output. ac tivity or np. Fach factor of interest has atleast one indicator to measureit pranerhs but some may require several good indicator has fv charaeterstles > Clear: prctse and unambiguous > Relevant: appropriate to thefactor cals avallble a easonable cost > Adoas st: provides asuiient bass to asses performance > quantifiable: can he independently validated Inaudition to these characterises, stakeholder interests are ako important. Certain {ndicarorsmay help stlcholders perform or mpnows more than others, Over ti, es Ta aR A aESn | aaa [Notall factors ean be measured directly. Proxies can he used when data for dioct in Aicators ae not aailable or feasible to elect af regular intervals or example i the bsenes ofa survey of lca! satislacton, ap organization might use the proportion of fllconitacts seeved san indicator ‘When estabishingan indicator its source method of clletion, collector, andthe cost frequency and difficulty ofeollection nee tbe considered Secondary sonnees flat nay he the mont economical but to meet the obher characteristics fa guod indicator primary research such aa surveys ier views of direct cbservations may be ecessy. The miethod of data collection isthe hey driver of a monitoring, evaluation and report 2 Metis Motries are quantifiable lvelsofindieators that are measured ata spoefed pint in (ine A target molscisthe objective ta be reached within a speciied period. In ntti ‘mtr ostlly one) fran indionor ts important to hava clear sndoestan din ‘lth baseline starting point resources thal enn be devoled to imprcving the factors fewer bythe indicator an politcal eonccens. Ametriceanbe a specific point, threshold or range A range ean he usc f the nd ‘ator Ise, The scope of tne to reach the target metric ean be ault-yearto annual ce quarters. even more frequent, éependingon the need 3 Staacture {ateblshing a monitoring und cyaluaion system requireaa dats colletion procedare date analysis procedure 2 reporting procedure. and collection of busine data. The data callction procedure coversunitsot analyse sampling procedures, data cllee ion instruments to use collection frequency, and responsibility foreollection, the snalyais method specifies the procedures for conducting the analysis and the data feonsumer, who may have strong interestsin how the analysis is conducted. Reporting procedure covers the report template, eeplent,frequency-and means of commu tation, Baseline information i that data provided iamediatey before ot at the bea ingot pero to measure. Baseline dat lensed a leurn about recent performance tnd to measure progress from that point forwaed. It needs tobe cllected foreach Indicator. analyted and reported There are Une key Ectors in assessing the quality of nicatoes a thie metres reliability validity and timligess,Rolability isthe exten to whic the dats election proach is stable and consistent acroys time and space Vali ithe extent Lo whieh data clearly end diroctiy measure the performance the organization intends to mes: site Timeliness the it ofthe Fequency an latency of data bo management’ need fo 4 Reporting Typically reports compared rent rntric and target metrics to cach oth «ef with calenlatons othe diferences presented in both absolute and relative toms. In nost Htuations, trends aremoreeredible and important than absolute metres. Visual presentations tend to he mote effective than tables, particularly when using qualitative text to explain the data e baseline, a aD PiaT eg 916.4 Usage Considerations 1 Advantages Establishing a mouitoring and evaluation system allows stakeholders to understand, theextentto which a solution meetsan objective. and how effective the Inputsand sctiviisof developing the solution (output were Indicators, metrics and roporting als fclitate organizational alignment inking paleo objectives, supporting solutions uaderying asks, and resources. 2 Disadvantages Gatheringexcessive amounts of data beyond what is needed will result unnecessary ‘expense in vollecting, analyzing and reporting (wil also distraet project members {rom other eesponsibilites, On agile projects, this willbe particularly relevant Aburcaucraic metsios program falls from collecting too much data and not generating Useful reports that will allow timely responsive nection. Those charged with collecting ‘metric data must be given feedback to understand how thle actions areafectig the ‘quality ofthe project rests ‘When metrics are used to asses perormance the individuals being measured are Iiklyto act to ineteaso thei performance on those metres even this causes sabopt ‘ml performance om other activities, 9.17 Non-functional Requirements Analysis 974 Purpose “The purpose of wo functional requirements st describe the required qualites ofa sjstem, sch as its usability and performance characteristics These supplement the documentation of functional requirements, which describe the behav of the systom, 917.2 Description Nonunetional requirements document the qualities of system that are important ta > theuser community, suet as usability, arnablli,relibilty et > thedesrlopment communis suchas slabs. malmtainabiliy reusablty. ote Siictly speaking, the term “non-functional rgoltements only applies when describing ‘esoltvare application, However, the vars eategores of non furetionsl reyuleements ‘may heapplicable lo ther solution components for which requirements can be devel ‘oped. For exemple, lily geutements fran organtzetional unit might elude speciiedlours of serves, and performance elliency requirements [0 business process might include cycle timo deal with customer request and may be captured Ina service level ageecment (SLA In these cases, a allernative tem ke “quality of service” requirements may bo prefaced 9473 Elements ‘he following elements are usually nluded in the description of non-funetios auirements, Ts Ta aR A aESn | a A Category Non-unetional requlzoments ae usualy organized into categories. Categortstion sipports the discovery of nonfunctional requirements pov iding& mental iccklist of characteristics to consider when performing requiremeals eitation. ‘the sebeme sted here isbased on TS0-9125, bu other eategortaanions taich as (URPS may also be used Roliability Is the software upplication available when needed? Rellablity equine men inchude the hilt af Ube application la recover fom eres pie cr falbarenin thetaterfaces, Performance EMcieney: Docs he software application deliver acceptable perfor mance levels given the resources available? Performance ifciones requiem Ince the tine talento perform activities and the resource utlinaton level Operability: sth software spplicaion understandable to use? Operability requite- ‘moni inelid the extent 1 whieh users ean reengnive whether un applieaion veil sctuall fulfil their nee the ease of Iazaingthe application snd the usability ofthe "pplication Security: Dies the apriication prevent intentional misuse? Soeuity requirements Include the abilty to ensure appropriate confidentially otnformatdon, the Integrity of information stored inthe appliceton, the ability to verify whether aetions were taken and by whom, andthe ablliy to authenticate uses. Compatibility: Can the application operate effectively with other applications inthe sine environment? Compaiblty requirements inchde requirements or property replacing another application the ablltyto o-extst wth other applications, and the ability to interact with other applications Maintainabiity: Can th eet cha pplication be effectively moe after implementation to ng nee? Maintainaility requirements include the silty to change one {component without allecting others, the ability to re-se components, whether Application canbe effectively texed und problensean be propery diagnosed, the ease of making changes, and the abilitytoimplerent changes without causing unexpected faites ‘Transferability: Can the application be installed and in another environment? Trans: ferabiity requirements inch the ease of nstallingand uninstalling the aplication, the kinds of diferent environments t can fun ln andthe ease of migeatlngll toa nes? 2 Measurement The definition ofa non Functional requirement should iacade an appropriate measure of success foreach one a0 that can be adequately tested Somenon-functionalre= ‘quirements may seom very subjective eg" Intute interface" hut caetalthowgh can usually provide an appropriate success measurement 2 Documentation Non-functomal equacments ate ypically documented in text using sdecssative sate=| a aD Psments such ass > Ninety percent of operators shall Be able to ux allthe functionality af the aystem after no mire than six hourso trang, > Thesystom shall provide 99% of responsesin no morethan 2 seconds, This documentation is presented as. pat ofthe total st of requirements documenta svoltenina section, oraseparate document, 917.4 Usage Considerations 1 Advantages Success in meeting non-functional requirements willhavea strong nflueace om ‘whether or mals aster ie ceepled by ils wer 2 Disadvantages [Non-funetional requirements ate otten more dificult define than functiunal requive ‘mens Expectations regarding quality airbus maynot be described and verso a pplication nay find them dificult toueticulate (Overly stringent non-funetional eulrements may sift epact the cost of developing a sftenreapplicntion, 9.18 Observation 9184 Purpose ‘Observations « means of eliciting requirements by conducting an assessment ofthe sake helder’s work environment This teniguo is appropriate when dacumenting Metals ubout eurrent processes or ithe projects intunded to enhance or change a cur rent process 918.2 Description ‘lyservation relies on studying people peforng tek jos, and ts somtimes called inh shadowsing" or Tollewing people around or instance, some penpe have theft ‘work outine down to such a habit that they have difficulty explaining what they Jo or ‘wy. The observer may need ta watch them pecform their work im oeder tounderstand the low of work, In gertain projects its imporiaut to understand the curtent p2oeess estobeter assess the process madifiations that may henecded, There are two basic approaches forthe observation Leche: Passive /luvisble: inthis approach, the abserver observes the user worl Ahcough the business rouine but sloexot ask questions. He byervereecords what fs observed, but otlterwise stays out ofthe way, The observer walts until the entice pracess has been completed efove asking any questions "the chserver should ‘obser the business proedss multiple tins ensure they understand how the process works todayand why works the way Ht does Ss Ta aR A aESn | aera Active / visible: i thls appa, while the obsceyer observes the eureent process land takes notes they may dialog with the sor When the observer hus questions ‘sto why something is beng done I, they ask questions right away. even fit brcaks the mutine ofthe nse, Variations ofthe observation technique: Insome eases, the observer might participate in th actual work to get hands on feel fae how the business process works tvay- Of necessity this woul be ited 1 activity that isappropriate fora non-expect to perfurm and whose results would rot negate impaet the business "The observer becomes temporary apprentes Te cnsevee watches a demonstration ofhow a specie process andr task is periormed 918.3 Elements Prepare For Observation > Determine what sampling of users (eg. experts and novices jst experts) to ab scree and which activities > Prepare questions to ask ducing or after the shadowing 2 Observe © Observer inleauces him or herself the person being observe a: > Reassuresthe user that their work isnot being questioned. Rather, the obserea tom ofthe work nd eesulting documentation willserve es input to requive= ments analysis © Informsthe user thatthe shserveeipresent only to stacy thelr processes and willzffal fom dlseussng future solutions to ay problens. > Explainstothouser har they maystop the abservation process at anytime if they below tha is interfering with her work © Suggests tothe user that they may"think aloud” while they are working asa ‘way 1 share thelr intentions, challenges, and concerns > Conduct observation > Takedetailed nots. > Ifusing theactive observation appratch, ask pring questions about why ot tain processes and tasks ae being performed a hey are, 3 Post Observation Wrap-Up - Documentation And Confirmation > Obtain answers to orginal questions or mew guetions that surfaced daria the shsereations BinOrGade Neier 29Sn eg > Providea summary of antes tothe users soan as possible for review and any > When observing muny users, compile acts at regular intervals to defy com monakics and differences among users. Review findings with the entre group to ‘ensure thatthe fin details represent the entire wroup, nat selected individuals 918.4 Usage Considerations 1 Advantages Provides realistic and practical insight into the husinessby getting a hands-on fel {or how the business process works today > blicitsderais offaformal communication and ways people setually work around thesystem that may not be documented anywhere. Disscvantages > Only pnssibi fr existing processes > Could be time-consuming, > May be disruptive to the person being shadowed > Unasat exceptions nd cet! stustionsthar happen infrequently may not cent at wall workifthe current procass involves a high Feel ‘or other work that isnot easily observable ellevtual activity 919 Organization Modeling 9194 Purpose Organization Modeling is used to describe the roles, responsibilities nd reporting structures that exist within an organization and to align chose structures withthe organization’ yous, 919.2 Description An organizational model defines how an organization or arganizational unit itt tured: Organizational unit bring tgether a group of pooplote fall commen [trpose or goals purpose maybe functional, eaning thatthe people in question Share a common set of sills and Lnowlidge or 1 seve a pastleular masket. An orga Zathonal model will define the scope af the organizational nit Hie formal cationsips between the people who are members of that uni, the roles those people il, and the Interfaces between thal nit and other unity or takeholrs 919.3 Elements 1 Organizational Purpose and Structure Funetlons:Funetionall-orented organizations coup together statfbesed on shated slillsorateas of expettise. They are generally adopted in order fo encourage star ddacization of work or processes within the organization. Funetional organizations es Ta aR A aESn | ni facilitate cost management aud reduce duplication of work but are pronoto develop communication snd cross fictional co-ordination probleme Saonen informally silos [Markets The term ‘market orkented” covers number of dffercnt posable ways of ‘organizing a enterprise al of which are based on serving a partitlar customer sey- ‘ment rather than on the common sas or expertise oF the emipleyeo. Market-otented structures enable the organization tu be helteroriented with the needs ois custo fr but are prone ta devtlop incomslstencles tn have work ts perforened and to duplicate ‘work in altipe divisions “market-erinted” organiration may be organived around festomer groups, geographleal areas poets, or processes. Matrix: this model, theve ste separate managers for each functional aves and for cic product, servie, or eustomer group Stal report into line manage, who ts tespansble forthe performance of typeaf work and for dentiying opportunities for cifcioney in the work, and toa market (product/service/projetote) manager. who {esponsibl for ersagiog the peduct, service, fc scree mulliphe functional ares 2 Roles An organirational nit will nce numberof defined roles, Fach roe will require specie set of skills and Lnow ledge wil have eetaln responsible, wil perf tein kindsof work, and wll have defined relainnshins with athe rales inthe organi 2 Interfaces ac organizational uo wil have interfaces with ther organizational units, Interfue ceemaybe inthe form of work packages thatthe organiratanal unit reccves or delivers toother ust, communieation with people in other roles and so forth, Work packages shoul have defined roquitements and quality standards that are ogreed to Bystake bokders affected by those packages, These requirements, standards, and expectations say be formally ot informally defined, and may be negotiated on a case-by-case base ‘callow for exbilly in he they are me 4 Orgchats he fondammental diagram used in organization modeling the org (organiation) chart, There no formal standard st for defining org chart, although tere are cor {ain slandard conventions that eos ory ears follow. The ong chart sve > Orguntzational Unit, which may represent peuple. teams departments div sions based om the level of abstraction of tho org chart. Frequent han ong char will ‘nix organieational wats shoving mix of people teams, and higher-level dik > Lines of Reporting, which trace accountabiity and control between organization alunits. solid Hine tyiealy denotes direct nithorty while a dated ine ndeates Information transfer o situational authority Lines of reporting visually dept the spam of control ofa particular manager or organinational unit Uh i the number ‘ot peoplethal a manager is responsible for directing) a aD PiTT eg > Roles and People, Aa orgchart should show thoes that exst within an organ ‘ation and the people signed to each of those roles. gure9-7:0r Chart Executive Function Incumbent Name ‘Management Function MansgerentFuncion| incumbent nae ncumbert Hae “Management Function 919.4 Usage Considerations A Advantages Organizational modelsare one ofthe Few types of medels any organization is almost cecttain 1 have defined. Even thesimpiestotganizaton hes to define the teporting strctores among team miemhersin onder to co-ordinate work tween ts peopl, 2 Disadvantages The primary limitation of Organization Madelingis not the techniqueitself but rather {heimplieatlons of including organizational redesign Inthe scope of «projet, Organ ‘athnal edesigns are likely tobe highly contentions an requite significant exccat ive support inorder 1 be suceessfu Asecondary problems that informal ines nf authority and communication that are tt cfleted in the og chart ae almost cesta bo exist within the organization, 9.20 Problem Tracking 9.204 Purpose Problem tracking provides an organtzed approach to tacking, management, and eso Iution of defects ste preblems, and eisks throughout business analis civics ‘Management of sus is importa yesusulved ina Umely manner to 9.20.2 Description Pralblems my Include issues questions. risks, dofets, conics ur other uncer that ‘need to he tracked to resoltion_ problem tracking system ensures that sstes ae not simply nogletod or lest. For cach problem, the tacking tool may include an identifica ofthe problem, status updates assigning of elated actions that ate requived to team membecs and tracking expected resolution dats, resolution results, ations and | Ta aR A aESn | ra decisions taken, pet and impacts. The ear reat status of prblems should be com tmanicated toa velevant staksholders Ensure problem fncking ends ts Resolution of problomsina timely manner that clininate or miniaze negative Impacts Allocation of resources to texas problems > entiation of oot causes of problems. 9.20.3 Elements 1 Problem Record A problem record may contain some oral fhe following information: > Descripti Alor nd concise desertion of the problem identified Raised By: The person who Mente the problem > Date ldentified Impact: the possible consequences if the problem i not resolved bythe Need by Date. Impact may be assessed based on sliedule, east or seupe, as examples. > Priority: Determine the pronty athe problem based on assesament by stakchol Am exanple of prieity sales: Critial, igh, Medium, aad Low. > Neod by Date: When the problem must be resolved by to avald the consequences, > Owner: One roam member who Is assigned ro manage the problem to elosure, This ‘may not be the same person who identified the problem or the sare person(s) who fre asngned actionatoreulve the problem, Statins Thecursent sala ofthe problem. Examples of atuses tht cae used Inchade Open, Assigned, Resolved, Cancelled > Action Needed to Resolve: Details of what action noes to he taken toresove the publem. May be more than one, > Responsible for Action: Person assign o take the spesifie action > Com Date of Action Can be anestinted fare date ot am actual past dato ifthe problem is eomplete > Outcome: The results ofthe resohition. 2 Problem Management The problem must be racked and managed until the problem is fixed ort is deter ‘mined that no action willbe Laken regularly scheduled review of the problem zeport by al elevant portics ensures visibility and facuson the problems if pablemseannat bbe resolved in areasonableperio of inte it may be necessary to escalate the matter. a aD PyaR eg 3 Mees An addtional clement that ean be useful to gauge How the project is doing regarding prablem resolnton is to decide ona se of metres and key performance indicators (16) ‘nd then measure and report on thot. Examples of possible KP are Number of problems by status and prot. cyclo ste for each problem (number af ays took from Dare Identified to Reso tion Dated 9.204 Usage Considerations 1 Advantages Problem tracking provides an organized method for trucking and rsolving risks ssuos ani delects. Il ovis mechanism to corsmmunicate probes across the eam aud hhlps to maintaia fucus on open prablems unt they are resolved. The roger teviee ol the problems together with the team aso helps to maintain ocus al ensure resus 2 Disadvantages Inthe following situations it maybe challenging tu use th echique sr priontiation and management of problems isnot done, the ist becomes ‘outdated and ireevant, > Ifkey am members are nor vallable on aregularhasisto discuss the lists of problems and Wo determine actions to be taken, then progress to resolve them may Dene very low ta nin-existon fb Afthete ina anit deadlineto deliver the sation, Une prblern management become a lower priority, Olen, root eause analysis ofthe problets cat take mio tiene and resources than ae aallale 921 Process Modeling 92a Purpose To understand tow work tht involves multiple roles and departments performed within an organization 9.212 Description A process deseres how multiple people o aroupseoaborate vera period of time to perform work Processes involve a numberof activities that ae inked hy sequence Mow. A process is repeatable and may have multiple patho completion ‘A process nitated by an event in the business domatn sich as asale of product 10 ‘customer, «request for nfurmation by wsenior exeeutive ora faire to compete a transaction. Fronts mayo actions raken by person, rales which eause actin toe taken, or simply the passage of period of time The process model mas involve manual setsiies. be completely automate. or & eambinationtheroo. The proces is complete ‘when the objector the goal of the process completed Sn Ta aR A aEProcess Modeling A process model sa visual representation of the sequential Naw and control og ofa set of elated activities or actions, Process modeling is used to obtain a graphics oP ‘escutation of eurcent oe future process within a czganlzatin. A mide may be used is ight level to abtain a general understanding ofa processor ata lower level as basis or simulation so that the prociss cua be made as eiciat as posible Figure9-8: Flowchart Swimlane for Role 1 ask ¥ + Ee) Ey ‘Swimlane for Role 2 The flow of work spits Tasks are xecited in parallel, Input! output [incr | * Decision pe Tasks Asubsprocess fembeds another process model. ‘Swimlanes are an unatfca, but common, extension to the flowchartng standard. BinOrGade Neier 29aR eg Figure 9-8:Actviy Diagram ‘Swimlane for Role t ‘Swimlane for Role 2 ? Task 1 The ow of work splits. Tasks are executed in paral ---{Flowmeses. | A sub-rocess embeds another process made! | Ta aR A aESn | ae 9.213 Elements there are many diferent notations in use to deplet process models. the most common Ay used areflowcharis and UMIL activity diagrams although BPMX has seen increasing fudoption in recent years. Process modesypealy eal som all ofthe flossing Joy lements 1 Notation Elements Activtion The individual seps or pieces of work that must be completed in order to fexveute the business process. An activity may be a ingle ack or maybe further decom posed into a sulprocess ith teow activity, Mn, ad other process clemeats Decistons: Forks where the aw of work proceedsin two ur more flaw sand, option ally whore separate flows merge together decision may create mutually exchsive oF paralll tows. vents: Events occur atte thescope ofa pracessandl may he the rest of actions {akea, messages eovelved, or the passage of lca, Evens may create, alercupt, of oe sminate processes, tose Indicate the itcction af the step-bystep sequence ofthe workilowe In generat Alagramsare awe from top to bottom ora the drcetion af reading to show the pas sage of ime The proces flow may split allow fr etnies to eur simultaneous ‘nd later merge olos Roles represent atype of peeson or group. Hale definitions typtealy match those the oganzation model (219) Swimlanes and Pools: Svimlanss are horizontal or vertical sections of process del that show which activities ace performed bya particular roke When the flow af work erossestheboundary of swimlane esponsiilty fr that work then pass to aather person o group within the organizaic A poo! represents an organizational bounds 1 may tacludes nunher of swlaanes (Common. processyFllinelude one poo far the customer and a second poo for the ‘ovganlzation, although its possible or «process to include aay eumber of pools Terminal Points: Terminal pototsreprosent the beginning or end of process oF pro 2s low. teeminal point generally represents seine kind oven! thats wisible to the ‘organiration or outside of 2 Processtmprovement ‘There area numberof farmeworks and methodologies that focus on process improve nent meth, such ax Sin Sigma, Lean, and. lye numberof proprietary BPM ap proaches Methods for procossimprovorment include value streum mapping, statistical alysis and control process sislalion benchmacking, process frameworks ava others, Common changes > processsin order to impeove thom inlude: Analysis ofa process to identity and remove: sakeholer where posible, ivities that do notadd value tow a aD Psren eg > Reduetion ofthe time required to complete a prncess (by reducing the ds ta pee > linproving interfaces or handoffs between roles and organizational units to remove Reduction a elimination of botte necks an backlogs. 9.214 Usage Considerations 1 vantages > Most stakeholders are comfortable itt te basic elements of and concepts behind process model > Proceas models areellectiveat sowing how ty lane a lege number oFacenssion and parallel branches, Process models arc likey to have value in thei ven sight, as they wil he used by busines stakeholders for training and ea-ordinalon of activites 2 Disadvantages Process models ean become extremely comple and unvvielly Iino structased cearellly. Complex proceasea raty involve cough activities and toa to make heen lost impossible for asingle individual to understand, » Problems ina procsss cannot slays heen hy looking atthe mod. Tt is allynecessry loenge stakeholders diet tof problems they have encoun tered while working with « press. 9.22 Prototyping 9221 Purpose Prototyping detile ser intriace requirements and integrates thom with other ‘qurements such as use casea scenarios, data und business rules Stakeholders often find prototypingtabe concrete means of identifying describing and validating their nterfuce needs 9.22.2 Description Prototyping can be categorized in two ways: Functional Scope, A horizontal prototype models. ashallow. and possibly wide vow of thesjstem's lnetionally. typically does not have any business lie cunning behind the vbualization. vertical prototype models «deep and usually narrow slew ofthe cnt syatens acti Usage Throughout System Development Lifecycle. A“Ihtow-swin" protatype secks to quickly uncover and canfy interface requirements using simple tools, sometines inst paper and poneilAy the mame suggests sucl a prototype is usally diseased ‘when tho final atom has been developed. The focus son functionality tha Ismet eas ity listed by other techniques, has confiting viewpoints, os dificult to understa ‘An “Evolutionary or Functional” prototype extends the inal incre requirements a Ta aR A aEi eet {nto afullyfanetoning system and requires «specialized prototyping Thi prototype prodscesa working safteare application, coo langue 9.22.3 Elements 1 Prepare For Prototyping Determine the prototyping approach: hrow-sway vera evlutlonsry /functlonl: vestical versishorizontal enti the functionality to be modeled 2 Prototype ailing the prototype isan terative process The initial elfors outline the highevel ws. Subsequent iterations add deta depending on the functional seope(hortzontal vers vericlh, ‘When prototyping report, Ue Hest teration may prnduce a lst ofxeponreguiremes sichas dats attribates selcetionerteria and derivation rules for total, Further analy ‘ismay deal a detailed layout athe port, ‘Wen prototypingn interface that appears ona sreen (whether on a computersereen ‘oF adevice such as cel phone, ora copy machine, numberof erations may be wse- (u1 The initial focus am end-to-end understanding ofthe interface low. Add details 5 appropriate tothe work > AStryboard (aso known asa Dialog Map, Dialag Whrarcy of Navigation Flow) portrays the navigation paths across the intrlace components this visual inlidee abscraction of cach sercea along with directional arrows thatindicatetheallow- ble navigation fos Screen protelypes provide data alteibues, selection eiterin an supporting bus rosso screen layout or mockup provides a graphical representation ofthe elements. Xt ‘this detailed evel, one would apply aay organizational sandatdsor style guides 3 Evaluate The Procorype For detailed prototypes, vey thatthe logleal interface clements trace ty usec raul smnts sch ss processes dit ar buses res. Validate thatthe prototype represents the users needs, Scenarios are use "tet the nteriaes, 9.224 Usage Considerations 1 Advantages > Supports users who ac fortable wl efiectve a articulating their seeds by using pltures as prototyping lets thera "sce” the future yates interface > Apprototypeallows fr early usorinternetion and feodhack a aD PySE eg Arrow away prototype ean be an inexpensive moanstoqulckly uncoser and con tiem variety frequirements that gobbeyond ast the interface suchas processen, data, business rule, > Avertical prototype can demonstrate whats fesstle with exlsting technology. and ‘where there maybe technology aps > Ancvoluonary / functional prototype provides a veel for designersand devel ‘oper toleara about the user interface needs and to evolve system reshiements, 2 Disadvantages Dependingen the complexity ofthe target system, using prototyping eect requltements can take considerable tie Ifthe pracess gets bogged dawn bythe how's rather than "what Assumptions about the underlying technology may need to bemade i order to ‘mitateprototy in. > Appolatypemay lad users develop untealistic expectations rexsrling the Aelivarod system's performance, completion date. reliability and usability char acteristics. This is because a elaborated detailed protlypecat look lot ikea fartional system, > Users:may focus onthe design specifications ofthe slution rather than the require ‘ments any solution must addeess. this can in ura consteain the solution de sign. Devclopers may belive that they us provide auser interface that precisely -maiches the prciatype, even superior techclogy and interface approaches exis 9.23 Requirements Workshops 9.231 Purpose requirements wokahop ia stature way to eapturergsiraments A workshop thotargr tom Vielhrun workshops are considered one af the most effective ways to deliver high qual fay requirements quickly. they ean promote trust, mutual understanding, and stg, comimunieations among the projet stakeholders and project team and produce deliv rable that structure and guide tutute analysis. 9.23.2 Description A roquierents workshop i highly productive focused event attended by eareflly sloeted key sakcholders and subject matter exports for a shor, intansive period typ tally one ora ew days The workshop is failiatea bya toa mombec oF Heals by an experienced, neutral facilitator. A scribe (also known asa recone documents the requirements elicited as swellas any otstanding issues. A usiness analyst may be the Falta or thescebe in these workshos Insitations here the business analyst sa subject matter expert on the topie, they may serve asa workshop participant, However, this must beappreached | Ta aR A aESn | a ‘with cautton, ast ean confuse othees aso the ole oF business analyst. addition, there mayhesuspicion that the business analyst who i also participant may wns bias the requirements documentation towardakis or her ow vewpolats and pelt: Avworkshop may be used to generate eas for new features or prohicts to reach fensonauson &toplo o review requirements. Other outcomes are ften dated requirements eared in models 9.233 Elements 1 Prepare forthe Requirements Workshop > Clarify the taksholders needs and the purpose ofthe workshop, > entity erteal stakeholierswho should participate inthe workshop. »Detine the workshops ageads Determine what means willbe used to document the output ofthe workshop. > Seheidulethe sessions > Arrange roor logisliee and eyipent nclading seating, Mipchatts, peojsctory, Sena materints in advance ta prepare the attendees and increase productivity at thomeeting > Conduct pre-workshop interviews with altendees These arenot fl requirements Jnterviews, Instead, they focus on ensuring thatthe purpose of the requirements ‘workshop Istundersood sind aligned with the nes ofeach acne, and to ensire ‘hat any preparation needed for th sexs by thal attendev is understood, > Determine the umber of stakehollers who should participate in the workshop, 2 Conduct the Requirements Workshop > Bei, analyze and document coquirements, > Obtain consensis on conficting views, > Maintain focus ty frequent validating the session's activities with the workshops sated abjetives. the festa has the responsibility to: Establish »profissional and objective fone forthe meeting Introduce the goals. end agenda for the mosting > Enforee disipline strnctureardl around eles re the mecting, > Manage the mocting and Koop the team om tack, BinOrGade Neier 29Aequirements Worshops 923.4 Facilitate process for deesion making and bulld consensus, but avoid patilpat ingin the content ofthe discussion Ensure tht stakholders participate an have theirinput head Askthe ight questions, This inchides analyzing the information Beng provide ‘and flloring up with problag questions necesary. “The senibe roles to documeat the regulzements in the formal determined prior to the workshop and keep treck of eng items orisses that are ferred during the seston sel 3 Post Requirements Workshop Wrap-Up Follow up on any open aetion tems that were recorded at the workshop. Complete the dacumestation and distribute Itto the workshop attendecs and the Usage Considerations Advantages A requirements workshop can bea canst lilt detaled equlzomonts ina rola tively short period of time. A requirements workshop provides a means fur stakehoklers to collaborate, make Risk-Aversion. A riskaverse person or organization will sek to reduee sks pa ticulaey negative risks and prefers to approach as ce Yo vertantyas posable. A reduction in potential benefits in ceturn fora moce certain vuteon ssceoptable radeat, Neutrality. neuteal approcch to risk means tha the probable bensis gained {rom the sk response must equal or outweigh the oats in order to justify action, > Risk-Seeking. A risk-secking person or organization wil he willing to acosp selatvely high lsksin order to maxlenlze the poeatlal bene lsk-seckers may sscopt low chances of sicces if the henefits of suecews ae higher. An individual or organization may exhibit diferent tsk olecances at diferent ines. For instance it has heen demonstrated that mest people willaceept greater risks avuidaperceived loss than they will to increase the pay fom a success even when the inaneial outenmes ae ential. The sie and potential fmpaet ofthe risk 39 a8 alec the isk tolerance 2 Assessment Assessment involves determining the probability that the isk will ccur and the [ur fit does occur Each ofthese facorsis assessed on a common sale (High, Me Agen and Low autmber for 1-5, nd fet) Thi cnables analyst foes on the ‘most important risks. 3 Response Response strategos dotcemine how tho organization will deal with arisk For negative ‘sks strategies Include: > Acceptance. No llort to deal with the isk s made, The organiaaion accepts the possibility thatthe isk wil accu a aD asEER eg > Transfer The esponsibility for dating with the isk and the possble effects of the risk are moved owe toa thied party Avoidance, Ihe orgunization takes measures to ensure that the risk annetoce » dtigation. The organization sakes stops to reduce the probability ofthe isk oe curing or the posable negative emaequences the rik acentring. For poiive risks acceptanco tals a viable strategy Other strateglesinlade > Share, Work with a thied party to increase the peobaiy the postive outcome will ‘occur and agree to share in thebenfits » Enhance. The organization takss steps to Increase probability af the risk occurring andthe potentialbensfitithe rik oveuts > Exploit the organization works to eayare thal the gvent does oxcus 9.244 Usage Considerations 1 Advantages Riskanalyais enables an organtzation to prepare for the likelihood that at least some things wlll goa planned, 2 Disadvantages The numberof posible tsks to most initiatves can easily hecome unmanageably lng ‘Hemay only be possible to manage a subset of potential sks Asrisks ate inherently uncertain. it may prove ificul to usefully estimate the impact ofthe ish, 9.25 Root Cause Analysis 9.251 Purpose The purpose of oot cause analysis is to determine the underlying soutes of problem. 9.25.2 Description Root euise anlyss isa structured examination ofthe wspocts of situation to esta: Is the root causes and resting effets ofthe problem. erie clement ort ea s6| analysis sto ensure thatthe current business thinking and processes are challenged. ‘That do they still make sense oF provide good hustness vac i ight of eurzont real tics? 9.25.3 Elements Theo commonly ayed ro cause analysis metus include the Fishbone Dingeem and theFive Whyse 1 The Fehbone Diagram Afishbone diagru (als known asm fsilvn or cause-and-effect diggtamn) fs wed twikdentifyand organize the posable causes of «problem. This tool helpstofocusion a Ta aR A aESn | Ge Figure 9-10: Fishbone Diagram Geese tego? ¥ \ Gage? Giese thecause of the problem vers the solution and organizes ins for farther analysis. “The dlagrum serves as a map depicting possible cause-and-ofeet relationships, Step to develop a eause-and-etcct diagram inched > Capture theissue or problem under discussion ina bus a the top of the diagram, > Draw ane irom the box across the paper of whiteboard (forming the spin ofthe Fishbone) > raw diagonal nes from the spine to represent categores of potential causes of the problem. The categories may inchde people, proces, tools and policies. > Draw smaller tines to represent desper cases Brainstorm exteyoris and potential causes ofthe problem and capture then us Aheapprepriatecalemney Analyze the cess, Remember that the group has identified only potential causes ‘ofthe prcblem. Further analysts isnceded to validate tho etal ease, dealy with dats rainstorm potential solutfans once the acta enuschas boon dentifed 2 Five Whys ‘The Five Whys isa questiou-asking process to explore the nature and cause of prob Jom, The Five Whys approach repeatedly asks questcns nan attnypt to et tothe root ‘cus of the problem. This sone athe staples failtation tools to use wher problems havea human snteraction component To er thi techaisies, > Write the problem on allipehact of whiteboard ack te ay do you think this problem occurs?” end capture theidea below the prob: > Asks *Why?" agaln and capture that eu below te Hes dea a aD aEContinuo with step $ unt you are convinced the actual root cause has bee cote Take may take more o loss han Sve questions the tochnig salle the ve why because itoften takes thal many to each the rootcause, nok because the question must bashed five times, ‘Use Hive Whys cam be used alone of as part ofthe fshbone diagram lechaique. Once aliens are capruted inthe diageam, use the Five Whys approach to drill doven to the 9.254 Usage Considerations A Advantages Root couse anelvts provides a structirod method token tho rot causes of dom fied problems, this ensuring a complete understanding ofthe prem aide eviews, 2 Dhadvantages oot cause analysis works best when someone whe has formal training or extensive perience facilitatusa team of experts The primary concern revolves around the bility ‘tthe fuciltatr to remain objective, critieal element fo elective root cause analsi 9.26 ‘Scenarios and Use Cases 9.264 Purpose Scenarios and use cases are written todeseribe how an actor interacts with asolation twaceomplsh ane or more a that actors guale oF te respond to anevent 9.26.2 Description ‘While the terms scenario and use caseare often used loosely, a scenario is generally wa Aeestond to describ just one way that an acta ean accomplish s particular goal, ele ‘uve case describes all the possible outcomes ofan attempt to accomplish a partleular foal that the elution wll support Scenarios are wetten asa series ofsteps performed by actors or by thesolation that fenahloan aclae to achleve a goal. use ese deribes several scenarios inthe form af Drimary and alternate lows: The primary or basic flow represents the simplest way to ‘secomplish the goal ofthe waeense. Sprealeireuesstances and exceprions that result ina failre to complete the gosl ofthe use coseare dacuented in alternate floes 9.26.3 Elements ‘Te seenario oF use ease must havea unique name within the project. Tho wse case same should deserie which al or excat el deal with, ed generally chads 4 ‘verb doseribing tho action taken by the actor) anda noun descrbng what sheng dome othe target ofthe action, 2 Retort) An actor isany person, spstem. or event external to the system under desig that iter ‘sets with tht system through use ease Euch actor must be wivenu unique name that feptesents the role they pay i interactions with thesyslem Thix ole does: ees a] Ta aR A aESn | aa sally correspond with jl ile a should never be the anne ofan actual person. particular person may hl the roles of maitple actors ser tse Caution: temporal events rarely modeled us an actor initiating a use ease. The most common useat a temporal ovent asa actors theuse ofa "Time" actor forgo a use ‘ase that must be execsted based onthe calendar date euch asa endo anth or ‘end-oFyear evesnilation ofa system). Some authors recommend against this ise, 3 Preconditions |\ precondition fsany fact that the salton can assum tobe rie when the ase ease bins. This msyinclade Gextual atatements such ax"aser must belgie i ss exe ientaloe" oF the seeessal completion of ator ws eas, 4 Flowof Events Deseribes what the ctor and the system do during the execution a he sexnario or use cise. Most usecase descriptions will further break this down ito a Basic or primary Mow (representing the shortest suceessful path that accomplises the goal of the aeton ‘anda nuinber of aerate lows that shane more complex logic ar error handing ‘drcumstanee tll allows the actor to succesfully achievethe goal ofthe use case ts {ined na alternative Ifthe citcumstance doce not allow the actor to achicws theft soc the ww caso fs consid unsealed ferme. This defined as sroeption 5 PostCondtions Any fact that must be true when the use case complete, The pt conditions smst be iucfor all posible ows through the use ease. The use ease may describe separate posi-conditions that are trac for sucessfuland unsuccessful exections afte use 6 Relationships Relationships bebween actors use eases at eled associations. Assocation do nat fcpresent input, output time or dependency An association line only ndieates tht an actor has acces (ofsome kind) to te functionality represented by the usecase Relationships hetween se casesare knowin as steroetynes There are twa commonly tased sterwotypes: Extond: allows forthe ingertion of additonal behavior Into ase case. The use ease thatiheing extended mist be eompicoly functional mite osen ight, The extending tse ease does not need tobe complete without reference tothe base usecase. An exten Son isiumetionally identical to an alternate ow but iseaphuted ina separate use ense for convenience, Include: allows or the hase use ease to make use of fanetlonabty present i another tus ease, The inchuded usecase does nat need tobe a compete se ease ints own right, iris drsetly triggered by an setor. This rationsp ts mot fen usod when some shared functionality i equiced by several uae cases, a aD as‘Scope Moding Aétort 9.264 9.27 9.274 9.272 he Ge ogra ‘System extends cindex SS ’ Use Case 2 Extension points: CallUse Cases Usage Considerations 1 Advantages {Use cases are good at clarifying seope and providing high-Level understanding of user behavioral goals normal situations alternatives or sxesplion paths through am activity or business process, 2 Disadvantages Business analysis are frequently compte to describe most or all system behavior using tse cases, Hecause many requitements can be captured in the use ease format, there fs Feequenly a temptation 1 use them co capture al requitements, even in tuations ‘where iifculto apply tensor another analysis method might prome mon fee ‘ae cases do not have any featuresta support Integration oF the discovery ofeommon ‘elements, whichis one ofthe reasons they are ususlly writen atthe highest-Level of steaction that sanptopriate, Additional analysis and desgn is asualy requieed alter tse ease ditions complete to identify these cumamon elemeats. Scope Modeling Purpose Scopemodeb arcused to dsuibe the sepe of alr the supe ofa solution Description Scope muelssrve aa has fr defining a dein the see of sines analysis ‘nd project work, Seope models slow the definition of “complete” senpe—that the bowadarics ofthe senpe carson with the natural boundaries of husiness domain There are many diferent standards for scope modeling n general the scope model selected will depend ga the analysis techniques selected to further explore the scope. (i ete ins Aina ad of airedSn | ea 9273 Elements 1 Context Diagram ‘Acomlext diagram is top-level data low diagram. I useva single data process to ddserie the scape and showsthe externa entities and data stores that provide data toand recelvedata trom the system. Context dlagrans arestil used on many projects that do no otherwise se data Rowe diageoms. Figure 9-1: Content Diagram (Gane-Sarion Notation) o ane External Name otBusiness | soe agent eaten eae Se Figure 9-1:Cntert ogra leon eration) external — Data Store easy inpuroa nA ‘output Dat oupatoaa External oupudaa Entity 2 Events External events happen in an taternal nity, They are external t the boundaries of thosystem being studied (customer makes request. a partnor sends a mesa. Tempore events ate driven by time (og. monthly or annual sports). The ime deter ‘mld by ime related business rus (og. produce ths report a the end oF every day or proparca tax elarn at the end of cach ta period) ‘When events have been ientited, the nest question asked “What processes are reqnited to provide aecnmplet response to this event?” The answers to the question Seti the processes ofthe system. These processes nay then be dacussented, and further analyzed using an appropriate procoss modeling toehniqne, a aD asa eg 3 Features A feature fs service thatthe solution provides to fll one or more stakeholder needs. Features are high-level abstractions ofthe setion thot must later be expanded into fully described functional and supplemental requirements, They allow for early pity sand scope management an fo validating the stakeholder vise ofthe solution 4 UseCase Diagram ‘Ause ease dingram visually deplets the use cases supported bya spstem, the actors ‘who trigger those use cases an relationship between the we cass. 5 Business Process ‘Ahigh+-ovel busines pracess maidel may alsa be used asa scope adel, 9.274 Usage Considerations 1 Advantages ‘Ascope model will makeit easier to determine what should bein and out of cope fora Ssulurton even whea new requirements are Mdentified or toques ehang. 2 Dikadvanteges A scone mode! wil ws eave much af the detailed soapestillneedingt be nest sated and detailed 9.28 Sequence Diagrams 9.281 Purpose Soqunoe dagams are uo modl he glo age sear by owing formation passed betveen objects in the system through the execution of Ihe seenato 9.28.2 Description ‘Asequenesedlogrum shows how classes and bjects interact daring a sexnarto, The ‘lasses required to execute the seenarv are displayed on the diagram, ase the ‘messags they pass to one anarher(eggered by stops in he use cal The sequence diagram shows how cbocts use in the scenario interact but not how they arerelated toone another Sequence diagrams are also often used to show how nser Interne’ eam ponents or software components interact 9.28.3 KeyFeatures The sequence diagram shoves particular instances ofeach objet witha hin beneath exch object to ldicate when the objeet I exeated and destroyed. The ealist events inthe scenario are depict at the tn of the eine. with ater events shosen feethcr down. Thesequence diagram only specifics the ordering of events and not theexact, The sequence diagcam shows the stimuli flowing between objets The stimulus is 8 ‘message and the atrval ofthe stimulus atthe objet sealed an event A message shown aan tow poiating from the feline ofthe object send ‘message to the lifeline of the object rceiving Message control Nove deseibes th | Ta aR A aESn | a types of messages sent between objects > Proceduni Pow iransfersta the reciving abject. The sender ean act unt a roturn message i recived » Asynclironous Flow (alo known as asignal) allows the abject o continue with is fn processing alter sending thesignal. The nbject may send ay signal sine ‘tanvousy, but may only aezept one sina at «time. Figure 8-14 Sequence Diagcam UML) ‘Object a Simple Message Asynchnonous Message Synchronous Message << [Shows when the 1 [odiect sect 9.284 Usage Considerations a Advantages ‘Te sequence dlagsam mayhe used in object-oriented analysis to valiate elas da rams (eseribed in 327) agninst ue eases (3126) 0 tosiow the timing ofimveractions between entities thin the spstem scope, 2 Disdvantages A sequence diogram must be defined fr eh posable scenario. Still speaking, sequence diagram requlres «fully defined class model eee Data Model although less form sequence diagrams or often developed that represent user interface elements ‘or lnteractions between actors 929 State Diagrams 9.291 Purpose ‘sate dlageam shoes hw the cholera cuncep enya objet changes ine dante locvets 9292 Description Astatediagram spooiies a sequence of states that an object goes through during ts Iietime, and defines which events catise x transition between those states. The alow able behavior of th objet i dependent on its eurrent stare. There are many tiles for a aD EsSate agra 9.293 thestate diagram lneludlg State Machine Diagram, State Transition Diagram, and Figue9-5:Stat Machine Disgram UN) val State entryfaction ddojactivty ext/action event/ation|arquments) can happen when the foxcini tot rea cane theodere he obectantanston Sax |@ Elements 1 States UL cay Dass Astate represents a unique condition that an object con heim orstatusthet it may Ihave. All sates for an objet are mutually exelusie—an objet can be a oaly one sate ft time. The meaning nf state is definable within the context of the business aren being analyzed. Additional details ote state such as mandatory characteristics nd relationship further deserbe the sat, For example a Canceled Project mist have a cancellation date Allstate maclines ms have an intial sate [epresenting the state ofthe objet at ‘ereation)and may have any number ofintermedate and end stats. 2 Transitions A transition reptesentydymumiclichavir that moves an em fom one sate tn all er. Transitions are iiggored by activities complete, vents er oter stl. ovr {may only cause a transition ithe objet i alec by the event in itscurzent sate In ‘uddition, business rules may detsrmine fan object respondsto a particwlar event. (i ete ins Aina ad of airedSn | Src 9.29.4 Usage Considerations 1 Advantages Domain SMEs should be iatinatey aware of ie eyce states for their key concscas, Helping them lst and doseribe the statesand then draw the allowable transitions between states eften uncovers missing ata, control and behavioral requirements and ‘may he helpful toclarify confusing oe even conflicting requirements 2 Dhadvantages Since domain SMEs can understand and develop state dlageams very quickly tis important ne to nintentionally expand Ihe seope Esc state nd associated tras tions) should be validated to determine iit is elevan to the solution scope There may be actual states an abject goes trough ax part ofits life eyce that do not havere- {ance the domain, These states should ot be modeled, 9.30 Structured Walkthrough 9.301 Purpose Structured walldhroushs are perfrrseltn comminicate verify and validate requir 930.2 Description structured walktheough a working session where invited parteipants review and Aiseussa se requirements Participants are required toosk questions. and make {comments and suayestions Other issues may also be identified during thesession. All ‘questions comments neers. and suggestinns ute recorded. ugh may result in revised requirements as wel seistes that require inves {Uzation. A walkthrough ay abo be refed tas a requirements relew. An Inspec thom is similar, bat follows more formal process and uses checklists and other tools 9.30.3 Elements 1 Prerequisites A complete requirements package. reyuicements model or package must by com plete inorder to sche a review. the review may easer any ane requirement doc ‘ment, several related documents, or an ati requirements package Alist of appropriate evlewers, Reviewers mey be projet stakaholders business analysts, other resources with xpeciicexpertise in thetype of requirement being, eviowed. Appropriate reviewers include > Knowledgeable representatives f stakeholders who contributed tothe reque= ments. Knowledgeable representatives of taksholers who willsethe requieements in evelopment of the solution, Reviewers representing the projects sponsor orend users, These Individuals must be "spprowed by management of those organizational unit and be authorired to make decisions as their epeescntatve, This sa voting pony delegation a aD EasTR eg meting vehicle, review may beheld in a conference room with all partdelpants Presrnt rit maybe held using technical fact allorng paeticipants n conte loc ‘ons to participate e.collaboratlon tool vklencont noe, laternet meeting softwar 2 Process Review Scope Provide review participants with a checklist ofitems for which the reviewer shouldbe Jooking. Examples of Using: tha might bein aehecklia for «particular seston include teaqunements that ate out ef scope requitement thal ate deserine how the require ‘ment will implemented solution specifications} instead uf business or stakeholder sequitements, or theaccurscy ofthe description ofthe eurrea business process. Crganiz and Schedule Review The Business Analyst must ensure tht the requirements package isissued fr enough In advance tallow all stakeholders to review lt in advance, Slakelolders with approval ‘authority shouldbe present atthe session. Heviowers need townderstand that the purpose ofthe reviews tofind and remove unclear, inconsistent aa incoreeet rogue Conduct the Review The ses isl hold have the fllowingstructe: Figuo9-1s:olestnaStrucred Wottvough Role Pasian ‘Author [Author of the requirements document, | Answers questions about the document, ypealy the business analyst. Thisrole [listens to suggestions, comments. ncor 'smandatory. Areview should not be | porates changes into the document after conducted without the presenceofthe | the review session author Seribe [ny projectteammamiber whe lefamiiar [Person whe dacumenteall suggestions, wih the project may play thisrole.The | comments, issues, cancers, otstand author may play this oe ing questions thet are raised during the ‘Moderator [Anoutal facitator Often i playedby | Faclliatesthe working session, Keoping [business analyst ora tester Thsrclels | participants focused each section ofthe mandatory Its best the author ofthe requirements document ae fe decussed, Jdocumentisnot the moderato athough | verhes that all participants have reviewed resource constraints often necessitate this | the document before the session begins station, When this isthe case, the iak | Ensures that all parcipants ae participa Islack of abjectivty regarding the docu- | ing inthe review. iment Peer This ie another business analyst who has | The peer reviews the dacument forts experience preparing similar require» | adherence to yood requirements doc iments documents entation standards. Reviewer [ny stakeholder Reviews the document priorto the work ing session. Presents questions com ments, suggested changes and dscusses them with the group. a Ta aR A aESn | Src > Tatzoduetion ofpariiosattending presentation > Statement of purpose ofthe reviewed deliver Statement of teview abjectives > Projot backyeownd i equired fo external parties > Formal walkthrough/review of dalverable fb Agrecment of actionfcanges required > Review of deliverable satus og sgnod-off ot signed aff te) Compile Hotes And Results OFThe Review Make sure that all participant comments are recorded and considered for revisions to the requirements document. A the end ofthe reo should he agro whether > there are quality nprovements that cam be made the requirements document > the requirementsdacument is acceptable ints current fem > Additional seiescers are equine to comment on or approve the requirements document Re-Review tecessary decison will alse be made as to whether another review Inspection i required ithe ‘discrable has not een seeped. 3 Rules ToBe Followed During The Review Ter ar several rakes that should by followed when conducting structured wale through Themederatorisresponsiblefor makings tht ll participants adhere to therules Under normal circumstances, supervisors or managers (especialy ofthe author) should exereise caution if they atend the review Tele organieaicnal authority specifically with regards to other review participants, can adversely affect the level ‘of eunidor during the roview. Thoremay also be temptation to exert thei authority tregatding decision pointsin an inappropriate mann. Reviewers must review and comatent gn the content, ot onthe thor ticipants must review the document before the sesson, the business analyst must determine the appropriate project stkellders who will participatein a structured walkthrough. The deliverable ofa struetured walkthrough [Wallstof questions comments, concerna, and suggestions that are cempiled during the working session, Se Problems Tracking (9.20) a aD asa eg 9.304 Usage Considerations 4 Advantages > Promotes discussion ofthe requirements among stakeholders > ffoctive at identifying possblc ambiguities and aroasofimisanderstanding, 2 Dikadvantages Reviw sessions. can eed to reposted rvisons ifchanges atenot carefully managed. The nth ofthe revision and eviee cycle ean sell ina lengthy approval process, 931 Survey/Questionnaire 9311 Purpose nous. ne rele shor pure time survey ct colle formation abot Cistoters products work pacientes Asusey ay alo beeen to a8 9.31.2 Description Asurvey administers a st of writen questions to the stakeholders and subject matter fexperts. Alternatively tespondents are provided with series of statements and asked for thelr level of agreement or endorsement, Thar reqponses ure analyzed and dist ted to the appenprits patie. Questionsin a survey are of tie types: > Closed The respondent is asked to select from avalable responses. This s sell when the range of users responses i fit well unde sto, bul the strength ‘ofeach rsponsceatezory needs tobe determined, The responses to closed ques tions ere easier to analyze than those gained from open-ended questions, because they van bv tie to numerical cveficleats. > Open-ended: he respondents free to answer the questions as they wish Usefl swhen the sues are knowa but the ange of user eesporses to thera isnot The responses to open-ended! questions may provide more detail and awider range “of responses tae those gained com elsed-ended questions. However. open-ended {questions are mote difficult to quantify und summarize as they often inelade quai tativeseather than quantitative, anguaae. 9.313 Elements 1 Prepare A survey rquires detailed preparation to ensure the needed information is obtained ‘while iiniing the enpondents ime to complet i Define the purpose ofthe survey and the targot survey group. Mently the cb ipetivos and the group to he surveyed, Confiem withthe sponsce a Ta aR A aESn | Sem > Choose the appeopeiate survey types nial steps ofa survoy are the same ws or lan interven (149, keopingin sind that semiatricteed interviews are simla to ‘open-ended surveys-and structured interviews axesinlla to lsed-eaded sur > Selet the sample group. Consider both the survey type (openvended or close ended} and the number of poople nthe Kentfed usergroup inorder to detereine FT the entice group needs to bescweyed, When the sample group stl ieroaybe practical to survey all members ofthe group. When the ample group is lange and thedesired survey type is opotvetded t may be nocessiry to demtiy asubset of ses. tna alo be enportant ta sarvey all members ofa ange group tthe user profile indicates wide variance due to geographic distribution, regulatory der fences ack of standardization in job function or busines proces. Fr such sia ationsuscof a alatistical sampling metiod will help cere Unt survey results te rot biased Select the distribution and collection methods For each sample group deter mine thespprepriate commainieation made, sich as harleory mall ems or web fora > Project the desired level of response, Determine what response rate would bese ‘ceptable. the acta response rate Is lower than the acceptable threshold the nse ‘of the survey resuls may be lined. Offeriag an incentive can raise hw response ratcbt the eas ofthe incentive must he justified and iat > Determine ifthe survey should be supported with individual interviews, As survey doos not prove the dopth of data thar can he chtained fom individual Interviews consider »Prosucvoy interviews with hey individuals may provide ideas for survey ques > Postesurveyiaterviows ca target speilc nurvey expanses o themesto eli aronter love of det. > Write the survey questions. © Communicate the purpose, Explain the objectives othe survey. I the stake- holders can see the feasin fr completing the aurves. they are mone kl te do » Be cognizant ofthe group's characteristics. Understand the backround of the target group, cain thee environment and specific terminology Use thisnformation whon writing the questions. lf theres significant diversity in the geoups backround it ay be use te vide s large group inte sealer and homozeneots sroups during the preparation stage and then produce varie lions of the survey thal it exch subgroups background » Pocus on the requizen bjectives ss: All questions must be directed towards the stated a aD Esa eg > Make the survey easy and fast to complete. Keally an more than fve oF 10 me utes his plies limiting the number of survey tems, and arcanging them fn order that tll a story. Mako surethat the quostion wordings clear and concise using terminology that is familias to the respondents ache mus address single point old double quostionsin a single gues > Avold the use of egatve prasng, vol! complex branching structures, where the outcome ofa I challenge Filtered further with subsequent i's, Avo asking questions that may make respondants foul uncomfortable, Tying to elicit information that i cessicted by relations likey tpt tespon= dents on the defensive, Test the strveg Perfor usability test on the survey. Use the results a fine tune thesurvey. 2 Distribute The Survey The distribution means should be selected according to: > Organizational poicls > Urgoneyaf talning the results > Level ofsccunity required ographie distribution ofthe respondents 3 Document Survey Results > Collate the responses For the responses to ‘open-ended! questions, evaluate the etal ond ilentify any emerging themes, Analyzed yuomsnarize the reall, Report ndings to the sponsor 9.314 Usage Considerations 1 Advantages > When usingglosed- ened questions surveys can he effective fr obtaining quant {alive data fore in statistical alysis > When usingopen-endod questions sueveyeesults ay ye insights and opinions not easily obtainable through other lctation techniques, > Docs not typeally eguiresigalicant tne from the responders a] Ta aR A aESn | aT 9.32 fective and efftent when stakeholders are not lated in one cation, > May result in lange mamber of responses > Quick ad eltiely inexpensive te administer. 2 Disadvantages > Uscofpemended questions requires mare analysis, > Toachiove unbiased results, specialized skills in statistical sampling methods are sede when the decision has bean made fo surveys subset of potential respon- dents Some questions may be loft unanswered or unswered ineorretly due to thsie sm: biguous nature > May roqure follow up questions or more survey iterations depending on the we swors provided. > Not wellsuted for colleting information on actual behaors > Theresponse rates for auveys are often too low for statistical significance. The use ‘SWOT Analysis 9.324 Purpose ASWOT analysts ia valuable tool to qulekly analyze varlous aspects ofthe current state ofthe bsiness process undergsing change 9.32.2 Description SWOT is an acronym for Strengths, Weaknesses, Opportunities und Thess, SWOT ‘analysi iva framework for stratege planning, opportunity analysis competitive analy ‘is Uusness and preduet developmen 9.323 Elements The steps to conduct a SWOT analyse areas fellows > Draw arid or mattis > Deseribethe ise or problem under disemssion atthe tap ofthe il > Conttuct a brainstorming semsion to cumple each section it the rid Steg and Woaknosses ate itor jrernal to the organization, ognize Ua. ‘olution, while Opportunities and Threats are external factors, © Strengths: Anything tht the assessed group does well May include exper: enced personel effective proceses (Tayatens customer telationspa or any ‘other internal factor that leads to success BinOrGade Neier 29> Weaknesses. Those things thatthe assessed group does pootl o nt ata, ® Opportunities. External factors tha the wssessed grup may be able to take advantage of May inlide new markets, ew technology, changes n the com: pelitive marketplace, or other forces Opportunities exist beyond the soape of Control ofthe assessed groupy the choles wshethor o not to take advantage of when tix identife Threats. External futon that ean negatively alec the assessed group. They may incade frtors auch asthe enfrance into the matket ofa new compet, cconomle downturns or other forces. Threats are also ouside ofthe group's control > Faciltatea diseusston to analyze the results. Remember thatthe group has iden fied only potential characterises the problem. Further analysis need to lyeoniiemed with data valkdate the actual characteristic, de > Oncothocharacterstes ofthe issue or problem have heon validated, the group brainstorms potential solutions tosole the problem. A standard practice for this toeompare internal strengths and weaknesses against external opportunities and Ahceats and ry ta define strategies foreach cel i Une matrix Fgure9-16:SWOT Max Opportunities Threats 50 strategies ‘ST stategles Howeanthe group's | How can the group use strengthoeucedto | esrengthsta ward off apo potential pote thet? Can Strengths | sporenitie? SO the threats betumed fategesarefelly [into cpparnties? swaightforwardo Implement WO Strategies WT Siatagion Canthegroupusean | ante goup opportunity toetminate | restuctretael to void esses |or7lonta weakness? | theenest Should he Mealiesses |ocathe oppetunity | grup consider geting watranc ene ‘utah market? WT ‘erloproent of aon | statepiesinvcve wast capzeites} ‘care scenarios an eth Bes na tneSn | a 9.324 Usage Considerations 1 Advantages The SWOT analysis helps quickly analyze variaus aspects ofthe current state ofthe organization and is environment peor to Mlebiying potential lation options 2 Disadvantages ‘The SWOT analysis a vory high-level view: more tall analysis is almost always sede 9.33 User Stories 9.334 Purpose User Stories are a brief description of fanetlon ty that users need from a solo te 9.33.2 Description Arar story isa textual desertion of things thatthe soliton needs tallow users to ¢, User stories ue typically a sentence or two that describes who uses the story the nal thoy nee trying in accomplish, and any adltonal information that may be rte Tounderstanding thescope ofthe stary 9.33.3 Key Features Auer story inctades a short description ofthe problem to be soved. hiss frm the perspective othe user. The only detail that needs to be included f information that, tealuces the rik of misunderstanding by developers that create the estimate. user stry includes > Actor: St oder who benefits fom the user story. > Doscription: A high-lovelovertew of what functionally the usr story includes > emet: The business val the story delivers Ausor story should aso have deflved Acceptance and Bvatuation Criteria (2). 9.33.4 When to Use 1 Asvantagee {User stories create an envionment of cstomer avnership of features and perth zallons in anineremental,terativedevelopavent vavizonmeat, They ay eliminate the need to provide fanetionsl rquirements in some envionments User storks alsa require tht the value delivered bythe story be clearly sticulated 2 Disadvantages They may nol be the bes echnigue for some environsnents with rulatoryrestrietions ‘or when an organiration mandates documentation. Ths modeling technique may not be effective when participants are not co-located. This technique des not explicit Ares hw ta daesiment non funetional requirements a aD Esa eg 9.34 Vendor Assessment 9.341 Purpose ‘Tousses the abilly ofa potential vendor to mcet commitments regarding a produet or 934.2 Description ‘When solutions are in part provide hy external vendors (who may e inva inde sgn, construction, implementation, or maintenance of he scion or sululion campo: ns of when the solution ison. there may he speelicegutement in esa {otheinvelvement af that thied pats For exemple, theremay bea need to ensure thatthe supplies inanially sscure capable of maintaining specific stating levels, comnmilting apprope lately skilled stat {osuppoet the solution, and so orth, Now fencfonalreguruments (277)ean be used Lodeline the service eves expected fa thi patty. Vendor assessment i conducted {oensure thatthe vendor irelluble and that sevice levels will meet an organizations expectations. 9343 Elements 1 Knowledge andlxperise ‘A common reason fr using third-party vendorsistht they cus provide knowledge fand expertise not avulabio within the organization. tn sch eases the busines anal ‘huuld consider whether that expertise will aed t be transferred and how capable the supplier sof performing tha ransft maybe desrale to target vendors with particularexpertise In methodologies or technologies with the goa ofhaving that exports ransfrted to people wlth the enterprise 2 Licensing and Pricing Models Ineasos whee asoiiton or sohiton component ‘nts vend, he licensing or pring model wil ‘any cases, solutions that offer snl farctinality may Alife eatin therHioens ing models cequiring an analysis dillerent usage scenarios to determine which ‘option wl provide the host enst/heneft ratio under the seanaros ky tobe encoun tered in the onesie reso frm op ontsonneed toa «Io be taken ote accownt lv 3 Product Reputation and Market Postion ow many customers are currently using the product or service Is the produet widely sccoptod ot uscd in similar organizations? Ie there regular update sebodale and oad napofteatuces that are planned for delivery? A Teams and Conditions Are the services provided by the wndort be temporary of permanent? The business ‘analyst shoukd investigate whethor the vendor licensing terms and technology infra eocture re likely to preset challengceif the organization Inter chooses to transition twanother suppllct Tete may alsobe considorations eegarding the vendo,’ uso of und esponsibility for protecting the integrity of the organizations confidentil data In ad Aiton, the terms under whch custemeations of the product should be cousldered es Ta aR A aE9344 5 Vendor Experience and Reputation ‘The vendor’ experlence with other customers may provide valuable information on Ihow likely itis that they willbe abe to meet thelr contractual and aon-eontractual ‘obligations, the vendor ean also be evaluated for conformance and compliance wit external rerun standards for quality. security and professionalism. 5 Vendor Stability Vow eertain iit cha the vendor wil be abe to prove the required serves inthe future Iemay be necessary to request tha steps he takem to ene that there ace no "isksif the vendor oncounters financial difficulties and that i will bo possible romain {ainand ealsance the solution even i the vendors stualion changes radically. Usage Considerations A Advantages An effective vendor asesement reduces the rsk of the organization developing a ela- Uonship with an usutable vendor and is Hkely to mprove longterm satiation wil thedecison, 2 Disadvantages Can be time-consuming to gather suliien information on multiple vendors: Some in~ formation muy not be readily available. vendors with new and inaoestvepeodicts may score poorly Because they do not havea signtieant history in the market,Copyrighted materialAppendix A: Glossary {Activity Diagram ‘A mode! that lustrates the fw of processes and/ fr complex use casosby sowing each activty slong with information Nows ae eancusrent ac tivities Stops can besperimposed onto hor ron 1 sivtmanes forthe oles that perfor the steps Activity ‘A unit of work peformed as part ofan initiative orpracess Actor's) ‘he human and nonhuman roles that interact with th syste Allocation See requirement alloetion Analyst ‘A generic name for arole with the responsibilities ‘of developing ond managing Feguie om. Otho ses inclade snes unt business bea tor. requirements analyst requirements engine, nl syatems analyst Aczociation Alinkbetween two elements or objects in a dia: ram ‘Assurnption ‘Assumplions ae Influncng factors that are belived tobe true but have not been confirmed to be accurate, Attribute AAdataclement with aspeifed data type that ‘describes information associated with a concept Baseline A pointintime view of requirementsthat have been reviewed and agreed upon toserveusa basis for further development Benchmarking -Acompartson ofa processor aystem's coat, tne ‘quality or other metries to those of leading pect ‘ryaniations to ientify opportunities for i provement Black Box Tests ‘Tests written without regard to how the goltware ‘is implemented. these tests show only what the ‘expected input and outputs wil be Brainstorming Brainstorming isa team activity that seeks bo pro dace abroxd or diverse wet of pions through the rapid and uncritical generation of ideas. Business Analysis Business analysis is tho set af taskssind teohniques sued to worka anon among stakeholders in fonder to nvderstand the structure, patieies and ‘operations oan ergauization,and recommend ‘lutions that enable the organisation to achieve Ws goals Business Analysis Approach ‘Theset ofproeesses, templates. and aetsiles ‘that willbe used to perform hsineseanasis in specific enntenl. Business Analysts Communication Plan A desertion ofthe types of commanieation the dnusinessamabst will perfor daring business “analyets,the recent of those communications, Aan the form in which comuniestion should Business Analysis Plan -Adescription ofthe planned sctvitio thatthe business analyst will execute in order to perfor the business analysis work involved ima specific Intuitive Business Analyst A practitioner obusiness analBusiness Architecture subset of Use enterprise arcitetare Una defines fn argantzaton'scurtent and fur state, includ Ingits strategyits gouls and objectives, he inter palenvifonment through s process of fusctional ‘ew: thecxternal environment in which the business operates andthe stakeholders affected by the organizations activites. Business Case An asssment ofthe costsand benefits asc ated witha proposed initiative: Business Constraints) Basiness contrainte ar initatoos placed on thesnintion slosan by the arganinaton that, seeds the slain. Business somstraints describe Unitations on availa solations, onan aspect of theeurruntstatethat cannot be changed by the deployment of he new aston. Sc abo fence Business Domain See domain Business Domain Model ‘conceptual view of all part ofan enterprise focasing on procicts delierablesand events that are important to the mission of the oegantzs tion. The domain models useful te vliate the ston seope with the busines anc cna Makcholders Scelso model Business Event Aster rig tha iin Business Goal Aslate or cond reac its vio he busines isfy to Business Need(s) typeof high level business requirement thet ise Statement of «business objective, ora impact the Solution should have on itsenvironment Business Policy ‘business policy la non-actlonablo directive that supports business goal Business Process Ast ol defined ad-hoe or vequenced eollaboralive ‘actines performed na repeatable fasion by an ‘organization, Provessos are ieigecod by events tna eny have rultiple pablo cutenmen A sie- ‘eosfulouteome ofa process will deliver valucte ‘one oF more sakehoters, Business Requirement higher level basincss rationale that when ad dressed wll erm the organization a increase ‘ever, avoid cout, anprove sevice, or eet regulatory requirements Business Requirements Document 2 fsiness Reuiemonts Document isa mgr ‘ments package hat deserves brmines require -ments and stakeholder roquemont it dacuments ‘equicements ofintrest to thebusiness rather than documenting busines equitements) Business Rule(s) Abusiness ules specie actionable, taste drive that is under the conte of the business fand supports business policy Capability A fonction of an organization that enables ito aachlevea busts goo! or objective Cardinality ‘The numberof occurrences ofone ently ina data ‘monet hat are linked toa second entity, Cardinal: Hy eshoven ona data mode! witha special nota on, umber (ey, Deotleter (ex, M foram, (Cause and Effect Diagram See fshhone dingram. Change Control Board (CC Amal group of sakehotders who will make deck sions regarding the dispostion and tratment of changing reverent CChange-driven Methodology A nicthadology that focuses on rail delivery af sotuton capitis in an nezemental fashion ‘and direct involvement uf stakeholders tu gather feedback on the seltion’s petfirmance, (i ete ins Aina ad of airedChecklist A quality control echnigue. They eayieclade 3 standard set of quality elements that eviewers use for requirements verification and requirements beldation of be specially developed to capture tesues of concern to the proc, Clase ‘A deverptor for aso ofsystem objocts that share thesame attributes, opsrations, relationships, nl ichavioe. A els tepresentea concep in the stem under design. When used as an analysis ‘mode, lass wil gencrally also contespon 0 8 real-world catty Class Model Atypeot data motel it depicts inforontion sroupsasclasses. Code | sgstem of programming statements symbols rd les used to represent insruetionsto a computer Commercia-of-the-Shelf Software (COTS) Software developed a ald fora particular ‘market, Competitive Analysts A structured process which eaptunes the key char- ctrisies fin indus to prodict he lon term proftbilty prospects and to determine the prac tices of the mos significant competitors Constraint A constraint describes any imitations imposed fon thesolutin that de nt suppor! the business to stakcolder need Context Diagram Aw analyais mode that illustrates product scope by showing the systom ints ensizanment with theexternal entities (people aad systems that ke to and eoeeise from te ator Cost Benefit Analysis Analysts dane to compare and quantify the nan- dal und non-financial costs of making change oF implementing solution eampaced to thebensits sulned BinOrGade Neier 29 Customer A stakeholder who uses products oe services delve cred by an organization. Data Dictionary Am analysts mode dsenibingthe dat fandattibutes needed by the system, Data Entity A group of elated information tobe stored by ‘he system: Entities can he peaple aes, places, ‘things organizations, aeeurrenees in ene, cou eeptejer documents Data Flow Diagram (OD) Amanalysis made tha lustrates processes that ‘occu snag with tue Hows of data to and from those processes. Data Model An analysis mode that depicts the logical struc ‘ure f data independent of the data design oF data storage mechani, Decision Analysis. An approsch to decision snaking that examines ‘and models the posable consequences of diferent decisions, Decision analysis assstsinsvaking a ‘optimal delson undcr condtons of uncertaln: Decision Tables Am analysts model that spcetfies complex business ‘ules o logic concisely in an easy-to-vad tebular format, speifyingall ofthe possible coalitions and actions thst eed to be counted for ln bust Decision Tree An analysis model that provides graphic! alter native to devision subiesby Mlasiratiny eondiians Decomposition _Atechnique that subdivide a probe into its ‘component purtsin order to faeltate analysis and understanding of those componentsDetect A delicacy in product oe service thal reduces Its quality or wares fom adesied attribute, state oe functionality Se also reguiremenasdifet. Deliverable Any unique and vriuble work producto service that a party has agreed to delve. Design Constraints Sofleare requirements that init the options svallableo the system designer Desired Outcome The business bocefits (hat wil result from met Ingthe husness need ond the end sate desired by akeholders, Developer Developers are responsible forthe construction of software anplicatinns. Areas of expertise elite Aevclopment languages development prnctiees tnd sppliention component. Dialog Hierarchy An analyas det that shows user Ings arranged as horarehles terface dia Dialog Map Am analysis model vat ilusteaes fl he ystemsuserinlerface Discovery Session Sec quirements workshops Document Analysis Document analysicisa meas to eis sequiee ments of an ensting system hy studying availble documentation and wleatiying relevant informa Domain ‘Te problem area undergoing analysis, Domain Subject Matter Expert (SME) ‘A person with specific expertise in an area ot ‘domain under investigation Elicitation An activity within coqutements development ta Mlntitis sources for requirements and then uses {echniques (ea imerviews, prototypes. faelitated workshops documentation studies) to gather equlzomens rom thososoueess Elicitation Workshop See requremants workshop, End User Aperson or systeun that directly Interacts with the the som, ce sptems that send or reeive data files too fromm these, Enterprise An organizationalumt,orgonization or ellection ‘of organivations that share a set of common gale andeollaborate ta prvi specific products or Enterprise Architecture Enterprise srchitecturets a desripton ofan ot. seaistion’s business processes, IT sftware a hardware. people. operatlonsad projets and terelationships betwee then, Entty-Relationship Diagram Anentity-rlatonship dlagram is a graphical representation af theentlies relevant toa chosen prablem domatn, the relationships between the, land thei attributes Evaluation “Thesysenatic and objective assessment ofa sal tion ts determine its status and effcay in moet ing objectives aver time and ta identify ways to Improve the soliton to etter most objectives. Soe also metric, tndcator and monitoring Event An eveat i something that accurs to which aor ganization uni ayer. press must respond Event Response Table ‘An anapals model n tab format that defines the events. the input tou that trigger the system tocarty ont some fnetion)an their Fesponses. (i ete ins Aina ad of airedEvolutionary Prototype A proolype thats continuously modified ad "update! n esponce to leelback from users. Exploratory Prototype A prnniype developed to explore a wry require Extornalinterfaces Interfaces with other systems (hardware so ‘ware. and human) theta proposed sytem wil Interact with Feasibility Analysis Sov asiblty stds, Feasibility Study Anevaluation of proposed alternatives to deter rine fthey are technically possible within the vyganization and whether they wll deliver the dese henofitsta the organiza: consteainty of Feature ‘cohesive bundle af externally visible Functional ity that should align with business goals and ajee- ‘ayes. Eac feature isa logieally related grouping functional recuirements or non-fanctional oquraments deserivedin broad strokes, Fishbone Diagram 2 diagramming technique used in roe cause ‘anys vo entity underyiny eauses of an ob Serted problem, andthe refatinshipe ha exist between those causes Focus Group 2 focus aroup iv mans lilt Hes and at tudes about a specific product, servic ot oppor ‘unity nan interactive group environment. The participants share thet impressions, preferences 1d noods guided by a moderator. Force Field Analysis ‘graphical method for depleting the loroos that support and oppasea change evolves enti Ingthe fore eplcting them on opposite sides of line (supporting opposing foes) and then estimating the strength ofeach se of forces BinOrGade Neier 29 Functional Requirement) The product capabilities, or things Use product ost ofits users Gap Analysis. A comparison of the current stateand desired future state of an organization in order toientity differences that need tobe adirssed Glossary Alt end definition of the businees terms and ‘concepts rlevuat to Une solation beng bull oF ceahanced Goat See busines got Horizontal Prototype A pretty that shows sallow and possibly ‘wide viet ofthe system’ functionality but whlch doesnot generally support any actual use or inter faction. Impact Analysis. An impact analss assesses the effets tha a [proposed change willhave on astakeholder oe stakcholder group projet orsystem, Implementation Subject Matter Expert (SME) Astakcholder who willbe responsibefor design ing, developing, sna implementing the change deserihed nthe reguieementsand havo special Jed knowledge reparding te construction of one ‘or more slution components Included Use Cases {Nnise case composed ofa common se af steps used by multiple useeases Incremental Delivery ‘Ceeuting working software in multiple releases so the entire product isdelivered in portions over ime Indieator An indicator Woutiis a specie numeral me surement that indicates progress toward achiev Jngan impact, ouipul aeivty ceimpul- SealsInitiative Any elfort undertaken with s defined goator one. Inspection ‘formu type of peer revi that utilizes pre defined and documented process, spite partic pnt roles and The eupture of defect and process Ietrics, Seeulso structured walkchrough Interface A shared boundary between any i persons and! te systomsetheoigh which information i come ieated Interoperability Abilty of ystems to communteateby exchanging data or services. Interview ‘\ssetematic approach to chic information frm auperson or gruup uf people in an informal or formal setting by asking relevant questions and documenting te responses eration A process in whieh a delverable(or tho selation overall) progressively elaborated upon Each it tration ts aself-contained “mink projet” whieh ‘tse of activities aroundectaker, resulting the development of ssc ofptojetdeberables ne team plansits work, does the work, and checks itor quality and complete est trations ean voor within oe tevatons ts wel For example, an ieraion of requirements evelopment would include eickarion. analysts speciation, and validation activities) For eath te Knowledge Area A group of related tasks tion ofdnsiness anata {supports key ance Lessons Learned Process proves improvement techakgue ised oleara bout and improve ona process or project. Al sons learned session inves a spciel mecting in which th team explores what woeked, what didt ‘work, what could be leaned fom the justo pleted iteration, and ho to adapt processes nd techniques belre continuing or latting anew Metadata Meladatais information thts used to unde stand the context nd vali of iforstion recorded in system Methodology Aset of processes rules templates, and working ‘methods tha preseribe how busines analss, solution development and imploruenttion Is ps formed ina particular contest: Metric Armctric sa quantifiable vel ofan indicator that ‘an organtration wants ta accomplish at «speci Modells) A representation and simplification of eality Aloped to eu information Wo a specifi audience to suppottanalvss.com:nunieation and understanding. Monitoring “Monitoring Isa continuous proosss of ollectin dats todeterimine hove well solfionsiewple mented evmpared to expeetod rss. ee also ‘metric and indicator Needs) ‘See business nes Non-functional Requitement{s) “The quality attributes, design and implementa tion constraints, and external interfaces thatthe product must have, Objective A target oc meiriethat a persen oc organtztion ‘seoks to mcet in order to progresstowards goat ‘Object Oriented Modeling Am anproach tn software engincering whore sft ‘wureiscomprised of components hat ace cncap sulated groups of data and funetions which ean Inert bchvior and attributes rom othe com ponents nd whore compos eammmnicate ‘la messages with one another. tn some orga zations, th same approaeh is used for business ‘enginecring ta deseriveand package the logic ‘components ofthe business (i ete ins Aina ad of airedObservation Observation 1 to elicit requirements by conducting an assessment of the stakeholders ‘work environment. Operational Support tabs holder who bss to ep the solution fan Honing, ether by peeviding support to end users (trainees, help desk) or by heplng the solution operational ona day to-day bass (network and other tech suppor Operative Rules) The busines ales an ongunization chooses to enforce asa matter af poly. They ate intended tognide the setionsof people working within the business They sy oblige people to take exetain sets, prevent people fam Eeking actions or proserbe the conditions under which an aetion maybe taken, Opportunity Analysis The praecss of examining new busines opporta nies to improve organizations] performance. Optionality Dotining whether or nota relationship between entice a data models mandatory, Optionality [shown on adata model with aspecal otathon, Organization An autonomous uni within an enterprise under themanaggment of single individnal or boa with clearly defied boundary that works Aowatd cmon goals ail objectives. Organi tons operate on a enntinows hats, es oppose organizational uni or project team, which may be shane oneo ts objets are ached, The analssstechnigue used to deseribe ros. re sponstblties and reporting structures that exist within an orzanization Organizational Process Asset All materials used by gromps within am organiza tion to define, allot Implement, and manta their processes BinOrGade Neier 29 ‘Organizational Readiness Assessment Anasseysment that describes whether plakelold- ‘ersare prepared to accept the change associated ‘witha solution and areable to use it efeetiney. ‘Organizational Unit Any recognized assucation of people in the oom test of an onganzalin or enterprise Peer Review Avalidation technique in which a small group of stakoholdersevaluates «portion of work prod toto Bnd errors to improne st qui Plan-driven Methodology Any methodology that emphasis planning and formal documentation ofthe processes used to accomplish «project and ofthe resis ofthe Prujet Plane metovllogies emphasize the reduction of iakand contrl aver outea tho rapid delivery afa soho, Prioritization “The proeoss of dotermining the relative impor tance of set ofitemsin order te determine the ‘order n whieh they il be aldeessed. Problem Statement Abiefatatement or paragraph rhat describes the problemen the current state and clarifies whist « ssceesfl soliton il look Uke Process ‘See fnwines proces Process Map A usiness mode that shoves a husines process Interms ofthe steps and Input ad output ows across mule functinns organizations, or jab roles Process Model ‘visual mode or representation ofthe sequential Noy ond contra logical asetof elated activities Product Asotution or component ofa sok result projectProduct Backlog have been identified as candidates for potentiat Implemeatation, prioritize. and estimated. telson features thal Product Scope the fatures and functions that eharacterie 8 product service or reall Project temporary endearor undertaken to create unique product servtee or resul. Project Charter ‘document issued by the projet iaitator or ‘sonearthat formally authorizes the existence of project, and provide the project manager with theauthorityo app arganizational resoureesto projet nett Project Manager wehoker assigned by the perTurming oran nization to manage the war requited 10 achieve the project objets Project Scope “he work that must be performed to deliver a product, service, or reall with the specified fs tutes and functions See also seqpe Prototype ‘A partial or preliminary version ofthe system, Quality ‘Tho degreeto which asot of nherent characteris: ts fulfills requirements Quality Assurance Activities performed toemsuce that a process will deliver products that mect an appeoprate lve of quality Quality Attributes The subset of nonfunctional regtrements that describes propertics of the sat vae"soperation development and deployment (e, performance, sceurity usability, partabiity and testabsi) Questionnaire Regulator A sakchiolder with legal or governance authority ‘over the solution or the pracess use to develop Relationshi A defined association between concepts, aston ‘or entities. Relationships are usually named and Inchide the cardinality of the association, Relationship Map Abusnese model hat showa the organtatlonal ‘context in terms ofthe reftdonshipe tha exlt lamongthe organization, sternal estomers, and providers, Repository {Arua or virtual facility where all inforaistlon ‘ona specitictopicis stored and is available for reteival Request For Information (RFI) ‘Arequitements Jocument issued to slit vendor Input ona proposed processor product Am RFI is ‘used whea the isuing organization sok to com: pare different alternatives ori wricertain sear Ingtheavallable options Request For Proposal (RFP) Arequitements document issued when an organt zation is seeking a formal proposal tom vendors. An FP typically requis that the propos sb submited following x spect. process and us- {ngsealed bids which willbe evahatedl against a formal evaluation methodol. Request For Quote (RFQ) An informal solicitation of proposals rom ven dors Requirement LA condition or capability seeded bya state folder tosolve problem or achieve an objec 2 condition oreqpabilty that must be mt of possessed bya solution o solution component To-satisya contract, standard, spectfation cor ather formally noposed ducuments. (i ete ins Aina ad of airedS.A documented representation of condition ‘orcapability asin I)or2) Requirement(s) Attribute Metadata related tos requirement uscd to assist ‘ith requiranents development and manage Requirement(s) Defect Anerror in equitemtents caused by incorrect, fncomplete, missing, oF canfcting requirements Requirements Allocation The proeess of wpportioning reguleements to sub: systems and components (se, peop haslese, and software) Requirements Discovery Session Soo requirements warkshop. Requirements Document Soo requirements package. Requirements iteration An itcration that defines requirements fr a sub set ofthe solos seape, For example, an eration ‘af roquiroments would include var ifyings part ofthe overall product scope to fueus upon, iden- tilying requirements sources for that portion of theproduct-analy2ing stakeholders and planalng have to eit requirementsron then, conducting liitationtetiniques, documenting the eoquire set, al alidting Ue requirements Requirements Management The activities that contro requirements develop- meat, including roquirements change conical fesjurementy attributes definition, and eeqine: ments traceability Requirements Management Plan 2 description ofthe requirements management proves Requirements Management Tool A software tol that stores requirements informa tion ina database capires requirements as bulis and asocltlons, and faelltatesrequle ments parting, BinOrGade Neier 29 Requirements Model A representation of requirements wing text land diagrams. Requirements models can also becaled user requirements mode's or analysis models ard ear supplement textaal requiements specications Requirements Package A requirements package isu st of requirements [grouped together na dacinient a presentation for communication to stakeholders. Requirements Quality See requirements validation ao rquircrnente verification Requirements Risk Mitigation Strategy An analysis of requitementsrlated risks that ranks ish and Meties actions to avd tite those rake Requirements Signoff Formal approval ofa set of tequite sponsor or other dovision maker entsbya Requirements Trace Matrix A mattis usod to track rogulcomentsroation Ships Fach coum inthe mates provides r= ‘Quirements information and asocinted projet or sottyare development components Requirements Traceability “Theatilty to identity and document the Hines ‘ofeach roquirement. including ts derivation Abckwed taceabllyis allocation toeward traceability), and ts relationship to other req Requirements Validation The work done to ensure that the stated require ments support and are aligned with the goats nd ‘objectives oth businessRequirements Verification work done lo evaluate requirements toeasare they redefine eornectly and are at an accep able lowe of quality It ensuresthe stesficiently dened and steuctured so that the Solution dovelapaenr tear can use them Inthe dest deeoen ad impleentaton the Requirements Workshop ‘requirements workshop is structured meeting fn which a carefully selected group ofstakcholi ers collaborate to defne and or refine require ments usd the guidance ota skilled neuteal faciitstor, Retrospective Soo lessons learned proces. Return on Investment measure of the praftaility ofa projec in ssstnent Risk An uncertain event or condition that iit occurs will afecr the goals or ohjeetives af proposed change Risk Mitigation Strategy Sou requirement isk mitigation strate Root Cause Analysis Root cause analysis is stewctured exaiination ‘ofan identified problem to nderstand the under Iying causes Scenario ‘A analysis model that deserlbes a series of a tions or tasks that respond to an event. Fact sconario ean instance at usecase Scope The area covered bya partiulae activity or topic ofinterest Soe also project scope a soltion scope. Scope Model ‘A model hat dllines the boundaries ofa business donate oe soltion Secondary Actor An artorwhe participates in but doce ot initiate Sequence Diagram A type of lagram that shows jects parlept ingin interactions wad the messages exchanged between them, Service Work carried out ar on behalf thers. Software Engineer See develope. Software/Systams Requirements Specification A requirements document veiten primarit for Implementation SMPs describing functional and ronfinctionalrequttements Solution ‘Aszltion mets business nee by resolving a problen ot allowing ao organization 10 take a- vantage of an opportanity Solution Requirement A characteristic of «solution that mocts the Dusiness and stakeholder requirements. May be subsivied into functional and non-functional roquleements Solution Scope “Thesot ofcapabilios solution must deliver in corer meet the business nee, See alse scape ‘Span of control Span ofcuntros the msmber of employees -manger Is directly (or indirety) respon able fr Sponsor [Aslakeholder who authorizes or lgitimizes the [oduct development effort by contracting loro Paying for the project. Stakeholder A group or person who hastntereats that enay be ‘toot by an initiative or influence over i (i ete ins Aina ad of airedStakeholder Analysis work token the stakelioklers who ay be Impacted by a proposed initiative and assess their Interests and likey participation. Stakeholder List, Roles, and Responsibility Designation Alisting f the stakeholders afocted bya busines ‘ed or proposed solution and adesription of thoi participation in a projector other initiative Stakeholder Requirement Stakeholder equinconente ae statements of theneeds fa particu stakuholdets Ihe desenbe the aceds that a given ‘takeholder has ant how that staksolder will {ersct witha solution, Stakeholder Reguitements serve asa bedgehetwoon Business Kaquirements 1 the various class of solution requirements, cher oF class of State Diagram Ananslysis mode! showing the hfeeycleof a data cent or case State Machine Seostate diagram. State Transition Diagram Seo state diagram, Stated Requirements ‘A requirementarticulated by stakeholder that has not been analyzed, verted or validated. Stated requirements frequent reflect the desires of astakelolder eather tha the aetual need Structural Rule Structural ules determing when something bs forsnot tmeoe when things fallinto a certain feuteyory They describe categorizations thal may change over tine. Storyboard See dialog hierarchy and dialog map. Structured Walkthrough A structured walkthrough isan organized peer ‘rovew of deliverable with te objective of ind Ingerrorsand omasions Ris considered afar of quaty assurance BinOrGade Neier 29 ‘Subject Matter Expert (SME) Aoslabcholder with specific expertise in sa aspect ‘ofthe problem domaln or potential solution ater natives or componets. Supplier Aslakcholder who provides products or scrvices Survey ‘Amurvey adiantsters ast of watten questions ta sakstioldersin order to collect responses from large group ina relatively short period of time. Swimlane Thehorizantalor vertical setion ofa process ‘model that show which ativitles are performed bya particular actor or rol ‘SWOT Analysis SWOT isan aeronym for Strengths, Weaknesses, Opportunites and Meats is amodel used to understand influencing factors ad how they may afoot an inatve system {Ncollection o'tsrrlated elements that interuct toachieve an objective System elements cami clude hardware oftware. an people. One systern ceanbo asub-zlement (or subsystem) of another system. ‘Technical Constraint(s) Techical constant are Iimbattons on the design of potion that derive from the teh ‘oyused ints implementation, See als busines Technique Tocliniques lle the way business analysis task is peratmed rdescribe a specific rm theaut- ppt ofatask may tke, Temporal Event Aspstom trigger thats ntited by time, Tester Astakchoider responsible for assesing the quality ‘of and identifying defects in, a software applicaThrow-away Prototype A proolype used to quickly uncover and clarity Interface requirements using imple tool, some times just paper and pencil Usually discarded ‘when the Bal ayters has been developed Timebox A fixed perl of time to accomplish «desired Traceability See requirements raccabiliy. Transition Requirement(s) A classification of requirements that deseribe capabilities tht the setton must have in ord to facilitate transition from the current state of the enferpriseto the desica futurestate, but that will fot enced sn that ranition i compe Unified Modeling Language (UML) ‘A monpropritary modeling speciation language used ta spel, visualize, and document delisorabes for objet-ortented sofwaro-itensive Use Case Analysis mode hat deseribes Uh tasks hat thosystem will perform for acirs and the goals thatthe system achieves for those actors akg, the way Use Case Diagram typeof diagram defined by UML that captures sll actorsand use cases volved witha syvem or Product User A stakeholder, person, devi, or system thet di roetly or ndizwetly accesses a system User Receptance Test Test casts thal usors employ to udgewhether the delivered system i acceptable. Exch acceptance test describes aset of system inputs and expected resalls User Requirement See stakeholder requrement() User Requirements Document requirements document written for auser landience describing user requirementsand the Impact ofthe anticipated changes on theusers. User Story high-level, informal, short deseription of solu Hon eapabilly that provides vale lo stakehld ‘A user story i typleally one cr two sentences Jengand providesthe minimis information rnocessary to allow developer a estimate the work required fo implement Validated Requirements Requirements that have been demonstrated ta Adelivorbusiness wale and to suppor the snes sgoslsand objectives. Validation ‘Thepracess ofeheckinga product to ensue that it sotieton src uae and eonformsta tre ‘asizments, Validation ensures Unt so bl the ‘oreect solution. Aso see requirement aldation Veriance Analysis Analyts of discrepancies hetwoon planned and ‘actual peformance to determine the magallude ‘ol those diserepaneies and recommend corrective and preveotative ation as required, Verifeation ‘The process ofehecking that deliverable peo duced ata given stage of development satises the ceonuitions orspeefieations ofthe previous tage. Veriiestinn ensues thal yous bul the sitio correctly Alga see reguiramonis verification. Verified Requirements Roquiroments that heve been shown to demon. strate thecharaceristcs of requrenients quality lands sich atv eahestve. complete. cass ‘orcec, feasible, modifiable, unambiguous,and testable, Aprotntype that divesinto the details fe inter face, Functionality oF bath (i ete ins Aina ad of airedVision Statement (product vision statement) Arif statement or parageaph that deseribes tie ‘hy; what, and who ofthe desired software prod uel from a business point of yew. Walkthrough Atype of peer review in which participants pres- ent discuss and sep through & work product to find ecrocs, Walkthroughs of ruirements docu 1mentation arc usd to verify the correctness of foqultements, See also structed walkthrongh Work Breakdown Structure (WES) A dalvrablo-oekented bermtchiea decomposition ofthe work to beexecutedby the project team to ‘sccamplish the projet objectives and ereate the regquired deliverables I organizes ani defines the total senpo a he prec Work Product 2 ddocumontor collection «notes oF dkageams used bythe business analyst daring the requires ‘mente dovelopment process,Copyrighted materialEV a aC Cy Ne ‘he following works were rafrenced by conributrs ‘to the BABOK” Guide during the development of ‘us version or ofprestous versions cases where ‘mulipie editions ofa mark were consulted, only the ‘most recent eto is ted. Jn adition tothe works ested here, many ather sources of information om business analysis were ‘nsued by contributor and reviewers or oter- tise or influenced the development of the BABOK" Guide, including articles while papers, websites, ‘log pasting. online forums sominars warkshops dan conferences Wh ony avery ew exceptions, the Meas and ‘concepts found inthe BABOK" Guide were not ‘reaed jor ororiinal tot The BABOK” Guide sa Sathesisef decades ofreseurch inte how ergiza tions work cnd methods that cam be used to dently potential improvements. The works listed elow ‘hemsehves build an the thoughts and research of many others. Asker, David A. 1995. Developing Basins Strate le. Joua Wiley 8 Sons ie Adelman, Sid, Larisa Moss and Majid Abal. 2005 Data Strategy Addison-Wesley Professional ‘Aleyandet fan. and Nel Malden, 2001, Seemart 1, Stories, Use Cases Through se Systems Develop ‘ment Life-Cycle John Wiley & Sonne Alexander fan, and Richard Stovens. 2002. Writing Detter eqniements. Adlson-Wesley Professional Altes, William 1999, The Thinking Managers Toolbox: ecte Procesaes for Probl: Sobing and Decision Making Oxlord University Press Ambler Seott W-200, the Ojet Prine: gue ‘Model-Driven Development wilh UML 20. Camn- bridge University Press Acmour, rank, and Granville Miller. 2000, Advanced Ue Case Modeling Software Systems ‘Addison-Wesley Professional, Association of Business Process Management Professionals, 2008, Guide othe Business Procest Management Common Bod 0) Know edge. ABPMP, Baird Jim, A oss Little alere Leblanc Louis Molnar. 2001 Business Requirements Ay sie Applet Des Practices alton. The Info Imation Architeeture Group. Bechtold, Richard. 2007 Fssentals afSaftvare Project Management, 2" Filion. Nasagerent Concepts. Bensoussan, Babette and Crag iaher 2008. Amabsis Without Party: 10 Toast Make Butter Strategie Decisions, FT Press. erman,Jfl20. Maximcing Projet Vale: Defining Managing, and Measuringfor Optinal deturm. Amacom, ‘Berman, Karen, and Joe Kalght. 2008. Finan Ineligence fr TT Professionals arvana sins School Press. Bienes Kurt. and lan Spence 202. Ue Case Aor ling. Addison-Wesley Professional Boar, Bernard H. 2001 th rt of Strategic Plan ng fr tnformation Technolgy John Wiley Sons ine ‘Boehm, Harry, and Richard Tuner. 2008, Balane= ingAeihty ad Discipline A Gide fr the Per- ‘plexed. Addison-Wesley Professional Drache, lan Pan Sam Holey Scott. 2005. Implementation: Hew to Transform Staten ‘ives nta Blockbuster Resale MeGrave Brassard, Michael Lynda Fina, and Dan Gin. 2002 The St SIGAKA Memory Jogger I-A Pocket. guide of Tool for Six SHGMA hmprovement Tess. Goal ee,eidgeland, Dav Mund Ron Zaha, 2908 usiness Modeling A Practical Guide to Realizing Dass Vane, Norgin Kalman, ‘Monte Essays on Software Eagineering Anniver sary Edition, Addinon-Wesley Professional Brown, Das.2006, Communtrating Design: De loping Web Site Documentation for Design and Planning, Now Riri Barton, Hichard M. Gorardine DeSantis, and Borge Ob. 2006, Organtzatonal Design Sep by Step Approach. Cambie University Pros. CCarkonord, Baraca. 2009, Seve Shops lu Master dng since Anat. Ross Publishing Carnegie Mellon University. 1995, The Capabitiy Maturity Madel Guadelnes for proving the 8 ware Drovass, Addison Wesley Professional Chriss, Mary eth, Mike Konrad, and Sarily Strum. 2006, CAAA Gudelines for Proces tegration avd Product Improvement (2° Ein ‘Addison-Wesley Professional Cimpereman, 2000, LAT Defined: A Gide to Practical User Acceptance Testing. dion. Wesey Cleaen, Robert 7.1996, Making Hard Detsons ‘An iniretacion to Decision Analysis. Wadsworth Pahlishing Corapany. Cookbura, Atistae N00. Writing fective Use Gases. Adio Wesey Professional Powered Methodology for Small Teas, Adlson Werley Professional Cohn, Mike. 2004. Ler Stres Applied For Ale Sofware Development. Addison-Wesley Protes sonal Constantine, Larry, and Laey A.D. Lackwood 199, Software fr Use: Practical Guide to the Models and Methods o Usage-Centerad Design ‘Addison-Wesley Professional (Craig Maloal, 2000, Thinking iowa: Business ‘Application of Fourteen Core Diagrams. Contin tm Iniermatona! Publishing Group Davis Alan M, 1995, 201 PrincplesofSoftvare Development. MeGraw-HUNL 196. Davis, Alan, 2005, st Enongh Regiremomts ‘Managerient: Where Software Development Meets ‘Marketing. Dotset House Demarco, Tom aun Thoth ster 2003. Wal Witk Hears Managing Wisk an Software Projet’: Dorset House Denney Richard 2005, Succeeding with Use Cases Working Smartt Delwer Quality. Adison Wesley Profesional Dc, Lowell Dand fumes, ennypacker, 2008 Projet Porto Management Selecting amd Priar= sizing Projects fr Compeutve dvantaga. Cte fe Business Practices Dymond, Kennsth M. 196, A Guide tothe CMA: Understanding the Copabiily Matty Aol for Siftaare Process ne. Eskerson, Wayne W. 2005. Performance Dest ards: Measuring, Monitoring. and Managing Your ‘snes, Jon Wiley Sons ne, Eriksson, Hans Bik und Magnus Penkor 2000, ‘Business Modeling with UAL: Dvinss Patter at ork John Wiley & Sons in Fisher, oger 1991 Getting to Yes Negotiating ‘Agroement Without Giving In, Penguin Ftrpatrik Jody L James WSanders, and Blaine Worthen, 2008, rogram Evaluation Alterna lve Approaches and Prctical Guidelines, Allyn & Bacon, Forsberg, Kevin, Hal Mooz,and Howard Cotter man. 2005, Yenaiing Projet Managemen vets and Frameworks for Mastering Complex Systems. Wiley. (i ete ins Aina ad of airedFowler, Marti, 2003, UME Distlod: A Brief Gute tothe Standard Object Modeling Language, Md son-Wesley Profesional 1990 Handbook of Walkthroughs, iapectons and Technical Rees: Evaluating Progrants, Projects, ‘and Proxiete, Dorset Howse (Gaus, Dona Cand Gerald M. Weinberg. 18, Esporing Reqsiremints Quality Bfare Desi: Dorset louse Goorge, Mlehuo Ls John Maxey, David 7. Row lands, and Malena Upon: 2004. Ze Leas Sis Sigma Pocket Toolboaks A Quick Refarenee Gude t0 270 Tool for improving Quality and Spot. eG sit Goldsmith, Robin F. 2004, Discovering et Bat nese Hequrements or Software Peace Secs Artech, Good paste. Joh €. 2001. sanaging Pract for Value, Projet Management Lasttute, Gortesdlenet. lle, 2002, Ae guirement ty Col luboraion Workshops for Defining Needs. Adsoa- Wesley Professional Gottesdiener, lle, 2005, The Software Reguree ‘ments Semary ager Pocket Gude ta Hep Software and Business Teams Develop and Manage egnicentens. Goal QP (yg) Craig, Nol DeCaro, and Bruce Willams ‘Six Sigma For Dimntes, Wiley Publishing, adden, Rita Chao, 2008 Lending Caleare Change fn Your Safivare Organization: Delivering suis arly. Management Concepts amuser Mice sa James Charpy. 2008, eongincerng the Corporation A Manifesto for Buginess Revolaion. HarperCollins Publishers Vammond, john S, Raph L-Koenes. and Howard aif 1996, Smart Choirs tarvard Business School Pres. BinOrGade Neier 29 Harmon, Paul, 2007, Busines Practes Changes A (nid for Business Managersand BPM and is Sigma Professionals Margin Kalman Review on Measuring Corporate Performance. Har ‘vatd Business School Pret Harvard Business Review 2007, Harvard Business Review on Making Starter Deesions.Uarvata Business Shoo! Pros, Hass, Kathleen Ih 2007 the Hesinese Analyt as Siraegist Translating Busnes Strategies into Valuable Solutions Naragerent Concepts Has, KatheeaB, Don J. Wessuls and Kevin Brenan, 207, eting i ight Auiness Hegre ‘ments dnabsts Tool and Techniques, Management Concepts ne Havey, Michael. 2008, Bona! Susiese Process Movdefing. OWeily Media Hay; David C. 2002. Aegatrements Analysts: From Lasiness Views to Aecitetare Prentice all Hetzel BH. 1999, The Complete Gude Software Testing. Wile. iat, rey Ms ad Timothy J Ceousey, 205, Change Management, Prosch Research. Holman, Laks 1996, ourney ofthe Software Pro: fisiona The Soeolagy af Computer Drogranming Preatie Hal Hopkins, Richard, and Kevtn Jenkins. 2008. Eating the IT Elephant: Moving Som Greenfetd Deets ‘rent to Brann. IOM Press Hubbard, Douglas W: 2007. Howto Measure Any thing: Finding the Value of'Itangibles"in Baines. Wiley. EE Compnter Soetety, 190, EER Sa o1-12 199: EEE Standared Glossy of Safimare Eng nerng fer minaigy- nsitute of Flectrical and eetrunies Enginoes,TREE, Computer Seeley. 1998 EE Sid 1282-1098 ILE Gta Jor Developing Syter Hequirements Secfcaions taste of Eletrieal and Bec woes Eagineerm, IEEE Computer Socte. 1998. JERE Sid 83-1008 HELE Recommended Practice or Sofware Require ‘ments Sperfeations, Insti of lectrical and Electronics Enginces IEEE Computer Society. 2001 Guide ro he Sop wave Engineering Bad of Knomedg, 2004 Version Institute of Eleetrieal and Electonics Engineers, International Orgarzation fe Shandatdiza- tion. 2008, ISAC C2 23010: Software enginoer ing Sofovare product Quality Requirements and ‘vaation Sues) ~ Software and quay se ‘models Requirements and Evalation (SQuaRE) tunity Madet. Veron 0.35, 1SOAARE Jackson, ML 1995 Suftnure Requirements And Seifcations, Addison-Wesley Professional Jacobson, far and Pan-Wei Ng 2004. Aspect rented Software Deselapment with Use Case, Addison-Wesley Profesional Jalote Pan 1999, CMM in Practice: Pracesee for Execuling Software Projects at Infos. ison ‘Wesley Professional Jonasson, Hans, 2007 Determaniag Projet Resure ‘ments, Aucehach Publications. Jones, Morgan D. 1998, the thinkers Tole 14 Powerfet Tecbnigesfor Problem Solving Three Jones, Capers 1998, Eetmaing Sptware Casts MeGraw-llil Juran.J.M.1992, Jaran on Quality by Desig The ‘ow Step for Planning Quality inte Goods and Services ree Press. Kaplan, Robert Sand David P Norton. 1996. The Balanced Sevrecard: Pranslatng Strategy ino Ae tion. larvae sins School P ‘Kessler Car. and Joh Swoltzer 2007- Outside te Seftvare Development. Practical Approach 2 Building Saecesafl Stakeholder based Products IBM Pees. Khoshatlan,Setrag. 2006, Service Oriented ater ‘rises. Auerbach Publiations Kit Edward, 195. Sofware Testing fa Te Real Wort: improving he Process. Addison-Wesley Profesional Kotanya, Gerald, and lan Sommerville. 198, fe ‘quirements Enginoering Processes rd Techniques Wiley. Kotter fol P. 196, Leading Change, Harvard Basiness School Pres. Kovitz, Benjamin L, 1998, Practical SofivareRe- quirements Manual of Content aaa Style Mas zing Publications. Larman, Craig. 2004. Applying UML ad Pastors An Introduction ro Object Oriented Analysis amd Design and erative Development Peace all Lauosen, Soren, 2001, Software Requirments: Siler Techagues Adison-Wesey Professional Laveson ae, Denis Desroches, and Tabs atch, 2007 Scorecard est Practices Des, Iplemen ‘aston, and Evaduaton. Wile. Latfingwell, Deus, and Don Widrig, 2008. Manag ing Suftware Requirements-A Use Case Approach 2° Ldition Addison Wesley Professional Lelfingwell Dean, 2007, Sealtag Safar Agi dies Practices or Lange nterprses ison Wes ley Professional Lepsinger fichard, and Antoinette D. Laci, 1098, The Art an Silence of Competency Maret Pinpointing Crtcat Succes Factorsin Organizae ‘one Josey Bass Pfs, Loney, Alex 2007, So Problem, Authorhomse, Malster, David I, Charles 8. Green, and Robert IM. Galton, 2001, The Trust Advisor Face Press (i ete ins Aina ad of airedMastin, James. 1989 Iyfirmation Bnncering Book ‘eIntroton, Prentice ah. Martin, James, 1990 yr mation Engineering Book Us Planning & Analyse Deets Hall Martin, ames, 1990. dnfrmation Engineering Book Lil Design and Constrtion. Prentice Wal MeCons crow eve 1996, Rapid Development. Mi- Mintaberg, Hency and James Brian Quis, 1995, "he Strategy Process Canesp, Cates and Cases Preatie Hall Morabito, Josep Ira Sack, ond Amuro hate 1998, Oruunization Modeling movatve Arete: hire for the 21 Century Prentice Hal Moss, Larissa and Sbaku Ave, 2008, Business Inteltgence Roadmap: The Complete Project Life ‘ple ur Decision Support Applications. Addison Wealey Professional Myers, leniord 2004, the Art of Sofware Let Ing, 2" Eton. Wiley. Nielsen, Jakob 199, Usabiliy Engivesring Mor gun Kaufmann, Niven, Paul 2008, Balanced Scorecard: Step Step for Governmnent and Namprofit gencios. Wey Object Management Group, 2007. Busines Motiv nom Mode! {2NA0 Speeifeation. Objet Manag sent Groups nc Objoct Management Group, 2008. Business Process Maturity Model(BPMAD, Version 10. Object ar sgement Group. Ine Objoct Management Group, 2008. Heiner Process Modeling Notation, V2, Ob\ct Management Group, te Ould, Martyn A. 2005 sins Proves Manage iment A Rigorous Approach, Meghan kifer Pr, Page Jonos, Meili. 1988. Praetial Gude to Stra tured systems Design, Prentice Hal BinOrGade Neier 29 Paul Debra, and Donald Yeates, 2006. Business Analysis. British Computer Society Society. erry. William E2000, Efecsive Methods jor Sot- ware Testing 2 lion, Jon Wiley Sons Porter, Michael E1980, Compesitie Strategy: Techniques for Analyzing Industries and Compe tars. Fooe Pres, Porter Michach 1985, Competitive Advantage ree Press, Pressman, Hoger $20. Software Engineering. A Pracsitione’ Approach. Meas Bl Project Management Insite, 2008 Gide a the Project Management Bay of Knowledge, * El ‘ion. Projet Management Institate. ‘Rad, ParvlzF, aod Gln Levin, 202, te vanced Project Management Office: A Compre sve ook at Pancton and Implementation, ORC Press Roam, Daa, 2008, Back Of the Nap. Penguin Group, Robertson, Suzanne and James .Hobertson 200, fequirements-Led Project Managem Discovering Davids Slingshot. Addison Wesky Professional Robertson, Saran, and James; Hbertson 20. Mastering the Hegurements Proce, 2° on, Addison Westy Professtonal. oss Jeanme W, Peter Well and David €.Reb- srtson, 2006, Enterprise Architecture os Strategy oss Ronald (2003, Printples ofthe Business Fale proach dkdson Wesley Professional oss, Ronald G, 2005, Business Re Concepts - Ge lingta the Point of Knowledge. 2" Eaton Basiness ul Solutions Ine Tube, Dard, 1997 Practeataelyis ae Design for Client‘Server and GUT Systems, Prntiew HiRumbaugh, james, Ivar Jacobson. and Grady Nooch, 2004 The Unified Modeling Language Refi. ‘ere Maral. Fon. alison Wesley Pro Rumer Geary A and Alan P Brache. 1995 “Inprving Performanes: How ta Manage the White Space nthe Organisation Chart. Josey Base. Scholtes, Peter 1992. the Leader's Handbook: Masking Things tappen. Gating Tings Dane MeGraw-tti Schiwaber Kem. 2008, Atle Project Management Wilh Sera. Microw Sens, Peter M1990 The Ft Dispin«, Double day. Sens Peter M1999 The Dance of Change. Dow Deda. Sharp, Ale, and Patek MeDeemott 2001 ak fos Madelinge Tools for Process Impraventen! and “Application Devlopment. Artech House. Sodhi, Jag. and Prince Soh, 2001.17 Project Nan agenient Handivek, Management Conceps, Sod, Jug and Prince Soh, 203. Managing 7 Systems Regurements, Management Concepts Softcara Fnginsering Institute 2006. CA for Deaclopment Verion 12, Carnegie Mellon Univer. Soltware Engineering lstitute 2007. CMMI for Aequiston, Version 12. Carnegie Mellon UnWer Sommerville lan and Pete Sawyer. 1997, Require ‘ments Engineering. A Good Practice Gude, Wiley. Stanford, Nom. 2007. nude 10 Organisation Design: CreatogHigh-Performing and Adaptable Enterprises Proile Books, Stevens tichrd, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. ystam Fnginring Coping vith Complex. Pearson Education. Surthel, Barbara), Bein L Jane. and Poe Scholtes 2003, The eam Mandboot Third Bition, Joiner/Ore ne Tarantino, Anthony 2008, Gorcenance, Rsk, and Compliance HandiooksToeknology. Finance. Env ronmental and international Guidance and Best Prastces, Wiley “ayntor, Christine 2005, Suseesyfal Packaged! Seftware Dnpleamentation. CRC Pres “Thayer, Richard 1997 Software Enginering Project Management. Whey IEEE Computer Sock ‘Thayer Richard Hf and Medin Dorfman. 1996, Seftrire Engineering, Wiley IEEE Compiter Sock evn thayer, Richa Hand Merlin Doman, 1997. Sefevare Roguiromonss Engineering. 2 Editon Wiley ELE Computer Society Pres. ‘Thorp. John. and Fujitsu Consulting's Conte for Strategic Leadership. 2005. the Information Par da: Healing the asin Benes of formation Technology, Revised Editon, MeGraw-1 ‘Tockoy Steve. 2004 Return on Softnare Mast izing he etn om Your Softvare vest ‘Addison-Wesley Professional ry, William. 1985, Getting Past Nos Negotiating in DiftetSiuastons Bantam Van Assen, Marcel, Gerben Van den Berg, and Paul Pietersen 2008, Key Managemen Model ‘he Gos models every manager meeds to know: Bear son fducation Canada ‘Van Bon, Jan, Aion de ong and Axel Koltot 2007 Foundations af Service Management Based on FIL V3.Nass laren Publishing ‘Yon Halle, Barhora, 2001. Haines Rees Apiads Building etter Systems Using the Basins es ‘Approceh. Wiley. (i ete ins Aina ad of aired‘Ward, Job Land Elza Daniel. 2006. Benejs Managememt:Delering Value from 1S & IP west. mens. Wiley. il, ater and Jeanne W Boss, MOL IT Gover: anes, MeGeas-N Europe. einer otal M198 The Paychaingy of Cm pater Programing Sher Anniversary Eton Dorset House. ‘White Stephen A, Derek Mert anil Layna Fis: her. 2008. BPAY Modeling and Hefervnce nid, Futuce Strategies Ine. Wiegers, Kae E2008, Software Aequirements 2 Buin, Micros, Wiegers. Kas E2006. More About Sofa Re- quirement: Thormy sues ara Practical Adves, Mictosat Pre, ‘Wiegers, Kut 2007 Prutieal Profs inition: Allandhook wth Tots. Micra. ‘Young, Ralph, 200), Eifectve Requirements Practices Addison-Wesley Professional Young, lp K. 2001 Reguirensente Engineering eanthook, Arts House. Yourdon, Edwatd. 1978 Strucured Walkthroughs "baton. Nourdon Poss.Copyrighted materialAppendix C: Contributors C1 Version 2.0 ca Body of Knowledge Committee Content fr this release was primarily developed by the Body of Knowledge Commit: Kevin Brenntn, CHAT, OCEB, PMP, Vice President, Hay of Knowledge (Require- ments Analysts, Underving Competences, Post Review Revision and Publication) > Rarhara 4. Carkenord, MBA, CRAP (Regntremens Management and Communi lion, Solution Assessment and Veldation) Mary Gorman.CRAP (Station) > Kathleen Bass. PMP (Emrprise Amati frends Keron, MA (Glossary) > Elieaboth Larson, CBAP, PMP (Business Amal Planning and Monitoring) chant Larson, C147, PMP (Review Committee Chait) Jason Questor (Fito, Graphics Team Lead) Laura Paton, MBA, CHAP, PMP (Project Manager) a2 Content Contributors {he following inividvals contributed addition content used in this revision Tony Alderson Monica fan James Baird CCheeifa Mansoura Laman, PRD. Jake Calabrese, BAP Karen ite ace C.Chaalhourne PMP, PMP Laura Markey Karon Chandler Richard Martin {arrolyn Chang Gitisn SoCtesey Hichaed Fos, CAP Willan 6. sureay Roseruury Hossenlopp gle Pers, CBAP Peter Gordon, CBA Dovid Wright | len Gottesdienee “The Graphics Team developed graphics and graphics standards Carl Gosselin Patric Sendino Perey Melo, CHAD, PMP. Maga Yang ‘lesundre Romanov Version 20 ako includes conten! developed or previous versions ofthe #ABOK’ GuideVersion 2.0 a3 ca Expert Advisory and Review Group, the following inlustry experts generously proved 184" sith adviceand guldance on ‘hescope und content of version 20 of the BABOK” Gude duringts planning and devel- ‘opment, and helped to shape the content and direction af this release Scott Armble Kent J MeDonald James Baird Mark MeGrogor Kurt Bitter Melle PageTones Rafael Dorantes Jmes Robertson Robin F Golds, D Susanne Robertson len Gottentienee onal Rows Paul Haron David Ruble Dean Lelfingyel Steve Tockey Gindys 8% tam Practitioner Reviewers Te fllowing invidvalsparticipate inthe practitioner review of version 20, and provided focdback used in the revision ofthe Publi Review Draft: Sharon M. Aker Barbara Koenig Welty, Baker CAP Stoven Koss, MA B.D. Barnes PhD, PE, PMP.CSSBB Douglas Kowaleayh Jennifer. Battan, CAP Robert Lam, 1S? Subtahmanys Gupta Boda Richard Larwon, CBAR PMP rig W. Brown, MPM, CSM Karen Little, CHAD Cathy Brunsting Joy Mathhows Peter Barg, PMP ery MeLeud, CBAP, PM (Greg Busby. CHAP Holly M, Meyer ‘Diana Cagle, MBA, CBAP Michael Mohammed Bruce Chadbourne, PgMP, PMP Nancy A. Murphy, EMP CRAP CCaroliyan Chao Blchard L Neighbanser,CSQA,CSQE. Patricia Chappell CBAP. MBA Tony Nowpon, CRAP Mark Cheek, PP Samia Osan VuuotLing Cg, BAP Cecilia Raiacell Desde Purvis (nde Chu, CBAP Swaanna Etheridge Rawlins POP Pauline Chang Helen tonnenborsh Jeseph Da Sie ZoyaRoythlat [Nitza Dovengpike Christopher iba James Downe. Ph.D. PMP Jalan Soy Tame: Ekfous),CISA,PRINCE2.ITIL Keith Saree, (BAP Steve Flank, BSe, Com ions) [enra Schlelcher Margaret Gain Living, MBA, CBAP Fred Seip Stephanie Garwood, CRAP Thomas Slahetha, CBA TooGass Warren Steger Rwy Gyast Jes St Seek Dob ile, PMP bun Tucker Die Johnson, CAP Krishna Vishwanath eter Johnson, CBAD A.S.Umashankar Tans Jonasson, CBAP, PMP (i ete ins Aina ad of aired“Te following ndvkdags also served as review team leads > Cathy Beunsting > Patric Chappell CRAP, MIA > Stephane Garwood, CBAP > ober Lam, MBA. ISP cas Other Significant Contributors ‘The following HBA volunteersand staff contributed Meas and support daring the plan ring, development process and release of this version > Kathleen Hareet, President and CEO > Angela Barrington-Foote, Chair Role Delineation Committe (Posen!) Suzanne Bertsch, Certification Manager + Michael Gladstone, NE, Vice Presiden, Certification > Sandra Micale Programm Manager > Indy Mitra, Seeretary and Head of Operutanal Compliance > Cleve Plfant, Chat, ole stineation Co tee (Forme) Lynda Sydney, Head of Communteathons > Katlo Wise. Gaphle Design cas Additional Thanks MBA’ and the Bady of Knowledge Committee would tke to thank all those pracitonens of business analysis how have provided us with comments and feedback ver the years aswell as those who provided us with feedback on the Public Revie Deaf 2 Version 1.6 C24 Body of Knowledge Committee > Kothleon Barret (Peeskdnt) > Kevin enon, CAF, PML (Vie Presiden, Bndyof Knowledge (at time of plies ton) and Chair, Requitemenis Analysis & Documentation and BA Fundamentals Sinb:cemmittes) Barbara Carkenord, MIA, CHAP (Chair, Requizements Communication Sub-com- ‘mittee and Solation Assessment and Validation Sub-committee) ments Elicitation Sub-carmmiee) Kathleen Bass: PMP (Chair, Enterprise Analysis Sub -couittec) a aD Es> Brenda Kerton(Chaieporson, Body of Knowledge Committe uring developenont) > Elzabeth Larson, CBAP, PMID (Co-chalt, BOK Review Sub-committee) > Michand Larvon, CBAR PMP (Co-chais BOK Review Sub-committee) > Due Olver (Chott, Requirements Planning & Management Sub-commitie) > Cleve Plant (Member Acereditation liaison to Body of Knowledge Committe) Contributors to Version 1.6 any Alderson ny Ba Nei Buston Koren Chander Richard Fox, CHAP Resemary Hensenfopp Peter Gordon, CBA Monica fain Peter Koves | Chris Matte Lawes Markey Reviewers of Version 1.6 Sharon Aker Betty Baker, CHAP. JoBenvett Cathy Brunsting Carcllynn Chang, CHAP Patricia Chappell, CRAP MBA, Pauline Chang, Joseph R.Caaracekt Stephanie Garwood, CRAP May)im, CRAP Pay knee arb Koenig Robert Las Cherfa Munsoura Liamant, PLD. alvin Martin Richard Martin Rosina Mete William Mucroy arish Pathe Kathleen Person Touy Rice Johasiatee Mark Tracy Jacqueline Young Gittan MeCleary Kelly Pieota Howard Podesira ste Ponder Cecilia Rath ei jek Keith Sarre, CBAP Jesslea Gonzalez Soll sim Subach Diane Talbot Krishna Vishwanath Marilyn Vout Seott WittUt URS UE MELT a ene Bd | DA Overview Version 2.0 of the BABOK" Guide is extensively revised, restructured, and rewritten by ‘comparison to version 1.6. This appendix providesa overview of where topics covered in version 1.6 may be found in version 2.0. Ihis summary is not a complete description ofthe changes, and in some cases the scope of a task or technique has changed signifi- cantly ata lower level D2 Enterprise Analysis ‘The tasks Define Business Need (5.1) and Assess Capability Gaps (5.2) have no direct equivalent in 1.6. eee eee Creating and Maintaining the Business Architecture (2.2) | Not directly addressed in version 2.0.Business analysis at the enterprise-wide or strategic level will be ad dressed ina separate application area extension. Conducting Feasibility Stucies (2.3) Determine Solution Approach (5.3) See aiso Chapter 9:Techniques for some of the refer enced techniques. Determining Project Scope (2.4) Determine Solution Scope (5.4). The project manage- ment content in this task has been removed. See ‘also Chapter 9: Techniques for some ofthe referenced techniques. Preparing the Business Case (25) Define Business Case (5.5) See also Chapter 9: Techniques for some of the refer- enced techniques. ‘Conducting the initial Risk Assessment (26) Define Business Case (5.5) Fisk Analysis (9.24) Preparing the Decision Package (2.7) Package Requirements (4.4) Communicate Requirement (4.5) “Selecting and Prioritizing Projects (22) Not directly addressed in version 2.0. Business analysis at the enterprise-wide or strategic level will be ad Gressed in a separate application area extension. “Launching New Projects (23) No directly equivaient task ‘Managing Projects forValue (2.10) Define Business Case (5.5) Inversion 20, thereare no separate tasks for re-evaluating or updating work done by another task. These situations are treated as another instance of the original task Tracking Project Benefits (2.11) Evaluate Solution Performance (77)Requirements Planning anéManape met D3. Requirements Planning and Management This Knowledge Area underwent consierable revision, Iwas determined that iat Aemplad to eover thre distinct Lopes » Management of toam of business analysts, which was determined ofall onside thescopeat busines anal ise > Management of requirements, which was moved tothe Aaqurements Management ‘an Communication Krovledge Are > Planning and managing th exceution of business analysis ativites which was moved to the fusinevs Analyte Planaing and Monitoring Knuswledge Are, The tash Plan Requirements Maregement Process inns ‘Understand Team Rok forthe Pict (3.2) 1) hay no direct equivalent in 6. eee Condvtiokeholdey Analysis 22) The vetsion 20 ask 's explo mite to analyzing roles and responsi nesin react stakehelderptcpaton a Business nals atts See alco Document Ana's (99). Iter (14) and Survey Ouesvonnate (9.1) foe eens described inehistaek Define Business Anaya Won Dison Satay BS No eoulvaletin 20 Define Acaureronts 5k Approach 4) No cract equivalent ack ke are denied through eleeationatiaties and ean be communt {ated and managed See techniques Prblem hacking (820) and Rk Analysis (826, Demi Planing Conaderaors BS) Plan Susie nays Appa Seber Requrements Actes G6) Plan susiness nays Actes (2.3) Section 363 Earrespends to lan sins Anos Communication (eat. Frimateeguiements ves BT) Plan Business hays Aces (23) ad Exaion (310 Manage Requrmeni Seopa = Esablnb Requirements Boene BA) Manage Satin Soper egreien (1) Site Requverents for Neveabity G2) ‘Manage Requirement aceobiiy () Tian pacts o Eero Stems aor her Arecsolthe jet 83) Assess Oroniznova ead est (73) Tent Scope Change Resulting fom Ragan {Change Change Wanazemen’ (38) (Wana Slalon Scope ard Regureer ED) Fintan Scope Anerowal 3.85) 7 ange Scan Scape nd queens) Measure and Reporton RegulrenensAcivy GS) Manage susiness Analy esfamance 5). The ds ‘sion of ments inthe version 20 ak i explicy lmvted to mets for Busines anaes acter and deliverables Manage Reairemeris Change 10) Mana Selon Scape and Reaweraerts (i ete ins Aina ad of airedS ersuncunctentrnts | ie a Da Requirements Elicitation The nami ofthis Knowledge Aree was changed to Elitaton. Ga ener Efi Requreents (2.2) Prepare orEfctavon GL. Condit Ebitton Actity 220 Documentation fests 33) Contin Eaton Rese Tanioming Best Daaiment Anais Decent aes rece xi vpn trae 35 iirc dt reve tens 31 obser ctor Obrstan Prong) song 21 Reiners Morag ED eqn ns Weshop evens aera Netnddedin 20 se venom 12 Suny uestonnte Ds Requirements Analysis and Documentation The aaneof this Knowle Area vas changed eyirmens Ana Piri egerements (1) has' direct equivalent LS. ees Geen ‘Stature Requrements Packages 52) Te pup ft moc es 0 most dovaly to Functional Decomposition 12 Create Busnes: Daman Node) ‘iganize Requirements 2) and Spec and weds Requirements) Analy erage Ea ‘Organize Requirements ah and Spec nd Nadel Reauiements ‘nals FunctonalRequrement ES) ‘Organize Requirement ba) and Speci and Node) Requvements 63) “analy Qa oe Requrenen®s EH) ‘Onarze Requirements) Spec and Model equ er efter Sm Determine sumptions and consvants 5 Detne Asimpions and Conroe Determine Regurement Arioctes EAL Deterining which atibutes re wsedis covered an Requtemens Banagervent Process 4 Capt Ing atubutes fora particular requrementis covered in pac and Mode eouements Document Reguiemen Pigpae Requement aekage a) adore Requires 5.10) alate Requiremens 6 aE aD eSRequirements Anois ond ocamentaion ieee Ven Require mens 5.1 econ Vert Requrements 5) Doe and Behovor Modes IL No ecuvalet ort grouping Many of re naa ual techniques ae presenti vsion 20s described ben: Bonar es = Runes hele Anais es Medel 123) 7 Oat edeng BL eR Mate 5.383) Not deseribedin version 20. = Data Diionay 5123 Data Dicbonary and Goss ata Transformation nd Wapping (12S) 7 Define Fanson Reyulemens Bay Ely Releonship Dogan 2.8) Dera Nedeing 22 Oats Moding 24 Pree Fw Model S13) No caulvalet or ths grouping, Hany of re nai Ualtechiquesare peesentin vasion 20. ascribed eon Ac Oia EL + Process Modeling I Data Flow Bagram 5.133) ta low Dragan 5) ‘rentienticaton 5.13 Not described inversion 20. Events are described inelspentoa number of other techniques and tay be neds a fr Scape Mode 12271 = Fowehart 53a = Process Modeling 82 = Sequence agra 5155) sequence Dagrams 9.25) Sint Machine ogra TT = State Dagens 9203 7 Werkow Models. 7 Prez Modeling 2 age Nedels 14) Nl ecuialentor ths grouping, Many oF reine laltechniques are presenti version 2s described below = Peeypine Ss = peop. = Stnnioareeeen ws la = Propping 8225 7 se Ce Destin 5183) 7 Seenaios ne Ue Caves 9) + Wie Case ogram S188, Seeranos nd he Cases 9.6), Use cave grams may lobe used ft Scope oceeg 2.22. > Gir erie Designs BAS) = Protnping 7 Userrates 5.56) [No direct equvatentin 20, Ths technique would fall within Conair stake ker nhs 22 7 WerSones aTa 7 er Storer (i ete ins Aina ad of airedSummary of Changes from Version 1.6 Requirements Communication D6 Requirements Communication This Knowledge Area was combined with requirements management tasks moved from Requirements Planning and Management into Requirements Management and Comntu- nication.'the task Maintain Requirements for Re-use (43) has no direct equivalent in Lo. emacs Bare ‘Create a Requirements Communication Pian (6.2 Plan Business Analysis Communication (2.4) ‘Manage Requirements Conflicts (6.3) ‘Manage Solution Scope and Requirements (4. Determine Appropriate Requirements Format (64) Plan Business Analysis Communication (2.8) and Pre- pare Requirements Package (4.4) Create aRequirements Package (6.5) Prepare Requirements Package (44) ‘Conducta Requirements Presentation (6.5) Communicate Requirements 4.5) Conducta Formaifequirements Review (6.2) Structured Walkthrough (9.30) Obtain Requirements Signoff 6B) ‘Manage Solution Scope and Requirements (4.1) DZ Solution Assessment and Validation Ihe text for these tasks was incomplete at the time version L& was published. ‘the t 2.dusea very different conceptual structure and therefore the tasks can only {very approximate fashion. ks Eien Eira Develop Altemate Solutions 7.2 Allocate Requirements (2.2) Evaluate Technology Options (73 ‘Assess Proposed Solution 7D Facilitate the Selection of aSolution 7.4) ‘Assess Proposed Solution (7.1) Ensure the Usability ofthe Solution (2.5) Validete Solution (25) Support the Quaily Assurance Process (28) Validete Solution (25) ‘Support the Implementation ofthe Solution 2. Define Transition Requirements A) ‘Communicate Solution impacts (7.8) ‘Assess Organizational Readiness 3) Post Implementation Review and Assessment (7.9) ‘Manage Business Analysis Performance (2.5) and Evalu- ‘ate Solution Performance (7.6) Ds Underlying Fundamentals No content had been created for this section at the time that version 1.6 was published. This Knowledge Area broadly equates to the Underlying Competencies n version 2.0. but the individual topics are structured very differently. BABOK* Guide, Version 2.0 nowledge Area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NBA International Institute of Business Analysis a A Guide to the Business Analysis Body of Knowledge’ (BABORK’ Guide) Version 2.0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