Print http://cat.ocw.uci.edu/oo/getPrint.php?

course=OC1305015

1. Select lesson from pulldown menu to the right.

2. Click button to the right to output lesson to page.

3. Click your browser's Print button.

Results
Lesson Topic Page Content

Business
Before we can start building a business solution, we need to know what the users of that solution want it to do for them! Thus, the business analyst's most important role is to
Analysis Introduction and
ensure that what the users (and other stakeholders) want is carefully captured, documented, analyzed, and then transmitted unambiguously to the people who are actually going to
Planning Lesson 1
implement it. In many cases, the term "business solution" implies an information technologies (IT) solution with a software application as one of the end products. However, a
and Objectives
solution can involve other technologies as well, or it might even encompass a simple business process improvement project with no new technology added.
Monitoring
Business
Business Analysis Planning and Monitoring The project manager and project team rely on the business analyst to provide well-defined and documented requirements. This requires
Analysis Introduction and
a disciplined and methodical approach to requirements elicitation, documentation, and communication. The Business Analysis Planning and Monitoring Knowledge Area in Chapter
Planning Lesson 2
2 of the BABOK focuses on this topic, presenting specific tasks that the business analyst should carry out in order to achieve high-quality, unambiguous, and actionable
and Objectives
requirements.
Monitoring
Business
Analysis Introduction and This planning process allows the business analyst to identify both tasks and people (including project team members and stakeholders) that are instrumental for effective
Planning Lesson 2 requirements elicitation. The success of the requirements elicitation process and the quality of the requirements themselves depend on quality work, for which an effective plan
and Objectives addressing tasks and overall process management is quite important.
Monitoring
Business
Analysis Introduction and However, before any work is done, the Business Analyst needs to carefully plan the work to be done, which deliverables to produce, identify the stakeholders involved (and how he
Planning Lesson 2 will communicate with them), and how to monitor whether the BA efforts are on course with the overall project. These tasks are described in the Business Analysis Planning and
and Objectives Monitoring Knowledge Area.
Monitoring
Deliverables As it turns out, the well-documented techniques of project management are well-suited to defining how business analysis activities are going to be performed in the
Business context of the project. In some ways, you might consider this planning process as a mini-project within the scope of the "actual" or overlying project. If the project were to be
Analysis Introduction and developed sequentially, business analysis planning would begin after the enterprise analysis has been completed. In reality, of course, you may need to start planning your
Planning Lesson 3 requirements gathering even before all the enterprise analysis is finished. The deliverables of BA Planning and Monitoring include lists of: Identified stakeholders associated with
and Objectives the project, along with their roles and responsibilities. Deliverables to be produced along with the templates, standards, etc. used by the organization. Specific tasks for
Monitoring requirements gathering along with the people responsible for those tasks. Techniques used to perform the elicitation and communication activities, as well as to estimate the amount
of BA work required. Metrics used to assess the BA work and estimates on the duration of BA tasks.
Business Upon completing this lesson, you should be able to: Identify the stakeholders for a particular project or initiative. Define the roles and responsibilities for the different stakeholders as
Analysis Introduction and they pertain to the current project. Determine the approach to be selected for performing BA work, including the SDLC methodology to be used. Develop a Business Analysis Plan,
Planning Lesson 4 which includes the planned BA activities, estimates to complete required business analysis tasks, and deliverables that the BA will produce. Develop a communication plan for the
and Objectives BA effort. Develop a plan to manage requirements implementation (i.e., how requirements are approached, traced and prioritized), as well as define a process for requirements
Monitoring change. Define the metrics to be used in assessing the business analysis work effort and the process used to determine if the BA effort needs preventive or corrective action.
Plan Business Analysis Approach Carrying out the project-related business analysis activities requires a carefully assembled plan. Developing this plan is the responsibility of the
Business project manager working with the business analyst. Without a good plan, there is a danger of not capturing all the requirements or defining them poorly, which could lead ultimately
Analysis Plan Business to a final product that doesn't meet the users' acceptance criteria. Some industries or organizations have specific methodologies for building their products. For instance, software
Planning Analysis 1 development has the System Development Life Cycle (SDLC) and Project Life Cycle (PLC) methodologies. Since these kinds of methodologies usually include requirements
and Approach elicitation, a business analyst working for a company that has adopted such a methodology will need to follow it in developing a requirements process plan. Additional factors to
Monitoring consider during this planning stage include: Stakeholder expectations Organization or industry standards (that may govern how projects are implemented) Do the business analysis
planning activities need to be tailored for a particular project or initiative?
Steps to Implementation The first step is to identify all the stakeholders from whom the business analyst will elicit requirements. These stakeholders include anyone who has an
interest in the functional aspects of the final product. For example, the user of a software package definitely has an interest in how the package works. However, an upper-level
manager who only wants to see reports (printed on paper) generated by that software package may not care how the software works. She only wants to see the reports! At this
Business point, the business analyst must decide how to approach the relevant stakeholders. Some may be physically remote and require travel or teleconference sessions while others are
Analysis Plan Business local and amenable to in-person meetings. Next, the analyst must determine which specific methods of eliciting requirements are appropriate both for the stakeholder being
Planning Analysis 2 interviewed and the type of information that needs to be acquired. Details of these methods are presented in Lesson 4. After the business analyst has captured and compiled all the
and Approach requirements, he must decide upon an appropriate approach for analyzing these requirements and determine the best approach for documenting them. Along with documentation,
Monitoring communication plays a critical role. No matter how well requirements are written down, they are not very useful unless the business analyst can communicate them effectively to
various decision makers and the technical personnel who will implement them. These activities are covered in Lessons 5 and 6. Finally, business analysts must work with a project
delivery team to identify implementation tasks in the form of a work breakdown structure (WBS) and formalize a means of evaluating how well the solution meets stakeholders'
needs. This is covered in Lesson 7.
The Business Analysis Approach According to the BABOK, a Business Analysis Approach describes the set of processes, templates and activities that will be used to perform
Business
business analysis in a specific context (i.e., a project or initiative). There are many ways to approach business analysis work. One approach is to use established methodologies for
Analysis Plan Business
software development (Waterfall/Agile) or business process improvement (Lean/Six-Sigma). An organization can also use a proprietary methodology or in-house practices and
Planning Analysis 3
process. The Organizational Process Assets defines the standards, templates and deliverables regarding how business analysis is done in the organization and how it fits into a
and Approach
project and other activities. Other factors to consider when planning the BA approach are: the Business Need - the problem of opportunity faced by the organization (and the reason
Monitoring
for the project!) and Expert Judgment - the BA expertise either from within the organization and/or the industry at large
Business
Analysis Plan Business
Planning Analysis 4 BA Methodologies
and Approach
Monitoring
Business
A plan-driven methodology emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. This methodology is
Analysis Plan Business
concerned about reducing upfront risk and having control over outcomes over the delivery of a solution. This approach is preferred when requirements can effectively be defined in
Planning Analysis 4
advance of implementation and the risk of an incorrect implementation is unacceptably high (think medical equipment or an oil refinery), or when managing stakeholder interactions
and Approach
presents significant challenges.
Monitoring
Business
Analysis Plan Business Change-driven methodology focuses on rapid delivery of solution capabilities in an incremental fashion (i.e., Agile) and direct involvement of stakeholders to gather feedback on the
Planning Analysis 4 solution's performance. This methodology will accept a higher degree of uncertainty (risk) regarding the overall delivery of the solution in exchange for the flexibility to manage
and Approach requirement changes.
Monitoring
Business
Analysis Plan Business
Planning Analysis 5 Plan-driven vs. Change-driven Methodologies Almost all methodologies fit along a spectrum between Plan-driven and Change-driven methodologies.
and Approach
Monitoring
Business
if (AC_FL_RunContent == 0) { alert("This page requires AC_RunActiveContent.js."); } else { AC_FL_RunContent( 'codebase','http://download.macromedia.com/pub/shockwave
Analysis Plan Business
/cabs/flash/swflash.cab#version=9,0,0,0','width','690','height','470','id','PlanVsChangeMethodologiesTbl','align','middle','src','../media/AR01/05015
Planning Analysis 5
/PlanVsChangeMethodologiesTbl','quality','high','bgcolor','#ffffff','name','PlanVsChangeMethodologiesTbl','allowscriptaccess','sameDomain','allowfullscreen','false','pluginspage','http:
and Approach
//www.macromedia.com/go/getflashplayer','movie','../media/AR01/05015/PlanVsChangeMethodologiesTbl' ); //end AC code }
Monitoring
Business 1. Which one of the following activities is not part of the Plan Business Analysis Approach task? a. Abiding to regulatory standards and federal guidelines. Incorrect. Abiding to
Analysis Plan Business regulatory standards and federal guidelines is part of the "Plan BA Approach" task as defined in the "Organizational Process Assets" input. b. Understanding the problems or
Planning Analysis 6 opportunities facing the organization.Incorrect. Understanding the problems or opportunities facing the organization is defined in "Business Need", an input to the "Plan Business
and Approach Analysis Approach" task. c. Developing a marketing plan to promote the product in the local market. Correct! Developing a marketing plan to promote the product in the local
Monitoring market is not part of the "Plan Business Analysis Approach" task. d. Using the standard document templates mandated by the organization.Incorrect. Using the standard document

1 of 5 7/8/2016 4:40 PM
Print http://cat.ocw.uci.edu/oo/getPrint.php?course=OC1305015

templates mandated by the organization would be part of the "Plan BA Approach" task as defined in the "Organizational Process Assets" input.
Business 2. According to the BABOK, Organizational Process Assets is an input to all of the tasks in the Business Analysis Planning and Monitoring Knowledge Area. As such, it includes:
Analysis Plan Business a. Methodologies for process change or software development, i.e. Waterfall or Agile. Incorrect. Not the most complete answer. b. Real estate and other assets as described in the
Planning Analysis 7 organization's Annual Report. Incorrect. Real Estate is not a process asset. c. Corporate governance standards followed by the organization. Incorrect. Not the most complete
and Approach answer. d. A and C only. Correct! A and C are both part of the Organizational Process Assets of an organization. e. A and B only. Incorrect. B is not part of the Organizational
Monitoring Process Assets of an organization.
Team Roles Stakeholder roles are usually described in a responsibility matrix (RAM), or roles and responsibilities table, sometimes called a RACI matrix. The initial step in the
requirements planning process is to work with the project manager to identify all roles needed to carry out the project (the entire project, not just the roles associated with
Business requirements gathering). Some organizations have defined roles while others give the project team more flexibility. The BABOK lists numerous possible roles; here are just a few
Analysis Conduct of them: Executive sponsor - has final go/no-go decision authority. Business analyst - works with project requirements. Project manager - oversees the overall strategy and tactics
Planning Stakeholder 1 for completing a project. Developer - Usually a technical person who creates IT or engineering solutions designed to meet stakeholder needs. Quality assurance analyst - ensures
and Analysis that project activities are carried out as formally specified by organizational, industrial, or professional standards. Application architect - creates a high-level design or approach for
Monitoring solving a particular business problem. Database architect or analyst (often a database administrator, or DBA, with development skills) - technical person who establishes the data
storage structure to be used in a given solution. End users - people who interact directly with the project's end product. Stakeholders - anyone affected or impacted by a project's
end product.
Information about each stakeholder should include the following: Name Job Title/Description Organization/Company Mailing and/or Physical Address Phone Numbers Email
Address Stakeholders Project stakeholders are perhaps the most important people in the life of a project because they have so much influence over the project's existence. They
Business
control financial resources and specify the desired end product. Different stakeholders have different "stakes" in the project so the analyst must look at each stakeholder and identify
Analysis Conduct
their individual needs and interests in the project. Sometimes stakeholders may not be obvious - end users, the public, the government, and other people or entities may all be
Planning Stakeholder 2
stakeholders in some capacity. It is very important to identify all stakeholders at the beginning of a project. Stakeholders that emerge late in the project's lifespan may demand
and Analysis
changes that require substantial rework or may even become adversarial to project outcomes. The business analyst needs to create a list of all stakeholders - including groups as
Monitoring
well as individuals - that have any connection to his/her project. This list should contain names of individuals along with their titles, contact information, etc. For groups, there should
be one representative on the list. As a starting point, the business analyst should consult all the documents prepared up to this point in connection with the project.
To identify stakeholders, the business analyst can begin by sending out questionnaires to potential stakeholders and interviewing the likely candidates. The results of the
questionnaires and interviews allow the business analyst to classify the stakeholders in terms of their influence on the project. The questionnaires can also help uncover additional
stakeholders before the project gets too far along. The BABOK lists many relevant questions that business analysts can ask to elicit this information. Once the business analyst
Business has compiled all the information, she can prepare a summary table similar to this one (only three rows are excerpted here): Stakeholder Name/Job Title Project Stake Description
Analysis Conduct John Smith, Executive Director Has been given a goal of increasing the number of recipients of program services by 15% over the coming fiscal year. Oversees all program
Planning Stakeholder 3 activities and strategies; is responsible for approving program expenses, including those for information systems upgrades. Joan Carlson, Board Member (represents Board of
and Analysis Directors) Responsible for ensuring the program's success and securing private funding. Together with the rest of the Board, provides leadership and direction for the program;
Monitoring ensures the program achieves its goals. Jason Flowers, IT Director Directs the program's information system capabilities including the development of new applications used by
program staff members. Leads the IT staff in supporting program activities with appropriate hardware and software components. Directs all in-house software development efforts.
The main goal is to ensure that the execution of the project goes as smoothly as possible. By identifying all stakeholders and knowing how they might influence the project's
execution and eventual outcome, the business analyst can help the project manager avoid decisions that later end up creating more obstacles and delays.
Business R= Responsible (does the work) A= Accountable (decision maker) C= Consulted (must be consulted before work proceeds) I= Informed (only needs to be informed after work is
Analysis Conduct completed) Role RACI Executive Sponsor C Business Analyst R Project manager A Developer C Quality Assurance Analyst I Trainer I Application Architect C Data
Planning Stakeholder 4 Modeler/Information Architect C Database Analyst (DBA) C Business Architect R Solution Owner C End User I Subject Matter Expert C RACI Matrix In order to understand the
and Analysis nature of each role, the BABOK encourages the use of the RACI Matrix, as defined in the table shown here. After specific roles have been identified, the business analyst must
Monitoring identify the people that will fill those roles for the given project. The stakeholder role is especially important and we will take a closer look at it in the following pages.
Business
Stakeholder Map It is often useful to categorize stakeholders and put them in groups representing the amount of power (influence) they have and whether they represent inhibiting
Analysis Conduct
or supporting factors for the current project or initiative. The Stakeholder Map is a technique that graphically displays the relationship of stakeholders to the initiative and to one
Planning Stakeholder 5
another. A typical mapping shows stakeholder influence and the level of interest in the project. From the BA perspective, this map can determine where the stakeholder focus
and Analysis
should be. See additional information on this technique.
Monitoring
Business
Analysis Conduct
Figure 2-5: Stakeholder Matrix, Business Analysis Body of Knowledge (BABOK guide), Version 2.0, 2009, International Institute of Business Analysis, Toronto, Ontario, Canada,
Planning Stakeholder 5
page 30.
and Analysis
Monitoring
Business
Stakeholder Onion Diagram Another way to group stakeholders and their relationship to the solution is by creating a Stakeholder Onion Diagram. This diagram consists of an inner
Analysis Conduct
circle (the solution), surrounded by outside circles. For example, stakeholders placed in circles closer to the solution are those that will have a day-to-day interaction with the
Planning Stakeholder 6
solution. On the other hand, stakeholders placed in the outer circles will have less involvement with the solution, but still can benefit from it. This diagram can provide insights to
and Analysis
potential conflicts of interest between the different stakeholders with respect to the solution. See additional information on this technique here.
Monitoring
Business
Analysis Conduct
Figure 2-6: Stakeholder Onion Diagram, Business Analysis Body of Knowledge (BABOK guide), Version 2.0, 2009, International Institute of Business Analysis, Toronto, Ontario,
Planning Stakeholder 6
Canada, page 30.
and Analysis
Monitoring
1. A network integration engineer who is assigned to work on a project that involves modifications to the existing IT network infrastructure would receive which RACI rating? a. "C"
because she needs to approve any work that will involve changes to the network. "C" stands for "Consulted", i.e., this person must be consulted prior to the work and gives input.
Business However, the network integration engineer here does the work (i.e., is "Responsible"), therefore the right designation in the RACI Matrix for this person is an "R". b. "R" because
Analysis Conduct she is one of the people actually carrying out work on the project. Correct! The network integration engineer here does the work (i.e., is "Responsible"), therefore the right
Planning Stakeholder 7 designation in the RACI Matrix for this person is an "R". c. "A" because she is responsible for identifying which business units will be responsible for developing and promoting new
and Analysis products. Incorrect. The designation "A" for "Accountable" is reserved for the decision maker only. The network integration engineer is not the decision maker. d. "I" because she
Monitoring does not need to know about any network changes until after users have had time to gain familiarity with the new system. Incorrect. An "I" for "Informed" means that this person
must be notified of the outcome of modifying the existing IT network infrastructure. However, the network integration engineer here does the work (i.e., is "Responsible"), therefore
the right designation in the RACI Matrix for this person is an "R".
Business
2. Which of the following people have the most authority to "kill" a project? a. Senior Business Analyst. Incorrect. The Senior Business Analyst doesn't have the authority to cancel
Analysis Conduct
("kill") a project. b. Project Manager. Incorrect. The Project Manager doesn't have the authority to cancel ("kill") a project. c. The company's private owners. Correct! The
Planning Stakeholder 8
company's private owners have the authority to "kill" a project. d. The Chief Financial Officer. Incorrect. The Chief Financial Officer doesn't have the authority to cancel ("kill") a
and Analysis
project.
Monitoring
Plan Business Analysis Activities The fundamental goal when planning the business analysis activities is to develop a concise and clear set of steps or tasks that lead to the
Business
implementation of a well-accepted solution. The Plan Business Analysis Activities task includes the following general activities: Identify the BA deliverables. Determine the scope of
Analysis Plan Business
work for the BA effort. Determine the activities that will be carried out by the business analyst. Develop estimates for the BA work. Which activities and how they are executed will
Planning Analysis 1
determine the business analysis deliverables quality and timeliness. When completed, this task will produce the Business Analysis Plan which includes a detailed list of all the
and Activities
activities including the resources needed (a work breakdown structure {WBS} is one way of presenting this list) and a description or diagram presenting the logical dependencies
Monitoring
among the activities.
Business
What's Needed for Planning BA Activities In developing Business Analysis Plans, the BA will use previously collected information from other tasks: BA Approach - information on
Analysis Plan Business
the SDLC, deliverables, templates, and tasks that should be included BA Performance Assessment - information on metrics and assessment of the BA effort Stakeholder List
Planning Analysis 2
(including stakeholder roles and responsibilities) - information on individual stakeholders' behaviors and preferences. In addition, the organization or a regulatory body might
and Activities
mandate specific deliverables. This comes under the umbrella of Organizational Process Assets.
Monitoring
Keep in Mind ... In planning the activities to be carried out, particular elements will influence the types of activities and how they'll be performed: Geographic Distribution of
Business Stakeholders, i.e., whether stakeholders are co-located or dispersed will affect the complexity of the project and impact the estimate of activities. Type of Project or Initiative. The
Analysis Plan Business type of project or initiative will influence the business analysis activities being planned (i.e., a new software development project and a process improvement project have different
Planning Analysis 3 characteristics and will have a different set of activities). Business Analysis Deliverables. Deliverables in the Requirements Package will vary according to the initiative in question.
and Activities Determine Business Analysis Activities.Typical activity lists are in the WBS. WBS defines scope of work to help with estimation within a hierarchy, decomposing activities and tasks
Monitoring to a greater detail (e.g., work packages). Create a WBS list by decomposing the project by deliverable, dividing the project into phases or iterations, or by using a previous similar
project as an outline for current project.
Business
Analysis Plan Business
Planning Analysis 4 Steps to Implementation
and Activities
Monitoring

2 of 5 7/8/2016 4:40 PM
Print http://cat.ocw.uci.edu/oo/getPrint.php?course=OC1305015

Business
Even though the business analyst has a list - perhaps even a very detailed list - of requirements activities, he still needs to estimate the scope of each activity, the resources
Analysis Plan Business
needed, and the time that will be required to carry each activity out. First, the business analyst can divide the entire requirements process into a collection of milestones, which mark
Planning Analysis 4
significant events or accomplishments in the execution of a project. Having a project charter signed is an obvious example of a milestone. Delivering a product to the customer for
and Activities
acceptance testing is another.
Monitoring
Business
Analysis Plan Business Next, the analyst must identify individual work units, which consist of very specific tasks or activities that have a clearly identifiable "product" or end result (which usually feeds into
Planning Analysis 4 another work unit). Some people define work units as tasks that cannot be decomposed into smaller tasks. Others define work units as activities that have a finite duration with a
and Activities minimum length. (In other words, you don't want to break down a task into such small pieces as to be ridiculous!). Obviously, judgment and experience are important.
Monitoring
Communication Today, many projects rely upon workers who are distributed globally. Consequently, communications can be challenging despite email, instant messaging,
web-based conferencing tools, and other technological aids. It is still important for project leaders to engage in some face-to-face meetings - even if only occasionally - to foster a
Business sense of cohesion. The internet makes it easier to share common project files so all workers can use the same design templates, electronic interface standards, and technical
Analysis Plan Business specifications as they build their portions of the project deliverables. Everyone should be able to look up documented requirements, business process documentation, and other
Planning Analysis 1 organizational documents that have an impact on their work products. Many project leaders set up online portals for their project teams so everyone can monitor milestones, view
and Communication current issues, and contribute to forum-like discussions - all from the convenience of their desktops. Another important component of a successful project is a mechanism for
Monitoring sharing undocumented knowledge that an individual worker may possess but hasn't been formally captured. This knowledge-sharing is very important in the earlier stages of a
project when several business analysts may be gathering requirements in geographically different places from stakeholders who rarely communicate with each other. A senior
business analyst needs to ensure that everyone shares the information they are accumulating in order to reduce redundancy and resolve conflicts.
Plan Business Analysis Communication A project involves many levels of communication throughout its lifespan. These communications may involve project managers, business
analysts, stakeholders of all kinds, and the people who actually design and implement the solution. On top of this, there may be occasional needs to communicate externally, to the
Business
general public, for instance, on projects that have especially high visibility. The business analyst must plan all avenues of communication in advance as part of the broader business
Analysis Plan Business
analysis effort. This plan must include interactions with stakeholders, including the actual requirements elicitation activities themselves, along with communications targeting
Planning Analysis 2
managers and the solution development team. Each deliverable has some element of communication associated with it and the analyst needs to plan those elements at the same
and Communication
time she identifies the deliverables. The BA Communication Plan is included in the overall Project Plan. Here are the kinds of things the business analyst needs to consider for each
Monitoring
deliverable of the plan: What is being communicated and what is the most appropriate format given the contents and the audience Who should be party to the communication When
does the communication need to happen
Plan Business Analysis Communication The communication of requirements is perhaps one of the most important tasks associated with communications planning. The audiences
Business
to which the business analyst must present technical information can range from high-level managers, who may have little technical knowledge, to engineers and technicians, who
Analysis Plan Business
will create the solution. The format of the communication must match the audience or the message will be lost. The consequences of not paying attention to the audience range
Planning Analysis 3
from bad to worse: the project might be executed incorrectly by technical professionals who misunderstand the requirements or it might not be approved in the first place by
and Communication
high-level leaders who don't see any business benefits. Various stakeholders must review project information at many points during the project's lifecycle. It is the responsibility of
Monitoring
the business analyst to understand each requirement thoroughly and present those requirements in a manner that is understandable and actionable by these stakeholders.
Business
Analysis Plan Business
Planning Analysis 4 Communication Types by Stakeholder
and Communication
Monitoring
Makeup of Audience/Stakeholders Type of Communications Sponsors, CEOs, high-level managers This audience requires summaries and, generally, high-level descriptions.
Members of this audience tend to be focused on major outcomes, especially in terms of the financial benefits that could accrue to their organization. Users (or customers) of the
business solution This audience understands the business aspects but may not understand the technical aspects of a proposed solution. Requirements must be cast strictly in
terms of business functions and outcomes. Members of this audience need to see the requirements in a fair amount of detail since they are the most affected by the solution.
Business Engineers, application developers, systems analysts These people are the "builders" of the solution. They need full specifications that can be translated into specific technological
Analysis Plan Business features of the solution they are implementing. It is also very important to provide them with unambiguous success criteria that must be met for the project to be considered
Planning Analysis 4 successful. Designers and developers This category of stakeholder is in many ways similar to the engineers and systems analysts. The main difference is that these people focus
and Communication more on the functional elements and user interface characteristics of the solution. They need to understand both the technical and the business requirements. Testing and quality
Monitoring assurance personnel QA personnel need to be involved nearly from the beginning of a project. They need to understand the functional requirements of the solution so they can
design test procedures that ensure 1) the solution works correctly and 2) the solution solves the business problem. They need both descriptive and technical details. In general, the
analyst can choose written (text) formats and visual (physical models or abstract diagrams) formats to present the requirements. Text is useful for describing abstract concepts or for
setting the context of a requirement while diagrams are better-suited to show relationships among objects or process flows through a system. Sometimes, it's best to have a
combination of the two for even more clarity.
Communication Criteria When deciding the best way to present requirements to a stakeholder (or group of stakeholders), the business analyst needs to consider the following
criteria and/or elements: Purpose of the communication - What will the stakeholder(s) do with the information? Approve a requirements change request? Provide comments and/or
constructive criticism? Brainstorm new requirements or refine existing requirements? Specific contents - what does this specific group need to know? How would another group of
Business
stakeholders with different needs interpret the contents of the same communication? Level of detail needed - What is the lowest level of detail that will serve the needs of the
Analysis Plan Business
audience? How about the needs of the business analyst or project manager? Audience's technical background and/or familiarity with the topic - Do they have the prerequisite
Planning Analysis 5
knowledge not only to understand the requirement, but to work with it? Degree of formality - How formal does this communication need to be? What is the audience expecting?
and Communication
Backup documentation - How much formal documentation needs to accompany any verbal or live presentations? Version control - Which version of the requirement documentation
Monitoring
is to be presented? Is this a final version (which is more formal) or an update (which could be rather informal)? It is important to note that a typical project is usually accompanied by
a wide variety of "deliverable" documents ranging from informal work papers or work products to formal reports. For instance, a requirements package is a "deliverable" item that is
clearly specified in the project plan. There are usually many deliverables throughout a project.
Business
Analysis Plan Business
Planning Analysis 6 Degrees of Formality in Communication
and Communication
Monitoring
Business
Another aspect of technical communications involves the degree of formality that is needed for a particular project or a particular audience. Projects require more formality if they
Analysis Plan Business
are large and complex (in terms of implementation strategy and the nature of the business area), the technology being used is new or controversial, the project's success is of
Planning Analysis 6
mission-critical importance, the project sponsors require formality, regulatory review will be involved at some point, or the project will be designed in-house but be produced by
and Communication
external developers.
Monitoring
Business
There is one important caveat to mention at this point. If the business analyst decides to create different versions of a particular requirements document in order to address the
Analysis Plan Business
needs of different audiences, she needs to ensure that they all are consistent. If a requirement changes, she needs to ensure that those changes propagate throughout all the
Planning Analysis 6
documentation. For large projects this might become a non-trivial task! It's best to plan carefully what needs to be documented and how it will be documented so that not only the
and Communication
audiences' needs are met but the documentation is easily kept up-to-date.
Monitoring
Communications Plan In smaller projects, the communications plan may not need to be written down formally; in larger ones, it is essential to write the plan down. In many cases,
the requirements elicitation activities are included within the communications plan. After all, the main product of requirements elicitation is a document that communicates user and
stakeholder needs to members of the project team. As an example of a communications plan, consider the following sample tasks from a software development project for ABC
Business Corporation's Human Resources Department: Task Audience Forum Deliverable Communications Method Hold the requirements kick-off event Stakeholders and project team
Analysis Plan Business members Group meeting PowerPoint presentation describing the project's vision Verbal presentation Elicit preliminary requirements from HR management Managers and
Planning Analysis 7 supervisors in the HR dept. Small group brainstorming session Notes and sketches Written documents to be summarized at a later date Elicit detailed requirements from HR
and Communication management Managers and supervisors in the HR dept. One-on-one discussions Notes and sketches Written documents to be summarized at a later date Elicit requirements from
Monitoring HR staff members (who are the ones that will use the new application most frequently) Senior HR representatives, clerks, data entry specialists, department administrators
Requirements Workshop Grid capturing systematically derived requirements based on management needs and expectations Document to be sent to upper management for review
and comment via email Prepare a preliminary cost estimate for developing the solution Developers, upper management Requirements documentation review - WBS development
Preliminary features list, infrastructure requirements, and labor requirements estimate Formal document to be delivered to upper management and project team members via email
Business 1. A junior business analyst working for you just brought you a full-color printout depicting a proposed web interface for an application to be used by the purchasing department to
Analysis Plan Business manage their internal operations. To which audience are you most likely to show the printout? a. Project Sponsors Incorrect. Project Sponsors are not the stakeholder "level" to
Planning Analysis 8 present the proposed web interface in so much detail. b. The CEO and CFO of the company Incorrect. The CEO and CFO are not the stakeholder "level" to present the proposed
and Communication web interface in so much detail. c. Designers and developersCorrect! Designers and developers (what the BABOK calls "Implementation SMEs") is the right audience for this
Monitoring document. d. The company's customers Incorrect. The company's customers don't need to see this document.
2. You need to gain the support of a group of company shareholders for a telecommunications upgrade project that will enable field workers to process text messages as well as
Business make voice calls. Which of the following communications approaches will you take? a. Demonstrate the value that the project will bring to the organization in terms of financial
Analysis Plan Business performance; avoid technical details. Correct! This is the best course of action at this point (you want to get the stakeholders buy-in) emphasizing the benefits of the initiative and
Planning Analysis 9 avoiding any distracting (technical) details. b. Present detailed wiring and cabling diagrams demonstrating your grasp of the technical intricacies of the project; the goal is to build
and Communication confidence in your approach. Incorrect. Too much detail is inappropriate this early in the initiative. c. Present a detailed, step-by-step implementation plan replete with technical
Monitoring diagrams.Incorrect. Too early to talk about implementation. d. Gather the shareholders together in a conference room and hold a brainstorming session to come up with the best

3 of 5 7/8/2016 4:40 PM
Print http://cat.ocw.uci.edu/oo/getPrint.php?course=OC1305015

implementation plan. Incorrect. Too early to talk about implementation.

Business
Plan Plan Requirements Management Process The purpose of this task is to define (and then follow) the process for planning the requirements work throughout the project or project
Analysis
Requirements phase. It defines the process for approving the appropriate requirements for an initiative, as well as the process to manage changes to the solution or requirements scope. This
Planning 1
Management process also determines: The process for requirements change Who will be informed on changes Which stakeholders need to approve changes Who does not need to be involved
and
Process on changes The need for requirements traceability and which requirements attributes to capture
Monitoring
Business
Plan Inputs to the Plan Requirements Management Process Task The previously defined Business Analysis Approach and the Business Analysis Plans, as well as the organization's
Analysis
Requirements approach to requirements definition, are used to determine the process used to manage requirements implementation and change. Some organizations have a formal requirements
Planning 2
Management process as part of their Organizational Process Assets. Others have inconsistent processes, while some might not have a process at all. In these cases, requirements are either
and
Process ignored or folded into other phases of the project or initiative.
Monitoring
Business
Plan Planning the Requirements Management Process In planning for requirements implementation and changes, the business analyst needs to address the following questions: Does
Analysis
Requirements the organization have a requirements repository? Are requirements organized for re-use? How are the requirements set for traceability? What requirement attributes are going to be
Planning 3
Management selected? What process will be used to prioritize requirements? What criteria is going to be used to allow requirement changes? Who will authorize the changes? Does the
and
Process requirements management process need to be tailored for a particular project or initiative?
Monitoring
Business
Plan Requirements Attributes Requirements attributes provide metadata about the requirements but are not part of the solution definition. Attributes, however, provide useful information
Analysis
Requirements that can help the project team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a
Planning 4
Management proposed change. Therefore, requirement attributes need to be planned for and determined, along with the requirements themselves. For a list of commonly used requirements
and
Process attributes, go to the BABOK, page 44. Do you use any of these attributes? Which of these attributes do you use?
Monitoring
Handling Changes As the project moves forward, there will be changes or updates to the recorded requirements, as well as conflicting requirements or conflicting priorities over
Business
Plan requirements. Organizations have either a formal or an informal change management process to deal with these issues. Business analysts need to consider these items when
Analysis
Requirements planning how they will handle requirement changes: The process has built-in authorization levels for approving changes based on a set criteria like a dollar amount or a certain
Planning 5
Management number of hours. The organization has a formal Change Control Board (CCB) that authorizes requirements changes after they've been approved. A project team or product owner
and
Process has direct control over requirements changes (i.e., an Agile SDLC environment) Impact of changes to business processes, hardware/software (including interfaces) and other
Monitoring
requirements, as well as expected risk from the change. Change request documents - wording and structure. Requirements change prioritization, again based on a set criteria.
Tailoring Changes The requirements management process sometimes is tailored to meet the needs of a particular project. A business analysis needs to consider the following:
Business
Plan Organizational culture - is the culture formal or informal, and how does this formality/informality react to a change in the normal requirements management process. Stakeholder
Analysis
Requirements preferences - distinct stakeholders want different levels of formality for change approvals and/or process documentation. Complexity of the project or product to be delivered -
Planning 6
Management tailoring based on unique characteristics of product or product component or project/project phase. Organizational maturity - how mature is the organization in terms of an
and
Process established requirements management process. Availability of resources - a major consideration and always a challenge, especially if the organization is launching many projects
Monitoring
simultaneously.
Business
Plan
Analysis Requirements Management Plan This plan is an output of the Plan Requirements Management Process Task. The plan: Describes the approach to be taken to structure traceability
Requirements
Planning 7 Defines which requirements attributes will be used Identifies a requirements prioritization process Identifies a requirements change process and how changes will be requested,
Management
and analyzed, approved, and implemented
Process
Monitoring
1. How do change-driven methodologies (for example Agile software development) handle requirements change management? a. Change-driven methodologies use a formal
Business requirements change control process and a formal requirements prioritization process. Incorrect. Change-driven methodologies do not use a formal requirements change control
Plan
Analysis process and a formal requirements prioritization process. b. Change-driven methodologies do not typically have a change control process that is separate from the requirements
Requirements
Planning 8 prioritization process. All requirements ("new"/"changed") are recorded in the product backlog and prioritized. Correct! Change-driven methodologies do not typically have a change
Management
and control process that is separate from the requirements prioritization process. c. Change-driven methodologies don't prioritize requirements. They handle requirements change in a
Process
Monitoring somewhat arbitrary way, sometimes formally, sometimes informally. Incorrect. Change-driven methodologies do prioritize requirements. The process to handle requirements change
may be informal, but it's not arbitrary.
Business 2. Even simple changes in requirements can have far-reaching consequences for the project. So, the Business Analyst involved in planning any type of requirements change
Plan
Analysis management process should be concerned with: a. Determining the cost/time estimate of making the change, as well as either benefits or risks for making the change Incorrect. Not
Requirements
Planning 9 the most complete answer. b. Adopting techniques like risk analysis that could establish whether the change is feasible Incorrect. Not the most complete answer. c. Following an
Management
and established process for requesting change and determining who will authorize any changes. Incorrect. Not the most complete answer. d. All of the above. Correct! All these choices
Process
Monitoring (A,B and C) need to be taken into consideration when planning a requirements management process. e. A and C only. Incorrect. A and C are correct choices, but B is also correct.
Business
Manage
Analysis Manage Business Analysis Performance The primary purpose of this task is to manage (and monitor) the performance of business analysis activities to ensure that they are
Business
Planning 1 effectively executed. In the planning stage, the business analyst needs to determine which metrics will be used to measure the work performed, such as: Tracking the BA work
Analysis
and Assessing the quality of the work Reporting issues Managing problems
Performance
Monitoring
Business
Manage if (AC_FL_RunContent == 0) { alert("This page requires AC_RunActiveContent.js."); } else { AC_FL_RunContent( 'codebase','http://download.macromedia.com/pub/shockwave
Analysis
Business /cabs/flash/swflash.cab#version=8,0,0,0','width','600','height','250','id','ManageBaQuest_RollOver','align','middle','src','../media/AR01/05015
Planning 1
Analysis /ManageBaQuest_RollOver','quality','high','bgcolor','#ffffff','name','ManageBaQuest_RollOver','allowscriptaccess','sameDomain','allowfullscreen','false','pluginspage','http:
and
Performance //www.macromedia.com/go/getflashplayer','movie','../media/AR01/05015/ManageBaQuest_RollOver' ); //end AC code }
Monitoring
Business
Manage
Analysis
Business Project and Product Metrics The next item in this topic focuses on project and product metrics, that is, the processes and methods of measuring how well the project is proceeding.
Planning 2
Analysis Project metrics focus on three primary criteria:
and
Performance
Monitoring
Business
Manage
Analysis
Business
Planning 2
Analysis
and
Performance
Monitoring
if (AC_FL_RunContent == 0) { alert("This page requires AC_RunActiveContent.js."); } else { AC_FL_RunContent( 'codebase','http://download.macromedia.com/pub/shockwave
/cabs/flash/swflash.cab#version=6,0,0,0','width','250','height','335','id','MoreAboutMetrics_RollOver','align','middle','src','../media/AR01/05015
Business
Manage /MoreAboutMetrics_RollOver','quality','high','bgcolor','#ffffff','name','MoreAboutMetrics_RollOver','allowscriptaccess','sameDomain','allowfullscreen','false','pluginspage','http:
Analysis
Business //www.macromedia.com/go/getflashplayer','movie','../media/AR01/05015/MoreAboutMetrics_RollOver' ); //end AC code } More about Metrics The three criteria of Time, Quality, and
Planning 3
Analysis Money are measurable and need a benchmark for comparison. This is so the business analyst (and project manager) can evaluate the project's status and make decisions to
and
Performance remain within the specified constraints. By monitoring these metrics, analysts and project managers can make adjustments to resources (hire more people, ask for more money,
Monitoring
negotiate for requirements changes, etc.). Generally, metrics should be collected and reported on a regular basis (such as weekly) and allow ample time for analysis and further
data collection, if needed.
Business
Manage
Analysis BA Performance Metrics Typically, the performance metrics used for BA work are aligned with the overall project metrics. For example, performance metrics could define a certain
Business
Planning 4 number of hours to produce a deliverable or a particular due date. Also, the metrics could be the deliverable itself. It all depends on how the metrics are defined at the beginning of
Analysis
and the project. When defining metrics, there are three elements to consider:
Performance
Monitoring
Business
Manage if (AC_FL_RunContent == 0) { alert("This page requires AC_RunActiveContent.js."); } else { AC_FL_RunContent( 'codebase','http://download.macromedia.com/pub/shockwave
Analysis
Business /cabs/flash/swflash.cab#version=6,0,0,0','width','600','height','200','id','BaPerformanceMet_RollOver','align','middle','src','../media/AR01/05015
Planning 4
Analysis /BaPerformanceMet_RollOver','quality','high','bgcolor','#ffffff','name','BaPerformanceMet_RollOver','allowscriptaccess','sameDomain','allowfullscreen','false','pluginspage','http:
and
Performance //www.macromedia.com/go/getflashplayer','movie','../media/AR01/05015/BaPerformanceMet_RollOver' ); //end AC code }
Monitoring
Business
Manage
Analysis Variance Analysis Please refer to pages 51 and 52 of the BABOK for more information and examples of this technique. Variance analysis is a technique that the business analyst
Business
Planning 5 can use to analyze discrepancies between planned and actual performance. One aspect to keep in mind is the magnitude of the variances based on the metric that is being
Analysis
and analyzed. If variances are found, the BA will determine if any corrective actions are necessary.
Performance
Monitoring
Business Manage 1. The organization has identified specific due dates for business analysis work within the project. While assessing the performance of the BA work so far, you discover that some of
Analysis Business these dates might slip because the work is going slower than expected. Therefore, you a. Keep quiet about this discovery because it will probably correct itself. Incorrect. You'll
Planning 6 never want to do that, will you? b. Decide to take corrective action by analyzing the gap between the expected BA work and the current work so far.Incorrect. Not the most complete
Analysis
and Performance answer. c. Update the project team on your findings, incorporating the variance analysis findings and describing a corrective line of action to keep the project on track. Incorrect. Not

4 of 5 7/8/2016 4:40 PM
Print http://cat.ocw.uci.edu/oo/getPrint.php?course=OC1305015

the most complete answer. d. A and C only. Incorrect. A is not the right choice at any time, would you agree? e. B and C only. Correct! B and C are both part of a corrective plan of
Monitoring
action.
Business In this lesson, you learned about the Business Analysis Planning and Monitoring Knowledge Area. Key topics included: Plan Business Analysis Approach Conduct Stakeholder
Analysis Analysis Plan BA Activities Plan BA Communication Plan Requirements Management Process Manage BA Performance The planning and management of the requirements
Lesson
Planning 1 process resembles in many ways traditional project management, which you may have studied in an introductory course on the subject. Though the BABOK focuses on the
Summary
and requirements gathering function, it is very useful for business analysts to understand modern project management methodology in general - not only because it helps them create a
Monitoring better requirements implementation and management plan but it helps them understand how to participate on a project effectively.

5 of 5 7/8/2016 4:40 PM