Professional Documents
Culture Documents
Alan McSweeney
Objectives
To provide an overview of the importance of business analysis in project success and to introduce the Business Analysis Body of Knowledge concept and structure
Agenda
Business Analysis Requirements Business Analysis Body of Knowledge (BABOK) Establishment of a Business Analysis Function
Business Analysis
Business Analysis
Set of tasks, knowledge and techniques required to identify business needs and determine solutions to business problems Business analysis is the connecting layer between strategy and systems/technology
Solutions
Include a systems development component, but may also consist of process development or improvement or organisational change
Business Analyst
Works as a liaison among stakeholders in order to elicit, analyse, communicate, and validate requirements for changes to business processes, policies, and information systems Understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organisation to achieve its goals
November 26, 2009 4
Gather requirements Document processes Identify improvement opportunities Document business requirements Act as the liaison between users and system/solution/technical architects
Gathers data that is unstructured comments/information/discussions/interviews from/with users) Converts that data into information in a structured format Converts that information into knowledge that is structured and usable Develop requirements for change to:
Business processes Information systems
Understand business problems and opportunities Provide recommendations for solutions Be an advocate for the business user Work as a liaison among stakeholders
November 26, 2009 7
A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements Half of all bugs can be traced to requirement errors Fixing these errors consumes 75% of project rework costs 25%- 40% percent of all spending on projects is wasted as a result of re-work 66% of software projects do not finish on time or on budget 56% of project defects originate in the requirements phase of the project Completed projects have only 52% of proposed functionality 75-80% of IT project failures are the result of requirements problems The average project exceeds its planned schedule by 120% 53% of projects will cost 189% of their original estimate 30% of projects are cancelled before completion 50% of projects are rolled back out of production The typical project expends least effort on analysis where most errors originate and whose errors cost most to fix Requirements errors cost the most and that poor requirements are the main cause of software failure
November 26, 2009 8
Effective and targeted project management and systems engineering processes, tools, and techniques Appropriate executive decision making Effective project leadership High-performing teams Collaboration and respect between the business and IT communities Business analysis processes that ensure the development team will have a clear understanding of the customers overall business and information needs
November 26, 2009 9
IT need to possess expertise in multiple domains IT must prove it can understand business realitiesindustry, core processes, customer bases, regulatory environment Contribute real business value to their enterprise
10
Implement
Manage Evolve Develop Test Deploy
11
Lack of advance planning for projects and initiatives Lack of formal training for Business Analysts Inconsistent approach to business analysis Outsourcing and relying on external contractors to perform major roles in system development Impatience with the analysis/design/planning process Gap between what Business Analysts are assigned to do and what they should be assigned to do
12
Projects fail to deliver solutions that meet requirements because of some combination of some or all of the following conditions
Poor understanding of the business need or problem Poorly defined and/or stated requirements Inadequately explored solution options Poor solution design Misalignment between requirements and project scope Poor project planning/execution Poor change management
Many of these are related to business analysis and related activities Cannot separate project management, project portfolio management, business analysis and solution architecture
13
14
Business Analysis
Solution Architecture
Project Management
Business Analysis
Ensure adequate and appropriate resources and involvement during project lifecycle
November 26, 2009 16
Need to ensure that the solution being managed meets business requirements Need to ensure business requirements are captured Need to ensure that solutions are designed to deliver business requirements and comply with organisations enterprise architecture Fundamentally the project exists to manage the delivery of the solution that has been designed to meet business requirements that assist with delivery of the business plan
17
Business Analysis
Delivery of Projects
Use of a business analysis methodology and framework can seem to impose an unnecessary burden but it delivers real benefits
Benefits of Adoption Consistency Speed Drives Delivery Ensures Acceptance Productivity Reuse Professionalism Customer Confidence Speed Accuracy Audit Trail Cost Saving Risk Management and Reduction
November 26, 2009
Potential Disadvantages Time to Adopt Cost to Adopt Suitability Too Comprehensive Cost of Use Not Currently In Use Within Risk
19
Requirements
20
Requirements
A condition or capability needed by a stakeholder to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents A documented representation of a condition or capability Focus on a particular business process or processes Describe the business need or problem and address all the functions associated with their delivery In project terms, requirements are the detailed items necessary to achieve the goals of the project Requirements analysis is key to successful project
November 26, 2009 21
Requirements
Objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it It is all about requirements
22
Identify team roles: project manager, business analysts, developers, quality assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc. Identify stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc. Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes Define risk monitoring and management approach for each identified risk Define the requirements and system development method Define the requirements and system development process Manage requirements change and scope: requirements creep is a big problem Define and collect project metrics and reporting mechanisms Other project planning and project management activities
November 26, 2009 23
De liv ery Ini an Strategic Objectives tia dO tiv es pe Solutions delivered by rat ion Systems and programmes and projects
need to be aligned to the overarching business vision and goal
Solutions
rom
Operation of Solution
November 26, 2009 24
Current State
Solution
25
Requirements Team
Business Analysis
Need the perspectives of all parties Requirements need to be verified by those who are contributors in solution definition Is there enough information in the requirements to build a solution that delivers the business case?
26
Project Manager
Lead Developer
e uir eq eR fin De
nts me gn es i dD an So
ion lut
27
Requirements
Business requirements drive strategy, architecture and project/solution implementation Capturing requirements is essential Define key principles/policies/critical success factors for IT Requirements define what is to be delivered Getting requirements wrong has a substantial cost and contributes to the reasons for project failure Requirements on their own are not sufficient: solution must be designed to deliver on requirements
Business
Requirements
Strategy
Architecture
Project/Solution Implementation
28
Requirements Specification
29
Gaps in Requirements
Solution Design
30
(Logarithmic Scale)
Errors/gaps/omissions become significantly more expensive to fix at later stages of project lifecycle
100
10
1
en ta tio n m en ts De sig rT es tin Te st m en t De pl oy n in g g
Re qu ire
Im pl em
st em
De ve lo pm
en t/
Sy
Us e
Requirements Elicitation
Requirements Communication
Present requirements Agree requirements Refine requirements
32
Requirements Management
e tur Cap e tur Cap
Cha nge
ss Asse
ss Asse
Requirements Development
Gather Tasks relating to the initial
Requirements Management
Capture Ensure that the new
gathering of requirements (uses numerous techniques). Analyse Analysing and categorising requirements. Specifying them. Review Agreeing (with the stakeholders) exactly what the requirements are. Modify if necessary to reach agreement.
November 26, 2009
requirements or change requests are captured and notated. Assess Consider whether the changes will be actioned. Approve or reject. Change Undertake the changes.
33
Objective is to develop an accurate understanding of the business problem and clearly articulate the solution Key components
Communication skills are critical two ways: not only clearly articulating things verbally and in writing, but also listening effectively Selecting the appropriate models, artifacts and other requirements documents formats Describing models and text artifacts clearly, accurately and concisely Key deliverable: requirements specification representing the BAs demonstrated understanding of the business and processes that need to be handled by the system and its necessary capabilities Specifications serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc. Preparing effective presentations for clients and stakeholders
34
Requirements Classification
Business Requirements
High-level statements of the goals, objectives, or needs of the enterprise Reasons why a project has been initiated, the objectives that the project will achieve Metrics that will be used to measure its success.
Stakeholder Requirements
Statements of the needs of stakeholders
Solution Requirements
Characteristics of a solution that meet business requirements and stakeholder requirements Functional Requirements
Describe the behaviour and information that the solution will manage
Non-Functional Requirements
Describe environmental conditions under which the solution must remain effective or qualities the solution must have
35
36
Developed by the IIBA (International Institute of Business Analysis) http://www.theiiba.org/ BABOK is the collection of knowledge within the profession of Business Analysis and reflects generally accepted practice Describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution Identifies currently accepted practices Recognises business analysis is not the same as software requirements Defined and enhanced by the professionals who apply it Captures the knowledge required for the practice of business analysis as a profession
November 26, 2009 37
Describes in idealised approach to performing the complete range of business analysis activities Can be customised to suit the needs of an organisation and initiative
38
Underlying Competencies
November 26, 2009 39
Each Knowledge Area consists of a set of tasks Each task has inputs and outputs Outputs from earlier tasks can be inputs to subsequent tasks Each task has stakeholders that may potentially participate Each task can use one or more generally accepted techniques that support the practice of business analysis
40
Inputs 1 Stakeholders
Task 1
Outputs 1 Techniques
Inputs 2 Stakeholders
Task 2
Outputs 2 Techniques
Inputs N Stakeholders
November 26, 2009
Elicitation
Work with stakeholders to identify and understand their needs and concerns and the environment in which they work Ensure that a stakeholders actual underlying needs are understood
Enterprise Analysis
Identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business
Requirements Analysis
Prioritise and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organisation and stakeholders
41
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Software Applications 42
BABOK Techniques
Acceptance and Evaluation Criteria Definition Brainstorming Business Rules Analysis Data Dictionary and Glossary Data Flow Diagrams Data Modelling Decision Analysis Document Analysis Interviews Metrics and Key Performance Indicators Non-functional Requirements Analysis Organisation Modelling Problem Tracking Process Modelling Requirements Workshops Scenarios and Use Cases
November 26, 2009 43
Agile Development Business Intelligence Business Process Management Business Rules Decision Analysis Enterprise Architecture Governance and Compliance Frameworks IT Service Management Lean and Six Sigma Organisational Change Management Project Management Quality Management Service Oriented Architecture Software Engineering (particularly Requirements Engineering) Software Process Improvement Software Quality Assurance Strategic Planning Usability and User Experience Design
November 26, 2009 44
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Software Applications 45
Identifying stakeholders Defining roles and responsibilities of stakeholders in the business analysis effort Developing estimates for business analysis tasks Planning how the business analyst will communicate with stakeholders Planning how requirements will be approached, traced, and prioritised Determining the deliverables that the business analyst will produce Defining and determining business analysis processes Determining the metrics that will be used for monitoring business analysis work Monitoring and reporting on work performed to ensure that the business analysis effort produces the expected outcomes
46
Business Need
Plan BA Activities
47
Business Need
Plan BA Activities
48
Spectrum of Options
Focus on minimising up-front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximise control and minimise risk Preferred in situations where requirements can effectively be defined in advance of implementation, the risk of an incorrect implementation is unacceptably high, or when managing stakeholder interactions presents significant challenges
November 26, 2009
Focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution Preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution
49
Requirements Prioritisation
How will requirements will be prioritised and how those priorities will be used to define the solution scope
Change Management
What is expected likelihood and frequency of change Ensure that the change management process is effective for those levels of change Effective business analysis practices can significantly reduce the amount of change required in a stable business environment but cannot eliminate it entirely
November 26, 2009 50
Project Complexity
The complexity of the project, the nature of the deliverables, and the overall risk to the business needs to be taken into consideration
51
Number of stakeholders Number of business areas affected Number of business systems affected Amount and nature of risk Uniqueness of requirements Number of technical resources required
52
Definition of the approach that will be taken for business analysis in a given initiative Specify team roles, deliverables, analysis techniques, the timing and frequency of stakeholder interactions, and other elements of the business analysis process Decision about which organisational process assets will be applied and any decisions made regarding tailoring of the process for a specific situation
53
Business Need
Plan BA Activities
54
Identify stakeholders who may be affected by a proposed initiative or who share a common business need Identify appropriate stakeholders for the project or project phase Determine stakeholder influence and/or authority regarding the approval of project deliverables
55
Identification
Who are the stakeholders are and what is the impact of proposed changes on them Understand what needs, wants, and expectations must be satisfied by the solution Requirements are based on stakeholder needs, wants, and expectations
Those that are uncovered either late or not at all could require a revision to requirements that changes or nullifies completed tasks or tasks already in progress, increasing costs and decreasing stakeholder satisfaction
57
Stakeholder Matrix
High Ensure stakeholder remains satisfied Influence of Stakeholder Monitor to ensure stakeholders interest or influence do not change Low Low Impact on Stakeholder High Keep informed; stakeholder is likely to be very concerned and may feel anxious about lack of control Work closely with stakeholder to ensure that they are in agreement with and support the change
58
Sponsors, executives, domain SMEs, and others who interact with the affected group
Organisation or Enterprise
End users, help desk, and others whose work changes when the solution is delivered
Project team and others directly involved with creating the solution
59
60
Plan BA Activities
61
Determine the activities that must be performed and the deliverables that must be produced Determine the scope of work for the business analysis activities Estimate the effort required to perform that work Identify the management tools required to measure the progress of those activities and deliverables
62
63
64
65
Plan BA Activities
66
Business analysis communications plan describes the proposed structure and schedule for communications regarding business analysis activities Basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications Determine how best to receive, distribute, access, update, and escalate information from project stakeholders Determine how best to communicate with each stakeholder Requirements should be presented in formats that are understandable for the reviewer Must be clear, concise, accurate, and at the appropriate level of detail
November 26, 2009 67
Issues
What needs to be communicated What is the appropriate delivery method Who is the appropriate audience When the communication should occur
Geography
Communications needed for a team that is collocated will be different from communications required for a project with geographically dispersed stakeholders
Culture
Cultural issues should also be taken into account when planning communications
Attitude to time Attitude to task completion Attitude to contracts Attitude to formal and informal authority
69
Project Type
Different projects will necessitate different deliverables Extent of documentation needed in a requirements package will vary depending on the project
New, customised in-house software development project Upgrading the technology or infrastructure of a current system Change in a business process or new data for an existing application Purchase of a software package Short, focused, agile style iterations of software development
Communication Frequency
Frequency required by various stakeholders for each type of communication
Communications Formality
Level of formality needed Varies from stakeholder to stakeholder, project phase to project phase, work within a project phase, and requirements presentation
70
71
Plan BA Activities
72
Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope Process for requirements change
Which stakeholders need to approve change Who will be consulted or informed of changes Who does not need to be involved
Assess the need for requirements traceability and determine which requirements attributes will be captured
73
Repository
Method of storing requirements, including those under development, those under review and approved Process for adding, changing and deleting requirements should be consistent and clearly understood by all
Traceability
Determine whether and how to trace requirements Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to have value
74
Change Management
Process for requesting changes Who will authorise changes Change analysis
75
76
Plan BA Activities
77
Determine which metrics will be used to measure the work performed by the business analyst How organisational process assets governing business analysis activities are managed and updated
Performance metrics or expectations for business analysis work
78
Performance Measures
Used to set expectations regarding what constitutes effective business analysis Measures enable the business analyst to determine when problems are occurring that may affect the performance of business analysis or other activities or identify opportunities for improvement
Performance Reporting
Written or informal and verbal Present to various levels of stakeholders and management
79
80
Elicitation - Tasks
BABOK Knowledge Areas
Business Analysis Planning and Monitoring Requirements Management and Communication Solution Assessment and Validation Requirements Analysis Underlying Competencies
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Software Applications 81
Key task in business analysis Requirements serve as the foundation for the solution to the business Essential that the requirements be complete, clear, correct, and consistent Need to actively engage the stakeholders in defining requirements Requirements are identified throughout the elicitation, analysis, verification and validation activities When initial requirements are used to build and verify model(s), gaps may be discovered Techniques
Brainstorming Document Analysis Focus Groups Interface Analysis Interviews Observation/Job Shadowing Prototyping Requirements Workshops Survey/ Questionnaire
82
Outputs
Elicitation Results
Solution Scope Document Elicitation Results Confirm Elicitation Results Stakeholder Concerns Supporting Materials
83
Outputs
Elicitation Results
Solution Scope Document Elicitation Results Confirm Elicitation Results Stakeholder Concerns Supporting Materials
84
Ensure all needed resources are organised and scheduled for conducting the elicitation activities Build a detailed schedule for a particular elicitation activity, defining the specific activities and the planned dates
85
Scheduled Resources
Includes the participants, the location in which the elicitation activity will occur, and any other resources that may be required.
Supporting Materials
Materials required to help explain the techniques used or perform them
87
Business Case
Business Need
Tasks
Outputs
Solution Scope
Elicitation Results
Scheduled Resources
Stakeholder Concerns
Supporting Materials
Supporting Materials
88
Meet with stakeholder(s) to elicit information regarding their needs Elicitation events takes place - brainstorming, focus groups, interviews, observation, prototyping, requirements workshops
Event-based requirements elicitation is highly dependent on the knowledge of the stakeholders, their willingness to participate in defining requirements, and the groups ability to reach consensus Ensure stakeholders are heard Clarify and possibly restate the requirements to encompass all stakeholders perspectives
Elicitation is performed - document analysis, interface analysis or distributed (survey/questionnaire) Ensure that the business analyst understands what information should be elicited from the stakeholders
November 26, 2009 89
Tracing Requirements
While eliciting the requirements it is important to guard against scope creep Tracing requirements back to the business goals/objectives helps to validate whether a requirement should be included
Metrics
Tracking the elicitation participants and the actual time spent eliciting the requirements provides a basis for future planning
November 26, 2009 90
Elicitation Results
May include documentation appropriate to the technique and capture the information provided by the stakeholder
91
Tasks Inputs
Prepare for Elicitation Conduct Elicitation Activity Requirements Stated Document Elicitation Results Confirm Elicitation Results Stakeholder Concerns
Outputs
Elicitation Results
92
Record the information provided by stakeholders for use in analysis For elicitation event (brainstorming, focus groups, interviews, observation, prototyping, requirements workshops) a summary of the output from the event, including issues is produced
93
94
95
Tasks Inputs
Prepare for Elicitation Requirements Stated (Unconfirmed) Stakeholder Concerns (Unconfirmed) Document Elicitation Results Confirm Elicitation Results Conduct Elicitation Activity Requirements Stated (Confirmed) Stakeholder Concerns (Confirmed)
Outputs
96
Validate that the stated requirements expressed by the stakeholder match the stakeholders understanding of the problem and the stakeholders needs
97
Review the documented outputs with the stakeholders to ensure that the analysts understanding conforms to the actual desires or intentions of the stakeholder
98
99
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Activities and considerations for managing and expressing requirements to a potentially broad and diverse audience Ensure that all stakeholders have a shared understanding of the nature of a solution Ensure that those stakeholders with approval authority are in agreement as to the requirements that the solution shall meet Communicating requirements helps to bring the stakeholders to a common understanding of the requirements Management of requirements assists with understanding the effects of change and linking business goals and objectives to the actual solution that is constructed and delivered Over the long term, ensures that the knowledge and understanding of the organisation gained during business analysis is available for future use
November 26, 2009 101
Outputs
Solution Scope
102
Outputs
103
Secure approval of requirements from those stakeholders who have the appropriate authority Manage issues that emerge during elicitation Baseline requirements after approval Any changes to requirements after baselining, if changes are permitted, involves use of a change control process and subsequent approval Solution scope is required as a basis for requirements management If business needs change during the lifetime of an initiative, the solution scope must also change Changes to the solution scope may also lead to changes in previously approved requirements that may not support the revised scope
November 26, 2009 104
Approval
Ensure that the stakeholder(s) responsible for approving requirements understands and accepts the requirements Record decisions
105
Requirements (Approved)
Requirements which are agreed to by stakeholders and ready for use in subsequent business analysis or implementation efforts
106
Outputs
Requirements (Approved)
Requirements (Communicated)
Solution Scope
107
Create and maintain relationships between business objectives, requirements and solution components Requirements are related to other requirements, to solution components and to other elements such as test cases Tracing links business requirements to stakeholder and solution requirements, to other artifacts produced by the team and to solution components Traceability is used to help ensure solution conformance to requirements Used to detect missing functionality or to identify if implemented functionality is not supported by a specific requirement When a requirement is changed, the business analyst can easily review all of the related requirements and software components in order to understand the impact of the change
November 26, 2009 108
Relationships
Records the dependencies and relationships for each of the requirements Dependencies and relationships between requirements helps when determining the sequence in which requirements are to be addressed
Impact Analysis
Evaluate the impact of a change When a requirement changes, its relationships to other requirements or system components can be reviewed Allows decision makers evaluate options with facts
109
Requirements traceability matrix showing requirements relationships to other requirements within the solution scope such that it is relatively easy to identify the effects on other requirements of a change
110
Outputs
Solution Scope
111
Manage knowledge of requirements following their implementation Identify requirements that have the potential for longterm usage by the organisation To facilitate re-use requirements must be clearly named and defined and easily available Maintenance of requirements assists in impact analysis of changes and reduces analysis time and effort
112
Ongoing Requirements
Requirements that an organisational unit is required to be able to meet on a continuous basis
Contractual obligations Quality standards Service level agreements Business rules Business processes
Satisfied Requirements
113
Requirements expressed in a form that makes them suitable for long-term use by the organisation Unapproved requirements can be maintained for possible future initiatives
114
Outputs
Solution Scope
115
Primary objective requirements package is to convey information clearly and in an understandable fashion Create set of requirements to ensure that they are effectively communicated to, understood by, and usable by stakeholders
Requirements Specification Presentation Material Process Models and Maps
Requirements package should support subsequent phases of initiative activities and deliverables Misunderstandings will adversely affect initiative implementation, leading to re-work and cost overruns, especially if gaps are discovered late in the process
116
Format
Depends on initiatives and requirements Select the most appropriate formats to present the material to convey an effective message to those participating in the requirements review process If the purpose of the package is to obtain formal approval, the requirements documentation should be complete in order to prepare the requirements package
November 26, 2009 117
A requirements document, presentation or package of requirements ready to be reviewed by stakeholders Package can contain all of the project requirements or can be broken into several sub-packages
118
Outputs
Requirements (Traced)
119
Communicating requirements is needed to ensure stakeholders have a common understanding of requirements Includes conversations, notes, documents, presentations, and discussions Concise, appropriate, effective communication requires that the business analyst possess hard and soft communication skills
120
General Communication
Requirements communication is performed iteratively Requirements communication can lead to elicitation of additional requirements
Enterprise Analysis Tasks - Business case and solution scoping information is communicated Elicitation Tasks - Communication of requirements may be useful during elicitation activities to help stakeholders identify other related requirements Requirements Analysis Tasks - Requirements are refined, modified, clarified and finalised through effective communication Solution Assessment and Validation Tasks - Assessments of the solution, allocation of requirements to solution components, organisational readiness, and transition requirements all must be communicated
Presentations
Formal or informal - based on by the objective of the communication and the audience needs
Ensure that internal project quality standards have been adhered to Ensure cross-functional fit with other business process areas within the same initiative Obtain business acceptance and sign-off.. Obtain delivery team sign-off.. Obtain testing team sign-off.. Examine solution options with a delivery team Prioritise a set of requirements before proceeding to next project stage Make decisions regarding solution scope
121
Communicated requirements understood by stakeholders - what the requirements are and their current state
122
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Business analysis activities necessary to identify a business need, problem, or opportunity, define the nature of a solution that meets that need, and justify the investment necessary to deliver that solution Analyse the business situation in order to fully understand business problems and opportunities Assess the capabilities of the organisation to understand the change needed to meet business needs and achieve strategic goals Determine the most feasible business solution approach Define the solution scope and develop the business case for a proposed solution Define and document business requirements (including the business need, required capabilities, solution scope, and business case)
124
Outputs
Business Case
Business Need
125
Outputs
Business Case
Business Need
126
Business need defines the problem that the business analyst is trying to find a solution for High-level statement of issue Used to determine which alternative solutions will be considered, which stakeholders will be consulted, and which solution approaches will be evaluated New business needs can arise in a number of different ways:
From the top down - the need to achieve a strategic goal From the bottom up - a problem with the current state of a process, function or system From business management - a manager needs additional information to make sound decisions or must perform additional functions to meet business objectives From external drivers - driven by customer demand or business competition in the marketplace
Frequently organisations act to resolve an issue without investigating the underlying business need Question the assumptions and constraints that are generally buried in the statement of the business need/issue to ensure that the correct problem is being solved and the widest possible range of alternative solutions are considered
November 26, 2009 127
Specific describing something that has an observable outcome Measurable tracking and measuring the outcome Achievable testing the feasibility of the effort Relevant in alignment with the organisations key vision, mission, goals Time-bounded the objective has a defined timeframe that is consistent with the business need
129
Business need describes a problem that the organisation is (or is likely to) face or an opportunity that it has not taken, and the desired outcome Guides the identification and definition of possible solutions
130
Outputs
Business Need
131
Identify new capabilities required by the enterprise to meet the business need Assess the current capabilities of the organisation and identify the gaps that prevent it from meeting business needs and achieving desired outcomes Determine if the organisation can meet the business need using its existing structure, people, processes, and technology May be needed to launch a project to create capability Change may be needed to the organisation
Business processes Functions Lines of business Organisation structure Staff competencies, knowledge and skills, training Facilities Locations Data and information Application systems Technology infrastructure
132
Assumptions
Can be difficult to prove that the delivery of a new capability will meet a business need Identify assumptions and ensure they are clearly understood so that appropriate decisions can be made if the assumption later proves invalid
November 26, 2009 133
An understanding of the current capabilities of the organisation and the new capabilities (processes, staff, features in an application, etc.) that may be required to meet the business need
134
Outputs
Business Need
Solution Scope
135
Determine the most viable solution approach to meet the business need in enough detail to allow for definition of solution scope and prepare the business case Describes the general approach that will be taken to create or acquire the new capabilities required to meet the business need Identify possible approaches, determine the means by which the solution may be delivered (including the methodology and lifecycle to be used) and assess whether the organisation is capable of implementing and effectively using a solution
Utilise additional capabilities of existing software/hardware that already is available within the organisation Purchase or lease software/hardware Design and develop custom software Add resources to the business or make organisational changes Change the business procedures/processes Partner with other organisations, or outsource work to suppliers
136
Alternative Generation
Identify potential options as possible to meet the business objectives and fill identified gaps in capabilities Include the option of doing nothing as well as investigating interim solutions alternatives that may allow the organisation to buy time
Description of the solution approach that will be taken to implement a new set of capabilities Solution approaches describe the types of solution components that will be delivered (new processes, a new software application, etc.) May also describe the methodology and approach that will be used to deliver those components
138
Outputs
Required Capabilities
Solution Approach
Solution Scope
139
Define which new capabilities a project or iteration will deliver Conceptualise the recommended solution in sufficient detail to enable stakeholders to understand which new business capabilities an initiative will deliver Solution scope will change throughout a project, based on changes in the business environment or as the project scope is changed to meet budget, time, quality, or other constraints
The scope of analysis (the organisational unit or process for which requirements are being developed) that provides the context in which the solution is implemented The capabilities supported by solution components, such as business processes, organisational units, and software applications The capabilities to be supported by individual releases or iterations The enabling capabilities that are required in order for the organisation to develop the capabilities required to meet the business need.
140
Implementation Approach
Describe how the chosen solution approach will deliver the solution scope Describe the implementation approach Provide a roadmap that indicates the timeframe in which a capability can be expected
Dependencies
Define major business and technical dependencies that will impose constraints to the effort to deploy the solution, including dependencies that may exist between solution components
November 26, 2009 141
Solution scope that defines what must be delivered in order to meet the business need The effect of the proposed change initiative on the business and technology operations and infrastructure
142
Outputs
Required Capabilities
Solution Approach
Solution Scope
143
Determines if the organisation can justify the investment required to deliver a proposed solution Describes the justification for the project in terms of the value to be added to the organisation as a result of the deployed solution when compared to the cost to develop and operate the solution Defines how the initiative is expected to achieve organisation objectives Lists the constraints associated with the proposed project Defines the estimated budget and expected cash flow Describes alignment with strategies established by the organisation Lists the methods and rationale that were used for quantifying benefits and costs States assumptions
November 26, 2009 144
Benefits
Estimates the benefits to the organisation of the recommended solution in terms of both qualitative and quantitative gains Non-financial benefits such as improved staff morale, increased flexibility to respond to change, improved customer satisfaction, or reduced exposure to risk should be stated with care Benefits should relate back to strategic goals and objectives
Costs
Estimate of the total net cost of the solution Total cost of ownership to support the new solution and consequential costs incurred by others
Risk Assessment
Determine if the proposed initiative carries more risk than the organisation is willing to tolerate
Solution feasibility risks Technical risks Financial risks Business change and organisational risks
Results Measurement
Defines how those costs and benefits will be assessed and evaluated
145
Presents the information necessary to support a go/no go decision to invest and move forward with a proposed project
146
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Outputs
Requirements
Solution Scope
148
Outputs
Requirements
Solution Scope
149
Ensures that analysis and implementation efforts focus on the most critical requirements Decision process used to determine the relative importance of requirements Importance can be based on their relative value, risk, difficulty of implementation, or on other criteria Priorities used to determine which requirements should be targetted for further analysis and to determine which requirements should be implemented first
150
151
Non-Negotiable Demands - stakeholders attempt to avoid difficult choices, fail to recognise the necessity for making tradeoffs, or desire to rank all requirements as high priority Unrealistic Tradeoffs - solution implementation team may intentionally or unintentionally try to influence the result of the prioritisation process by overestimating the difficulty or complexity of implementing certain requirements
152
Set of prioritised requirements has an attribute that describes its relative importance to stakeholders and the organisation Each requirement should have an assigned priority. The priorities may apply to a requirement or to a group or related requirements
153
Outputs
Requirements
Solution Scope
154
Create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives Relationships and interdependencies among requirements adds complexity Organised requirements needs to clearly depict the inherent relationships between requirements
155
Levels of Abstraction
Requirements can be articulated at different levels of abstraction Described as what needs to be done Express at whatever level of abstraction is appropriate for the audience Requirements tools can also determine the level of abstraction used when defining requirements
Model Selection
Determine the types of models required to describe the solution scope and meet the informational needs of stakeholders Objective of developing a model is to simplify reality in a way that is useful Usually necessary to develop multiple models using different modelling techniques to completely analyse and document requirements
User Classes, Profiles, or Roles - categorise and describe the roles that directly interact with a solution Concepts and Relationships - define the objects, entities or facts that are relevant to the business domain and what relationships they have with other concepts Events Processes - sequence of repeatable activities executed within an organisation Rules - enforce goals and guide decision-making
156
Organised structure for the requirements and a documented set of relationships between them
157
Inputs
Prioritise Requirements
Organise Requirements
Requirements Structure
Requirements (Stated)
Requirements Structure
Requirements (Prioritised)
Requirements (Validated)
Verify Requirements
Validate Requirements
Requirements (Verified)
158
Analyse expressed stakeholder desires and/or the current state of the organisation using a combination of textual statements, matrices, diagrams and formal models Create specifications and models to analyse the functioning of an organisation and provide insight into opportunities for improvement Facilitate development and implementation of solutions, facilitating communication among stakeholders, supporting training activities and knowledge management, and ensuring compliance with contracts and regulations
159
Text
Describe the capabilities of the solution, any conditions that must exist for the requirement to operate, and any constraints that may prevent the solution from fulfilling the requirement
Matrix Documentation
Tabular representation of information in a uniform structure that can be broken down into elements that applies to every entry in the table
Models
Graphical simplified representation of a complex reality Formal models use modelling standards (UML)
Improvement Opportunities
Identify opportunities to improve the operation of the initiative
Automate Or Simplify The Work Improve Access To Information Reduce Complexity Of Interfaces Increase Consistency Of Behaviour Eliminate Redundancy
160
161
Outputs
Requirements
Solution Scope
162
Assumptions are factors that are believed to be true but have not been confirmed Identify and document assumptions, confirm their accuracy, and identify and manage risks related to the ability of a solution to meet the business need Constraints are defined as restrictions or limitations on possible solutions - aspects of the current or planned future state that may not be changed Document any restrictions or limitations to the solution design, construction, testing, validation and deployment
November 26, 2009 163
Assumptions
Anything that is believed to be true but that has not actually been verified Source of potential project risk May also reflect an understanding of how desired outcomes are likely to be achieved
Business Constraints
Limitations on available solutions, or an aspect of the current state that cannot be changed by the deployment of the new solution Examine to ensure that they are accurate and justified
Technical Constraints
Architecture decisions and limitations that are made that may impact the design of the solution May create a situation where a requirement cannot be met using the current solution approach or by a solution component
November 26, 2009 164
Documented and verified assumptions and constraints Assumptions and constraints will limit potential solution options and will be monitored for potential changes While they are not technically requirements, they can be managed and communicated in a similar manner
165
Outputs
Requirements
Solution Scope
166
Ensure that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work Requirements that do not meet quality standards are defective and must be revised Final check by the business analyst and key stakeholders to determine that the requirements are:
Ready for formal review and validation Provide all the information needed for further work based on the requirements to be performed
167
Requirements Quality
Cohesive - support the overall initiative purpose and scope Complete - represents all relevant requirements with each requirement selfcontained without any missing information Consistent - do not contradict each other or describe the same requirement using different wording and with the same level of detail Correct - defects in requirements will lead to defects in the resulting solution Feasible - requirements must be implementable within the existing infrastructure, with the existing budget, timeline and resources available Modifiable - grouped in order to be modifiable Unambiguous - must not allow for multiple divergent valid interpretations Testable - must be a way to prove that a requirement has been fulfilled
Verification Activities
Check for completeness Ensure all triggers and outcomes have been accounted for Check for consistency across all requirements models and representations Ensure the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organisation
168
Verified requirements are of sufficient quality to allow further work based on those requirements to be performed
169
Inputs
Stakeholder, Solution and Transition Requirements
Prioritise Requirements
Organise Requirements
Requirements Structure
Business Case
Requirements (Prioritised)
Requirements (Validated)
Verify Requirements
Validate Requirements
Requirements (Verified)
170
Ensure all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need Ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements Stakeholders will have different, conflicting needs and expectations that may be exposed through the validation process and will need to be reconciled
171
Identify Assumptions
May not be possible to prove that implementation of the requirement will result in the desired benefit May be necessary to make assumptions as there are no similar previous experiences to rely on Assumptions need to be identified and defined so that associated risks can be managed
172
173
Validated requirements are those that can be demonstrated to deliver value to stakeholders and are aligned with the business goals and objectives If a requirement cannot be validated, it does not benefit the organisation or it does not fall within the solution scope, or both
174
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Solution Options(s)
Solution Scope
Stakeholder Concerns
176
Solution Options(s)
Solution Scope
Stakeholder Concerns
177
Assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements Determine if the solution delivers enough business value to justify its implementation
178
Define solution scoring criteria simple or complex Assess and score solutions against criteria Top-rated solution or solutions are then investigated in greater detail
Identification of Additional Potential Capabilities
Solution options may offer capabilities to the organisation above and beyond those identified in the requirements or the original business case Determine if these capabilities are of immediate value or have the potential to provide future value
November 26, 2009 179
Assess the value delivered by each proposed solution If multiple options are available, a recommendation of the best solution should be made. A recommendation to terminate the initiative may be given if no solution delivers enough value to justify being implemented
180
Solution Scope
Stakeholder Concerns
181
Allocate stakeholder and solution requirements among solution components and releases in order to maximise the business value given the options and alternatives generated by the design team Allocation is supported by assessing the tradeoffs between alternatives in order to maximise benefits and minimise costs Business value of a solution changes depending on how requirements are implemented
182
Solution Components
Business solutions generally consist of multiple components Each component implements a subset of the requirements Allocation of requirements to solution components is a primary driver of the cost to implement the solution and the benefits delivered by it
Release Planning
Plan decisions about which requirements will be included in each solution release/phase/iteration Ensure all parties understand the consequences to the organisation based on the planned schedule of releases and identify the solution capabilities that will deliver the greatest business value Understand organisational restraints or policies that must be adhered to in any implementation, including constraints such as freeze periods for implementation, general company policies, and any phased-in activities
November 26, 2009 183
Requirements are allocated and associated with a solution component that will implement them
184
Solution Scope
Stakeholder Concerns
185
Assess whether the organisation is ready to make effective use of a new solution Describe the effect the new solution will have on an organisation and whether the organisation is prepared for the change that the solution implementation will cause Understand what changes will occur in the organisation area, technical infrastructure or processes and how these affect other organisation units or operations
186
Cultural Assessment
Determine whether stakeholder groups genuinely want the change to be successful Assess the attitudes of key stakeholder groups and their willingness to accept change Determine if stakeholders understand the reasons that a new solution is being implemented Determine if stakeholders view that solution as something that will be beneficial and if they understand the reasons why a new solution is required
Organisational readiness assessment specifying whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively May lead to revisions in solution or project scope
188
189
Define requirements for capabilities needed to transition from an existing solution to a new solution During the transition period the orgamisation may need to operate both solutions in parallel Transition requirements are elicited, analysed, managed, and communicated by performing the same tasks as for other requirements
190
Data
Data used by the old solution may need to be transferred or archived Rules for conversion will need to be developed, and business rules may need to be defined to ensure that the new solution interprets the converted data correctly
Ongoing Work
Will work will be ongoing in the old version of the solution at the time the new version is implemented Evaluate options for managing this ongoing work such as finishing existing work using the current solution and starting new work in the new solution, holding the processing of new work for a period of time, or converting all work at the time of implementation
Organisational Change
Process for managing the people side of change related to the solution
November 26, 2009 191
Transition requirements define the capabilities that must be developed in order for the organisation to successfully transition between solutions Transition requirements must be verified, validated, managed and communicated
192
Solution Scope
Stakeholder Concerns
193
Validate that a solution meets the business need and determine the most appropriate response to identified defects Ensure the delivered solution meets the business needs on an ongoing basis Problems that are identified through solution validation will be reported and prioritised for resolution
194
Identify defects in a solution or solution component by looking at cases where the outputs from the solution are below an acceptable level of quality
Assess Defects and Issues
Identified defects are reviewed to assess the effect that they will have on the operation of the organisation Determine the severity of the defect, the probability of the occurrence of the defect, the severity of the business impact, and the capacity of the business to absorb the impact of the defects
November 26, 2009 195
196
Solution Scope
Stakeholder Concerns
197
Evaluate functioning solution to understand the value they deliver and identify opportunities for improvement Investigate how a solution is actually used after it is deployed, and assessing the effect it has had, both positive and negative Post-implementation assessment when performed immediately following the completion of a project
198
199
Solution performance assessment that escribes how the solution is performing in relation to business goals and objectives
200
Elicitation
Enterprise Analysis
Prioritise Requirements
Organise Requirements
Allocate Requirements
Behavioural Characteristics
Business Knowledge
Communication Skills
Communicate Requirements
Verify Requirements
Validate Solution
Interaction Skills
Validate Requirements
Underlying Competencies
BABOK Knowledge Areas
Underlying Competencies
Behavioural Characteristics
Business Knowledge
Interaction Skills
Software Applications
Creative Thinking
Ethics
Verbal Communications
General-Purpose Applications
Decision Making
Personal Organisation
Teaching
Specialised Applications
Learning
Trustworthiness
Organisation Knowledge
Written Communications
Teamwork
Problem Solving
Solution Knowledge
Systems Thinking
November 26, 2009 202
Creative Thinking
Involves generating new ideas and concepts, as well as finding new associations between or new applications of existing ideas and concepts
Decision Making
Includes gathering information relevant to a decision, breaking down the information relevant to a decision, making comparisons and tradeoffs between similar and dissimilar options, and identifying the option that is most desirable
Learning
Learning about a domain passes through a set of stages, from initial acquisition and learning of raw facts, through comprehension of their meaning, to applying the knowledge in day-to-day work, and finally analysis, synthesis, and evaluation
Problem Solving
Defining a problem involves ensuring that the nature of the problem is clearly understood by all parties and that underlying issues are visible
Systems Thinking
Systems theory and systems thinking suggest that the system as a whole will have properties, behaviors and characteristics that emerge from the interaction of the components of the system, and which are not predictable from an understanding of thecomponents alone
203
Behavioural Characteristics
Ethics
Requires an understanding of the standards that should govern behaviour and the willingness to act to ensure that behaviour meets those standards
Personal Organisation
Involves the ability to readily find files or information, timeliness, management of outstanding tasks, and appropriate handling of priorities
Trustworthiness
Stakeholders must trust the business analyst to behave ethically and to perform business analysis work effectively
204
Business Knowledge
Industry Knowledge
Understanding of the competitive forces that shape an industry and of major trends impacting the industry will help shape business requirements
Organisation Knowledge
Understanding of the business architecture of the organisation being analysed
Solution Knowledge
Familiarity with the workings of solutions will enable easier identification and recommendation if changes that can be implemented easily while still providing concrete benefits
205
Communication Skills
Verbal Communications
Enable business analysts to effectively express ideas in ways that are appropriate to the target audience
Teaching
Required to ensure that business analysts can effectively communicate issues and requirements and to ensure that the information communicated is understood and retained
Written Communications
Necessary for business analysts to document elicitation results, requirements, and other information for which medium-to-long term records are required
206
Interaction Skills
Teamwork
Be able to work closely with other team members to effectively support their work so that solutions can be effectively implemented
November 26, 2009 207
Software Applications
General-Purpose Applications
Office productivity applications to document and track requirements
Specialised Applications
Modelling, diagramming and requirements management tools to support the development of formal models, and in some cases, their validation and implementation as well
208
209
Business Analysis
Business analysis is currently where project management was ten or more years ago We all know of it, we know we need it, but it is often unclear exactly what a business analyst does or what value they bring to the business The key benefit of adopting a consistent and robust framework in business analysis is the enablement of genuine benefits realisation through a solution which actually meets the business need BABOK is a key enabler to implementing effective business analysis framework and processes
November 26, 2009 210
Desired State
Robust business analysis methodology has become the way to do business across the organisation Business analyst role clearly defined and supported through the Business Analysis Centre of Excellence Business analyst demonstrating proficiency in key competencies Requirements defects reduced substantially Improved mix of internal Business analyst and external consultants
November 26, 2009 211
Key Benefits
Establishing enterprise standards, procedures, governance Standardising infrastructure, development methods, and operational procedures Increasing business agility to adapt quickly as the environment changes Reducing risk, complexity, redundancy, and support complexity Aligning business and IT Enabling re-use and faster time-to-market Reduced project failures and problems due to requirements and analysis defects
Structure of a BACOE
BACOE Key Functional Areas
Business Analysis Standards Business Analysis Development
Skills and Competency Assessments Training and Education
Competitive Analysis
Business Architecture
Portfolio Management
Performance Metrics
Mentoring
Feasibility Studies
Benefits Management
Career Development
Analysis Reviews
Process Modelling
213
Identify and understand the business problem and the impact of the proposed solution on the organisations operations Document the complex areas of project scope, objectives, added value or benefit expectations, using an integrated set of analysis and modeling techniques Translate business objectives into system requirements using powerful analysis and modeling tools Evaluate customer business needs, thus contributing to strategic planning of information systems and technology directions Assist in determining the strategic direction of the organisation Liaise with major customers during preliminary installation and testing of new products and services Design and develop high quality business solutions Select the projects that will give the greatest business benefit and then ensure project success Contribute to overall business growth and development
November 26, 2009 214