Certified Foundation Level Business Analyst (CFLBA) Syllabus

Transcription

1 (CFLBA) Syllabus Versin December 2013 Internatinal Qualificatins Bard fr Business Analysis

2 Cpyright Ntice This dcument may be cpied in its entirety, r extracts made, if the surce is acknwledged. Cpyright Ntice (hereinafter called IQBBA ) IQBBA is a registered trademark f gasq Service GmbH. Cpyright 2011 the authrs fr the versin 10 December 2013 (Karlina Zmitrwicz (chair), Alexey Alexandrv, Alan Calder, Eric Riu du Csquer, Maureen Denning, Michał Figarski, Werner Henschelchen, Alexey Lemeshev, Beata Karpińska, Judy McKay, Ingvar Nrdström, Alain Ribault, Dariusz Paczewski, Dmitry Parilv, Yves Suvenir, Rbert Treffny) All rights reserved. The authrs hereby transfer the cpyright t the Internatinal Qualificatins Bard fr Business Analysis (IQBBA). The authrs (as current cpyright hlders) and IQBBA (as the future cpyright hlder) have agreed t the fllwing cnditins f use: 1) Any individual r training cmpany may use this syllabus as the basis fr a training curse if the authrs and the IQBBA are acknwledged as the surce and cpyright wners f the syllabus and prvided that any advertisement f such a training curse may mentin the syllabus nly after submissin fr fficial accreditatin f the training materials t an IQBBA-recgnized Natinal Bard. 2) Any individual r grup f individuals may use this syllabus as the basis fr articles, bks, r ther derivative writings if the authrs and the IQBBA are acknwledged as the surce and cpyright wners f the syllabus. 3) Any IQBBA-recgnized Natinal Bard may translate this syllabus and license the syllabus (r its translatin) t ther parties. Versin 2013 Page 2 f December 2013

3 Revisin Histry Versin Date Remarks First versin f the Certified Fundatin Level Business Analyst Syllabus Updated first versin f the Certified Fundatin Level Business Analyst Syllabus Versin 2013 Page 3 f 105

4 Table f Cntents Acknwledgements... 5 Intrductin t this Syllabus... 5 Purpse f this Dcument... 5 Examinatin... 5 Accreditatin... 5 Internatinality... 5 Knwledge (K) Levels... 6 Level f Detail... 6 Hw this Syllabus is Organized Fundamentals f Business Analysis (K2) Enterprise Analysis (K3) Business Analysis Prcess Planning (K3) Elicitatin (K3) Requirements Analysis (K3) Slutin Validatin (K3) Tls and Techniques (K3) Cmpetencies (K2) Prcess Imprvement (K2) Innvatin, Design and the Custmer (K2) References Standards Bks and Other Publicatins Appendix A Learning Objectives/Cgnitive Level f Knwledge Level 1: Remember (K1) Level 2: Understand (K2) Level 3: Apply (K3) Appendix B Rules Applied t the IQBBA Fundatin Syllabus References Surces f Infrmatin Appendix C Ntice t Training Prviders Index Versin 2013 Page 4 f 105

5 Acknwledgements Internatinal Qualificatins Bard fr Business Analysis Wrking Party Fundatin Level (Editin 2011): Karlina Zmitrwicz (chair), Alexey Alexandrv, Alan Calder, Eric Riu du Csquer, Maureen Denning, Michał Figarski, Werner Henschelchen, Alexey Lemeshev, Beata Karpińska, Judy McKay, Ingvar Nrdström, Alain Ribault, Dariusz Paczewski, Dmitry Parilv, Yves Suvenir, Rbert Treffny) and all Natinal Bards fr the suggestins fr the current versin f the syllabus. Intrductin t this Syllabus Purpse f this Dcument This syllabus defines the basic level (Fundatin Level) f the training prgram t becme an IQBBA Certified Fundatin Level Business Analyst (CFLBA). IQBBA develped this syllabus in cperatin with the Glbal Assciatin fr Sftware Quality (GASQ). The syllabus serves as a fundatin fr training prviders wh are seeking accreditatin. All areas f this syllabus must be incrprated in the training dcuments. The syllabus shuld, hwever, als serve as the guideline fr preparing fr certificatin. All the areas listed here are relevant fr the examinatin. Examinatin The examinatin t becme a Certified Fundatin Level Business Analyst is based n this syllabus. All sectins f this syllabus are subject t examinatin. The examinatin questins are nt necessarily cnfined t an individual sectin. A questin may refer t infrmatin in several sectins. The frmat f the examinatin is single chice (ne crrect answer ut f fur ptins). Examinatins can be taken after having attended accredited curses, r in an pen examinatin withut a previus curse. Yu will find detailed infrmatin regarding examinatin times n the GASQ website ( and n IQBBA website ( Accreditatin Prviders f an IQBBA Certified Fundatin Level Business Analyst curse must be accredited. IQBBA accreditatin is granted after an expert panel reviews the training prvider's dcumentatin. An accredited curse is ne that is determined t cnfrm t the syllabus. When an accredited curse is given, an fficial Certified Fundatin Level Business Analyst examinatin (CFLBA exam) may be administered. An exam may als be administered by an independent certificatin institute (accrding t ISO rules). Internatinality This syllabus was develped by a grup f internatinal experts. Versin 2013 Page 5 f 105

6 The cntent f this syllabus can therefre be seen as an internatinal standard. The syllabus makes it pssible t train and cnduct examinatins internatinally at the same level. Knwledge (K) Levels The syllabus has been divided int three different Knwledge (K) levels. This divisin enables the candidate t recgnize the "knwledge level" that is required fr each tpic. The three K-levels used in the current syllabus are: K1 - remember, recgnize, recall K2 - understand, explain, give reasns, cmpare, classify, summarize K3 - apply in a specific cntext Level f Detail The level f detail in this syllabus allws internatinally cnsistent teaching and examinatin. In rder t achieve this gal, the syllabus cnsists f the fllwing items: General instructinal bjectives that describe the intentin f the Fundatin Level certificatin. A list f infrmatin t teach that includes a descriptin and references t additinal surces if required. Learning bjectives fr each knwledge area that describe the cgnitive learning utcme, and the mindset t be achieved. A list f terms that students must be able t recall and understand. A descriptin f the key cncepts t teach that includes surces such as accepted literature r standards. The syllabus cntent is nt a descriptin f the entire knwledge area f Business Analysis; it des reflect the level f detail t be cvered in Fundatin Level training curses. Hw this Syllabus is Organized The syllabus cntains ten majr chapters. The tp-level heading f each chapter shws the highest level f the learning bjectives that is cvered within the chapter, and specifies the minimum time t be spent fr training in the chapter. Versin 2013 Page 6 f 105

7 1. Fundamentals f Business Analysis (K2) 100 minutes Terms: Artifact, business analysis, business analyst, requirement, requirements classificatin, requirements types, standard, traceability Learning Objectives fr Fundamentals f Business Analysis The fllwing bjectives identify what yu will be able t d after the cmpletin f each mdule. 1.1 Why is Business Analysis Necessary (K2) LO LO Describe, with examples, the way in which missing r incmplete Business Analysis can result in failure f a prject. (K2) Explain why Business Analysis is necessary by prviding examples. (K2) 1.2 What is Business Analysis (K2) LO LO LO LO Define Business Analysis and Business Analyst. (K1) Recall the cmmn bjectives f Business Analysis. (K1) Prvide examples f the Business Analysis bjectives, in the different phases f the sftware life cycle. (K2) Recall the relatinship t the slutins life cycle. (K1) 1.3 Cre Cncepts f Business Analysis (K2) LO Explain the cre cncepts in Business Analysis. (K2) 1.4 Knwledge Areas (K1) LO Recall the knwledge areas in Business Analysis. (K1) 1.5 Tasks and Respnsibilities (K2) LO LO Recall the majr tasks f a Business Analyst. (K1) Explain the rle and respnsibilities f a Business Analyst in the different phases f the prject. (K2) Versin 2013 Page 7 f 105

8 1.1. Why is Business Analysis Necessary? (K2) 20 minutes Sectin Learning Objectives Prblems with requirements can cause prjects t fail. In mst cases thse prblems are caused by pr r incrrectly cnducted Business Analysis (especially Requirements Engineering, a part f the Business Analysis knwledge area). Cmmn pitfalls in Business Analysis include (K2): Ambiguus, under-specified, unclear, impssible, cntradictry business requirements Instability f the requirements (frequent and uncntrlled changes in requirements) Pr translatin f the business needs t requirements (incmplete, incnsistent, r nt measurable requirements) Unclear bjectives f the initiative Cmmunicatin prblems Language barriers Knwledge barriers Vague wrding Overly frmal wrding Redundancy Gld plating (adding unnecessary scpe) Insufficient user invlvement Overlked user classes Minimal specificatin The abve issues may result in prblems later, during scpe definitin, planning, implementatin and testing. Unclear requirements, r lw quality business design f the slutin, can lead t cnfusin and questins regarding the intended sftware prduct r prcess slutin. If n actins are taken t crrect this state, the risk f the prject s failure increases. The impact f imprper Business Analysis n the prject is already knwn, but still very ften neglected. The majr reasns fr neglecting Business Analysis are (K2): Time pressure Exclusive fcus n fast results Exclusive fixatin n csts Perceiving dcumentatin r the analysis and understanding f the business prcesses within an rganizatin as a cst, nt an added value Pssible cnsequences f neglecting Business Analysis (K2) are: Sme business prcesses within an rganizatin are nt knwn r understd, which may cause the fllwing effects: Versin 2013 Page 8 f 105

9 Requirements are imprecise Requirements are ambiguus (can be interpreted differently) Requirements are cntradictry Requirements d nt fulfill the agreed criteria (i.e., quality criteria) Requirements are missing Business prcesses and artifacts are nt cvered by requirements r are described incmpletely. All stakehlders are nt identified. Business gals r needs are nt identified causing the designed slutin t fail t meet the rganizatin s needs and nt achieve the business gals. Versin 2013 Page 9 f 105

10 1.2. What is Business Analysis? (K2) 20 minutes Sectin Learning Objectives Business Analysis (K1) Business Analysis is the set f tasks, knwledge, tls and techniques required t identify business needs and determine slutins t business prblems [BABOK]. Slutins may include: Develpment f sftware systems Develpment f sftware cmpnents Extensins f existing sftware Imprvements t the business prcess Changes t the rganizatin Business Analyst (K1) A Business Analyst (BA) is a persn respnsible fr identifying the business needs f the custmer (external r internal) and ther stakehlders and fr determining slutins t business prblems [BABOK]. Specific activities f the Business Analyst include identifying, analyzing, develping and managing the requirements. It is imprtant t remember that a Business Analyst is nt respnsible fr determining the slutin implementatin (creating the prduct s design). The slutin implementatin is a result frm the infrmatin prvided by the Business Analyst s wrk but it is nt a BA rle t determine the slutin implementatin. Implementatin ften includes sftware develpment, but may als cnsist f prcess imprvements r rganizatinal changes. The Business Analyst acts as a bridge between the custmer and ther stakehlders (e.g., the prject team), identifying, negtiating and achieving a cnsensus between the needs f the varius representative individuals and grups Cmmn Objectives f Business Analysis (K1) Cmmn bjectives f Business Analysis are the fllwing: Cllect and dcument the requirements (business level) Design business slutins t reslve the business prblems Assist in the timely cmpletin f the prject by prviding accurate requirements identificatin and analysis Imprve efficiency by increasing the quality f requirements identificatin and analysis and therefre reducing the need fr rewrk and fixes in the later stages f the prject Versin 2013 Page 10 f 105

11 Business Analysis in Different Phases f the Sftware Life Cycle (K2) Business Analysis n the custmer side (i.e., the recipient f the slutin) begins as sn as a need fr a new slutin appears. On the vendr side (i.e., the creatr f the slutin), Business Analysis is usually initiated by establishing a budget, agreement, assignment r prject. Fr example, when the business requires new r mdified functinality t imprve a business prcess, the first step shuld be an analysis f the needs and requirements. In traditinal appraches, the initial phase f the prject is called the analysis phase. In this phase f the prject the purpse f the Business Analysis prcess may be: Identifying and evaluating the current business prcesses in an rganizatin ( as is analysis) Gathering initial requirements fr the needed business slutin ( t be analysis) Creating and analyzing the business case Cnducting a feasibility study Preparing ideas fr the business slutin During the next phase, the specificatin phase, a Business Analyst is respnsible fr: Identifying and dcumenting business requirements n a mre detailed level Supprting the Systems Analyst in preparing the detailed system specificatins (e.g., cvering such items as data, mapping, integratin issues, user interfaces) Validating the prpsed sftware design with the custmer and ther stakehlders Managing any requirements changes During the next phase, the develpment phase, the tasks f the Business Analyst include: Supprting the develpment team during implementatin (e.g., clarifying issues related t the requirements, validating business rules t be applied in the cde) Validating the evlving slutin accrding t the intended requirements and needs (when pssible) Supprting testers in preparing test cases and test scripts at the business level and validating the resulting wrk prducts Managing any required changes t the requirements (resulting frm detected defects, regulatry r legal changes, needs fr new r extended functinality, etc.) During the testing phase, the rle f Business Analysis may vary. Fr example, during system test, the BA rle may be limited t verifying test results and reslving issues related t defects r gaps in the requirements. During test levels invlving the custmer, BA effrt shuld be increased, and ften includes the fllwing items: Participating in the preparatin f test cases fr User Acceptance Testing Supprting the acceptance testers by answering questins during test executin Versin 2013 Page 11 f 105

12 Relatinship t the Slutins Lifecycle (K1) Different prjects r appraches (t management r prduct develpment) may require prducing requirements in a specific frmat and with different levels f detail. The level f detail, and requirements frmat, may als be determined by the business area and any external regulatry requirements. A Business Analyst must wrk tgether with the prject team, and ther stakehlders, t determine which tasks and techniques defined in the general Business Analysis prcess are apprpriate fr the rganizatin and fr a specific prject. Fr example, Enterprise Analysis will nt be cnducted in every case; in sme prjects the initial requirements and business prcesses within an rganizatin are already knwn and understd. Versin 2013 Page 12 f 105

13 1.3. Cre Cncepts f Business Analysis (K2) 30 minutes Sectin Learning Objectives Business Analyst Rle (K1) A Business Analyst is a liaisn between stakehlders, respnsible fr identificatin, analysis, cmmunicatin and validatin f requirements fr changes t business prcesses, plicies and/r infrmatin systems [BABOK] Business Analyst and Systems Analyst (K2) The Business Analyst is respnsible fr dcumenting and gathering the business requirements. This infrmatin is then prvided t the Systems Analyst, wh is respnsible fr writing technical requirements frm the business requirements. The Systems Analyst rle prvides a bridge between the business requirements and the technical definitin f the IT slutin. The Systems Analyst may be required t be familiar with prgramming technlgies and shuld have knwledge f the existing IT infrastructure t be able t match the planned slutin t the cntext. The tw rles are cmplementary and bth are needed fr a successful IT prject Requirement (K1) A requirement is defined in [IEEE Std ] as: 1. A cnditin r capability needed by a stakehlder t slve a prblem, r achieve an bjective. 2. A cnditin r capability that must be met r pssessed by a system r system cmpnent, t satisfy a cntract, standard, specificatin, r ther frmally impsed dcuments. 3. A dcumented representatin f a cnditin r capability as in 1 r 2. Requirements are the fundatin f systems, r system cmpnents. They can be bligatry (required functins, cnstraints, etc.), essential fr the sftware t perfrm its functins, and meet the expectatins and needs f the intended stakehlders. T ensure clarity, requirements shuld be placed int ne f the fllwing categries: Business requirements User requirements Functinal requirements Nn-functinal requirements The meaning and purpse f requirements is defined as fllws (K2): Prvide a fundatin fr assessment, planning, executin and mnitring f the prject activities Define custmer expectatins (expressed as real requirements and stakehlder s value f thse requirements) Serve as a cmpnent f agreements, rders, prject plans Versin 2013 Page 13 f 105

14 Establish system bundaries, scpe f delivery, and the services classificatin f the requirements [Ebert05] Classificatin f Requirements (K2) Requirements cnsist f prcess requirements and prduct requirements [Ebert05]: Prcess requirements describe needs and limitatins f the business prcesses (e.g., management r prductin prcesses) including csts, marketing, prcessing time, sales and distributin, rganizatin, and dcumentatin. Prduct requirements cnsist f functinal and nn-functinal prduct requirements. Bth can be regarded frm the pint f view f the custmer (external), and frm the pint f view f the vendr team (internal) Types f Requirements (K1) The fllwing is a categrizatin f the types f requirements: Custmer requirements (business requirements) Slutin r system requirements Prduct r cmpnent requirements Requirements Elicitatin (K1) Requirements Elicitatin is the cllectin f activities, appraches, tls and techniques fr capturing the requirements fr a planned sftware system (r ther business slutin) frm the stakehlders [BABOK] Traceability (K2) Traceability is an assciatin that exists between different types f requirements and the fllwing items: Requirements (mapping the higher level requirements that defined the needs and features t the mre detailed requirements) Detailed requirements t design mdels Detailed requirements t test cases (e.g., fr system testing) High level requirements t test cases (e.g., fr acceptance test) Requirements t release/cde branch/versin When dealing with medical cmpliance (e.g., the FDA, the MDD), in mst cases traceability is als used fr determining Risk. Traceability between requirements and ther prject artifacts allws a Business Analyst t ensure all business requirements have been met. Fr the testers and develpers, traceability ensures that the requirements cverage has been achieved. Traceability is als imprtant frm the change management perspective, t determine the impact f a change n the system r prcess. Versin 2013 Page 14 f 105

15 Artifact (K1) Artifacts are either final r intermediate wrk prducts that are prduced and used during a prject. Sme artifacts (fr example use cases and ther UML diagrams, requirements and design dcuments) describe the functin, architecture, and design f sftware. Other artifacts are cncerned with the prcess f develpment itself, such as prject plans, business cases and risk assessments [RUP]. It is necessary t ensure that all artifacts imprtant t the prject are under versin cntrl and crrectly traced t their rigin. Versin 2013 Page 15 f 105

16 1.4. Knwledge Areas (K1) 10 minutes Sectin Learning Objectives Business Analysis cnsists f the fllwing knwledge areas [BABOK].: Enterprise Analysis Requirements Planning and Management Requirements Elicitatin (Identificatin) Requirements Cmmunicatin Requirements Analysis and Dcumentatin Slutin Assessment and Validatin Business Analysis can influence ther areas f the prject. It has a significant impact n prject management (especially scpe and time management) and als t the fllwing areas: Design Business Analysis determines the required business architecture and scpe f the slutin. Develpment The Systems Analyst (wh determines detailed requirement specificatins) uses the Business Analysis t determine what has t be implemented. Testing and ther Quality Assurance activities Prducts f Business and Systems Analysis are a basis fr testing (i.e., the requirements specificatin is a basis fr test case preparatin and executin) and have t be tested themselves (i.e., the requirements specificatin has t be tested fr cnsistency, cmpleteness, and cmpliance with standards). Versin 2013 Page 16 f 105

17 1.5. Tasks and Respnsibilities (K2) 20 minutes Sectin Learning Objectives Majr Tasks (K1) The fllwing are the majr tasks f a Business Analyst [BABOK].: Requirements elicitatin (identificatin) Requirements analysis and mdeling Requirements realizatin planning Requirements cmmunicatin Requirements dcumentatin Requirements validatin Requirements cnfiguratin management Business slutin prpsal Rle f Business Analyst in Different Phases f the Prject (K2) The wrk f a Business Analyst des nt end with cmpletin f the initial analysis and design phases f the prject. A Business Analyst supprts ther activities perfrmed during the next stages f the prject; in fact the BA shuld be invlved during the whle sftware life cycle, including the maintenance phase. The reasns fr this invlvement include: Supprting implementatin wrk in rder t ensure develpers understand and implement the requirements prperly Supprting testing, fr example by validating test cases in rder t ensure that testing will adequately cver all the requirements Analyzing and dcumenting change requests fr the requirements Prcessing new requirements (new regulatins, standards, etc.) Prcessing the requests t fulfill new needs requested by the custmer r user All the issues abve require invlvement f the Business Analyst, and in many cases als the Systems Analyst. Therefre, a Business Analyst supprts the prject frm the beginning thrugh the system deplyment (and smetimes t the system retirement). Versin 2013 Page 17 f 105

18 2. Enterprise Analysis (K3) 150 minutes Terms: Business case, business gal, business needs, business prcess, enterprise analysis, S.M.A.R.T., slutin scpe, stakehlder, stakehlder s value Learning Objectives fr Enterprise Analysis The bjectives identify what yu will be able t d after the cmpletin f each mdule. 2.1 Stakehlder Identificatin and Analysis (K2) LO Explain wh can be a stakehlder in a prject. (K2) LO Explain, with examples, hw stakehlders can be identified. (K2) LO Describe hw the needs f different stakehlders can affect the prduct. (K2) 2.2 Enterprise Analysis - Identifying Business Prcesses (K2) LO LO LO LO Recall what Enterprise Analysis is and why it is necessary. (K1) Recall the definitin f a business prcess. (K1) Explain, with examples, the reasns why identificatin f business prcesses is necessary. (K2) Explain the techniques fr identifying business prcesses. (K2) 2.3 Business Needs and Gal Definitin (K3) LO Recall what business needs and gals are. (K1) LO Explain the basic principles f building prper business gals. (K2) LO Fr a given scenari, identify the business needs and gals. (K3) 2.4 Business Case Definitin (K3) LO Recall what a Business Case is. (K1) LO Explain the basic principles f building a prper Business Case. (K2) LO Explain when the building f a Business Case is necessary. (K2) LO Fr a given scenari, define the Business Case. (K3) Versin 2013 Page 18 f 105

19 2.5 Determining Slutin Scpe and Apprach (K3) LO Explain why determining slutin scpe is necessary. (K2) LO Fr a given scenari, determine the slutin scpe. (K3) Versin 2013 Page 19 f 105

20 2.1. Stakehlder Identificatin and Analysis (K2) 20 minutes Sectin Learning Objectives One f the key activities t be cmpleted when starting wrk n a new system is the identificatin and analysis f the stakehlders. It is imprtant t analyze and understand the system requirements, and t be able t deliver a prpsed design f the business slutin. A Business Analyst shuld, therefre, knw all the individuals and rganizatins affected by the planned slutin and, frm the ther side, thse that will be affecting the slutin Stakehlder (K1) A Stakehlder is any persn invlved in, r with an interest in, a prject. They may be individuals and/r rganizatins actively invlved in the prject, r thse whse interests may be affected as a result f the prject executin r prject cmpletin. Stakehlders may als influence the prject s bjectives and utcmes. Stakehlders cme frm the vendr s rganizatin, the custmer s rganizatin, and frm external parties. Stakehlders n the vendr side (i.e., the rganizatin that will be creating the slutin) may be: Prject Managers Business and System Analysts Develpers and Architects Database designers GUI designers Technical writers Testers and Quality Assurance staff Installatin and Operatins persnnel Stakehlders n the custmer side (i.e., the rganizatin that will receive the slutin) may be: Custmer representatives (i.e., Business ) Prject spnsrs End users (frm the custmer cmpany) Installatin and Operatins persnnel External stakehlders may be: End users wh are nt a part f the custmer s rganizatin (e.g., clients f the custmer) Other rganizatins (e.g., regulatry entities) Stakehlder Identificatin (K2) Stakehlders can be identified using the fllwing techniques: Investigating the business dmain Versin 2013 Page 20 f 105

21 Identifying wners f the business prcesses Analyzing the structure f the custmer s rganizatin Explring the target market f the custmer s rganizatin Analyzing relatinships with external rganizatins (suppliers, etc.) Stakehlders Needs and Expectatins (K2) Different stakehlders may have different needs and expectatins regarding the planned slutin. It is very imprtant t identify all the stakehlders and their needs, and t find a cmmn understanding f the purpse f a slutin, in rder t avid the situatin where the final prduct may meet the requirements f nly a selected grup f stakehlders. It is als imprtant t ensure that the features t be implemented will nt cnflict with the requirement f ther stakehlders. Fr example, a sftware prduct designed nly fr a knwledgeable custmer representative may nt be satisfactry fr the end users since end users may have different needs regarding the sftware, such as a user friendly GUI, intuitive navigatin, and an extended help system. One f the respnsibilities f a Business Analyst is t identify all the stakehlders and define their requirements and expectatins. This prcess is ne f the key activities in the Enterprise Analysis, as it determines the initial scpe and requirements f the system. Hwever, this activity is ften skipped r perfrmed nly partially, usually leading t prblems as the prject prgresses Stakehlder Identificatin Prblems (K2) The main prblems with identifying stakehlders include: A lack f understanding f the real peratrs f the business prcesses in the rganizatin Unclear definitin f respnsibilities within the custmer s rganizatin Excluding stakehlders wh are nt clearly and directly related t the prcess (e.g., the end custmers) Incmplete analysis resulting in missing prcesses and activities, and the related stakehlders Versin 2013 Page 21 f 105

22 2.2. Enterprise Analysis - Identifying Business Prcesses (K2) 30 minutes Sectin Learning Objectives Enterprise Analysis (K1) Enterprise Analysis is defined as the strategic part f the prject lifecycle and an initial phase f Business Analysis [BABOK]. Enterprise Analysis cnsists f the fllwing activities [BABOK]: Determining business pprtunities Develping strategic gals t be achieved by the rganizatin, and a strategic plan fr planning and executing the gals Understanding and develping the business architecture Determining the ptimum prject investment path fr the rganizatin, including implementatin f new business and technical system slutins, as well as prcess r rganizatinal changes Chsing the mst suitable slutin appraches fr prjects, and develping their business cases Initiating prjects, and ensuring they deliver value t the stakehlders In ther wrds, Enterprise Analysis cnsists f the cllectin f pre-prject activities that captures the future view f the business, in rder t prvide cntext t the prject requirements identificatin and slutin design fr a given initiative r fr lng-term strategic planning. In large and cmplex rganizatins, Enterprise Analysis may be cnducted as a stand-alne prject. In smaller nes, Enterprise Analysis is perfrmed by the custmer rganizatin befre invlving the vendr, and the results are prvided t the vendr as part f the initial requirements. In sme cases, Enterprise Analysis is nt cnducted at all, fr example, when the gal f the prject is clear and defined in measurable way. The gal f Enterprise Analysis is t identify and describe business requirements fr the future investments. Thse requirements are defined at a high level as business gals, needs, and expectatins f the rganizatin. It is imprtant fr the Business Analyst t have a cmplete understanding f the strategic gals f the custmer s rganizatin and t ensure new initiatives fit in its lng term strategy r missin. Even if the Business Analyst is nt directly invlved in the Enterprise Analysis activities (as it may be cnducted nly n the custmer side); they shuld have knwledge abut the gals f the rganizatin Enterprise Analysis Activities (K1) The Enterprise Analysis activities include [BABOK]: Identifying business prcesses perfrmed in the rganizatin Creating and maintaining the Business Architecture Cnducting feasibility studies t determine the ptimum business slutin Versin 2013 Page 22 f 105

23 Defining the scpe f the new business pprtunity Preparing the Business Case Cnducting the initial Risk Assessment Preparing the Decisin Package Business Prcesses (K1) A business prcess is a set f activities aimed at prducing a specific utput fr a particular custmer r market. A business prcess fcuses n hw the wrk is dne within an rganizatin, the way f rganizing wrk, activities, relatinships and the dependencies between them. A prcess can be cnsidered as the rdering f wrk activities acrss time and place, with a beginning, an end, and clearly defined inputs and utputs [Sparx]. A business prcess must have the fllwing characteristics [Sparx]: Has a gal Has specific inputs Has specific utputs Uses resurces Has a number f activities that are perfrmed in sme rder Affects at least ne rganizatinal unit Creates value fr the custmer (bth internal and external) Identificatin f current business prcesses perfrmed within the rganizatin, allws the Business Analyst t understand the rganizatin s gals, and als t determine the activities and the flw required t achieve future planned business and strategic gals. This identificatin helps establish all the activities and rles that are respnsible fr the executin f the activities that prduce the desired utputs. Identificatin f business prcesses helps find pssible gaps and ineffective parts f the prcess, which may then be imprved via prcess ptimizatin. If business prcesses are nt established and understd, then the rganizatin may have a lw maturity level, which makes measuring and cntrlling prcesses very difficult. In additin, there are likely t be significant prblems with the definitin f the business gals and needs. Versin 2013 Page 23 f 105

24 2.3. Business Needs and Gals Definitin (K3) 30 minutes Sectin Learning Objectives Business Gal (K1) A Business Gal is a shrt- r lng-term bjective f an rganizatin. Business Gals shuld be characterized by the fllwing qualities [Entrepreneur]: Specificity Optimism Realism Bth shrt- and lng-term scpe The Meaning f Business Gal (K2) Setting Business Gals is imprtant fr the fllwing fur reasns: 1. The rganizatin needs t have a visin f what it wants t accmplish. This is facilitated by having clearly stated gals, alng with establishing time perids in which they need t be achieved. 2. It keeps a clear picture f what the rganizatin is trying t d with the business, and helps fcus mtivatin. 3. It allws the rganizatin t understand and maintain a cmmitment t the business main bjectives. 4. It prvides a metric against which t measure the rganizatin s prgress SMART (K2) SMART is a system and a tl that is used t establish gals and define their quality bjectives. SMART requires that all gals have the fllwing characteristics [G. T, Dran]: S Specific M Measurable A Attainable R Relevant T Timely Business Need (K1) A Business Need describes the business prblem r pprtunity which the Business Analyst must understand and analyze in rder t recmmend apprpriate slutins. It is imprtant t nte that befre a prject starts, the Business Need (understd as a prblem r an pprtunity) and Business Case (understd as csts vs. benefits) are defined, either frmally r infrmally. These definitins shuld be dne t ensure prper prject selectin, and t establish Versin 2013 Page 24 f 105

25 prper pririties fr the prjects that help the rganizatin reach its visin, strategic gals, and business bjectives. The Business Need shuld be defined by the persn r grup requesting the prject, which may include the fllwing persn r grup: Spnsr Steering Cmmittee Regulatry r cmpliance bdy High-level Subject Matter Expert (SME) [Pyzdek, Thmas and Paul A. Keller] Business Analysts are ften supprted by Prject Managers and Prduct Managers in defining Business Needs. Hwever, the results f their wrk are mst effective when they are neutral facilitatrs, nt wners. Prject/Prduct Managers and Business Analysts need t make recmmendatins regarding which prjects the requesting rganizatin shuld undertake t achieve specific business gals, but they shuld nt be the nly decisin-makers; the custmer s invlvement is necessary. Therefre, ne f the respnsibilities f a Business Analyst is t cperate with the persn r grup requesting the prject, including users r prxy users, and t help them articulate the real need Stakehlder Value (K1) Accurately determining stakehlders value is ne f the key factrs f a prject s success. The main gal f a prject always shuld be achieving realized value (als knwn as benefits ) fr the stakehlders. A value can be understd as the benefit we think we get frm smething [Gilb, Cmpetitive Engineering]. Versin 2013 Page 25 f 105

26 2.4. Business Case Definitin (K3) 30 minutes Sectin Learning Objectives A Business Case prvides the reasning fr initiating a prject (i.e., initiative). The case describes a justificatin fr the prject in terms f the value added t the business as a result f the prject utcmes, in cmparisn t the cst f develping the new slutin [BABOK] (K1). Usually, a Business Case is presented in the frm f a structured dcument; hwever, it may be expressed as a shrt argument r presentatin. Fr example, cnsider the case in which a sftware upgrade might imprve system usability; the Business Case here is that better usability wuld imprve custmer satisfactin, require less task prcessing time, r reduce training csts. A Business Case may cver the fllwing tpics: Infrmatin abut the pprtunity (market trends, cmpetitrs) Qualitative and quantitative benefits Estimates f cst and time t breakeven Prfit expectatins Fllw-n pprtunities Cash flw cnsequences f the actin, ver time, and the methds used fr quantifying benefits and csts The impact f the prpsed prject n the business peratins r business prcess The impact f the prpsed prject n the technlgy infrastructure Cnstraints assciated with the prpsed prject Estimated budget Alignment with pririties established by the business Basic Principles f Building a Prper Business Case (K2) Building the Business Case shuld be dne with care. A Business Case must demnstrate that the slutin prpsal has been analyzed prperly, that the full benefits will be realized ver time, and any technical aspects have been thrughly evaluated. Depending n the size and availability f infrmatin, a Business Case shuld cver sme r all f the fllwing tpics [Wikipedia]: Reference Cntext Prject name/reference Backgrund Business bjectives and pprtunities Business pririty Value Prpsitin Versin 2013 Page 26 f 105

27 Desired business utcmes Business benefits (by utcme) Quantified benefits value Csts ROI financial scenaris Risks and csts f nt prceeding Prject risks (t prject, benefits and business) Fcus Prblem/slutin scpe Assumptins Cnstraints Identified and evaluated ptins Size and scale assessment Cmplexity assessment Deliverables Planned prducts and benefits Organizatinal areas impacted (internally and externally) Key stakehlders Dependencies Wrklad Apprach Definitins f phases Prject activities Technical delivery activities Wrklad estimate Prject plan Prject schedule Required resurces Prject leadership team Prject gvernance team Team resurces Funding Cmmitments Prject cntrl Reprting prcesses Deliverables schedule Versin 2013 Page 27 f 105

28 Financial budget and schedule Quality Attributes f a Business Case (K1) The Business Case prcess shuld be characterized by the fllwing qualities [Wikipedia]: Adaptable Adjusted t the size and risk f the prpsal. Cnsistent Every prject addresses the same basic business issues. Business-riented Fcused n the business capabilities and impact. Cmprehensive Cnsiders all factrs relevant t a cmplete evaluatin. Understandable The cntent is clear and lgical. Measurable Key aspects can be quantified. Transparent Key elements can be directly justified. Accuntable Cmmitments fr the delivery f benefits and management f csts are clear Prcedure f Building the Business Case (K1) Building the Business Case is perfrmed in fur steps: Identify and quantify the benefits Identify and quantify the csts Prepare the Business Case Define the prcedures that will be used t measure the csts and benefits Purpse fr Building the Business Case (K2) A prperly built business case allws the rganizatin t [Wikipedia]: Understand and apply a way f thinking that allws decisin makers t analyze the value, risk and pririty f a prject prpsal. Justify the value f the prpsals t the rganizatin and t reject any prpsals that d nt have prven and measurable value. Decide if the prpsal is f value t the business and is achievable in cmparisn t alternative prpsals. Track and measure the prgress and achievements f the business case (helping prper prject management). Ensure that prjects with inter-dependencies are undertaken in the ptimum sequence. A sample Business Case cntains the fllwing elements [BABOK]: 1. Executive summary 2. Intrductin and summary Prject ratinale fr the preferred ptin Current business prcess Versin 2013 Page 28 f 105

29 Descriptin f the prblem Opprtunity Prject bjectives Prject scpe Business benefits Prject csts Assumptins Ptential business and staff impact analysis Ptential technlgy impact analysis Other issues Implementatin plan 3. Apprach Financial metrics Privacy impact assessment (as well as regulatry, legal, etc.) Alternative evaluatin criterin 4. Key selectin criterin Weighting Cnstraints and limitatins 5. Preferred alternative Business benefits Alternative csts Assumptins Ptential business and staff impact analysis Other issues 6. Risk Management Plan Risk assessment Risk respnse Benefit realizatin 7. Cnclusin and recmmendatins Versin 2013 Page 29 f 105

30 2.5. Determining Slutin Scpe and Apprach (K3) 40 minutes Sectin Learning Objectives Defining slutin scpe is a basis fr establishing the scpe f the prject (prject planning), and fr develping further detailed requirements. The cst and time is usually determined by the prject manager. The estimatin is based n the prject scpe r the scpe f the slutin t the prblem (e.g., using functinal decmpsitin f the planned slutin t establish the ttal wrk effrt t be dne within the prject). Planning the scpe f the prject a different way may increase the risk f prject failure by causing any f the fllwing: Delays Budget verruns Incmplete delivery Defining the prject scpe is ne f the respnsibilities f the Business Analyst. Prject scpe is initially defined by the business requirements, and is further detailed during the requirements develpment, which is ne phase f a typical prject develpment life cycle. Slutin scpe may be determined using the fllwing techniques (K2): Wrk Breakdwn Structure (WBS) - a decmpsitin f the wrk that is required t cmplete a prject, and accmplish the business bjectives Prduct Breakdwn Structure (PBS) - a decmpsitin f the cmpnents f the prduct System Interface Analysis - a definitin f the wrk required t integrate the new slutin int the existing business and technical envirnments Versin 2013 Page 30 f 105

31 3. Business Analysis Prcess Planning (K3) 180 minutes Terms: CCB (Change Cntrl Bard), change life cycle, change management, change request, cmmunicatin, cnfiguratin item, cnfiguratin management, requirements engineering prcess Learning Objectives fr Business Analysis Prcess Planning The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 3.1 Business Analysis Cmmunicatin Planning (K2) LO LO LO LO Recall prject rles and activities are affected by the results f Business Analysis activities. (K1) Recall the cmmn Business Analysis deliverables. (K1) Explain why cmmunicatin is an imprtant part f the wrk f a Business Analyst, and define what factrs need t be cnsidered in establishing a cmmunicatin plan. (K2) Describe, with examples, ways f cmmunicating Business Analysis activities and deliverables. (K2) 3.2 Requirements Management Prcess Planning (K2) LO LO LO Describe the prcess f Requirements Management. (K2) Describe the additinal elements t be included in Requirements Management prcess planning. (K2) Describe factrs t be included in planning. (K2) 3.3 Cnfiguratin and Change Management Prcess (K3) LO LO LO LO Explain the cncept f Change Management and Cnfiguratin Management. (K2) Explain the difference between Change and Cnfiguratin Management. (K2) Fr a given scenari, implement a Change Management prcess. (K3) Explain the rle f the CCB. (K2) 3.4 Tls and Techniques Selectin (K1) LO LO Recall the types f tls that can be used t supprt Business Analysis activities. (K1) Recall the cmmn Business Analysis techniques. (K1) Versin 2013 Page 31 f 105

32 3.1. Business Analysis Cmmunicatin Planning (K2) 50 minutes Sectin Learning Objectives Business Analysis is the starting pint fr designing and implementing a sftware slutin. Its deliverables are inputs t many ther prject phases and prcesses, such as establishing the system architecture that will allw meeting the business gals, creating detailed functinal and nnfunctinal system specificatins, and planning and executing QA activities. Outputs frm the Business Analysis are als inputs t system acceptance testing, which is the final check befre the prductin release. System acceptance testing is cnducted t verify that the sftware is wrking as expected, and is needed in rder t realize its gals (i.e., imprving efficiency f perfrming the business prcess). Business Analysis prvides infrmatin t the fllwing prcesses: Prject management (scpe planning, scheduling, and estimating develpment and testing) Systems analysis Design (system specificatin and architecture) Implementatin Testing The fllwing rles are affected by the results f Business Analysis activities: Prject manager (cntrlling the prject schedule and scpe) System analysts and develpers (planning and designing the implementatin) Architects (planning the system architecture, integratin, etc.) QA staff Testers Business Analysis Deliverables (K1) The mst imprtant deliverables f the Business Analysis phase are: Business requirements A list f the stakehlders f the prject Limitatins and assumptins Business prcess flw definitin Definitin f business prcess prducts The main purpse f planning the Business Analysis cmmunicatin is t define hw t receive, distribute, access, update and escalate infrmatin t and frm the prject stakehlders, as well as hw t rganize the schedule and structure f the cmmunicatin within a prject. Business Analysis activities and deliverables can be cmmunicated in bth frmal and infrmal ways. Cmmn methds f cmmunicatin include: Wrkshps Versin 2013 Page 32 f 105

33 Presentatins (frmal r infrmal) Reviews (frmal r infrmal) Any cmmunicatin activity shuld take int cnsideratin the fcus f the cmmunicatin (e.g., needs, infrmatin, and cnsequences). Having this infrmatin, the Business Analyst can decide what the apprpriate delivery methd is, the apprpriate audience, and hw t present the infrmatin. Fr each cmmunicatin, the Business Analyst must decide the mst effective frm f cmmunicatin fr bth the tpic and the stakehlder Factrs t be Cnsidered in Planning (K2) There are many different factrs which shuld be cnsidered when planning Business Analysis cmmunicatin. These factrs include: Type f prject Cmmunicatin frmality Cmmunicatin frequency Gegraphical lcatin Culture Different types f prjects require varying amunts f dcumentatin, and ften have diverse prcesses and different deliverables. Cmmunicatin frmality varies between prjects, prject phases and stakehlders. Cmmunicatin tends t be mre frmal when the prject is large, r its dmain is cmplex, r the prject itself is cnsidered t be critical r strategic, r dependent n legislatin, sectr standards, r agreements. Sme stakehlders may require frmal cmmunicatin regardless f the prject type. Cmmunicatin frequency may vary amng stakehlders fr every frm f cmmunicatin. Gegraphic disparity can als be a factr that limits cmmunicatin pssibilities, especially when stakehlders live in different time znes. Versin 2013 Page 33 f 105

34 3.2. Requirements Management Prcess Planning (K2) 70 minutes Sectin Learning Objectives This step is t define the apprpriate Requirements Engineering strategy, including planning and estimatin f the wrk fr a specific prject r rganizatin. This strategy determines the main activities and rles used in the prcess. It als includes defining the prcess f handling Change Requests (described in the next chapter) The Requirements Management Prcess (K2) The mst imprtant inputs fr the Requirements Management prcess phase are [BABOK]: Business Analysis apprach Business Analysis plan Organizatinal prcess assets The Business Analysis apprach is the verall apprach used by the rganizatin t derive the Business Analysis prcesses, and may include a definitin f the Requirements Management prcess. The Business Analysis plan defines what deliverables (i.e., the requirements specificatin fr a selected area f the slutin) will be prduced and when. The rganizatinal prcess assets are a set f standard templates r guidelines fr the prcesses existing in the rganizatin. These assets may greatly affect the prcess f requirements management. The prcess f Requirements Management is a nn-cre prcess (nt a key activity adding primary value t an utput), which affects all disciplines f systems develpment including (K2): Identificatin f requirements (recrding) Analysis f requirements Specificatin f requirements (dcumenting) Changes f requirements (tracking and updating) Quality assurance (ensuring adherence t prcess) One f the imprtant parts f Requirements Management is the cmmunicatin planning, particularly regarding change management and tracking. The main factrs included in these activities are (K2): Organizatinal culture Organizatinal standards Stakehlder preference Cmplexity (f prduct, prject) Organizatinal maturity Versin 2013 Page 34 f 105

35 Organizatinal culture has t be cnsidered when determining the frmality f cmmunicatin. There is a risk that cmmunicatin that is t infrmal may be a threat t prject success when agreements are nt adequately dcumented and nt cmmunicated well t all stakehlders. Likewise, cmmunicatin that is verly frmal may impede the efficient flw f infrmatin. Frmality f cmmunicatin can als be a chice f individual stakehlders. Sme f them require mre frmal cmmunicatin, while thers cnsider frmal dcumentatin as an unnecessary verhead Additinal Aspects f Requirements Management (K2) The Requirements Management prcess shuld als include prvisins fr methds f string, tracking, and updating requirements. A repsitry shuld be used t stre all requirements and their respective status. The state f each requirement shuld be tracked in this repsitry (e.g., under develpment, under review, apprved, changed). The repsitry can be a single tl r a set f tls (e.g., wrd prcessrs, diagram designers, wikis, management tls). Fr better effectiveness the repsitry shuld have a prper wrkflw fr the requirements as they mve thrugh the life cycle. Apprpriate stakehlders shuld be able t add, delete, update r view a requirement. A Business Analyst must define a prcess fr tracing requirements frm their surce. This prcess has t be tailred t the cmplexity f the prject dmain, the stakehlder s needs, the ptential risks, and the available resurces. Each requirement shuld be assigned attributes. Custm requirement attributes allw the Business Analyst t include mre detailed classificatin infrmatin fr the requirements, and allws reprting and analysis based n thse attributes. The attributes need t be planned and defined in the Requirements Elicitatin phase. Nt all requirements are equal in imprtance t the stakehlders, and they d nt have the same value fr prject success. Pririty, as a factr f imprtance and impact, shuld be determined by the Business Analyst, alng with the prper stakehlders, during the Requirements Elicitatin phase. This pririty may be updated thrughut the life f the prject as new infrmatin surfaces. A frmal Change Management prcess is als required fr the requirements. Change Management is a prcess designed t track, identify and manage changes. Refer t Cnfiguratin and Change Management Prcess (K3). Versin 2013 Page 35 f 105

36 3.3. Cnfiguratin and Change Management Prcess (K3) 60 minutes Sectin Learning Objectives T ensure prper Requirements Management, a Cnfiguratin Management prcess must be implemented. In many cases requirements are nt stable, and the subsequent changes may affect ther related prject artifacts. The Business Analyst must manage changes in the requirements, and ensure that all affected items have been prperly adjusted. The apprach fr reslving such issues must als be included in the Business Analysis prcess planning Cnfiguratin Management (K1) Cnfiguratin Management is a discipline that applies technical and administrative tls and techniques fr the fllwing reasns: Identify and dcument the functinal and physical characteristics f a cnfiguratin item Cntrl changes t thse characteristics Recrd and reprt change prcessing and implementatin status Verify cmpliance with specified requirements [IEEE 610] A Cnfiguratin Item is an artifact, dcument, prduct (hardware and/r sftware) that has an enduser purpse and is treated as a single entity in the Cnfiguratin Management Prcess. [after IEEE 610] (K1) In Business Analysis, cnfiguratin items include: Single requirements Business needs Requirements specificatins Business cases Mdels The purpse f Cnfiguratin Management is t establish and maintain the integrity f the prducts (cmpnents, data, and dcumentatin) and the sftware artifacts, thrughut the prject and prduct life cycle. Fr Business Analysis, Cnfiguratin Management ensures that all wrk prducts (utcmes) f Business Analysis are identified, versin cntrlled, tracked fr changes, related t each ther, and related t ther prjects items (e.g., develpment and test artifacts) s that traceability can be maintained thrughut the prductin prcess. When planning the prject, Cnfiguratin Management prcedures and infrastructure (tls) shuld be chsen, dcumented and implemented. This is due t the fact that cnfiguratin items shuld be defined and brught under change cntrl as sn as pssible. The Business Analysis phase prduces many wrk prducts (e.g., requirements, specificatins), and all f them must be identified as cnfiguratin items, baselined and cntrlled. Versin 2013 Page 36 f 105

37 The prcess f Cnfiguratin Management includes the fllwing activities [IEEE 1042] (K2): 1. Cnfiguratin Identificatin - The purpse f Cnfiguratin Identificatin is t determine the attributes that describe every aspect f a cnfiguratin item. These attributes are recrded in cnfiguratin dcumentatin and baselined. 2. Cnfiguratin Change Cntrl - Cnfiguratin Change Cntrl is a set f prcesses, and apprval stages that are required t change a cnfiguratin item's attributes, and t establish a new baseline fr the changed item. 3. Cnfiguratin Status Accunting - Cnfiguratin Status Accunting is the ability t recrd and reprt n the cnfiguratin baselines that are assciated with each cnfiguratin item at any mment f time. 4. Cnfiguratin Audits - There are tw types f Cnfiguratin Audits: Functinal Cnfiguratin Audits Physical Cnfiguratin Audits A Functinal Cnfiguratin Audit ensures that functinal and perfrmance attributes f a cnfiguratin item are achieved, while a Physical Cnfiguratin Audit ensures that a cnfiguratin item is installed in accrdance with the requirements f its detailed design dcumentatin Change Management Prcess (K3) Change Management can be cnsidered as a sub-discipline f Cnfiguratin Management, and allws managing changes f the requirements in an effective way. The Change Management prcess includes the fllwing elements: Identifying a ptential change Requesting new functinality Analyzing the change request Evaluating the change Planning the change Implementing the change Reviewing and clsing the change request Ptential changes can be identified as a result f: A defect fund in the cde, dcumentatin r requirements System imprvement effrts External changes (regulatry, legal, etc.) New r changing requirements (resulting frm new regulatins, changes within the business dmain, new features requested by the users, etc.) Business prcess imprvement initiatives When the need fr a change appears, there shuld be a Change Request raised by a stakehlder requesting new r mdified functinality. Imprtant elements f a change request are a unique identifier, the authr, the deadline (if applicable), an indicatin whether the change is required r ptinal, the change type, and an abstract, r descriptin, f the prpsed change. Versin 2013 Page 37 f 105

38 The riginatr f a change may be any stakehlder n either the custmer r vendr side f the prject; this includes users, custmers, Prject Managers, Business Analysts, develpers, testers, architects, etc. It is imprtant t ensure that the change is submitted in a frmal way and is prperly managed. All changes shuld be tracked in a Change Lg r Change List. This dcument must be baselined, and wned and updated by ne persn (usually the Change Manager). The ther stakehlders shuld be aware f this dcument and shuld be able t view it. Changes shuld be managed by the Change Cntrl Bard (CCB). The CCB is nt allwed t submit, apprve, reject, r implement changes withut discussin with the ther stakehlders. A change may have significant impact n ther elements f the system, such as cmpnents, interfaces, functinality, etc. Therefre, each change shuld be analyzed, and the impact f change implementatin determined. Impact analysis includes analysis f the changes needed in the prject schedule r budget that wuld be necessitated if the change were t be implemented. The result f the impact analysis shuld be ne f the main drivers in making decisins abut apprving r rejecting a change request. As the impact analysis is dne, the CCB makes a decisin regarding apprving, rejecting, r deferring the change. A decisin t reject r defer the change is cmmunicated t the change riginatr with relevant justificatin. Apprved changes must be planned fr implementatin. The planning f change implementatin includes: Updating plans as needed depending n the phase f the prject (e.g., Prject Plan, Develpment Plan, and Test Plan) Updating business and system dcumentatin (e.g., specificatins, architecture design, user manuals) Updating test cases and test scripts Implementing the change (cding) Testing by vendr r/and custmer test team Deplying the change t the prductin envirnment (if applicable) After the change has been implemented, it must fllw the usual path t be tested. It is imprtant t ensure the implementatin is crrect and that it cmplies with the needs f the stakehlders, withut causing any negative effects. If testing discvers any issues, changes shuld be returned t the develpment team fr crrectins. If the implemented change is determined t be crrect and stable, it may be mved t the target envirnment, and the Change Request may be clsed Change Life Cycle (K2) The status f a change will vary based n the stage in the Change Management prcess. Examples f pssible status values include: Submitted Open Apprved Rejected Deferred In implementatin Implemented Versin 2013 Page 38 f 105

39 In testing Tested Clsed The life cycle f a change is very similar t that f a defect. Similarly, the prcedures fr Change Management and Defect Management are very similar. In fact, the same management tls are ften used fr these tw prcesses Change Cntrl Bard (CCB) (K1) The CCB is a grup f peple respnsible fr evaluating and apprving r rejecting prpsed changes t cnfiguratin items, and fr ensuring implementatin f apprved changes. [IEEE 610] The Change Cntrl Bard (CCB) usually includes (K1): Prject manager Business Analysts Develpment team Quality assurance team Business manager, if applicable Custmer, if applicable Versin 2013 Page 39 f 105

40 3.4. Tls and Techniques Selectin (K1) 10 minutes Sectin Learning Objectives Each type f Business Analysis activity has its wn set f supprting tls. In general, tls can be divided int the fllwing categries based n their functinality (K1): Text prcessing tls Table calculatin tls Mdeling tls Requirements Management tls Prcess simulatin tls Cnfiguratin Management tls Change Management tls There are numerus techniques designed t aid Business Analysis activities. Techniques change the way in which Business Analysis tasks are perfrmed, and determine utputs fr thse tasks. In this sectin nly a few f the cmmn techniques are listed. Cmmn Business Analysis techniques include (K1): Brainstrming CATWOE Data Flw Diagrams Five Why s Functinal decmpsitin Interviews MSCW MOST PESTLE Prttyping Requirements Wrkshps Risk Analysis Scenaris and Use Cases SWOT User stries Versin 2013 Page 40 f 105

41 4. Elicitatin (K3) 180 minutes Terms: Apprenticing, baseline, brainstrming, change management, field bservatin, interview, quality criteria, questinnaire, requirements acceptance, requirements elicitatin, reuse, RTM, scpe, selfrecrding, specificatin, standards, traceability Learning Objectives fr Elicitatin The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 4.1 The Cncept f Requirements Elicitatin (K3) LO LO LO LO LO Define Requirements Elicitatin. (K1) Explain hw Requirements Elicitatin is a key task in Business Analysis. (K2) Describe the gals f the identificatin f requirements. (K2) Describe and apply standard techniques used t cllect the requirements f the system. (K3) Describe the characteristics f functinal and nn-functinal requirements. (K2) 4.2 Requirements Scpe Management (K2) LO Understand and explain the cncept f requirements scpe. (K2) LO Explain the rle f requirements in defining the scpe f the slutin. (K2) 4.3 Requirements Traceability (K2) LO Define Requirements Traceability. (K1) LO Explain why Requirements Traceability is imprtant. (K2) LO Describe the techniques and tls that are used t trace requirements. (K2) 4.4 Requirements Dcumentatin (K3) LO LO LO LO Define the standard cntents f a requirements dcument. (K1) Explain the prcess f cnstructing a requirement. (K2) Apply several cmmn techniques used in Requirements Dcumentatin. (K3) Describe, with examples, the mst cmmn mistakes in requirements dcuments. (K2) Versin 2013 Page 41 f 105

42 4.5 Cmmunicatin (K2) LO Explain the prcess f requirements cmmunicatin. (K2) LO Explain the purpse f requirements acceptance. (K2) 4.6 Standards (K2) LO Recall the standards and nrms that apply t Requirements Engineering. (K1) LO Explain, with examples, the quality criteria fr requirements. (K2) Versin 2013 Page 42 f 105

43 4.1. The Cncept f Requirements Elicitatin (K3) 70 minutes Sectin Learning Objectives Business Requirements Elicitatin is defined as a set f appraches, techniques, activities, and tasks used t capture the business requirements f a planned slutin frm the stakehlders and ther available surces [BABOK]. (K1) Business Requirements Elicitatin has several purpses, including: (K2) Identifying the desired functins, characteristics, limitatins, and expectatins f the planned slutin Establishing the final scpe and business design f the slutin Orienting the requirements tward the prject visin Excluding features that the custmer des nt want and need The fllwing techniques are used during Requirements Elicitatin: (K3) Questinnaires Interviews Self-recrding Hsting representatives f the custmer at the vendr s site Reviewing existing dcuments Reusing a specificatin frm a previus prject Brainstrming Field bservatin Apprenticing Cnducting wrkshps t refine the requirements after each iteratin Requirements Elicitatin shuld apply t enterprise requirements as well as user r custmer requirements. Identificatin f requirements shuld include expressing them using the fllwing quality characteristics [ISO 25000, previusly ISO/IEC 9126] (K2): Functinality Reliability Usability Efficiency Maintainability Prtability Versin 2013 Page 43 f 105

44 4.2. Requirements Scpe Management (K2) 20 minutes Sectin Learning Objectives Requirements Scpe (K1) Requirements may cver any f the fllwing areas: System r cmpnent develpment Prcess imprvement Organizatinal change Requirements Scpe Management (K2) Requirements Scpe Management invlves the fllwing activities [BABOK]: 1. Establishing the requirements baseline 2. Creating a requirements structure fr traceability 3. Identifying impact t external systems and ther areas f the prject 4. Identifying changes in the scpe resulting frm requirements changes 5. Maintaining scpe apprval by the stakehlders Establishing the Requirements Baseline All requirements identified and apprved by stakehlders must be baselined. The baseline is a base fr the next phase f develpment and will serve as a pint f reference fr any changes in the cntent f the requirements r scpe. Creating a Requirements Structure fr Traceability Requirements traceability is necessary fr the prcess f managing changes t the requirements that will ccur after the requirements are baselined. Traceability establishes the rigin f the requirement and defines all related cmpnents. Identifying Impact t External Systems and Other Areas f the Prject In rder t ensure that there is n wrk utside the baselined list f requirements, it is necessary t identify and dcument all pssible impact t external systems and ther areas f the prject. This cnfines the prject t the defined requirements. Changes in requirements scpe may affect: Prject schedule Prject cst Prject and prduct risk Prject resurces Versin 2013 Page 44 f 105

45 External interfaces t ther systems r hardware Identifying Changes in the Scpe that Result frm Requirements Changes Change Management is the prcess f cntrlling changes t the requirements f the systems develpment cmpnent, prcess imprvement and/r rganizatinal change prject, in a cntrlled manner [BABOK]. (K1) In mst cases, custmer requirements are nt cnstant thrughut the prject s lifecycle. They are changeable and very ften nt fully cmplete until the end f the implementatin phase. Changes in requirements may have varius impacts n the prject; if the change is minr, it may have n impact n the prject scpe, time r cst; if the change is majr (such as changing business lgic r prcess flw fr critical functinality) it may have a drastic effect. Maintaining Scpe Apprval Having the list f requirements is nt sufficient t be able t manage the scpe prperly. The list must be apprved and baselined and must reflect stakehlders expectatins fr the prject. The apprved list f requirements is cnsidered as a mutual understanding between the custmer and the vendr team abut the requirements. Any changes in the apprved list f requirements shuld be managed via change management prcedures Baseline (K1) A system baseline is any set f system attribute specificatins that frmally define the state f a system under specified cnditins [TGilb]. The Baseline is cnsidered t be an fficial list f the requirements, and can be treated as an internal agreement. Prpsed changes are cmpared t the baseline t determine the verall impact. Versin 2013 Page 45 f 105

46 4.3. Requirements Traceability (K2) 20 minutes Sectin Learning Objectives Traceability is an assciatin existing between high level requirements (needs and features) and the mre detailed requirements. Traceability may be established between detailed requirements, and bth design mdels and test cases. Traceability between requirements, and ther prject artifacts (such as test cases), allws a Business Analyst t ensure all requirements have been fulfilled. (K1) Tracing f requirements is necessary t ensure all requirements are prperly managed within the prject life cycle, especially in the area f managing changes t the requirements. When changing any requirement, traceability assciatin allws a determinatin f what ther requirements are affected by the change and what ther artifacts shuld be prperly adjusted. When a change is made t a traced requirement, verificatin can be made t determine the necessary changes and updates required fr any affected requirements and artifacts. Traceability affects the rganizatin in the fllwing areas (K2): Scpe management Impact analysis Cverage analysis Prf f implementatin Use f the requirement Defect reprts Requirements Management tls are used fr string the requirements f all specificatins f a technical system under develpment. These requirements are usually arranged in a specificatin tree, and are linked t their "parent" requirement in the higher-level specificatin. This parent/child relatinship is a frm f traceability. Requirements are implemented as design artifacts, cde, test cases, etc. Each f these artifacts shuld be traced back t the requirement(s) frm which they riginated. This is typically dne via a Requirements Traceability Matrix (RTM). Versin 2013 Page 46 f 105

47 4.4. Requirements Dcumentatin (K3) 40 minutes Sectin Learning Objectives In sme cases, in additin t dcumenting requirements, the Business Analyst als dcuments business prcesses that are perfrmed within an rganizatin. Business prcesses may be dcumented using prcess flw diagrams such as Business Prcess Mdeling Ntatin (BPMN) r Dmain Specific Language (DSL). Prcesses may als be described in mre detail via written text. This is helpful in cmplex and large prjects, when understanding the verall prject scpe requires knwledge f the exact flw f the prcesses, inputs, utcmes, and dependencies between separate activities Dcumenting the Requirements (K2) When dcumenting particular requirements, the Business Analyst shuld fllw cmmn standards and guidelines. Using standardized dcumentatin increases quality and readability, and helps ensure that all readers will have a similar understanding f the cntent. In the specificatin, requirements are described in a structured way and are mdeled separately. The specificatin serves t track and manage the individual requirements. An apprved requirements specificatin serves as a frmal agreement and scpe definitin, and prvides input infrmatin fr the ther members f the prject team (e.g., systems analysts, develpers, testers etc.). Imprtant guidelines fr the creatin f the requirements dcument include the fllwing: Each requirement must be unambiguus, precise, and understandable. Superfluus infrmatin shuld be avided. Templates shuld be used as an aid. Mdels and diagrams shuld be used t make the specificatin dcument clear and mre understandable fr readers. Frmal graphical ntatin shuld be used as a methd fr presenting cmplex requirements, dependencies, and relatinships. The standard cntents f a requirements dcument may include (K1): Intrductin Secrecy clause Regulatins Standards Stakehlders Purpse f the prduct Overall descriptin Functinal requirements Nn-functinal requirements Limitatins and assumptins Versin 2013 Page 47 f 105

48 Dependencies Risks Safety requirements Dcument acceptance When creating a requirements dcument, the Business Analyst shuld remember that requirements specificatins must be cmplete, cnsistent, mdifiable, and traceable [Wiegers] Cmmn Mistakes in Requirements Dcumentatin (K2) In practice, there are ften many issues affecting the quality f such dcumentatin. Sme f the mst cmmn mistakes are [T. Simn, J. Streit, and M. Pizka]: Trivialities - Lengthy descriptins f cmmnly knwn issues shuld nt be included. Infrmatin ut f scpe - Infrmatin that des nt add any value t the descriptin f the slutin t be built shuld nt be included int dcumentatin. Thinking in slutins - In many cases, the authr f the requirements dcumentatin prvides a descriptin f slutins (such as technical details that wuld drive the implementatin). The requirements specificatin shuld discuss the prblem t be slved nt the technical design f the slutin. Redundant details - Details that unnecessarily cmplicate the implementatin shuld nt be included. This prblem is related t Thinking in slutins as the authr (frequently having sme implementatin experience) suggests desired implementatin details and ges int a detailed descriptin. Lacking ratinale - Requirements dcuments shuld describe what shall be achieved with the sftware system, and cmpnent r particular features. The cncrete requirements may be described at an apprpriate level f detail (including cncrete numbers and metrics). Versin 2013 Page 48 f 105

49 4.5. Cmmunicatin (K2) 20 minutes Sectin Learning Objectives Requirements Cmmunicatin includes activities fr expressing the utput f the requirements analysis, and dcumentatin t the stakehlders. Cmmunicatin f requirements is an nging and iterative activity, including presenting, cmmunicating, verifying, and btaining apprval f the requirements frm the prject stakehlders. Cmmunicating requirements is ne f the majr tasks f the Business Analyst; their respnsibility is t nt nly identify and dcument the custmer s requirements, but als t bring the stakehlders t a cmmn understanding f the requirements and resulting slutin. Clear and effective cmmunicatin is essential, as the stakehlders may have different knwledge and represent different dmains. The rle f a Business Analyst is t cmmunicate requirements in a way that allws all stakehlders t gain the same understanding f a particular requirement. T ensure this, the Business Analyst must cnsider what cmmunicatin apprach is apprpriate in a given situatin Requirements Cmmunicatin Prcess (K2) The Requirements Cmmunicatin Prcess includes the fllwing activities [BABOK]: Preparing the requirements cmmunicatin plan Managing requirements cnflicts Establishing the mst apprpriate requirements frmat Creating the requirements package Cnducting requirements presentatins Perfrming frmal requirements reviews Obtaining requirements apprvals (Sign-ff) Requirements Acceptance (K2) Requirements shuld be agreed t and accepted by all stakehlders that are respnsible and dedicated t this task. It is extremely imprtant t ensure that all requirements are frmally apprved since the frmal agreement is a starting pint fr a further detailed system specificatin, designing the architecture, and ther aspects f the planned system. Requirements usually are accepted by the fllwing stakehlders: Prject Manager Business Analyst Business Analyst n custmer side Architects (n bth sides) Test/QA Manager Versin 2013 Page 49 f 105

50 The list f requirements is binding fr bth the vendr and the custmer. This means that nce the requirements are agreed and accepted, the baseline requirements then define the design f the system. Any changes in the scpe r cntent f the requirements must be managed via Change Management. Versin 2013 Page 50 f 105

51 4.6. Standards (K2) 10 minutes Sectin Learning Objectives The fllwing standards are applicable t the Business Analysis prcess: ISO (previusly ISO/IEC 9126) defines a quality mdel with the fllwing six quality characteristics: IEEE 830: Functinality Reliability Usability Efficiency Maintainability Prtability Recmmended Practice fr Sftware Requirements Specificatins IEEE 1233: Guide fr Develping f System Requirements Specificatins IEEE 1362: Guide fr Infrmatin Technlgy System Definitin Versin 2013 Page 51 f 105

52 5. Requirements Analysis (K3) 240 minutes Terms: Assumptin, BPMN, checklist, cnstraint, decmpsitin, gal, gal decmpsitin, feature list decmpsitin, functinal decmpsitin, mdeling, quality assurance, review, specificatin, structuring, UML, verificatin, validatin Learning Objectives fr Requirements Analysis The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 5.1 Requirements Organizatin (K2) LO Explain the reasns fr rganizing requirements. (K2) LO Describe hw requirements can be rganized. (K2) LO Recall the cmmn types f decmpsitin. (K1) 5.2 Mdeling and Specificatin (K3) LO LO LO Describe, with examples, hw requirements can be mdeled. (K2) Apply cmmn techniques that are used fr requirements mdeling (BPMN, UML). (K3) Explain the purpse f GUI prttyping. (K1) 5.3 Defining Assumptins and Cnstraints (K2) LO Define assumptins and cnstraints. (K1) LO Explain hw assumptins and cnstraints may affect Business Analysis. (K2) 5.4 Verificatin and Validatin (K1) LO Explain the difference between verificatin and validatin. (K1) 5.5 Quality Assurance (K2) LO Explain the imprtance f high-quality requirements in the slutin lifecycle. (K2) LO Explain hw reviews can help imprve the quality f requirements. (K2) Versin 2013 Page 52 f 105

53 5.1. Requirements Organizatin (K2) 40 minutes Sectin Learning Objectives Requirements can be rganized (structured) int packages. This packaging cnfrms t the bundaries (limitatins) and slutin scpe established during Enterprise Analysis and helps t further define thse bundaries. The Business Analyst decmpses the prblem mdel t make each requirement mre detailed and t ensure that the mdel crrectly reflects the bundaries fr the business prblem. Decmpsitin allws the Business Analyst t clarify the requirements (functinal and nnfunctinal as well as supplemental requirements) and ensures the prper level f detail is achieved Decmpsitin (K2) Cmmn types f decmpsitin used t define the structure f requirements and the scpe bundaries are: Gal decmpsitin Gals are business requirements [BABOK]. (K1) Gal decmpsitin helps t ensure the slutin will satisfy stakehlder s needs. Feature list decmpsitin A feature is a service that the slutin prvides t fulfill ne r mre stakehlder need [BABOK]. (K1) A feature is understd as an abstractin f the slutin f the prblem expressed at a high-level. A feature is develped int cmpletely described functinal and supplemental requirements. Functinal decmpsitin Functinal decmpsitin is a breakdwn f a list f items int classificatins r grups based n the functin each item perfrms r the use it prvides [BDictinary]. (K1) Functinal decmpsitin identifies the high-level functins f the prpsed slutin, r the rganizatin itself, and then breaks them dwn int sub-prcesses and activities. The purpse f functinal decmpsitin is t break functins dwn int smaller pieces t analyze the prcesses in detail and t ensure prper cverage f all majr prcesses. Functinal decmpsitin is usually perfrmed by a Systems Analyst. Functinal decmpsitin can be used t hierarchically decmpse a system int functinal cmpnents. Functinal decmpsitin can be used t hierarchically decmpse a business prcess int sub-prcesses. Functinal decmpsitin prvides a definitin f all the business functins and subfunctins identified as system requirements. Versin 2013 Page 53 f 105

54 Levels f Detail fr Functinal Decmpsitin (K2) There are several levels f detail that are used during functinal decmpsitin [Tlbx]. These are: Enterprise Level f Detail - In this apprach, the rt f the decmpsitin diagram may cntain the name f the rganizatin r a majr functin within an rganizatin. The secnd level typically represents majr business functins (e.g., Planning, Executin, Cntrl). Cnceptual Level f Detail - The cnceptual level identifies the majr business prcesses needed t accmplish each functin that was defined at the lwest level f the Enterprise Level f Detail. Prcesses identified at this level typically reflect applicatin systems r sub-systems (e.g., Marketing, Sales, Finance). Lgical Level f Detail - At the lgical level, the decmpsitin diagram decmpses prcesses int the lwest level f detail. At this level all the prcesses within the scpe f the prject are identified. Versin 2013 Page 54 f 105

55 5.2. Mdeling and Specificatin (K3) 80 minutes Sectin Learning Objectives The Cncept f Mdeling (K1) Mdeling is a way f expressing requirements by representing parts, r the whle, f the prpsed slutins. Mdels may cntain textual elements, matrices and diagrams, and are used t reflect the relatinships and dependencies between the requirements that fulfill the identified business needs. In case f large and cmplex sftware systems requirements, mdeling is helpful in expressing the verall structure f the slutin. In additin, presenting cmplex requirements and relatinships in the frm f a mdel, especially sme graphical frm such as diagrams, helps ensure the slutin is understd by ther stakehlders. Mdels are ften easier t read and cmprehend than written text. Expressing requirements in the frm f mdels may be helpful in the prcess f requirements specificatin; hwever, it is nt required and may be mitted in sme cases. The decisin t perfrm requirements mdeling shuld be driven by the scpe and cmplexity f the slutin and by the vendr and/r custmer s rganizatinal standards and applied apprach. The rganizatin may skip mdeling in the fllwing situatins: The slutin is fully understd by the stakehlders and is easy t implement. The requirements are mstly nn-functinal and difficult t express in the frm f a mdel. The prblem dmain is well knwn. The slutin is dedicated t use by very few peple. The scpe is declared as cnstant and there is a lw prbability f changes in the scpe resulting frm future requirements r needs. It is established that the mdel representatin wuld be less understandable by the key stakehlders than written text (e.g., n knwledge r experience with UML). The benefits f using requirements mdeling are: Mdels are perceived as a simplified expressin f real prcesses and allw the Business Analyst and ther stakehlders t fcus n the imprtant aspects and areas f the slutin. Mdels describe a cmplex system in the mst clear and unambiguus way. Mdels are mre readable than written text. Mdels present the whle system and its cntext in a single diagram and therefre help t lk at the prblem frm the verall perspective. Cmmn techniques f mdeling requirements include (K3): Using UML ntatin t express requirements as use case diagrams, activity diagrams, cmpnent diagrams, state machine diagrams, etc. Using BPMN ntatin t express business prcesses. Using DSL, a specificatin language dedicated t a particular prblem dmain, a particular prblem representatin technique, and/r a particular slutin technique. Versin 2013 Page 55 f 105

56 Using SysML ntatin t develp specificatins, analysis, design, verificatin and validatin dcumentatin fr systems and systems-f-systems. The specificatins may include hardware, sftware, infrmatin, prcesses, persnnel and facilities. Using prttyping as a technique f GUI mdeling Business Prcesses Mdeling (K2) Business prcesses may be mdeled using a technique such as BPMN. This mdeling prvides a view int the varius prcesses perfrmed within an rganizatin. It helps the reader t understand the rganizatin s prcesses and supprts effective requirements analysis and mdeling t ensure the prpsed slutin meets the needs f the current business prcesses. As the cmplexity f business prcesses cntinues t increase, it needs t be prperly managed. There are six main quality criteria fr business prcess mdels [Becker J., Kugeler M., and Rsemann M.]: Crrectness (syntactic and semantic crrectness) Relevance (n irrelevant details) Ecnmic efficiency (designed fr a particular purpse) Clarity (understandable by the audience) Cmparability (based n the same mdeling cnventins within and between mdels) Systematic design (cntains well-defined interfaces t ther types f mdels) Business Prcess Mdeling is a part f Business Prcess Management (BPM) (K1) GUI Prttyping (K2) Prttyping allws the visualizatin f the interface requirements befre the applicatin is designed r develped. The purpse f prttyping is t create mck ups f the screens r reprt layuts fr an applicatin. Prttyping assists in identifying, describing and verifying GUI interface needs, especially in the case when users, r ther stakehlders, are nt able t articulate their expectatins and requirements withut seeing the prpsed versins f the GUI interface. There are tw types f GUI prttypes (K1): Static Screens r layuts withut any business lgic running behind the visualizatin, nly mck ups. Dynamic Applicatin prttypes that allw navigatin thrugh the screens and simulate real business prcesses. This kind f prttyping can be used t perfrm sme usability testing Ten Key Principles fr Successful Requirements (K2) There are ten key principles that have been defined t help ensure the success f the requirements [Gilb and Brdie RQNG]. They are: 1. Understand the tp level critical bjectives. 2. Think stakehlders, nt just users and custmers. 3. Fcus n the required system quality, nt just its functinality. Versin 2013 Page 56 f 105

57 4. Quantify quality requirements as a basis fr sftware engineering. 5. Dn t mix ends and means. 6. Capture explicit infrmatin abut value. 7. Ensure there is rich specificatin ; requirement specificatins need much mre infrmatin than just the requirement itself. 8. Carry ut specificatin quality cntrl (SQC). 9. Cnsider the ttal lifecycle and apply systems-thinking, nt just a fcus n sftware. 10. Recgnize that requirements change; use feedback and update requirements as necessary. Versin 2013 Page 57 f 105

58 5.3. Defining Assumptins and Cnstraints (K2) 30 minutes Sectin Learning Objectives Cnstraint (K1) A cnstraint is a requirement that explicitly and intentinally tries directly t restrict any system r prcess. Cnstraints include limitatins n the engineering prcess, a system s peratin r its lifecycle [TGilb]. The purpse f defining cnstraints is t infrm the stakehlders that ptins they wuld nrmally be allwed t cnsider are nt available. There are tw types f cnstraints, as fllws [BABOK] (K2): Business cnstraints - Business cnstraints describe the limitatins n the prject s flexibility t implement the requested slutin. They may reflect financial r time restrictins, limits n the number f resurces available, skills f the prject team, r ther rganizatinal restrictins. Technical cnstraints - Technical cnstraints are any restrictins that are related t the architecture f the slutin such as hardware and sftware platfrms, prgramming language r technlgy, and sftware that must be used. Technical cnstraints als include restrictins such as database size, resurce utilizatin, message size and timing, sftware size, maximum number f and size f files, recrds and data elements Assumptin (K1) Assumptins are cnditins that are believed t be true, but have nt yet been cnfirmed. Assumptins can be defined as unprven cnditins, which, if prven t be untrue at sme defined pint in time, wuld have a negative effect and might impair the ability t achieve the prpsed slutin [TGilb]. There are tw types f assumptins related t Business Analysis [BABOK]: Business assumptins Requirements assumptins The purpse f defining business assumptins is t infrm the prject team f key stakehlder expectatins. The purpse f defining requirements assumptins is t transfer business dmain knwledge t the prject team. It is imprtant t ntice that assumptins are used t dcument tw types f issues: Issues identified by the Business Analyst as likely t be true, but impssible t verify [BABOK] Issues identified by the Business Analyst as true in the current situatin, but subject t change that culd have a negative r even a destructive impact n the prject [TGilb] Assumptins and cnstraints identify aspects f the prblem dmain that can limit r impact the design f the slutin, but are nt functinal requirements. In sme cases assumptins becme cnstraints f the slutin. Versin 2013 Page 58 f 105

59 5.4. Verificatin and Validatin (K1) 40 minutes Sectin Learning Objectives Validatin (K1) Validatin is an activity f cnfirmatin by examinatin and thrugh the prvisin f bjective evidence that the requirements fr a specific intended use r applicatin have been fulfilled [ISO 9000]. The gal f validatin is t ensure that the stated requirements crrectly and fully implement the business requirements that are determined in the Enterprise Analysis and Requirements Identificatin phases. Validatin techniques include (K1): Wrkshps with key stakehlders Demnstratins f the slutin Reviews f the requirements dcumentatin Verificatin (K1) Verificatin is a cnfirmatin by examinatin and thrugh the prvisin f bjective evidence that specified requirements have been fulfilled [ISO 9000]. Verificatin ensures that requirements are defined clearly enugh t allw slutin design, implementatin and test preparatin t begin. T cmplete the verificatin prcess, it is required t invlve and cperate clsely with the custmer, users and the prject team. Requirements can be stated as verified nly if: Prject stakehlders have agreed that the requirements are crrectly understd. A Business Analyst has validated the requirements with the custmer and user, and has cnfirmed that the requirements cmpletely describe what has t be implemented and that they are f high quality. A cmmn technique fr slutin verificatin is testing (K1). Testing may invlve sftware cmpnents and/r dcumentatin, r any ther wrk prduct frm the Business Analysis. Versin 2013 Page 59 f 105

60 5.5. Quality Assurance (K2) 50 minutes Sectin Learning Objectives Quality Assurance is a prcess f systematic mnitring and evaluatin f the varius aspects f a prject r slutin. The gal is t maximize the prbability that the slutin has achieved a desired standard f quality Quality Criteria fr Requirements (K1) The quality criteria fr requirements include the fllwing items: Allcatable Cmplete Cnsistent Crrect Des nt determine slutin Feasible Measurable Necessary Priritized Testable Traceable Unambiguus Understandable Checklists (K1) One f the mst cmmn techniques fr requirements quality cntrl is the use f checklists. Checklists may include a standard set f quality elements, r custmized (adjusted t the specific prject) quality elements that the Business Analyst will use t validate the Requirements Specificatin. The fllwing shws tw sample checklists fr different types f prjects. General Checklist [SRS Checklist]: Is a functinal verview f the system prvided? Are sftware and hardware envirnments specified? Are there any assumptins that affect implementatin? Are they dcumented? Is the functinality f hardware/sftware interacting with the system specified? Has every acrnym been defined in the Dictinary? Are all the requirements, interfaces, cnstraints, etc., listed in the apprpriate sectins? Versin 2013 Page 60 f 105

61 Interface Checklist [SRS Checklist]: Are all inputs t the system specified? Are all utputs frm the system specified? Are all screen frmats specified? Are all reprt frmats specified? Are all interface requirements between hardware, sftware and prcedures included? Reviews (K1) Other cmmn techniques fr requirements quality assurance are reviews. A Business Analyst shuld ensure that utcmes f their wrk have been reviewed, and any majr issues identified and reslved as a pst-review fllw up activity. A review is an evaluatin f a prduct, r prject status, t ascertain discrepancies frm planned results and t recmmend imprvements. There are several types f reviews: management reviews, infrmal reviews, technical reviews, inspectins, walkthrughs and audits [IEEE 1028]. In particular, the fllwing review types are cmmnly used t verify the wrk prducts frm Business Analysis: Peer review A review f a wrk prduct by clleagues f the authr f the prduct fr the purpse f identifying defects and imprvements. Technical review A grup discussin fcused n achieving cnsensus n the technical apprach t be taken. Walkthrugh A step-by-step presentatin f a dcument in rder t gather infrmatin, and t establish a cmmn understanding f its cntent [Freedman and Weinberg, IEEE 1028]. A walkthrugh is cnducted by the authr f the dcument. Inspectin A type f frmal review that relies n visual examinatin f dcuments t detect defects (e.g., nn-cnfrmance t higher level dcumentatin, r t develpment standards). Versin 2013 Page 61 f 105

62 6. Slutin Validatin (K3) 70 minutes Terms: Slutin assessment, validatin Learning Objectives fr Slutin Validatin The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 6.1 Assessment (K2) LO Explain reasns fr slutin assessment. (K2) LO Prvide examples f slutin assessment techniques. (K2) 6.2 Validatin (K3) LO Recall cmmn validatin techniques and methds. (K1) LO Explain when validatin shuld be perfrmed. (K2) LO Plan basic activities fr slutin validatin. (K3) Versin 2013 Page 62 f 105

63 6.1. Assessment (K2) 30 minutes Sectin Learning Objectives The gal f the slutin assessment is t evaluate its apprpriateness and cmpliance with the requirements [BABOK] (K2). After handing ver the requirements t the develpment team, the Business Analyst is expected t assess the design and the implementatin increments that are returned t the prject team. The Business Analyst is usually the best persn t assess the apprpriateness f the slutin design, in terms f its alignment with the stated requirements. Others, such as the spnsr and prject manager, may have mre ability t assess the value prvided fr the mney spent. The Business Analyst will check the slutin fr cmpliance with the agreed requirements and will prvide feedback t the develpment team. The fllwing tls may be used t assess the slutin s cmprehensiveness: Requirements Traceability Matrix (RTM) Tracing features t Use Cases Requirements specificatins dcuments Demnstrating the sftware (prttype) t the custmer Getting the custmer feedback RTM is a dcument that crrelates tw baselined dcuments that require a many t many relatinship (a type f cardinality that refers t the relatinship between tw entities) t determine the cmpleteness f the relatinship. RTM ften crrelates high-level requirements and detailed requirements f the sftware prduct with the matching parts f the high-level design, detailed design, test plan, and test cases. RTM is usually presented in the frm f a table. Versin 2013 Page 63 f 105

64 6.2. Validatin (K3) 40 minutes Sectin Learning Objectives Slutin validatin is the activity f demnstrating, explaining and cnfirming the slutin's apprpriateness t stakehlders and spnsrs. This ften invlves explaining technical cncepts t stakehlders wh have nly business knwledge [BABOK]. The rle f the Business Analyst is t ensure that all invlved peple have a cmmn understanding f the prpsed slutin, and t validate if the slutin meets the stakehlder s needs and expectatins. In sme cases, the validatin prcess must be fllwed by a written apprval. Slutin validatin als invlves managing test activities. The test strategy and test plan gvern the test activities. The Business Analyst prvides infrmatin that is used fr test planning and creating test specificatins, and als supprts the wrk related t preparing tests cases that will cver the requirements. Once the slutin design has been agreed upn, the Business Analyst shuld supprt the develpment team during the detailed design f the applicatin. This includes perfrming the fllwing tasks: Supprting functinal specificatin creatin Helping t build usability Reviewing the technical design deliverables In rder t ensure the mst effective system develpment and testing, the Business Analyst shuld als participate in planning the develpment f particular parts (e.g., cmpnents, mdules) f the sftware system. Because the Business Analyst has the best knwledge abut the prcess(es) being implemented, and knws the dependencies and relatinships between specific parts f the prcess, they may be able t prvide advice regarding an effective and lgical way f splitting the whle functinality int increments. In the case f COTS (Cmmercial-Off-The-Shelf) systems r cmpnents, the Business Analyst shuld prvide advice n required custmizatin wrk, as well as helping define the interface requirements. Once the slutin r a cmpnent f the slutin is implemented and delivered fr testing, the Business Analyst supprts the testing team. The Business Analyst shuld understand the activities perfrmed by the testing team and their bjectives, and shuld be available t give advice n the testing f the slutin. The Business Analyst may be requested t review test deliverables (e.g., test plans, test cases, test scenaris, test data) t ensure that the requirements and business risks are cvered by testing. In sme cases the rle f the BA is t review and verify test results. One f the Business Analyst s respnsibilities is t supprt business stakehlders with user acceptance testing, defect reprting and reslutin. In fact the Business Analyst ften prepares r participates in the preparatin f the UAT (User Acceptance Test) test cases. Due t changes requested fr the system (resulting frm change requests including new requirements, next phase issues, and any ther pst implementatin supprt), the system develpment may nt end with releasing the system t prductin. The Business Analyst is invlved in identifying and managing all changes t the requirements, and shuld make sure that the prductin rllut f any change is cmpleted as smthly as pssible. Versin 2013 Page 64 f 105

65 7. Tls and Techniques (K3) 80 minutes Terms: Five Why s, CATWOE, GUI prttyping tls, mdeling tls, MSCW, MOST, tls, PESTLE, prcess simulatin tls, requirements management tls, SWOT Learning Objectives fr Tls and Techniques The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 7.1 Business Analysis Tls (K2) LO LO LO LO Explain the purpse f Requirements Management tls and prvide prper examples. (K2) Explain the purpse f Mdeling tls and prvide prper examples. (K2) Explain the purpse f Supprting tls and prvide prper examples. (K2) Explain the purpse f Prcess Simulatin tls and prvide prper examples. (K2) 7.2 Business Analysis Techniques (K3) LO Recall cmmn Business Analysis techniques. (K1) LO Given a specific scenari, apply the apprpriate Business Analysis techniques. (K3) LO Explain when using a specific technique wuld be helpful. (K2) Versin 2013 Page 65 f 105

66 7.1. Business Analysis Tls (K2) 30 minutes Sectin Learning Objectives Requirements Management activities may be supprted by varius tls, methds and techniques. The simplest tls are the spreadsheets and wrd prcessrs that stre the infrmatin related t the requirements. Hwever, in mst cases, managing and maintaining requirements in such frm may be ineffective and t time-cnsuming. Especially in the case f large and cmplex prjects that cntain a huge number f requirements, ften with many dependencies, this apprach is nt effective and des nt ensure the quality f Requirements Management r the requirements themselves. (K2) Requirements Management Tls (K2) A Requirements Management tl is a tl that supprts the fllwing activities: Recrding requirements Defining requirement attributes (e.g., pririty, respnsibility) and anntatins Traceability thrugh layers f requirements Traceability t ther system and develpment tls Requirements Change Management Static analysis (e.g., cnsistency checking and vilatins t pre-defined requirements rules) Apprval histry tracking Mdeling Tls (K2) Apart frm Requirements Management tls, which cllect and stre requirements, there are als Mdeling tls. Mdeling tls prvide the capability t: Link requirements tgether in mdels presenting their relatinships and dependencies, and representing the business structure f the sftware system Create graphical representatins f the requirements Represent relatinships between requirements, and between requirements and ther artifacts Establish and maintain traceability Design the verall structure f the system including hardware, sftware, peple, etc. (SysML) Other Tls (K2) In additin t Requirements Management and mdeling tls, the Business Analyst may use several supprting tls such as GUI design tls. GUI prttyping is a helpful technique that allws demnstratin f the system design t the stakehlders; it als serves as an aid t implementatin. Elements f the GUI may be designed in the frm f static screens r dynamic ( wrking ) prttypes f the applicatin. The secnd slutin Versin 2013 Page 66 f 105

67 allws the user t navigate thrugh particulate system screens and may be used t cnduct initial usability verificatin. Prttyping, either static r dynamic, is very helpful when the requirements are nt clear and the sftware purchaser (custmer) is nt able t articulate his needs and expectatins. Presenting such demnstratins t the stakehlders can help them t determine the desired functinality, navigatin and the appearance f the applicatin. Other helpful techniques fr the Business Analyst are: Mind mapping Ishikawa diagrams Mind Mapping A mind map is a diagram used t represent ideas, tasks r ther items that are linked t, and arranged arund, a central key wrd r idea. Mind maps generate, visualize, structure, and classify ideas, and are a great aid fr studying and rganizing infrmatin, slving prblems, making and dcumenting decisins [Jhn W. Budd]. Mind mapping can be used t identify and analyze requirements. Ishikawa Diagrams Ishikawa diagrams (als called fishbne diagrams r cause-and-effect diagrams) shw the causes f a certain event. The Ishikawa diagram is ften used in prduct design and quality defect preventin, and identifies ptential factrs causing an verall effect. Each cause r reasn fr a defect is a surce f variatin. Causes are gruped int majr categries t identify these surces f variatin. Ishikawa diagrams may be used t identify the causes f prblems detected in an rganizatin, thus helping t determine and implement slutins fr the prblem [Ishikawa]. An Ishikawa diagram may be created n a simple piece f paper r by using sftware applicatins Prcess Simulatin Tls (K2) Prcess simulatin is mdel-based sftware that represents varius prcesses and unit peratins perfrmed within an rganizatin [C.L. Rhdes]. Basic prerequisites fr using these tls include a thrugh knwledge f the prcesses and their assciated attributes. This infrmatin is used by the sftware t discver the weak pints in the prcess flw. By changing varius parameters (such as resurce allcatin), the prcess can be ptimized. Prcess simulatin requires creating a mdel f the prcesses in the rganizatin and cnfiguring their parameters (e.g., duratin f particular activities r prcesses, resurce usage). Such mdels can be designed using BPMN r ther frms f business prcess mdeling. By running the simulatin, the Business Analyst can watch the sequence f the different activities, and can determine weak and strng pints in the current prcess. Prcess simulatin can be used t discver the ptimal cnditins fr a specific prcess r set f prcesses. Versin 2013 Page 67 f 105

68 7.2. Business Analysis Techniques (K3) 50 minutes Sectin Learning Objectives There are a number f techniques that a Business Analyst can use t increase the effectiveness f the wrk. These range frm wrkshp facilitatin techniques, used t elicit requirements, t different techniques fr analyzing and rganizing requirements. Tw techniques that are used t perfrm external and internal envirnmental analysis are PESTLE and MOST. The PESTLE technique is used t perfrm an external envirnmental analysis by examining external factrs that affect an rganizatin. PESTLE analyzes the fllwing six attributes: Plitical Ecnmic Scilgical Technlgical Legal Envirnmental The MOST technique is used t perfrm an internal envirnmental analysis t ensure that the prject is aligned t each f the fllwing fur attributes: Missin Objectives Strategies Tactics In additin t MOST and PESTLE, ther analysis techniques are used t define the envirnment and general requirements f a prject r set f prjects. These are discussed belw. SWOT SWOT analysis is used t determine the strengths and weaknesses f the rganizatin, and t identify pprtunities and dangers in the frm f bth internal and external threats. Using SWOT analysis, the rganizatin may fcus its effrts n areas f strength and capitalize n pprtunities. The fur attributes f SWOT are: Strengths Weaknesses Opprtunities Threats Versin 2013 Page 68 f 105

69 CATWOE CATWOE is a technique that helps identify and analyze what the business is trying t achieve. This business perspective helps the Business Analyst understand the impact f any prpsed slutin n the peple invlved. The six elements f CATWOE are the fllwing: Custmers Actrs Transfrmatin Prcess Wrld View Owner Envirnmental Cnstraints Five Why's (5 x Why) The 5 x Why technique is used t get at the rt f what is really happening in a situatin. Fr each answer given, a further why is asked. This technique can help t identify additinal requirements and analyze requirements mre deeply. MSCW The MSCW technique priritizes requirements by allcating an apprpriate pririty expressed in the fllwing terms: Must have Shuld have Culd have Wuld like t have in the future Requirements defined as Must have and Shuld have shuld be implemented crrectly r the slutin will be rejected. Culd have requirements are nt necessary t satisfy the business needs established fr the prject, but increase delivery satisfactin. Requirements marked as Wuld like t have are less imprtant, and cnsidered as nn-crucial needs that can be planned in the future and are nt necessary nw. Other Techniques Other cmmn Business Analysis techniques are: Six Thinking Hats This technique is ften used in a brainstrming sessin t generate and analyze varius ideas and ptins. It restricts the members f the wrking grup by frcing them t think in specific ways - giving ideas and analysis in the md f the time. VPEC-T This technique is used when analyzing the expectatins f multiple parties that have different views f a system (e.g., different pririties, different respnsibilities), but in which they all have a cmmn interest. VPEC stands fr: Values, Plicies, Events, Cntent. Versin 2013 Page 69 f 105

70 8. Cmpetencies (K2) 90 minutes Terms: Dmain, facilitatin, facilitatr, sft skills Learning Objectives fr Cmpetencies The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 8.1 Dmain Knwledge (K2) LO LO Explain why business and dmain knwledge is necessary. (K2) Prvide examples fr business knwledge required fr different areas f the Business Analyst s wrk. (K2) 8.2 Sft Skills (K2) LO LO Recall cmmn sft skills required in the wrk f the Business Analyst. (K1) Explain why sft skills are necessary t achieve success as a Business Analyst. (K2) 8.3 Facilitatin Skills (K2) LO Explain facilitatin, using examples. (K2) LO Recall cmmn facilitatin techniques and tls. (K1) LO Explain when facilitatin may supprt a Business Analyst s wrk. (K2) Versin 2013 Page 70 f 105

71 8.1. Dmain Knwledge (K2) 20 minutes Sectin Learning Objectives The gal f a Business Analyst is t prvide business slutins (with r withut invlving technlgy) t business issues by assessing business prblems, and identifying and analyzing rt causes. The success f Business Analysis is determined by the benefit that the slutin prvides t the business either in terms f savings in csts, imprvement in prductivity, and/r increase in custmer satisfactin. T be able t prvide a business slutin that prvides a measurable benefit t the rganizatin, the Business Analyst must have knwledge f the business dmain. Understanding the business, its rules, prcesses, risks and cntext, is a necessary cnditin fr effective and valuable Business Analysis. Sme f the reasns why dmain knwledge is imprtant include: Dmain knwledge makes it easier fr the Business Analyst t cnnect and cmmunicate with Business Users. Dmain knwledge makes understanding and analyzing business issues easier. Lack f dmain knwledge may lead t delays in prviding the slutin, since the business prcess and business rules must first be understd. Dmain knwledge is nt a replacement fr Business Analysis methds. Bth dmain knwledge and methds knwledge are needed t be a gd Business Analyst. Related t dmain knwledge, the Business Analyst must als understand the dmain envirnment. The Business Analyst needs the fllwing skills t effectively understand and wrk within the defined envirnment (K1): Analytical skills Financial analysis Statistical analysis Operatins research Requirements analysis Systems analysis Technical skills Wrking knwledge f technlgy Understanding f engineering principles Ability t apply financial principles t feasibility studies Managerial skills Prject management capabilities Understanding f rganizatinal behavir Versin 2013 Page 71 f 105

72 8.2. Sft Skills (K2) 20 minutes Sectin Learning Objectives Business dmain knwledge, analytical skills, and experience are nt the nly factrs that determine the success f an individual as a Business Analyst. In additin t business and technical cmpetencies, the Business Analyst needs t pssess a minimum set f sft skills. This is because the wrk f a Business Analyst is clsely related t effectively cmmunicating and cperating with varius peple. Cmmn Business Analysis activities include negtiating, discussing and reslving cnflicts. The Business Analyst shuld pssess the fllwing sft skills: Negtiatin skills: Ability t negtiate t btain data Ability t negtiate with stakehlders t implement prjects Cmmunicatin and writing skills: Ability t cmmunicate with all levels f management Ability t cmmunicate with stakehlders f varius knwledge levels Precisin in articulating ideas and thughts Ability t relate with line wrkers Gd technical writing skills Strng cmmunicatin skills in all frms (verbal, nn-verbal, written, etc.) Public speaking skills In additin, the Business Analyst must be an effective facilitatr. Facilitatin skills are discussed in the next sectin. Versin 2013 Page 72 f 105

73 8.3. Facilitatin Skills (K2) 50 minutes Sectin Learning Objectives Facilitatin (K2) Facilitatin can be defined as a prcess f enabling grups t wrk cperatively and effectively. Facilitatin prvides leadership [I. Bens]. Facilitatin serves t imprve the fllwing skills [I. Bens]: Leading Slving issues Building team and cmmunity Empwering Reslving cnflicts Transfrming Evking wise demcracy Building persnal effectiveness Facilitatr (K1) A facilitatr is a persn wh cntributes structure and prcess t interactins s that grups are able t functin effectively and make high-quality decisins. The facilitatr s gal is t supprt thers and enable them t achieve high perfrmance [I. Bens]. Sme f the facilitatr s tasks and activities are [I. Bens]: Helping the grup t define its gals and bjectives Prviding prcesses t supprt members f the grup t help them use their time effectively and t make high-quality decisins Guiding grup discussins t ensure bjectives are met, and nting any ideas and cncepts raised by members during the discussin Supprting members f the grup in assessing their current skills and building new skills Using cnsensus t enable the grup t make decisins Managing cnflicts using a cllabrative apprach Helping the grup t cmmunicate effectively and t access resurces needed t make decisins The facilitatr must always stay neutral, listen actively and ask questins that allw the grup t identify and cllect ideas and cncepts. One f the facilitatr s tasks is t nte and summarize all ideas raised by the members f the grup. Versin 2013 Page 73 f 105

74 A key cmpetency f the Business Analyst is effective facilitatin. This cmpetency is cmpsed f an essential set f skills necessary fr wrking with a grup f stakehlders t elicit, dcument, analyze, verify and achieve cnsensus n requirements. In rder t be effective, a Business Analyst must als be a gd facilitatr. A gd facilitatr demnstrates the fllwing cmpetencies [I. Bens] (K1): Cmmunicates well Prcesses ideas frm peple Shws a natural interest Listens well Maintains cntrl Empwers the grup Handles uncertainty Cnnects with the grup quickly Fcuses n the business nt n persnal slutins Negtiates between parties Understands grup dynamics Helps the grup t listen and draw lgical cnclusins Runs meetings Manages peple s expectatins Understands and explains the prcess Many Business Analysts lack frmal training and experience as facilitatrs, and smetimes have difficulty running a facilitatin sessin. In the cntext f Requirements Develpment, facilitatin techniques fcus n the skills necessary t elicit and analyze the requirements fr a prject. Knwing what t ask, hw t ask, and hw t help the stakehlders discver their requirements, are all critical skills fr the Business Analyst rle Tls and Techniques f Facilitatin (K1) There are a number f techniques that are cmmnly used fr facilitatin. include [I. Bens]: Applying engagement strategies Creating participatin Generating and rganizing data Initiating reflectin Mbilizing energy Igniting actin Recrding infrmatin Applying SWOT analysis These techniques Versin 2013 Page 74 f 105

75 Sme f the tls used in facilitatin include [I. Bens]: Gap analysis Flipcharts Checklists Multi-vting Rt cause analysis Brainstrming Managing cnflicts tips sheet Fcus grup framewrk Versin 2013 Page 75 f 105

76 9. Prcess Imprvement (K2) 80 minutes Terms: Business Prcess Imprvement (BPI), Business Prcess Simulatin (BPS), ptimizatin, prcess imprvement, prcess simulatin Learning Objectives fr Prcess Imprvement The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule. 9.1 Prcess Imprvement (K2) LO LO LO Explain Prcess Imprvement and its purpse and pssible applicatins. (K2) Recall cmmn methdlgies and strategies that are useful fr Prcess Imprvement. (K1) Explain the cncept f BPI. (K2) 9.2 Prcess Simulatin and Re-design (K2) LO Explain prcess simulatin. (K2) LO Explain the rle f prcess simulatin and re-design in Business Analysis. (K2) Versin 2013 Page 76 f 105

77 9.1. Prcess Imprvement (K2) 30 minutes Sectin Learning Objectives Prcess Imprvement (K1) Prcess Imprvement supprts the intrductin f change int the current prcess in rder t imprve quality, reduce csts and/r accelerate schedules [S. Ck]. Supprting Prcess Imprvement is ne f the tasks f a Business Analyst. The Business Analyst mdels and analyzes business prcesses used within an rganizatin in rder t discver any ineffective elements. Such analysis fcuses n finding any bttlenecks, elements with excessive resurce usage, r activities that take t much time. With this knwledge, the Business Analyst is able t refine the prcess and imprve it. Imprving business prcesses may be accmplished in the fllwing ways: Manually re-design prcesses n the basis f experience and dmain knwledge with the gal f eliminating bttlenecks and making the executin times shrter and mre efficient Intrduce tls, including sftware, t ptimize the business prcesses in the rganizatin (e.g., SAP, ERP, CRM sftware) Simulate and ptimize prcesses Adpt a selected methdlgy r strategy Prcess Imprvement is a set f actins taken by a Prcess Owner t identify, analyze and imprve existing prcesses within an rganizatin t meet new gals and bjectives. Prcess Imprvement effrts ften fllw a specific methdlgy r strategy such as (K1): Benchmarking Business prcess imprvement Business prcess reengineering Capability Maturity Mdel Integratin/Capability Maturity Mdel (CMMI/CMM) ISO 9000 IT Gvernance Just In Time manufacturing Lean manufacturing Perfrmance imprvement Prcess management Prcess Imprvement and Management (PI&M) Six Sigma Ttal Quality Management (TQM) Versin 2013 Page 77 f 105

78 Business Prcess Imprvement (K1) Business Prcess Imprvement (BPI) is defined as a systematic apprach t ptimize an rganizatin s prcesses t achieve mre efficient results. The gal f Business Prcess Imprvement is t significantly change the perfrmance f an rganizatin [H. James Harringtn]. BPI is cnducted in three steps [H. James Harringtn]. (K2): 1. Define the rganizatin's strategic gals and purpses tgether with the existing structure and prcesses (define the as-is ) 2. Determine the rganizatin's custmers r stakehlders, identify what utcmes wuld add value t the rganizatin's bjectives and determine what wuld be the best way t align its prcesses t achieve thse utcmes (define the t-be ) 3. Re-rganize the business prcesses t realize the gals and meet the new bjectives, using the tls available within the BPI methdlgy There are fur rles within the BPI [H. James Harringtn]. (K2): Business Leader - The Business Leader is respnsible fr develping business plans (including strategic plans) and resurce plans needed t make the rganizatin successful. Prcess Owner - The Prcess Owner is respnsible fr designing the prcesses necessary t achieve the bjectives f the business plans created by the Business Leaders. The Prcess Owner creates, apprves and maintains the dcuments (e.g., prcedures, wrk instructins/prtcls) that supprt the prcess. Operatinal Manager - The Operatinal Manager is respnsible fr rganizing the resurces and prcesses that achieve the bjectives f the business plans created by the Business Leaders. The Operatinal Manager instructs and teaches the Prcess Operatrs hw t perfrm the prcesses. Prcess Operatr - The Prcess Operatr learns and perfrms the prcesses necessary t achieve the bjectives f the business plans that are created by the Business Leaders. The Prcess Operatr ensures that the prcesses are perfrmed t meet the prcess perfrmance bjectives and t prduce a prduct which meets the specificatins. Each f the rles has different respnsibilities but they wrk tgether. Versin 2013 Page 78 f 105

79 9.2. Prcess Simulatin and Re-design (K2) 50 minutes Sectin Learning Objectives Business Prcess Simulatin (BPS) is a part f Business Prcess Management (BPM), specifically fcused n evaluating designed and re-designed business prcesses. Business Prcess Simulatin is a technique that simulates the executin f business prcesses and their parameters ver time, based n prcess mdels. Such mdels must represent nt nly the specific elements f the business prcess, but its attributes as well (e.g., executin time, resurce usage, csts). Running such simulatins prvides a way t check hw the prcess is perfrmed, t determine the resurce usage at every step f the prcess, and t find the ptential bttlenecks and areas f instability. Business Prcess Simulatin allws the Business Analyst t understand, analyze and design (r redesign) business prcess mdels with respect t perfrmance metrics such as thrughput time, cst r resurce utilizatin. Using simulatin allws the Business Analyst t evaluate and cmpare the re-designed prcesses and t determine the best chice t implement within the rganizatin. Simulatin may be used whenever there is a need fr ptimizing the business prcesses in an rganizatin. As prcesses becme mre and mre cmplex, ptimizatin is an imprtant element fr increasing the rganizatin s perfrmance. Changing the existing prcesses, in an intuitive way, may lead t unanticipated negative results and actually lwer prcess perfrmance instead f reaching the designer s gals. Simulatin prvides quantitative estimates f the impact that a new prcess design is likely t have n prcess perfrmance. These quantitative estimates prvide a basis fr the cmparisn f the prpsed prcess(es) t help with the selectin f the ptimal slutin. The simulatin f business prcesses is perfrmed in several steps [Jansen-Vullers, Netjes] (K2): Mapping the business prcess nt a prcess mdel Identifying the sub prcesses and activities Creating the cntrl flw definitin (determining and describing the cnnectrs linking the different parts f the prcess) Identifying the resurces and assigning them t the activities Defining perfrmance characteristics (realizatin time, resurce utilizatin, etc.) After cmpleting these activities, the simulatin may be run. T ensure better and mre reliable results, the simulatin shuld be executed several times. Each executin shuld be f sufficient run length t prduce valid results. A simulatin is run in a specific tl. Mst tls shw an animated picture f the prcess flw r real-time fluctuatins in the key perfrmance measures. Simulatin tls may be selected frm the fllwing areas [Jansen-Vullers, Netjes]: Business Prcess Mdeling Business Prcess Management General simulatin tls Versin 2013 Page 79 f 105

80 After finishing the simulatin exercise, the results can be analyzed. When areas f lw perfrmance are identified, the Business Analyst may re-design the prcess flw r manipulate resurces t increase the perfrmance and ptimize the prcess. Simulatin is nt limited t re-designing and ptimizing existing prcesses within the rganizatin, but can als be used when planning t intrduce new prcesses (such as new prduct develpment), and integrating them int the current business structure. Versin 2013 Page 80 f 105

81 10. Innvatin, Design and the Custmer (K2) 60 minutes Terms: Innvatin, cntinuus innvatin, innvatin types, innvatin areas, design, design thinking, insight, cmmditizatin, multidimensinal analysis, persna, trial and errr Learning Objectives fr Innvatin, Design and the Custmer The bjectives identify what yu will be able t d fllwing the cmpletin f each mdule Rle f the Innvatin (K2) LO Define the basic aspects f innvatin. (K1) LO Explain the rle f the design fr the cmpany. (K2) LO Explain the rle f innvatin as a tl fr achieving cmpetitive advantage. (K2) LO Explain the rle f Business Analysis in innvatin. (K2) 10.2 Cmpetitin and Market Research (K2) LO LO LO LO Explain hw cmpetitin and market analysis are used as regular tls fr a Business Analyst. (K2) Explain the prcess f Market Analysis. (K2) Recall cmmn techniques fr market data cllectin. (K1) Recall basic infrmatin abut trends and their influence n the requirements. (K1) 10.3 Design Thinking (K1) LO Define design thinking. (K1) LO Define the fundamental design thinking prcess. (K1) LO Recall key attributes f the design thinking prcess. (K1) LO List sample participants f the design thinking prcess. (K1) 10.4 Basic Methds, Tls and Techniques (K1) LO Define multi-disciplinary teams. (K1) LO Define multi-vectr research. (K1) LO Define persna. (K1) Versin 2013 Page 81 f 105

82 LO LO LO LO LO LO Define insights. (K1) Define brainstrming. (K1) Define prttyping. (K1) Define enlightened trial and errr. (K1) Define strytelling. (K1) List sample persnas in the innvatin prcess. (K1) 10.5 Wrking with the Final User (K2) LO Explain why wrking with the final user is mandatry. (K2) LO Recall different techniques used fr user research. (K1) Versin 2013 Page 82 f 105

83 10.1. Rle f the Innvatin (K2) 30 minutes Sectin Learning Objectives Tday it is mre and mre difficult fr an rganizatin t achieve a cmpetitive advantage ver ther cmpanies. Traditinal prducts and services d nt ensure that an rganizatin will achieve success in the market. Mre is needed t cnvince custmers that the prducts r services delivered by a given rganizatin are better than thers Triggers fr Innvatin (K2) The key factrs that define the need t change the apprach f hw t design sftware and business slutins are [A. Richardsn]: N clear bundaries f the business. External cnditins, new cmpetitrs and sphisticated custmer expectatins frce rganizatins t extend the business area (extending the ffer) and the gegraphic area f activity (chapters and branches all ver the wrld), and t use ther cmmunicatin and distributins channels. Very ften expansin is happening in multiple new areas simultaneusly. Mre demanding custmers. Tday s custmers nt nly need a prduct; they require a prduct with high usability and with the ability t cmmunicate with ther prducts (als prduced by ther cmpanies). They want a prduct that makes them feel cmfrtable and fits int their lives. Satisfying such needs is a big challenge fr many rganizatins. Custmer needs and expectatins must cme first. Organizatins understand that custmer satisfactin is ne f the mst imprtant success factrs. There is much mre effrt allcated t meet the custmer s requirements, bth direct and hidden. T be cmpetitive, the rganizatin must nt nly satisfy the custmer, but it must make them surprised, in a psitive way, and willing t cme back t buy mre prducts and services. Mre interest in integrated systems f prducts, sftware and/r services wrking as a whle. These integrated systems are ften the keys t expansin beynd the cre areas f the rganizatin s business. It is als a way t meet custmer expectatins that culdn t be achieved by mre islated fferings. There are many questins withut any answer; there are many prblems withut a slutin. Whever finds the right answers r wrking slutin first, can achieve a cmpetitive advantage ver the cmpetitrs and get a chance t bring the rganizatin t the tp n the market. Innvatin is ne f the tls that help the rganizatin achieve a cmpetitive advantage. The Business Analyst, the persn familiar with all the business prcesses within the rganizatin and wh knws the best f all utcmes and prducts f the prcesses, can be the right persn t intrduce innvatin. Based n feedback frm custmers, market research, analysis f cmpetitrs and persnal bservatins, the Business Analyst, tgether with the supprt f ther teams, is able t identify the fllwing items: Areas that require enhancements Ptential new prducts that can be delivered by the existing prcesses Changes that will increase custmer satisfactin and ptential prfits Versin 2013 Page 83 f 105

84 Innvatin (K2) Innvatin is the prcess f renewing smething that exists. T allw this renewal, peple need t change the way they make decisins; they have t d things differently and make chices utside f their nrm. Innvatin changes the values n which the system is based [J. Schumpeter]. Innvatin is nt the intrductin f smething new; it is nt inventin, but rather the changing f smething already existing by adding value int it. The best wrld-wide recgnized definitin f innvatin, s far, says: peple implementing ideas that create new value [Innvatin Netwrk]. This apprach clearly underlines the mst imprtant elements f innvatin: There is n idea and n implementatin withut peple. An idea withut implementatin is just an idea. Implementatin f smething that des nt create new value is nt an innvatin. There are the fllwing types f innvatin: Radical (breakthrugh, destructive) Using r intrducing a new technlgy that changes an existing market, r creates a new ne, that is mst likely destructive fr the cmpetitin r ensures cmpetitive advantage Incremental (cnservative, sustaining) Intrducing small changes, based upn existing knwledge and technlgy, which allw existing prducts t remain cmpetitive, enabling shrt-term cmpetitive advantage Innvatin can be applied in the fllwing areas: Prducts (i.e., intrducing a new prduct r service t the market) Prcesses (i.e., intrducing a new, mre effective way f achieving smething) Behavir (i.e., changing hw peple perceive reality r achieve their gals) Categries f Innvatin (K1) Innvatin can be applied t many areas and can be perceived frm varius perspectives. Sme f categries f innvatin are: Degree Scpe Business area Surce Disruptive innvatin Line extensin innvatin Applicatin innvatin Enhancement innvatin Prduct innvatin Prcess innvatin Organic innvatin Acquisitin innvatin Versin 2013 Page 84 f 105

85 These categries are nt exclusive; fr example, a prcess innvatin can accmpany an acquisitin innvatin User Innvatin (K2) A specific type f innvatin is the User Innvatin. It refers t innvatin by cnsumer users (individual end-users r grups). In this case, the authr f the innvatin is the end user wh develps r refines acquired prducts and services at the site f use. This happens because mst prducts r services are designed t meet the widest pssible needs. When individual users need mre features r face prblems, they have t either buy a new prduct r intrduce their wn mdificatins t an existing prduct. Users ften share their ideas and slutins with the prducer t suggest implementing these ideas in the prduct (this is called free revealing ) [M. Bgers, A. Afuah, B. Bettina] [E. vn Hippel] Design and Innvatin Design is a term ften linked with innvatin. Similar t innvatin there is n generally-accepted definitin f design [Ralph, Wand]. It can be cnsidered in terms f the specificatin f an bject intended t accmplish gals in a particular envirnment, r in terms f a prcess that prduces such specificatins. Depending n the cntext, the wrd design is ften cnsidered t be ambiguus. Frm a business perspective, design shuld be cnsidered as the prcess which allws the cmpany t achieve a cmpetitive advantage in the different stages f the cmpany s life by: Slving user r custmer prblems in the creative way Creating unique value and an unfrgettable (psitive) user experience Jining functinality, aesthetics, ergnmics and user experience with the frm Distinguishing the cmpany frm the cmpetitrs Design methds and techniques can be applied t all pssible aspects and disciplines f human life, frm new prduct design thrugh prcess r service design, t fashin, urban and industrial design. Hw d innvatin and design relate t Business Analysis? The wrld and business envirnment are changing in a fast way. In a cmpetitive envirnment, simply gathering r meeting the business requirements might nt be enugh. Cmpanies nw realize that they need t fcus n the design, innvatin and the custmer (wh is placed in the heart f bth f these disciplines), if they want t leave the cmpetitin behind. In additin what ne day seems t be mst wanted can turn int a cmmn gd very quickly, due t cmmditizatin. In rder t preserve a leading psitin, cmpanies shuld nt nly use innvatin and design, but shuld develp the innvatin and design culture t achieve cntinuus innvatin. Des it mean that Business Analysis is nt needed anymre? Nt at all. Business Analysis is imprtant and shuld always be dne in the best pssible way, but it is nw ften cnsidered t be smething bvius, regular and expected due t the cmmditizatin prcess. Prper Requirements Elicitatin, Analysis and Dcumentatin are still crucial fr a prject s success but accrding t a large Bstn Cnsulting Grup survey, nine ut f ten senir executives believe that lng-term cmpany grwth, and its survival in the challenging market, depends n innvatins [Ten faces f innvatin]. Versin 2013 Page 85 f 105

86 10.2. Cmpetitin and Market Research (K2) 30 minutes Sectin Learning Objectives One f mst effective tls fr achieving cmpetitive advantage is market analysis and research. Business Analysts shuld be familiar with these tls and be able t use them in planning new prducts, r imprvements in rganizatin prcess r prductin Market Research (K2) Market Research is a structured activity with the purpse f gathering infrmatin abut markets r custmers. Market Research is a very imprtant cmpnent f a business strategy (being a part f a Business Analyst s areas f interest) [E. McQuarrie]. Accrding t ICC/ESOMAR Internatinal Cde n Market and Scial Research, Market Research prvides a systematic way t gather and interpret infrmatin abut individuals r rganizatins, using statistical analytical methds and techniques. This infrmatin supprts making decisins abut the future curse f the rganizatin [ICC/ESOMAR]. Market Research is cnsidered the key factr t gain advantage ver cmpetitrs. It prvides imprtant infrmatin t identify and analyze the market s needs, the market size and the cmpetitin. Market Research discvers what peple (nt nly the custmers f a given rganizatin) need and hw they act. Sme f the instruments fr Market Research are questinnaires and fcus grup discussin surveys. Once that research is cmpleted, the results, such as discvered trends, may be used t determine the future curse f the Business Strategy Market Analysis (K2) Market Analysis is a structured and dcumented investigatin f a market [Dillerup, Sti]. It is a great help when new prducts r an expansin f the business is planned. It determines if there is a need r audience fr a prduct r service. Market Analysis prvides infrmatin abut the market's needs and hw thse needs are currently serviced. This is essential fr planning and develping new prducts r services. The gal f a Market Analysis is t determine the attractiveness f a market, bth nw and in the future. In this way the rganizatin may discver and understand evlving pprtunities and trends, and match them with the rganizatin's strengths and weaknesses. Market Analysis can be used t: Prepare t enter a new market (expansin) Determine if there is a market fr new prducts r services, and evaluate the chance fr the success f intrducing a new prduct r service, r intrducing changes (innvatins) int existing nes Plan t start a new business Establish the need fr develping a marketing plan Obtain market infrmatin that will assist in the sale f the prduct r service There are several dimensins f a Market Analysis; each may be used fr different purpses (e.g., evaluating market prfitability r determining market trends). These dimensins are [D.A. Aaker]: Versin 2013 Page 86 f 105

87 Market size (current and future) Market grwth rate Market prfitability Industry cst structure Distributin channels Market trends Key success factrs Market Research and Analysis Prcess (K2) The Market Research and Analysis prcess specifies the fllwing steps: Define the prblem Analyze the situatin Obtain data and infrmatin specific t the prblem Analyze and interpret the infrmatin Frmulate ideas and slutins fr prblem Design a plan It is very imprtant fr the Business Analyst t crrectly define the prblem, and t btain reliable and useful data abut the given issue. Only then can further analysis give adequate and usable results that help in decisin making. Many appraches may be used t cllect data. The gal f such research is t determine what custmers think abut sme tpics (fr example, abut the usability f a prduct), r t define usage patterns. The research can be dne in persn r thrugh a survey, depending n the area and scpe f the stated prblem and the current needs and pprtunities f the rganizatin. Questining can be qualitative r quantitative. An effective apprach t cnducting market research is t use bservatin f custmers and their purchases r utilizatin f a prduct r service Techniques fr Cllecting Market Data (K2) Sme techniques fr cllecting market data are: Qualitative research (pen-ended questins t btain in-depth answers) Quantitative research Mail questinnaires Telephne surveys Persnal interview surveys Observatin Results frm the Market Research and Analysis prcesses may be used t determine market trends. Versin 2013 Page 87 f 105

88 Trends (K1) A trend is a tendency f a market, r specific prduct r service, t mve in a particular directin ver time [G. Fntanills and T. Gentile]. These trends are classified as: Lng term trend Medium term trend Shrt term trend Glbal trend By analyzing the identified trends, the Business Analyst is able t predict the desired future slutins and plan their prductin and implementatin. Therefre, trends affect business requirements as they may determine the future extensins f a prjected slutin. Future trends may als affect the current slutin in rder t prepare it fr later enhancements. Versin 2013 Page 88 f 105

89 10.3. Design Thinking (K1) 30 minutes Sectin Learning Objectives The cmbinatin f design and innvatin is Design Thinking. It is a methdlgy fr practical, creative reslutin f prblems r issues fr an imprved future result [Simn Herbert]. Anther definitin describes Design Thinking as the cllabrative prcess by which the designer s sensibilities and methds are emplyed t match peple s needs with what is technically feasible and a viable business strategy. Design Thinking cnverts needs int demands [Change by design]. Design Thinking is a team-riented discipline, and is based n the idea that it is better t have five peple wrking tgether fr ne day than ne persn wrking alne fr five days. The success f the Design Thinking methdlgy depends n several factrs, including simplicity, prven effectiveness, reasnable csts, and adaptability fr different types f rganizatins. The prcess can be described in three majr phases: inspiratin, ideatin and implementatin Design Thinking Inspiratin (K1) It s hard t cme up with creative and innvative ideas while sitting at a desk; that s why designers are encuraged t lk fr inspiratin in all available places. It is imprtant that the inspiratin phase is perfrmed frm the user and custmer perspective, withut business cnstraints. The main gal f the inspiratin phase is t gather insights frm custmers. These insights are later used as the basis fr inspiratins and, after that, fr innvatin which will result in a cmpetitive advantage fr the cmpany. The purpse f gathering insights is t enable inspiratin and innvatin; therefre, encuraging creativity and discuraging criticism amng the team members are desired. By the end f the inspiratin phase the team shuld: Be clear n wh, r what, is the target f the prject Have a deep understanding f the prblem frm the rganizatin and custmer perspective Have gathered insights that will be used in the later phases f the prcess Have knwledge abut the pprtunities and cnstraints Have dcumentatin f their research (e.g., pictures, mvies) Design Thinking Ideatin (K1) The gal f the ideatin phase is t take the insights frm the first phase, analyze them and prduce ideas which later becme a part f the slutin t the prblem at hand. The slutin shuld satisfy the needs f the custmer and the rganizatin (cmpetitive advantage). Team members are encuraged t prpse as many ideas as pssible (i.e., during a brainstrming sessin). It is crucial during the ideatin phase t restrain frm judgment when new ideas emerge. Even when ne idea seems t be in cntradictin t anther, infeasible, r even silly, it shuld nt be rejected. The team can use these questinable ideas as a surce fr further inspiratin. Designers ften emply tls that can be used t supprt their ideas (e.g., stries, sketches, prttypes). At the end f the ideatin phase, the decisin is made regarding which ideas will becme part f the final slutin. This is ften dne by having the team members vte n the varius ideas. The primary tl f the ideatin phase is prttyping, which is used t prttype the best ideas and slutins. Versin 2013 Page 89 f 105

90 Design Thinking Implementatin (K1) In the implementatin phase the prttypes shuld be stable and be ready fr further testing and verificatin by the users. The gal f the implementatin phase is t cnvince the rganizatin and stakehlders that the prpsed slutins meet their expectatins, and ensure success after release t the market. The best way t achieve this gal is t use strytelling; a persuasive technique crucial t achieving stakehlder understanding. Design Thinking is smetimes brken int seven stages: define, research, ideate, prttype, chse, implement and learn. Fr the purpse f the Fundatin Level syllabus the three-stage apprach is assumed. Versin 2013 Page 90 f 105

91 10.4. Basic Methds, Tls and Techniques (K1) 30 minutes Sectin Learning Objectives Multidisciplinary Teams (K1) Multidisciplinary Teams are ne f the critical factrs that enable innvatin. As the name says, the team shuld cnsist f peple frm varius, mst likely cmpletely different, functinal areas (e.g., engineering, legal, finance, art, marketing, chemistry, scilgy). This diversity f viewpints is beneficial when the bservatins are made, insights are gathered, and ideas are generated. It is als cmmn t rganize the teams arund the explicit prblem rather than a leader. Since leadership ften is fluent and depends n the given situatin, all f the team members shuld be independent in their tasks and able t prceed with minimal guidance. T ensure the mst effective cllabratin, team members shuld be able t cmmunicate clearly with each ther (e.g., avid technical jargn), play by the same rules (e.g., n judgment r criticism when the ideas are generated, take thers ideas and build n them), and enter the prject with the same apprach (e.g., enthusiasm, ptimism, excitement). Multidisciplinary teams wrk best with clear, but nt narrw, gals and challenging terms Multi-Vectr Research (K1) While gathering data that is needed t prpse the best slutin which wuld have a chance t ensure cmpetitive advantage, it is imprtant t cnsider all available pints f view and surces f infrmatin. The best way t gain a 360-degree pint f view is t use a Multi-Vectr Research tl. The idea behind the tl is simple: create a number f vectrs which allw yu t research the prblem at hand frm several directins, and then synthesize thse vectrs t uncver insights. When using multi-vectr research it is imprtant t pursue all the vectrs at the same time with the same team and with a mixture f qualitative and quantitative tls. In this way, the true ptential f this methd can be realized. A set f typical vectrs used in Multi-Vectr Research includes: Custmers Cmpetitrs Cmparatives Brands Organizatin tlbx Technlgy Sales and Retail Trends The best way t d the multi-vectr research is t use multidisciplinary teams, where a persn wh is an expert with ne vectr des the analysis f the vectr that is utside f his r her specialty. This tl has been widely described in [A. Richardsn]. Versin 2013 Page 91 f 105

92 Persnas (K1) Persnas are yet anther pwerful tl used t get a better view f the prblem frm the custmer s perspective. Accrding t the definitin, a persna is a fictinal character (an archetype descriptin), which represents ne f the different types f users wh will be using the final prduct r slutin. A persna shuld represent a grup f peple with the same needs, attitudes, behavirs r expectatins tward the prduct. Persnas shuld be defined and emplyed in the very beginning f the prject. Defined persnas help with such tasks as knwing the types f peple t hire fr interviews, hw t design the research areas and methds, and hw t prperly set pririties fr the requirements. Each rganizatin can define the persnas in the way it finds suitable fr the current prject r prblem at hand. Once the apprpriate persnas are defined, it is imprtant that they be used and nt left in the crner t gather dust [Inspired] Insights (K1) Custmer insights are the basis fr inspiratin and innvatin. The first rule regarding insight gathering is t always examine frm the custmer s pint f view. The best way t gather insights is t enter the anthrplgist s shes and submerge int the custmer s wrld, embrace the custmer s needs, fears, emtins and prblems. This is the best way, and actually the nly reasnable way, because nly by experiencing the given event first hand, and by lking at it with fresh eyes, can the anthrplgist be truly sure that they have slid material fr further analysis, untainted with cmmn knwledge, assumptins r speculatins. There are many surces f insights available: custmers and their feelings, needs, values and prblems, extreme users and utliers, children, yungsters, the elderly, mega trends and all kinds f general trends, cmpetitin, technlgy, cmplementing and cmparable rganizatins and many mre. The mst valuable insight is ne that is relevant fr the custmer and the cmpany, and that yields unique infrmatin Brainstrming (K1) Brainstrming is a widely adpted technique used fr generating a large number f ideas fr the slutin f defined prblems. There are three imprtant rules fr brainstrming sessins: Refrain frm judgment and criticism twards ideas presented by team members. Build new ideas n the ideas prvided by thers, while refraining frm criticizing. Wild and crazy ideas are welcme and encuraged. Brainstrming sessins are mre abut quantity than quality. The bigger the number f generated ideas, the better the brainstrming sessin. Brainstrming sessins are mre likely t be facilitated than mderated Prttyping (K1) A Chinese prverb says that ne picture is wrth a thusand wrds ; the same rule can be applied t prttyping. Using prttypes can better explain and present ideas r slutins t thers, cme up with new ideas (during the prttyping), test the slutin, gather the feedback frm the stakehlders and custmers, etc. The advantages f prttyping are bvius. In mst cases the designers will need t create dzens if nt hundreds f prttypes befre achieving satisfying results, therefre, the prttypes shuld be easy, quick and cheap t create (paper prttyping is a Versin 2013 Page 92 f 105

93 pwerful tl). It shuld be remembered that in the cncept phase, the gal f the prttyping is nt t create a final prttype but t create smething that can be easily tested, evaluated and mst prbably destryed afterwards. Creating and destrying a large number f prttypes des nt mean failure, rather it means that the team is learning abut the strengths and weaknesses f an idea, with each subsequent prttype being better than its predecessr as the team appraches the final slutin. Prttyping encurages an iterative apprach t the prblem slutin Enlightened Trial and Errr (K1) Usually the best slutin desn t cme first. James Dysn created 5127 prttypes f his vacuum cleaner befre he was satisfied with the result. Trial and Errr is the prcess f btaining knwledge by generating/prttyping slutins, testing them and learning frm the mistakes. The testing f the slutin is perfrmed using the dispsable prttypes. One f the slgans explaining the idea f Trial and Errr says fail ften in rder t succeed sner and is based n the assumptin that a quick verificatin f the slutin, even if unsuccessful, brings better results than trusting in the plans f the lne genius. [IDEO] Strytelling (K1) Strytelling is a persuasive technique used t cnvince the listener t supprt the arguments f the stryteller. Stries are based n assumptins r the real situatins that were experienced during the research phase. The stries are wrapped arund the prduct, the user and the user s experience. Using the mtt shw, dn t tell, the stryteller emplys pictures, vides, sketches, etc. t tell the stry. The gal f a gd stry is t sell an idea t the thers, mtivate them t d wrk, and encurage them t make hard decisins Sample Persnas in the Innvatin Prcess (K1) Althugh there is n single wrld-recgnized innvatin prcess, sme f the elements are cnsistent regardless f the apprach t innvatin. Basing n 27 years f experience IDEO defined ten rles, r s called persnas, that seem t cntinuusly emerge n innvatin prjects. These ten innvatin persnas are brken int three grups [IDEO]: The learning persnas: The Anthrplgist One wh is a true bserver f human nature, gathering insights by getting int the shes f the persn t be bserved and actually living their lives fr a while. The Experimenter One wh adds sme flesh and bnes t the ethereal ideas. His jb is t prttype, experiment and imprve the slutin using the trial and errr prcess. The Crss-Pllinatr One wh takes a dive int ther industries and cultures t return with findings that can be used t benefit the enterprise. The rganizing persnas: The Hurdler One wh understands that keeping innvatin alive is nt an easy task and uses all means available t remve the bstacles that culd delay r stp the innvatin prcess. The Cllabratr One wh is able t rganize, supprt and cach the prject team and is ften invlved in remving the danger f skepticism flwing frm the rganizatin. Versin 2013 Page 93 f 105

94 The Directr One wh sheds the light f innvatin in the rganizatin, builds the innvatin culture in the rganizatin, and encurages peple and leads them tward his visin. The building persnas: The Experience Architect One wh is respnsible fr delivering the prduct t the custmer and creates a unique experience that stays in the custmer s mind even after the prduct itself is lng gne. The Set Designer One wh prvides the physical stage with the best cnditins fr creative wrk and creates places where innvatin can cme t life. The Caregiver One wh gives special care t the custmer s needs, keeps the fcus n the custmer, anticipates his needs, and always puts him first. The Stryteller One wh prvides the gd stry that helps t pen the sealed dr, cnvinces thers f the idea, launches a prject r builds a visin and increases the mrale f the team. These are nt all f the persnas that can appear in the areas related t innvatin. Hwever, they give an idea f what is needed fr innvatin t happen. The detailed descriptin f each persna can be fund in [Ten faces f innvatin]. Versin 2013 Page 94 f 105

95 10.5. Wrking with the Final User (K2) 20 minutes Sectin Learning Objectives One f the main tasks f a Business Analyst is t prvide a business design f a slutin that will satisfy the custmer s needs and expectatins. T be able t d s, the Business Analyst must knw these needs. This includes nt nly thse articulated directly but als the hidden expectatins f which the custmer may nt be aware. The rle f a Business Analyst is t wrk with the end users t identify and explre their requirements and prvide supprt fr frmulating their varius needs. Fr example, wrking with the end users may help t identify usability requirements that were nt determined in the initial requirements cllecting phase. User research may be dne using the same techniques as Market Research. Particularly these are (K1): Custmer feedback Qualitative research Quantitative research Mail questinnaires Telephne surveys Persnal interview surveys Observatin Direct wrk with the end users n site (assisting in perating r using the slutin) Versin 2013 Page 95 f 105

96 11. References Standards [CMMI] Chrissis, M.B., Knrad, M. and Shrum, S. (2004) CMMI, Guidelines fr Prcess Integratin and Prduct Imprvement, Addisn Wesley: Reading, MA See Sectin 2.1 [IEEE 1028] IEEE Std. 1028, IEEE Standard fr Sftware Reviews and Audits See Sectin 3.2 [IEEE 12207] IEEE 12207/ISO/IEC , Sftware Life Cycle Prcesses See Sectin 2.1 [IEEE 1042] IEEE Std IEEE Guide t Sftware Cnfiguratin Management [ISO 25000] ISO (ISO/IEC :2001), Sftware Engineering Sftware Prduct Quality See Sectin 2.3 [BS 7000] BS :1999 Guide t managing innvatin Bks and Other Publicatins [IQBBA Glssary] Standard glssary f terms used in Sftware Engineering Versin 1.0 [ISTQB Glssary] ISTQB Glssary f Testing Terms 2.1 [A. Richardsn] A. Richardsn (2010), Innvatin X. Why a cmpany's tughest prblems are its greatest advantage, Jssey-Bass [Becker J., Kugeler M., and Rsemann M.] J. Becker, M. Kugeler, and M. Rsemann (2003), Prcess Management - A guide fr the design f business prcesses. Springer-Verlag: Berlin [BABOK] Internatinal Institute f Business Analysis (2006), A guide t the Business Analysis Bdy f Knwledge, versin 1.6 [BDictinary] [C.L. Rhdes] Rhdes C.L., The Prcess Simulatin Revlutin: Thermphysical Prperty Needs and Cncerns, J.Chem.Eng.Data, 41, , 1996 [Change by design] T. Brwn, Change by Design: Hw Design Thinking Transfrms Organizatins and Inspires Innvatin, HarperCllins, 2009, ISBN [D.A. Aaker] D.A. Aaker (2007), Strategic Market Management, ISBN [Dillerup, Sti] Dillerup, R., Sti, R. Unternehmensführung, 2006, München: Vahlen. [E. McQuarrie] E. McQuarrie (2005), The market research tlbx: a cncise guide fr beginners (2nd ed.), SAGE, ISBN Versin 2013 Page 96 f 105

97 [E. vn Hippel] E. vn Hippel (1986), Lead users: a surce f nvel prduct cncepts, Management Science 32: [Entrepreneur] Defining Yur Business Gals, [Freedman and Weinberg] D. Freedman and G. Weinberg, Walkthrughs, Inspectins, and Technical Reviews, Drset Huse Publishing, 1990, ISBN [G. T, Dran] Dran, G. T.. There's a S.M.A.R.T. way t write management's gals and bjectives. Management Review, Vlume 70, Issue 11, 1981, (AMA FORUM), pp [G. Fntanills and T. Gentile] G. Fntanills and T. Gentile (2001), Start Market Curse, Gerge Fntanills, Tm Gentile, Jhn Wiley and Sns Inc. [Gilb and Brdie RQNG] T. Gilb and L. Brdie (2010), What s fundamentally wrng? Imprving ur apprach twards capturing value in requirements specificatin [Gilb, Cmpetitive Engineering] T. Gilb (2005), Cmpetitive Engineering: A Handbk fr Systems Engineering, Requirements Engineering, and Sftware Engineering using Planguage, Elsevier Butterwrth-Heinemann [Gilb, Real] T. Gilb, Real Requirements, see [H. James Harringtn] H. James Harringtn, Business Prcess Imprvement: The Breakthrugh Strategy fr Ttal Quality, Prductivity, and Cmpetitiveness, 1991 [ICC/ESOMAR] ICC/ESOMAR (2008), Internatinal Cde n Market and Scial Research. ICC/ESOMAR Amsterdam, the Netherlands, 4th ed. See: [I. Bens] I. Bens, Facilitatin at a Glance, 2 nd editin, 2008 [Inspired] M. Cagan, Inspired: Hw t create prducts custmers lve, SVPG Press, 2008, [J. Schumpeter] J. Schumpeter (1934). The Thery f Ecnmic Develpment. Cambridge, MA: Harvard University Press [Jansen-Vullers, Netjes] M.H. Jansen-Vullers and M. Netjes, Business Prcess Simulatin - A Tl Survey, Department f Technlgy Management, Eindhven University f Technlgy, /Paper/Business-Prcess-Simulatin-A-Tl-Survey.pdf [Jhn W. Budd] Jhn W. Budd Mind Maps as Classrm Exercises, The Jurnal f Ecnmic Educatin, Vl. 35, N. 1 (Winter, 2004), pp Published by: Taylr & Francis, Ltd. Article Stable URL: [K. Ishikawa] K. Ishikawa (1990), Intrductin t Quality Cntrl, ISBN X OCLC [M. Bgers, A. Afuah, B. Bettina] M. Bgers, A. Afuah, B. Bettina (2010), Users as innvatrs: A review, critique, and future research directins, Jurnal f Management 36 (4): [Ralph, Wand] P. Ralph and Y. Wand, A Prpsal fr a Frmal Definitin f the Design Cncept, Springer Berlin Heidelberg, 2009, ISBN [S. Ck] Ck, Sarah, Prcess imprvement: a handbk fr managers. Gwer Publishing Ltd, et al.. Retrieved February 4, ISBN [Simn Herbert] S. Herbert, The Sciences f the Artificial, Cambridge: MIT Press, 1969, ISBN [Sparx] The Business Prcess Mdel, see: Versin 2013 Page 97 f 105

98 [SRS] Checklist] Sftware Requirements Specificatin Checklist [T. Pyzdek and P. A. Keller] T. Pyzdek and P. A. Keller (2009), The Six Sigma Handbk, Third Editin, New Yrk, NY: McGraw-Hill, ISBN [T. Simn, J. Streit, and M. Pizka] T. Simn, J. Streit, and M. Pizka, Practically Relevant Quality Criteria fr Requirements Dcuments, itestra GmbH, Ludwigstr. 35, Kaufering, Germany [TGilb] see: Planguage Cncept Glssary [Ten faces f innvatin] T. Kelly and J. Littman, The Ten Faces f Innvatin: IDEO's Strategies fr Defeating the Devil's Advcate and Driving Creativity Thrughut Yur Organizatin, Dubleday, ISBN [Tlbx] [Wikipedia] retrieved Versin 2013 Page 98 f 105

99 12. Appendix A Learning Objectives/Cgnitive Level f Knwledge The fllwing learning bjectives are defined as applying t this syllabus. Each tpic in the syllabus will be examined accrding t the learning bjective fr it. Level 1: Remember (K1) The candidate will recgnize, remember and recall a term r cncept. Keywrds: Remember, retrieve, recall, recgnize, knw Level 2: Understand (K2) The candidate can select the reasns r explanatins fr statements related t the tpic, and can summarize, cmpare, classify, categrize and give examples fr the testing cncept. Keywrds: Summarize, generalize, abstract, classify, cmpare, map, cntrast, exemplify, interpret, translate, represent, infer, cnclude, categrize, cnstruct mdels Level 3: Apply (K3) The candidate can select the crrect applicatin f a cncept r technique and apply it t a given cntext. Keywrds: Implement, execute, use, fllw a prcedure, apply a prcedure Reference (Fr the cgnitive levels f learning bjectives) Andersn, L. W. and Krathwhl, D. R. (eds) (2001) A Taxnmy fr Learning, Teaching, and Assessing: A Revisin f Blm's Taxnmy f Educatinal Objectives, Allyn & Bacn Versin 2013 Page 99 f 105

100 13. Appendix B Rules Applied t the IQBBA Fundatin Syllabus The rules listed here were used in the develpment and review f this syllabus. (A TAG is shwn after each rule as a shrthand abbreviatin f the rule.) General Rules SG1. The syllabus shuld be understandable and absrbable by peple with zer t six mnths (r mre) experience in Business Analysis. (6-MONTH) SG2. The syllabus shuld be practical rather than theretical. (PRACTICAL) SG3. The syllabus shuld be clear and unambiguus t its intended readers. (CLEAR) SG4. The syllabus shuld be understandable t peple frm different cuntries, and easily translatable int different languages. (TRANSLATABLE) SG5. The syllabus shuld use American English. (AMERICAN-ENGLISH) Current Cntent SC1. The syllabus shuld include recent Business Analysis cncepts and shuld reflect current best practices in Business Analysis where this is generally agreed. The syllabus is subject t review every tw t five years. (RECENT) SC2. The syllabus shuld minimize time-related issues, such as current market cnditins, t enable it t have a shelf life f tw t five years. (SHELF-LIFE). Learning Objectives LO1. Learning bjectives shuld distinguish between items t be recgnized/remembered (cgnitive level K1), items the candidate shuld understand cnceptually (K2), and items the candidate shuld be able t practice/use (K3. (KNOWLEDGE-LEVEL), LO2. The descriptin f the cntent shuld be cnsistent with the learning bjectives. (LO- CONSISTENT) LO3. T illustrate the learning bjectives, sample exam questins fr each majr sectin shuld be issued alng with the syllabus. (LO-EXAM) Overall Structure ST1. The structure f the syllabus shuld be clear and allw crss-referencing t and frm ther parts, frm exam questins and frm ther relevant dcuments. (CROSS-REF) ST2. Overlap between sectins f the syllabus shuld be minimized. (OVERLAP) ST3. Each sectin f the syllabus shuld have the same structure. (STRUCTURE-CONSISTENT) ST4. The syllabus shuld cntain versin, date f issue and page number n every page. Versin 2013 Page 100 f 105

101 (VERSION) ST5. The syllabus shuld include a guideline fr the amunt f time t be spent in each sectin (t reflect the relative imprtance f each tpic). (TIME-SPENT) Versin 2013 Page 101 f 105

102 14. References SR1. Surces and references will be given fr cncepts in the syllabus t help training prviders find ut mre infrmatin abut the tpic. (REFS) SR2. Where there are nt readily identified and clear surces, mre detail shuld be prvided in the syllabus. Fr example, definitins are in the Glssary, s nly the terms are listed in the syllabus. (NON-REF DETAIL) Surces f Infrmatin Terms used in the syllabus are defined in Standard Glssary f Terms used in Sftware Engineering. A versin f the Glssary is available frm IQBBA. A list f recmmended bks n Business Analysis is als issued in parallel with this syllabus. The main bk list is part f the References sectin. Versin 2013 Page 102 f 105

103 15. Appendix C Ntice t Training Prviders Each majr subject heading in the syllabus is assigned an allcated time in minutes. The purpse f this is bth t give guidance n the relative prprtin f time t be allcated t each sectin f an accredited curse, and t give an apprximate minimum time fr the teaching f each sectin. Training prviders may spend mre time than is indicated and candidates may spend mre time again in reading and research. A curse curriculum des nt have t fllw the same rder as the syllabus. The syllabus cntains references t established standards, which must be used in the preparatin f training material. Each standard used must be the versin quted in the current versin f this syllabus. Other publicatins, templates r standards nt referenced in this syllabus may als be used and referenced, but will nt be examined. The specific areas f the syllabus requiring practical exercises are as fllws: 2. Enterprise Analysis 2.5 Determining Slutin Scpe and Apprach 3. Business Analysis Prcess Planning 4. Elicitatin 3.2 Requirements Management Prcess Planning 3.3 Cnfiguratin and Change Management Prcess 4.1 The Cncept f Requirements Elicitatin 4.4 Requirements Dcumentatin 5. Requirements Analysis 5.2 Mdeling and Specificatin 7. Tls and Techniques 7.2 Business Analysis Techniques 8. Cmpetencies 8.3 Facilitatin skills 9. Prcess Imprvement 9.2 Prcess Simulatin and Re-design 10. Innvatin, Design and the Custmer 10.2 Cmpetitin and Market Research Versin 2013 Page 103 f 105

104 Index Assessment, 18, 25, 31, 64, 65 Baseline, 46, 47 BPM, 58, 81 BPS, 81 Brainstrming, 42, 43, 45, 77, 84, 94 Business Analysis, 1, 2, 7, 9, 10, 12, 13, 14, 15, 18, 24, 33, 34, 42, 43, 54, 67, 68, 70, 71, 73, 74, 83, 103 Business Analysis techniques, 42, 67, 71 Business Analyst, 1, 3, 7, 9, 12, 13, 14, 15, 16, 19, 24, 27, 32, 33, 37, 38, 40, 48, 49, 50, 51, 55, 57, 60, 61, 62, 63, 66, 68, 69, 70, 71, 72, 73, 74, 76, 79, 82, 85, 88, 89, 90 Business Case, 25, 28, 30 Business Gal, 26 Business Need, 26, 27 Business needs, 12, 20 business prcess, 20, 25, 34 Business Prcess Management, 58, 81 Business Prcess Simulatin, 81 CATWOE, 71 Change Cntrl Bard, 33, 40, 41 Change List, 40 Change Lg, 40 Change Management, 33, 37, 38, 39, 47, 52 Change Request, 39, 40 Cnfiguratin Management, 33, 38, 39, 98 defect, 9 Design Thinking, 83, 91, 92, 98 Enterprise Analysis, 14, 18, 20, 24 Facilitatin, 72, 75 Five Why's, 71 IEEE 1233, 53 IEEE 1362, 53 IEEE 830, 53 Innvatin, 85, 86, 87, 98 Insights, 84, 94 ISO 25000, 45, 53 ISO 9126, 53, 98 learning bjective, 8, 9, 20, 33, 43, 54, 64, 67, 72, 78, 83, 100, 101 Market Analysis, 83, 88 Market Research, 88, 89 Mind mapping, 69 Mdeling tls, 42, 67, 68 MSCW, 71 MOST, 70 Multidisciplinary Teams, 93 Multi-Vectr Research, 93 Persna, 83, 94 PESTLE, 67, 70 Prduct Breakdwn Structure, 32 Prttyping, 42, 58, 69, 84, 94, 95 Quality assurance, 22, 36, 54, 62 Quality criteria, 62 Requirement, 15, 43, 44, 48, 51, 67, 68 Requirement acceptance, 44, 51 Requirement Management, 68 Requirement management tls, 67 Requirements Analysis and Dcumentatin, 18 Requirements Cmmunicatin, 18, 19, 51 Requirements dcumentatin, 43, 49 Requirements Elicitatin, 16, 18, 43, 45 Requirements Engineering, 10, 33, 36 Requirements Planning and Management, 18 Requirements scpe, 43, 46 Versin 2013 Page 104 f 105

105 review, 101 RTM, 48, 65 Six Thinking Hats, 71 SMART, 26 slutin scpe, 20, 21, 29, 32 Stakehlder, 20, 22, 49 Stakehlders, 11, 22, 23, 34 Standards, 44, 49, 53, 98 Strytelling, 84, 95 SWOT, 42, 70, 76 System Interface Analysis, 32 Traceability, 16, 48, 65 Trend, 90 Trial and Errr, 83, 95 Validatin, 18, 61, 64, 66 Verificatin, 54, 61 Wrk Breakdwn Structure, 32 Versin 2013 Page 105 f 105