Important Terminology and Concept to Note

7/30/2019 Important Terminology and Concept to Note

1/49

BABOK v 2.0

IMPORTANT TERMINOLOGY

& CONCEPT TO NOTE

Created By: Emmanuel Omudu

1


2/49

A business analyst can exist anywhere in anorganization, not necessarily in project department or ITdepartment alone.

Anywhere a business problem needs to be solved, then

a business analyst will be needed in that area. A business analyst work can start before even the

project starts.

The activities are not intended to be performed in linear

fashion

BA activities are PROGRESSIVELY ELABORATED(i.e.. Continuously and constantly modified)

2


3/49

Requirements

Requirement A Condition or Capability needed by thestakeholder to solve a problem or to achieve an objective

Requirements focuses on Three Cs Capability something needed to solve a problem

Conditions something that determines a possible outcome

Constraints limits and boundaries

Capability = Functional Requirements

Condition + Constraints = Non functional Requirements.

3


4/49

Requirements classes:

Business Requirement (Highest level, high level goals)

Stakeholders Requirement (Define the needs of theStakeholders)

Solutions Requirement (Detail type of Requirement, describesthe solutions to meet the high level requirements)

Functional Requirements (capabilities of the solution)

Non Functional Requirements (Constraints and conditions

of the solutions) Transitional Requirements (solutions capabilities to transition

from current state to the future state).

4


5/49

Project phases and Business Knowledge Areas arenot the same thing.

KNOWLEDGE AREAS

Business Analysis Planning and Monitoring

Enterprise Analysis Elicitation

Requirement Analysis

Requirement Management and Communication

Solutions assessment and validation

BEaRERS BEaRERS of Good news

5


6/49

KNOWLEDGE AREAS (Contd)

They describe what the business analyst must do

Content of each knowledge areas will be described based

on this structure as we move on in the course: Tasks sets of tasks to be performed

Inputs information or preconditions required by a task

Elements detailed concepts necessary to perform tasks.

Techniques The many ways the tasks may be done

Stakeholders who may be involved in the tasks

Outputs results that are created when tasks are performed.

6


7/49

7

Lesson 2:

Business Analysis

Planning and Monitoring

Purpose:

- Provide the Business Analyst with knowledge of the skills

used to plan for business analysis activities.

- Educate the Business Analyst on Change Mgt. and Control

Objective:

- Understand the team roles for the project

- Be able to plan for requirement activities

- Identify the deliverables to be produced and coordinate with

other project work.

- Understand requirements risk planning

- Be able to plan for requirements communication

- Be able to monitor and report on requirement activities


8/49

8


Enterprise-Wide Planning

Identifies and name projects. This is usually a collaborative effort involving variousdepartments: marketing, information technology, one or more business areas ordomains.

Project Planning and Scope Definition

Determines known and unknown information about the project. It determines theproject scope: statement of purpose, objectives, problem and opportunities,stakeholders, external interaction high-level processes, business and project risks, anditems out-of-scope.

Prepare the project initiation documentation: scope, methodology/approach, intendedaudience, project stakeholders, and their roles, requirement rules and guidelines.

Initiate scope change management.Business Analysis Planning

Plan for requirement gathering and elicitation and, if necessary, start designingand modifying requirement templates.

Planning Overview


9/49

9


Plan Business Analysis Approach

Conduct Stakeholders Analysis

Plan Business Analysis Activities

Plan Business Analysis Communication

Plan Requirement Management Process

Manage Business Analysis Performance

What are the skills (tasks) needed to perform

Business Analysis Planning and Monitoring ?


10/49

10

IIBA Operational VisionBusiness Analysis Planning and Monitoring


11/49

11

Plan Business Analysis Approach

Purpose: This task describes how to select an approach toperforming business analysis, which stakeholders need to beinvolved in the decision, who will be consulted regarding andinformed of the approach, and the rationale for using it.

Description: Business analysis approaches describe theoverall process that will be followed to perform businessanalysis work on a given initiative, how and when tasks willbe performed, the techniques that will be used, and thedeliverables that should be produced.


12/49

Approach:

Plan Driven Everything is planned before the workbegins

Change Driven Planning done in small iterations

12


13/49

13

Plan the Business Analysis Approach

Inputs


14/49

14


Elements Timing of Business Analysis Work

Formality and Level of Detail of BA Deliverables

Requirements Prioritization

Change Management change control &requirement forms.

BA Planning Process

Communication With Stakeholders

Requirements Analysis and Management Tools

Project Complexity


15/49

15


Techniques

Decision Analysis

Process Modeling

Structured Walkthrough


16/49

16


Stakeholders [Audience] Customer, Domain SME, End User or Supplier

Implementation SME

Project Manager

Tester

Regulator

Sponsor

Output Business Analysis Approach


17/49

17


Case Study 1: Activity 1 Process Modeling usingVisio

Expectations for this deliverable:

In your process flow, represent the relevant entities and

attributes discussed in the case study.

Wherever applicable, introduce decision trees/boxes toillustrate alternative flows and relationships.

Be prepared to walkthrough your process maps (models). Eachteam will have 3-5mins to present.


18/49

18

Conduct Stakeholder Analysis

Purpose: This task covers the identification of stakeholders whomay be affected by a proposed initiative or who share a commonbusiness need, identifying appropriate stakeholders for the projector project phase, and determining stakeholder influence and/orauthority regarding the approval of project deliverables.

Description: Stakeholder analysis is performed as soon as abusiness need is identified and will usually be an ongoing activityas long as business analysis continues. Stakeholder analysisbegins with identifying stakeholders who may be affected by thebusiness need or a new solution. Stakeholders may be grouped

into categories that reflect their involvement or interest in theinitiative.


19/49

19


Inputs


20/49

20


Elements

Identification

Complexity of Stakeholder Group

Attitude and Influence Authority Levels for Business Analysis Work


21/49

21


Techniques General Techniques

Acceptance and Evaluation Criteria Definition (9.1) Brainstorming (9.3) Interviews (9.14)

Organizational Modeling (9.19) Process Modeling (9.21) Requirements Workshop (9.23) Risk Analysis (9.24) Scenarios and Use Cases (9.26), User Stories (9.33) Scope Modeling (9.27)

Survey/Questionnaire (9.31) RACI Matrix Stakeholder Map


22/49

22


Sample Stakeholder Matrix


23/49

23


Sample Stakeholder Diagram


24/49

24


Stakeholders

Domain SME

Implementation SME

Project Manager Tester

Regulator

Sponsor


25/49

25


Output

List of required roles

Names and titles of stakeholders

Category of stakeholder Location of stakeholders

Special needs

Number of individuals in this stakeholder role

Description of stakeholder influence and interest

Documentation of stakeholder authority levels


26/49

26


Case Study 1: Activity 2 Identification ofStakeholders

Deliverable expectations:

Conduct an impact analysis to identify key stakeholders that

are likely to be affected by the intended CRM initiative.

Discuss their roles within the organization as well as extent oftheir influence and approval levels regarding the projectdeliverables.

Discuss potential issues or challenges that may evolve in

attempt to balance risk across the various stakeholdersdomains.


27/49

27


Purpose: Determine the activities that must be performed and thedeliverables that must be produced, estimate the effort required toperform that work, and identify the management tools required tomeasure the progress of those activities and deliverables.

Description: The business analyst determines which activities arerequired for a given initiative, how those activities will be carriedout, the work effort involved, and an estimate of how long theactivities will take. This task includes activities to:

Identify business analysis deliverables

Determine the scope of work for the business analysis activities

Determine which activities the business analyst will perform and when Develop estimates for business analysis work.


28/49

28


Inputs


29/49

29


Elements Geographic Distribution of Stakeholders

Collocated vs Dispersed

Type of Project or Initiative

Feasibility studies

Process improvement Organizational change

New software development (in-house)

Outsourced new software development

Software maintenance or enhancement

Software package selection Business Analysis Deliverables

Determine Business Analysis Activities


30/49

30


Techniques

Estimation (9.10)

Functional Decomposition (9.12)

Risk Analysis (9.24)


31/49


32/49

32


Purpose: A BusinessAnalysis communications plan describes theproposed structure and schedule for communications regardingbusiness analysis activities. Record and organize the activities toprovide a basis for setting expectations for business analysis

work, meetings, walkthroughs, and other communications.

Description: Planning business analysis communications includesdetermining how best to receive, distribute, access, update, andescalate information from project stakeholders, and determining

how best to communicate with each stakeholder.


33/49

33


Considerations for a Business Analysis Communication Plan: what needs to be communicated what is the appropriate delivery method who is the appropriate audience and when the communication should occur. Time and resource availability constraints. Physical location/time zone of the stakeholders.

Communication approach for the stakeholder. What types of communications will be required (e.g. status, anomalies, issues and their

resolution, risks, meeting results, action items, etc.) What types of requirements will be elicited (business, stakeholder, solution, or

transition; high level vs. detailed) and how best to elicit them (see the Elicitation KA foroptions)

How best to communicate requirements conclusions/packages, including authority level

(signoff authority, veto authority, or review only).


34/49

34


Inputs


35/49

35


Geography Culture

Relationship to time. Relationship to task completion Relationship to contracts Relationship to formal and informal authority.

Project Type A new, customized in-house software development project. (all requirements)

Upgrading the technology or infrastructure of a current system. (technical requirements) Change in a business process or new data for an existing application. (process and data requirements, business rules, functional and

technical requirements ) Purchase of a software package. (Request For Proposal, and the package will need to include the business requirements, technical

requirements, limited functional requirements and other vendor specifications) Short, focused, agile style iterations of software development (very little formal requirements documentation)

Communication Frequency Communication Formality (more formal when)

The project is unusually large The domain involved is very complex The technology employed, if any, will be new

The project is considered to be mission critical The executive sponsor and/or key stakeholders require formality The requirements are likely to be subject to regulatory review The requirements will be presented to suppliers in an RFQ/RFI/RFP.

Elements


36/49

36


Prepare Requirements Package (4.4)

Communicate Requirements (4.5)

Communication Skills (8.4)

Structured Walkthrough (9.30)

Techniques


37/49

37


Stakeholders [Audience]: Customer and Supplier Domain SME (influence over the approvers) End User (considerable influence) Implementation SME Operational Support (requirements to support the solution)

Project Manager Tester Regulator Sponsor

Output: The stakeholder communications requirements for business analysis activities Format, content, medium, level of detail.

Responsibility for collecting, distributing, accessing, and updating information.


38/49

38

Plan Requirements Management Process

Purpose: Define the process that will be used to approverequirements for implementation and manage changes to thesolution or requirements scope.

Description: This task determines the appropriate requirements

management process for a particular initiative. It includesdetermining the process for requirements change, whichstakeholders need to approve change, who will be consulted orinformed of changes, and by extension, who does not need to beinvolved. The task also includes assessing the need for

requirements traceability and determining which requirementsattributes will be captured.


39/49

39


Input


40/49

40


ElementsRepositoryTraceability

Select Requirement AttributesAbsolute referenceAuthor of the requirementComplexityOwnership

PriorityRisksSource of the requirementStabilityStatusUrgencyAdditionally cost, resource assignment, and revision number, traced-from and traced-to

Requirement Prioritization Process

FormalityEstablishing The Process And TechniquePlan The Participation.


41/49


42/49

42


Techniques: Decision Analysis (9.8) Problem Tracking (9.20) Risk Analysis (9.24)

Stakeholders [Audience]:

Domain SME End User Implementation SME Operational Support Project Manager Tester

Sponsor


43/49

43


Requirements Management Plan: Approach to be taken to structure traceability

Definition of requirements attributes to be used.

Requirements prioritization process.

Requirements change process, including how changes will berequested, analyzed, approved and implemented.

Output


44/49

44


Purpose: To manage the performance of business analysisactivities to ensure that they are executed as effectively aspossible.

Description: This task covers determining which metrics will be

used to measure the work performed by the business analyst. Itincludes how to track, assess, and report on the quality of thework and take steps to correct any problems that may arise. Thismay feed into the development of future business analysis plans.The selected metrics are defined and described in the

organizational process assets or the business analysis plans.


45/49

45


Input


46/49

46


Performance Measures

Performance Reporting

Preventative and Corrective Action

Elements


47/49

47


General Techniques

Interviews (9.14)

Lessons Learned Process (9.15)

Metrics and Key Performance Indicators (9.16)

Problem Tracking (9.20)

Process Modeling (9.21)

Root Cause Analysis (9.25)

Survey/Questionnaire (9.31)

Variance Analysis

Techniques


48/49

48


Stakeholders: Domain SME and End User (should be informed) Implementation SME, Operation Support and Tester (dependent on

the effect performance of BA activities to perform the role, should beconsulted)

Project Manager (accountable for the success of project must be keptinformation) Sponsor (reports on BA performance)

Output: Business Analysis Performance Assessment Business Analysis Process Assets


49/49

Questions?

Date post:	04-Apr-2018
Category:	Documents
Upload:	eaomudu
View:	217 times
Download:	0 times

Important Terminology and Concept to Note

Documents