business analysis - how to gather and document user requirements (1)

8/14/2019 Business Analysis - How to Gather and Document User Requirements (1)

1/193


2/193

Copyright ESI International

April 2009

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted,in any form or by any means, electronic, mechanical, photocopying, recording, or

otherwise, without the prior written permission ofESI International.

ESI grants federal government users "Restricted Rights" (as the term is defined in FAR52.227-14 and DFARS 252.227-7013). Use, reproduction, or disclosure of these materials is

subject to the restrictions set forth in the MOBIS, FSS, or contract under which the materialswere provided.

All material fromA Guide to the Project Management Body of Knowledge(PMBOKGuide)is reprinted with permission of the Project Management Institute, Four Campus Boulevard,

Newtown Square, Pennsylvania 19073-3299, USA, a worldwide organization of advancing

the state-of-the-art in project management. Phone: (610)356-4600, Fax: (610)356-4647.

PMI

did not participate in the development of this publication and has not reviewed thecontent for accuracy. PMIdoes not endorse or otherwise sponsor this publication andmakes no warranty, guarantee, or representation, expressed or implied, as to its accuracy or

content. PMIdoes not have any financial interest in this publication and has not

contributed any financial resources.

The names of all companies and characters used in these materials are purely fictional. Any

resemblance to any existing or no longer existing company or living or dead person is not

intended, and is purely coincidental.

PMI is a service and trademark of the Project Management Institute, Inc., which is

registered in the United States and other nations.

PMBOK is a trademark of the Project Management Institute, Inc., which is registered in theUnited States and other nations.

PMPis a certification mark of the Project Management Institute, Inc., which is registered inthe United States and other nations.


3/193

CONTENTS

Page

Chapter 1: Introduction to Requirements Elicitation.............................................. 1

Reference Material...................................................................................1Positioning Business Analysis................................................................... 2The Requirements Elicitation Process .......................................................7Requirements........................................................................................... 9The Key Requirements Documents ........................................................ 15Chapter Summary ..................................................................................19How to Gather and Document User Requirements: Next-Steps

Action Plan...................................................................................... 20Action Plan............................................................................................21

Chapter 2: Establishing Vision, Scope, and Quality .............................................. 23

Reference Material.................................................................................23Eliciting Solution Vision......................................................................... 24Defining Solution Scope ........................................................................29Ensuring Solution Quality ......................................................................32Validating Vision and Scope ..................................................................35Chapter Summary ..................................................................................37How to Gather and Document User Requirements: Next-Steps


Chapter 3: Modeling at the Enterprise Level ........................................................ 41

Reference Material.................................................................................41The Function of Modeling in Business Analysis ...................................... 42Business Rules ....................................................................................... 44Modeling Techniques ............................................................................ 48Organization Models .............................................................................49Strategy Models ..................................................................................... 51Process Models......................................................................................53Information Models ...............................................................................61The Business Analysts Toolkit ............................................................... 63Chapter Summary ..................................................................................65How to Gather and Document User Requirements: Next-Steps

Action Plan...................................................................................... 66


4/193

CONTENTS

Page

Profiling Users ....................................................................................... 82Managing Risk ....................................................................................... 86Chapter Summary ..................................................................................89How to Gather and Document User Requirements: Next-Steps


Chapter 5: Requirements Elicitation..................................................................... 93

Reference Material.................................................................................93Overview of Requirements Elicitation ....................................................94Elicitation and Validation Techniques ....................................................99Reviewing the AS-IS.............................................................................101Survey Techniques............................................................................... 105Facilitated Techniques ......................................................................... 113Product-Based Techniques ...................................................................119Chapter Summary ................................................................................122How to Gather and Document User Requirements: Next-Steps

Action Plan ....................................................................................123

Action Plan..........................................................................................124Chapter 6: Developing the Business Requirements Document........................... 126

Reference Material...............................................................................126What Is the BRD?.................................................................................127A Note About Technical Writing ..........................................................137Analyzing Requirements ......................................................................148Documenting Requirements.................................................................151Chapter Summary ................................................................................162How to Gather and Document User Requirements: Next-Steps

Action Plan ....................................................................................163Action Plan..........................................................................................164

Chapter 7: Validating Requirements................................................................... 166

Reference Material...............................................................................166Checking the BRD ...............................................................................167Building Consensus ............................................................................. 174Approval and Change Management .....................................................184Chapter Summary ................................................................................186How to Gather and Document User Requirements: Next-Steps

Action Plan ....................................................................................187A ti Pl 188


5/193

Introduction to Requirements Elicitation

Reference Material

Business analysis is an important step in the development of businesssolutions. It involves the investigation of a business problem (root causeanalysis) or opportunity, the systematic analysis and documentation of

the requirements that a solution must satisfy (requirements elicitation),and support throughout solution development, testing, andimplementation to ensure the requirements are met (requirements

management).

This course focuses specifically on the requirements elicitation and

documentation processes in business analysis. While the processes andtechniques presented are often thought of in terms of systems or software

development, they are applicable to process improvement and solutiondevelopment efforts in general.

Chapter Overview

1


6/193

Introduction to Requirements Elicitation

Positioning Business Analysis

Various studies over the last decade have shown that most technologyprojects fail in some way, from total abandonment of the project to costoverruns, schedule slippage, and missing features. Numerous IT

professionals report at least one IT project that either failed or sufferedfrom cost or time overruns or missing features.

The most common reasons cited for project failure are

A lack of user involvement in design and developmentPoorly defined or incomplete requirements

Changing requirements and specifications

Other frequently cited reasons for project failure are

Requirements that do not map to business goalsA lack of management support

Scope creep and poor change managementA failure to understand project complexityUnrealistic expectations, requirements, or timelinesA lack of resources

Poor risk planning

A failure to align the solution to the business environment orculture

Business analysis helps set the stage for successful project completion bymanaging expectations and risk and providing a clear, complete pictureof solution requirements from the outset. By preventing errors during the

Analysis phase, the business analyst (BA) eliminates costly rework lateron in the project. Without this initial work, no amount of competentproject management can overcome the resulting problems stemming

from incomplete or misunderstood requirements, scope creep, and poorunderstanding of project goals and complexity.

What Makes ProjectsFail?

41


7/193

Positioning Business Analysis (continued)

The BAs involvement in a project may begin with a small work requestto investigate an operational problem. The BA needs to link theoperational problem to a business opportunity that affects customers,cost, or compliance. This helps ensure that any business process

improvements resulting from the investigation are worth the investment.Depending on the business impact, the investigation may remain a small

work request, or it may lead to the initiation of a project.

The PMBOKGuide defines a project as a temporary endeavorundertaken to create a unique product, service, or result.1A projectmanager (PM) is the person assigned by the performing organization to

achieve the project objectives.2

Ideally, both the PM and BA will be involved throughout the project life

cycle with clearly defined roles. The PM and the BA support each other,with the PM responsible for orchestrating the project as a whole and theBA responsible for ensuring that requirements clearly reflect the businessneed and remain mapped to business goals. The table below illustrates

some of the differences between the two roles.

Business Analyst Project Manager

Defines solution scope

Models business (AS-IS)Develops requirementswork plan (RWP)Develops business

requirements document(BRD)Models requirements

(TO-BE)Validates requirementsManages requirementsSupports testing

Defines project scope

Forms project teamEstimates resourcesDevelops project plan

Coordinates projectManages project constraintsReviews and acceptsproject

Performs project closeoutCaptures lessons learned

A Note on ProjectManagement


8/193


The project constraints, which represent the scope, cost, time, risk,quality, and resources on a project, are a key aspect of projectmanagement and are depicted as interrelated in the below graphic,because each facet is critical and related to the others. In fact, changing

one almost inevitably changes the others.

What is meant by each facet or factor of the project constraints?

Scope:as defined in the PMBOKGuide, p. 440, is the sum ofthe products, services, and results to be provided as a project.More specifically, project scope is the work that must beperformed to deliver a product, service, or result with the

specified features and functions (PMBOKGuide, p. 436). Inother words, project scope is all the work that must be completed

for the project.

Budget/cost: the approved estimate for the project to any workbreakdown structure component or any schedule activity.(PMBOKGuide,p. 420)

Project Schedule/time: the planned dates for performing scheduleactivities and the planned dates for meeting schedule milestones.(PMBOK G id )

The Project

Constraints


9/193


Risk: an uncertain event or condition that, if it occurs, has apositive or negative effect on the projects objectives. (PMBOKGuide,p. 438)

Quality:the degree to which a set of inherent characteristics

fulfills requirements. (PMBOKGuide,p. 437)

Resources: skilled human resource, equipment, services,

supplies, commodities materials, budgets or funds. (PMBOKGuide, p. 438)

What then is the constraint? The constraint is how each factor affectsthe others. For example, if a decision is made to speed up the schedule

and complete a project earlier than originally planned, it will haverepercussions. It may require the assignment of more resources or a

reduction in the scope of the project lessening the quality. If projectmanagers can make their managers and clients understand the projectconstraints, they will avert or solve many potential problems!

The classic example of compromise to keep the project constraintsbalanced arises when the project schedule must be accelerated. If a

project manager develops a reasonable schedule to complete a projectwithin two months but is required to finish in half the time, one of threethings will happen: The project will either cost more because it willrequire added or more costly resources to complete on time; the end

products scope or quality will suffer; risk increases regardless, or somecombination of both consequences will occur.

The requirements elicitation process takes place during the Analysisphase of the project.

The above life cycle is a generic development version Different

The ProjectConstraints

(continued)

Business Analysis and

the Project Life Cycle


10/193


All business analysis deliverables and requirements should have thefollowing five quality attributes. They should be

Visible.Business analysis mandates the formal documentation of

all requirements. Nothing should remain hidden or left to verbalagreement.

Specific.All requirements and deliverables must be described in

enough detail that they can be differentiated from relatedrequirements and deliverables.Traceable.Traceability ensures forward and backward mapping

of project deliverables from the various level of requirementsthrough their system specifications and shows how the differentlevels relate to each other and to business goals.

Accountable.Business analysis mandates that all requirementsdocumentation be approved by the business sponsor, who

represents the aggregate needs of the users and has authority(delegated by the project sponsor) to sign on their behalf.

Measurable.Although users may begin by describingrequirements in qualitative language, the BA must work withthem to elicit and define quantifiable measurements ofrequirements success. Only then can the project team develop

appropriate quality standards to ensure that requirements areunderstood and testable.

Depending on the project, many participants may be involved inrequirements elicitation. Some of the most common participants are

Customers. A customer requests and accepts the product, system,or service. The customer (or someone the customer reports to) isusually the project sponsor. This means the project sponsor often

funds the project. The project sponsor has a managerial (as

opposed to a day-to-day) view of the solution.End users.As the name suggests, end users are people who willuse, operate, and maintain the new product, system, or service.

These individuals need the product, system, or service to performtheir jobs. End users can have a significant voice in the overall

corporate acceptance of the solution after it is implemented.Business analysts Business analysts develop business

Business AnalysisQuality Attributes

Participants in

RequirementsElicitation


11/193


Systems analysts.Systems analysts use requirementsdocumentation to identify technical specifications so thatdevelopers can build the technology to accommodate business

needs. Systems analysts may also play a support role in helpingthe business analyst elicit functional and nonfunctionalrequirements necessary to support user requirements.

Testers.Testers execute test scenarios to prove that the product,system, or service meets or conforms to requirements. Testers area great resource for reviewing requirements to ensure that theycan be measured. The project needs testers from both the

business and technical areas to test the solution effectively.Business sponsor.The business sponsor, often called the projectsponsor, signs off on the project and its deliverables. The business

sponsor may delegate acceptance authority to another individual,

known as the client acceptor. The project must have a singlepoint of approval.

Other project participant responsibilities may include regulatory, legal, orauditing roles. In addition, business owners, technology vendors,

developers, operations support, and technical or end-user trainers mayparticipate in identifying solution requirements. All participants havetheir own ideas and objectives concerning project requirements, and it isup to the BA to elicit, analyze, and structure the information to best

facilitate meeting business goals.

The Requirements Elicitation Process

The primary focus of business analysis is requirements elicitation and

documentation. The requirements elicitation process can be illustrated asfour activity streams interwoven with four underlying themes.

The underlying themeselicit, structure, document, validateare thefour basic steps repeated throughout the iterative activity streams. Theprocess is more than just listening to people and writing down what they

Participants in

RequirementsElicitation(continued)

Overview


12/193

The Requirements Elicitation Process (continued)

The requirements elicitation process can be illustrated as four activitystreams interwoven with four underlying themes. Although the followingchart shows a sequential process, in practice the activities can overlapconsiderably, especially since the BA typically uses an iterative approach

to requirements elicitation and documentation.

The first activity stream traces the development of the vision and scopereport, which defines, at a high level, what the organization hopes toaccomplish and sets the boundaries for the requirements elicitation. The

second activity stream traces the development of the requirements workplan (RWP), outlining the schedule, cost, and resources necessary for theAnalysis phase. The third activity stream shows the requirementselicitation itself, involving various elicitation techniques, as well as

business and process modeling to show both current and future states.Finally, the fourth activity stream traces the development of the business

Documenting inStages


13/193

The Requirements Elicitation Process (continued)

Note: The goal is for the BRD to be comprehensive. However, in reality,the BA strives for excellence based on the requirements work planapproved by the business sponsor. Excellence means that the BA doesthe best analysis in the amount of time and cost set.

Having a formal documentation strategy guides the requirementselicitation process and ensures the capture of adequate information for

validating and supporting requirements. Although it requires moreup-front time and effort than ad hoc approaches, the overall project iscompensated with less time and expense due to rework. A formaldocumentation strategy

Sets expectations for all concerned as analysis gradually uncoversrequirements

Structures the approach to complex solution environments, withpredefined review, feedback, elaboration, and approval pointsProvides communication, planning, and negotiation tools usedthroughout the requirements elicitation process

Having such a formal documentation strategy, or any rigid process forthat matter, may seem counterintuitive in rapid developmentenvironments, but the need for parties to develop a common

understanding and prepare a set of written requirements (which may be

in the form of code) still exists. The documentation simply happens at anaccelerated pace.

Requirements

A basic definition of requirement is a documented representation of acondition or capability

[N]eeded by a stakeholder to solve a problem or achieve anobjective[T]hat must be met or possessed by a solution or solution

Documenting inStages (continued)

The Importance of aDocumentation

Strategy

Requirements VersusSpecifications


14/193

Requirements (continued)

In contrast, a specificationdetails how the condition or capability will bemet, providing design criteria such as prescribed materials or dimensions.The difference between requirements and specifications is thatrequirements define the functions and characteristics of the solution and

specifications define the method (design) used to provide the solution.

The BA is responsible for requirements, and the systems analyst orsolution team is responsible for specifications. The table below explainsthe difference between requirements and specifications:

Requirement Specification

Answers who, what, where, when,how often, and how much isneeded to solve the problem (or

pursue the opportunity)

Answers how we will solve the

problem (or pursue theopportunity)

Describes performance; nomention of possible technology

Describes technical solution

Concerned with processes andbehavior

Concerned with physicalarchitecture and infrastructure

Example:An integrated administrative systemto track student enrollments

Example:A three-tier Web solution usingASPover an Oracleback end

Throughout the requirements elicitation process, the BA must identifyand monitor assumptions, constraints, and dependencies. Any of the

three can have a significant effect on project success. (For example,careless assumptions can both create constraints and cause the BA tomiss constraints that might otherwise be obvious.)

The BA must identify and document assumptionspertaining to theanalysis. An assumption is a factor that is considered to be true, real, orcertain and is often used as a basis for decision making (Ward, p.24).

Requirements VersusSpecifications

(continued)

Assumptions,Constraints,

Dependencies


15/193


Assumptions include, but are not limited to, the following:

Priority of the project relative to other projectsBusiness and system environment within which the solution will

liveHuman resources expertise before, during, and following

implementation of the solution (which leads to a training plan)

Constraintsare limits that may be imposed on the solution. When theconstraint is deemed necessary, then the constraint becomes a

requirement. The BA needs to investigate each constraint to understandthe limits it imposes and whether it is truly necessary.

Some typical project constraints that limit solution options include

Existing or planned technology infrastructure

New technology that will become available during the project lifecycleCost Hard costs, including budget Soft costs, including opportunity cost

ScheduleResource availability and competency levelsBusiness pressures

Strategic, tactical, operational direction Politics Regulation and policy Market pressures

Dependenciesare relationships among projects and project-relatedfactors that could affect project success. Dependencies may be external(outside the control of the team or organization) as well as internal.

Some typical sources of dependencies includeGovernment actionsWeatherPerformance of others, such as subcontractorsRelated projects

Limitations on resources

Assumptions,Constraints,

Dependencies(continued)


16/193


Typically, as part of the requirements elicitation process, the BA capturesvarious levels of requirements. Part of the BA role involves linkingrequirements and ensuring they are traceable, while resolving conflictsand ensuring that project stakeholders understand the requirements

themselves as well as the relationships among the various requirements.

Requirements must be mapped to both business needs and the resultingdeliverables. All requirements must be linked from the lowest level(resulting deliverable) up to the top level (business need) to ensure a

strong business case. Lack of clear, explicit links results in a weakbusiness case, which in turn makes it more difficult to obtain funding,resources, and commitment for the project.

At minimum, the BAs requirements documentation should capturewhere each requirement came from (who suggested it and why), how

each supports business goals, what level each is (and how it relates to thelevels above and below), and how requirement success will bemeasured. In other words, the requirements should be visible, specific,traceable, accountable, and measurable.

Four levels of requirements (with several subdivisions within levels) feed

into the final specifications.

Level ofRequirement

Requirements Source Elicited By

Regulatory Internal or external legal orgoverning body

Business:

Strategic

Senior management

Business:Tactical

Middle management

Business:O ti l

First-line management

Business Analyst

RequirementTraceability

From Requirementsto Specifications


17/193


For example, the case of an ATM illustrates a wide range of requirementsanswering questions, such as

Why do banks use these systems?What high-level business requirements do they satisfy?What are some of the physical features of ATMs?

What kinds of functions do they perform for users?

ATM regulatory requirement:All ATMs must comply with the bankingregulations of the resident state or political entity.

Regulatory requirements originate from the federal government, bankingindustry standards and practices organizations, or internal regulations

within the individual banks. They are usually incorporated by reference,noting the version and paragraph number of the regulatory document.

ATM business strategic requirement: By providing superior service toour retail customers, Monumental Banks ATM network will increaseassociated service fee revenue by 10% per annum on an ongoing basis.

The strategic requirement focuses on the long-term, strategic goals of theorganization. It is measurable, but still a very high-level, strategic

statement.

ATM business tactical requirement:Monumental Bank ATMs must allowseamless interoperability for all functions provided by BANK 3000,allowing our retail customers who have accounts with both banks to useour ATMs as if they were using a BANK 3000 ATM.

Tactical requirements focus on the needs of middle management and

interoperability among internal and external systems. Many projectsbegin as tactical responses to strategic goals.

ATM business operational requirement:ATM-based account transactionupdates must occur in real time for all accounts.

From Requirements

to Specifications(continued)


18/193


Operational requirements focus on the needs of operational managementwith regard to staff and system activity. They address issues with theeveryday operations of the organization.

ATM user requirement:Users must be able to deposit funds into their

accounts.

User requirements focus on the experience users need to have with thesystem, with no concern for the inner workings of the system. Theserequirements are tied to benefits and/or risk mitigation at the job level.They may still be high level and form the basis for functional and/ornonfunctional requirements.

ATM solution requirement:The solution must provide the ability towithdraw funds from a personal account.

Solution requirements describe the technology-independent behaviorsand information needed by the solution to support the user requirements.

There are three basic types of solution requirementsfunctionalrequirements, nonfunctional requirements, and transition requirements.

From Requirementsto Specifications

(continued)


19/193


Type of

SolutionRequirement

Definition Example

Functional The product capabilities, orthings the product must do for itsusers. (BABOK, p.227)

The solution mustallow users tocheck theiraccount balance

prior towithdrawingfunds.

Nonfunctional(quality of

service)

The quality attributes, design

and implementation constraints,

and external interfaces that theproduct must have. (BABOK, p.228)

The transaction

must take place

from login to cashin less than oneminute.

Transition A classification of requirementsthat describe capabilities that thesolution must have in order tofacilitate transition from the

current state of the enterprise tothe desired future state, but thatwill not be needed once thattransition is complete. (BABOK,p. 234)

Existing automated

teller machines(ATMs) mustcontinue to

operate while thenew ATM networkis beingimplemented.

The Key Requirements Documents

This section provides an overview of the key documents necessary tomanage project requirements. The BA serves in the appropriate lead or

support role in the creation of each resulting in a suite of requirements

From Requirementsto Specifications(continued)

Documenting theProcess


20/193

The Key Requirements Documents (continued)

These documents represent key milestones in the elicitation, structuring,documentation, and validation of requirements. Different organizationsmay

Use different names for the same documentsBuild the documentation set in a different order

Combine documents

Have additional documentsIn reviewing the key documents, focus on the purpose of the individual

documents, not their titles. Focus areas for the BA are shaded in thefollowing table.

Document BA Role Description

Project charter Contributor Created during project initiation, under

the direction of the business sponsor Provides formal, high-level scope

definition and project deliverable

accountability

Empowers the project team to act on

behalf of the business sponsor

Vision and scopereport3

Lead orcontributor

Defines opportunity and scope with

volumetric values

Enumerates high-level benefits andrisks to the organization

Provides general cost estimates

May offer possible solution approaches(buy/build)

May be authored by the BA or PMthrough high-level discussion with key

stakeholders (a common mistake is not

to involve the BA or PM) Begins the requirements elicitation

process with the business sponsor andkey stakeholders

The Key Documents


21/193


Business case Contributor Is a concise and focused overview ofproject scope, benefits, risks, costs, andrecommended solution

Created by a team of contributorsincluding the PM, BA, financial analyst,

business sponsor, and key stakeholders Seeks formal investment funding

approval from executive committee orinvestment planners

Tied to quantified projected profits,cost savings, and revenue streams over

time

May be done twice: as an initial

business case (following vision andscope definition) and as a final business

case (more detailed, following BRDapproval)

RWP Lead Is a mini project plan focusing solelyon the scope, cost, and schedule of theAnalysis phase (requirements

elicitation) of the project

Created by the BA

May become a component of the

overall project plan

Must be completed and approved

before any requirements analysis workbegins because analysis consumes

project resources, budget, and time

The Key Documents(continued)


22/193


BRD Lead Is an elaboration of the regulatory,business, user, and system (functional,nonfunctional, and implementation)

requirements

Created by the BA and handed off to

the systems analyst following formalreview and approval by the businesssponsor

Provides insights into the current (AS-

IS) and future (TO-BE) states of theorganization

Includes detailed profiles of usercommunities

Provides a baseline for requirementsmanagement throughout the project

life cycle

Vendor requestdocuments

Contributor Collectively called RF(x); includesrequest for information (RFI), requestfor proposal (RFP), and request forquotation (RFQ)

Prepared by the PM with support fromthe project team

May incorporate the BRD as part of its

terms in the RFP

Business contractdocuments

Contributor Is legally binding, documentedcommitment between the solution

provider (internal or external) andfunding organization

Is completely dependent on successfulrequirements elicitation and

documentation

May include professional services

agreement, statement of work, end-userlicense agreement

The Key Documents(continued)


23/193

Chapter Summary

Poorly defined or incomplete requirements are a majorcause of failed projects.

Requirements elicitation takes place during the Analysisphase of the project life cycle.

The business analyst is responsible for solution scope, andthe project manager is responsible for project scope.

The requirements elicitation process comprises four activity

streams: vision and scope definition, requirementsplanning, requirements elicitation, and requirementsdocumentation.

During the requirements elicitation process, the BA collectsand categorizes various

Levels of requirements including regulatoryrequirements, business requirements (strategic, tactical,

and operational), user requirements, and solutionrequirements

Types of requirements including functional,

nonfunctional, and transition requirements

Requirements describe the functions and characteristics of

the solution, whereas specifications describe the method(design) used to provide the solution.

The business analyst needs to establish a formaldocumentation strategy and a set of documents thatprovides checks and balances to aid validation and ensure

traceability.

The business analysts primary deliverables in therequirements elicitation process are the vision and scope

report, requirements work plan, and business requirementsdocument.


24/193

How to Gather and Document UserRequirements:

Next-Steps Action Plan

The following worksheet is designed to help you begin prioritizing whatyou want or need to do when you return to your organization and to

develop a realistic timeline. Take a few minutes to think about andreview what you have learned from the course and how you will applythe principles learned when you return to your organization. Thendocument your next steps on the Action Plan.

1. Read the Questions to Consider to start thinking about actionsyou can take to improve your organizations processes.

2.

Develop a list of at least five actions in each area that you willcomplete when you return to work.

3. Next, identify who you need to involve for each item you have

listed.

4. Finally, identify the appropriate time frame for accomplishing

each of these steps. For items you know will be ongoing, identifymilestones for each period (3, 6, 9, and 12 months and over).

Next-Steps Action

Plan


25/193

ESI 21

How to Gather and Document User Requirements Chapter 1: Introduction to Requirements Elicitation

Action Plan: Apply what you have learned about requirements elicitation by developing a list of actions you will complete when you return to yourorganization.

Questions

to Consider:

How can business analysts work with project managers in my organization to ensure project success?

How do I differentiate between the different levels and types of requirements?

Time

What do I want/need to do next? Who 3 months 6 months 9 months 12+ months

1.

2.


26/193

ESI 22

Time


3.

4.

5.


27/193

Establishing Vision, Scope, and Quality

Reference Material

The vision and scope report is the first important deliverable in therequirements elicitation process. Capturing solution vision and scope is acritical step in the requirements process that provides stakeholders and

the project team with a high-level description of the proposed solutionfor which the BA will gather requirements and that defines theboundaries of the proposed solution. Although the vision and scope

report looks at the business problem or opportunity from a high(conceptual) level, the report still needs to include quantified processimprovement targets, which are the foundation for the quality standardsagainst which the project deliverables will be measured.

Note:In this chapter, whether a business problem exists or a new

business venture is identified, the term opportunityis used to describeboth situations to reflect the positive nature of the vision.

Chapter Overview

2


28/193

Establishing Scope, Vision, and Quality

Eliciting Solution Vision

The vision and scope report clarifies the business opportunity that thesolution must address for stakeholders and the project team by providinga high-level view of the

Business goalsidentifying the business opportunities that werethe catalyst for the current project or investigationSolution visiona shared and clearly articulated description of

the proposed solution to the business opportunitySolution scopedefining the boundaries of the proposed solution

At the enterprise (or organizational) level, mission statements often areused to identify

Who the organization isThe goods and/or services it provides

Its customers, suppliers, and business partnersIts industry, market niche, and geographical boundaries

In contrast, enterprise vision statements deal with the TO-BE, or future

state, of the organization. Enterprise vision statements define where theorganization would like to be 5, 10, or 20 years from today without

regard for technology, timing, budget, or other constraints.

The mission describes the fundamental purpose for an organizationsexistence; the vision describes where the organization is going.

For example--

Mission:

Monumental Bank provides the highest level of customer service andmost advanced business and personal financial solutions throughknowledgeable team members, efficient teamwork, and technologicaladvancements while striving for innovative and creative ways to improve

our procedures and products.

Mission Versus

Vision: The AS-IS and

the TO-BE

42


29/193

Eliciting Solution Vision (continued)

Vision:

Monumental Bank will invest in its culture of continuous improvement inpeople, processes, and systems with the goal of becoming the leadingfinancial services supplier for personal and business banking in North

America, as measured by the annual Financial Services Customer

Satisfaction Index, by December 31, 2012.

In conjunction with this, we will realize a net market share increase of 30percent and a net profit increase of 20 percent compounded annually.

This strategic goal will encompass wide-ranging tactical initiatives underthe umbrella name Summit Seven, or S7.

In contrast with an enterprise vision statement, which describes wherethe organization will be in 5 to 20 years, the solution vision statementdescribes the desired state of the affected business areas once the projectis complete. The solution vision needs to

Address the business opportunityProvide an unbounded view of the possible solution

Map to business goalsBalance competing interests to provide a shared vision backed by

stakeholder consensusBe captured in the vision and scope reportBe only one or two paragraphs in length

While the BA is not responsible for developing the solution for theopportunity, the BA may be responsible for documenting the solution in

the vision and scope report. In addition, the BA can offer significantcontributions to the visioning process by

Organizing vision workshops

Clarifying, organizing, and prioritizing ideasValidating vision statements and solution features

Mission VersusVision: The AS-IS andthe TO-BE(continued)

Solution Vision

Capturing SolutionVision


30/193


Capturing the solution vision is a creative process involving acollaborative effort among stakeholders to define the high-level(conceptual) solution that will best address the opportunity whilefurthering business goals. The process is an excellent way to obtain

executive support for the project and build a sense of collectiveownership, enthusiasm, and mutual understanding. It includes, at

minimum, the

Project sponsorsUser representatives

Technical representativesProject managerBusiness analyst

Just as requirements are captured at different levels and types, dependingon the source, vision statements also reflect their source. For example

Strategic

Management Level

As an S7 initiative, the S7-ATM enhancement

project will provide innovative, new, and enhancedfunctionality to our ATM worldwide network by

1. Auditing and enhancing all existing ATM

functionality to provide clear anddemonstrable advantages to our ATM

customers compared with similar servicesfrom our competitors

2. Doubling the total number of service

offerings through new local and interbankfunctions

The success of the S7-ATM will be measuredagainst the goal of increased ATM-based marketshare of 10 percent in the first year of operation and3 percent every year thereafter until fiscal year-end

2012.

Capturing SolutionVision (continued)


31/193


Tactical ManagementLevel

The S7-ATM project will facilitate increasedenterprise-wide knowledge management anddecision support across all areas of Monumental

Bank related to personal and business accountmanagement.

It will fully integrate with existing and planned dataflow among our Investment Planning, Financial

Services, and Marketing applications.

Existing reporting functionality will be consolidated

from our current three separate ATM networkapplications.

OperationalManagement Level

The S7-ATM project will create increasedefficiencies and quality control for all ATM-related

operations. The standards for measuring the firstyear of operation enhancements are as follows:

1. Branch personnel: Full-time recovery (FTE)reductions of 25 percent related to dailyATM maintenance and service, to beaccomplished through increased

automation of system start-up, self-diagnosis, repair, and backup procedures.FTE recovery will allow for redeployment of

existing administrative personnel into moreadvanced ATM knowledge worker positions

to be determined.

2. Quality: System availability to be increasedto 96 percent within the first six months ofoperations and 98 percent thereafter, withassociated reductions in service costs.



32/193


User Level The S7-ATM project will provide ATM bankpersonnel with the following benefits:

1. Web-based graphical user interface (GUI)portal interface to the branch and head

office ATM administrative and supportnetwork, tailored to the needs of the ATMadministrator, ATM technical

representative, and ATM help deskconsultant

2. Enhanced communications among thesepositions for situation identification,

analysis, and resolution through instantmessaging, live voice link, and real-time

incident report collaborative editing

Each category of participants in the process has a different perspective

about the solution. The BAs job is to refine each level by steering awayfrom specifications, encouraging a future vision, and eliciting quantitativeinformation that ultimately allows the development of quality standards

against which the solution is measured. Remember that the BA mustdefine precisely what needs to be accomplished in the elicitation, leavingthe technical team maximum room for creativity in solution design.

Following the visioning process, the BA must analyze the results to lookfor potential problems and evaluate each statement collected. Consider

the following questions:

Does the solution vision map back to business goals?Does the solution vision have any conflicting statements?Do the stakeholders share a common understanding of the vision?

The BA must be sure to clarify any unclear or conflicting statements,

unspecific or immeasurable features, and abstract or intangible benefits.O l h i h i i d b d d d d f


Validating the Vision


33/193

Defining Solution Scope

Once the BA and project team capture the solution vision, the next stepis to define the solution scope. Solution scope places boundaries around

the solution by clearly delineating what project stakeholders expect thesolution to do and not do.

In contrast, project scope defines what work the project team will andwill not perform over the course of the project. Project scope applies to

the entire project and is the responsibility of the PM; solution scopeapplies only to the requirements of the solution itself and is the

responsibility of the BA.

Defining the solution scope is one of the most important early steps in

requirements elicitation because planning for everything else, includingproject costs, resources, risks, and so on, depends on it. It drives theother planning processes and thus, the project itself. If the BA does not

clearly define solution vision and scope, not only will the BA be unableto accurately plan the requirements elicitation process and managecustomer expectations, the PM and the project team will be unable to

accurately plan the time and costs involved for the project scope.

Do not make assumptions about what is included in solution scope.

Remember you are eliciting requirements, not determining them. Whenyou assume something is included, it may not be. When you assumesomething is excluded, it may be in scope in the mind of the customer.

Because including every feature imaginable in the solution is almost

never possible, defining scope becomes a natural follow-on process tovisioning. In scoping, the BA, stakeholders, and project team make trade-offs to determine what features to include in the solution based on

priority, effort, and resource considerations. Note that a featureis a high-level (conceptual) requirement that will be further defined into detailed

requirements during the analysis.

Once the ideas captured during visioning have been organized intological categories, the BA, stakeholders, and project team must decidewhat is in scope and what is out of scope. For example, the team may

d id t li i t id th t

Solution Scope

Versus Project Scope

Defining Boundaries


34/193

Defining Solution Scope (continued)

Obviously, the team will have to discuss some ideas more thoroughlythan others to determine whether they need to be considered in scope orout of scope. In the end, the team must have a clearly defined scope,listing both features that are included and those that are excluded from

the opportunity solution.

Scoping is especially critical in iterative development or rapid

development projects because each iteration can bring about scopechange. Scoping affords the project team the ability to classify features

into releases so that scope, although constantly changing, is a bit moremanageable.

Ultimately, the clear definition of vision and scope through businessanalysis will help

Guide requirements elicitationContain scope creepManage change

Manage client expectationsUnite the project team in a common purpose

Justify further resource commitment for the project

Establish quality standardsEstablish acceptance criteria

Scope creep is the gradual, progressive increase of a projects scope suchthat it is not noticed by the project team or the customer. Generallyscope creep occurs when the customer, project team, or other project

stakeholder identifies additional, sometimes minor, requirements thatwhen added together, collectively result in significant scope expansionand cause cost and schedule overruns.

One of the most important, ongoing uses of the vision and scope report isthe management of change and scope creep. Note that the BA hasdifferent concerns about scope creep than does the PM. The PM works to

avoid scope creep; in the requirements process, the BA works to managescope in order to maximize the benefits of the opportunity solution while

Defining Boundaries

(continued)

Benefits of DefiningVision and Scope

Scope Creep


35/193


The BA must not be seen by the customer as a roadblock to improvingsolution scope. The BA needs to balance the benefit with the time andcost needed to include all features in the solution. If prior to theapproval of the BRD, the BA is presented with a new feature that was not

cited within the original scope, the BA needs to analyze the benefit of thenew feature. Some questions to ask include

Can the added feature be mapped back to business goals?How will the added feature affect project schedule and cost? Isthe effect significant?

Who made the request?

If the change request is received after the approval of the BRD, the BAmust defer to the documented project change management process.

Change is simply the transition from one condition to another. In terms ofthe project environment, change can be any

Expansion or reduction of project scope

Modification of policies, processes, plans, or proceduresIncrease or decrease in costs or budgetsRevision to the schedule

Change requests can be direct or indirect, external or internal, mandatory

or optional. Once the BRD has been approved, only formallydocumented change requests can be processed, approved, and

implemented through the project change management process.

Changes to the project can come from almost anywherethe customer,the team, the project manager, senior management, or outside regulatoryagencies. The key from a project perspective is to manage them. Major

sources of change include

CustomersProject management and team members

Organization managementGovernment agenciesEnvironment

Scope Creep(continued)

What Is Change?

Managing Change


36/193


Because changes will happen, the project team must be ready for themwith a process that is written into the project plan. The PM must includea change management plan in the project plan, especially on technicalprojects. The change management plan needs to establish procedures

for

Submitting change requestsReviewing the effect of proposed changes on project cost, time,scope, and qualityApproving and rejecting proposed changes

Do not let comments in casual conversations be considered changerequests. All change requests, no matter what the source, must be visible(for example, submitted in a standard written format). The process must

clearly specify who has authority to direct changes and to what extent.

Enforcing the change management process may seem overly laborious ina rapid development environment, but it is still important to track whatchanges have been made, why they were requested, and who approvedthem. During rapid development, the business sponsor is in the room

with the designers and is available for immediate approval or disapprovalauthority. All meetings should be documented through meeting minutesor notes, thereby satisfying the need to document changes.

The BAs role in change management is to help the PM determine theimpact of the change on the requirements (scope) of the solution and theproject. The BAs role may also entail replanning how to test, or validate,

the requirements in the testing phase.

Ensuring Solution Quality

A final purpose of the vision and scope report is to provide a quality

baseline for the project. Quality is defined as the

Total characteristics of an entity or item that affect its ability toi f d i li d d

Managing Change

(continued)

Defining Quality


37/193

Ensuring Solution Quality (continued)

Customers define quality. No matter how well made the product, or howwell performed the service, an organization will not achieve quality if itsproducts and services do not meet customer expectations andrequirements.

This relationship to quality is why the BA needs to strive to quantifyvision and scope, despite most users tendencies to speak in qualitative

terms. Specificity greatly strengthens the BAs deliverables as well as theprojects overall business case. For example

Specify Instead of

The solution will increase revenue20 percent or more by 2008

The solution will increase revenue

No more than two defective partsper thousand, according tocompany standard 3.2.5

High-quality products

14-point text Readable text

Building quality measures into the solution from the start is much lessexpensive and burdensome than fixing deficiencies that are discoveredafter the solution has been implemented. In a nutshell, the more the BA

can do during the Analysis phase to elicit specific, quantifiable goals thathelp define quality standards, the fewer failures due to nonconformancethat will be discovered and require correction.

The cost of quality is generally shown as this equation:

cost of quality = cost of conformance + cost of nonconformance

The commitment to quality may increase an organizations conformance

costs (for example, hiring a business analyst to perform requirementselicitation and documentation), but the resulting savings innonconformance costs decreases the organizations total cost of quality.

Defining Quality(continued)

The Cost of Quality


38/193


After committing to a quality program, the opposite is generally true: Thepercentage of costs as a result of conformance is usually much greater

than the percentage for nonconformance. In the after example above,the organization is spending $5 million per year on conformance costs (a$2 million increase), but only $2 million on nonconformance costs (an

$8 million decrease) for a total of $7 million. As a result, theorganizations total cost of quality has decreased by $6 million.

Regardless of whether an organization is proactive or reactive aboutquality, there is a cost. In the long run, the total cost of quality is less

expensive in a proactive environment. However, proactively ensuringquality is often more painful and inconvenient because it appears to slow

down the start of a project.

In discussing quality in the context of requirements elicitation, twoimportant distinctions need to be made:

Quality versus gradeExcellence versus perfection

Grade refers to categories used to distinguish items with the same

function. For example, when you pull into a gasoline station, you canusually choose among three or more grades of gasoline: regular, super,and premium Any of the three will run a standard car but each offers a

The Cost of Quality(continued)

Grade, Excellence,and Perfection


39/193


Excellence is the highest level of quality that can be achieved withinproject constraints, such as schedule and cost. It is by nature a movingtarget (and a good reason to keep project time frames shorter thantechnology life cycles, because excellence today may be obsolete next

year). Perfection, on the other hand, means zero defects. Perfection has acost and in most cases, business solutions simply cannot afford zero

defects. The cost difference between a system that is available 100

percent of the time and one that is available 99 percent of the time maybe more than double (necessitating, for example, tandem systems).

The BA must realize that when customers demand perfection, what theyoften really want is excellence. The BA must determine the acceptablevariance: the difference between perfection (zero defects) and what is

both possible within project constraints and acceptable to the customer.

Validating Vision and Scope

The projects vision and scope are captured in the vision and scope

report, which includes, at minimum

The executive summaryApprovals

Current business, AS-IS model, describing the- Business problem and root cause Business opportunity

Vision and scope, TO-BE model, describing Process improvement targets Proposed solution featuresAny assumptions, dependencies, or constraints

RisksThe proposed scheduleThe proposed budget (with cost-benefit analysis)The revision log

Grade, Excellence,and Perfection

(continued)

The Vision and ScopeReport


40/193

Validating Vision and Scope (continued)

Before submitting the vision and scope report for approval, the BA needsto analyze each feature in the solution scope to determine its feasibility,to look for potential problems, and to evaluate risks. Consider thefollowing questions:

Does the solution vision map back to business goals?

Does each feature included in the scope map back to the solutionvision and business goals?Are there any conflicting statements in the solution vision?Are there any conflicting features in the solution scope?

Are all features feasible given known project constraints?Do the stakeholders share a common understanding of the visionand scope?

The BA must ensure that all statements are clear, all features aremeasurable, and all benefits are tangible. Only then is the vision and

scope report ready to be passed on for acceptance and approval.

Validating Vision andScope


41/193

Chapter Summary

Visioning is a key activity in the development of solutionscope.

Solution vision describes what will change once thesolution is implemented.

Solution scope delineates boundaries for the solution, bothfeatures that are included and those that are not.

Project scope is managed by the project manager; solution

scope is managed by the business analyst.

Quality must be analyzed according to desired grade and

excellence.

Cost of quality = cost of conformance + cost ofnonconformance


42/193

How to Gather and Document User

Requirements:

Next-Steps Action Plan

The following worksheet is designed to help you begin prioritizing whatyou want or need to do when you return to your organization and to

develop a realistic timeline. Take a few minutes to think about andreview what you have learned from the course and how you will applythe principles learned when you return to your organization. Thendocument your next steps on the Action Plan.

1. Read the Questions to Consider to start thinking about actionsyou can take to improve your organizations processes.

2. Develop a list of at least five actions in each area that you will

complete when you return to work.

3. Next, identify who you need to involve for each item you have

listed.

4. Finally, identify the appropriate time frame for accomplishing

each of these steps. For items you know will be ongoing, identifymilestones for each period (3, 6, 9, and 12 months and over).

Next-Steps ActionPlan


43/193

ESI 39

How to Gather and Document User Requirements Chapter 2: Establishing Vision, Scope, and Quality

Action Plan: Apply what you have learned about establishing the vision, scope, and quality by developing a list of actions you will complete when youreturn to your organization.

Questions

to Consider:

How can I work with stakeholders to define the solution vision and scope?

How can I manage change to the solution scope should the need for a change arise?

How can I ensure that quality is considered when eliciting requirements?

Time


1.

2.


44/193

ESI 40

Time


3.

4.

5.


45/193

Modeling at the Enterprise Level

Reference Material

This chapter introduces several modeling techniques that the businessanalyst (BA) uses to create the business architecture baseline. The BAuses models to document both the AS-IS (the current state of the

enterprise or process) and the TO-BE (the future state of the enterprise orprocess) at all levels of the organization with the goal of processimprovement. This chapter highlights the most commonly used models.

Chapter Overview

3

4

3


46/193

Modeling at the Enterprise Level

The Function of Modeling in Business

Analysis

Business analysis supports the investigation of problem areas andopportunities in existing or proposed business processes with a goal of

process improvement. The BAs toolbox in this endeavor is a collectionof enterprise and process models used to document current (AS-IS) andfuture (TO-BE) states.

With business models, the BA can

Produce clear, pictorial representations of the enterprise and its

processesHighlight areas of inefficiency and redundancy

Assess the impact of proposed changesDocument process changes that accurately reflect userrequirements

All the models are scalable, meaning the BA can perform analysis andrequirements elicitation at precisely the level of detail necessary. Themodels can be as simple or as complex as they need to be. At theenterprise level, the models give the BA a structure for asking questions

about the business. Such questions might include who is accountable for

various parts of the business, who are the suppliers for materials andservices, and what are the business locations. Process models, however,

give the BA an easy way to change processes to see the effect ofproposed improvements without actually changing the business.

BAs use models to document both the AS-IS (the current state of theenterprise or process) and the TO-BE (the future state of the enterprise or

process). Both AS-IS and TO-BE modeling use the same techniques, butthe goals and, therefore, the approaches are different.

Why Do We Use

Modeling?

AS-IS Versus TO-BE

43


47/193

The Function of Modeling in Business Analysis (continued)

Differences Between AS-IS and TO-BE Modeling

AS-IS (Current State) TO-BE (Future State)

Analysis covers the business area asneeded

Analysis covers all change areas andtheir relationship to other areas

Models may be incomplete Models are complete and unified

Analysis may be a mix of formal andinformal techniques

Analysis is formal and precise

Models specify areas for change Models extend solution vision,

highlighting changes from AS-IS

AS-IS modeling is part of enterprise analysis and provides the baseline

against which changes to the business architecture are measured. Itpositions the project within the goals, constraints, and mission of the

funding organization, and it facilitates root cause analysis. Outputs of thisprocess include

Business goals, drivers, and objectives

Organizational structure

Business functions and servicesBusiness processes

Business rolesKey stakeholders concernsGap analysis (what is the difference between the AS-IS and thedesired TO-BE?)

Sources of information for AS-IS information include

Decision makers (such as owners, shareholders, directors,

managers)Users and operatorsImplementers

TO BE d li id h i li i i b idi

AS-IS Versus TO-BE(continued)

AS-IS Modeling

TO BE Modeling


48/193

The Function of Modeling in Business Analysis (continued)

Once the elicitation is complete, the BA integrates user requirementswith the TO-BE models, developing a complete package to guidesolution design and construction.

When documenting requirements, models and text should be used

together. Lists of text-only requirements tend to be incomplete,ambiguous, confusing, and difficult to manage.A complete package that

integrates models with text requirements gives the project team severaladvantages because it

Encourages complete elicitation of requirements and rulesAids the understanding of requirements by providing a businesscontext

Helps ensure precision and clarityAllows for validation prior to implementationAids in managing changes

Helps ensure that solution requirements are consistent withsolution vision

Business Rules

Business rules govern the way a business initiates actions and responds tosituations under various conditions (for example, normal processing,alternative processing, and exception processing). Business rules mayoriginate inside (corporate policy) or outside (government regulation) theorganization, and they may take various forms in the organization, such

as

RegulationsCalculation formulas

Process rulesInformation management rulesDecision logic

Some sample business rules include the following:

TO-BE Modeling(continued)

What Are BusinessRules?


49/193

Business Rules (continued)

All submitted insurance claims must have the individuals name,date of incident, and the individuals policy number or the claimwill be returned to the individual.

A sales tax of 7.5 percent must be added to all purchases, exceptfood and prescription medicines.

Business rules and requirements are not the same thing. Business rulesare a characteristic of business operations and exist independently of the

proposed solution or opportunity. Requirements, on the other hand, arecharacteristics of the solution and describe it directly.

In general, business rules constrain processes and drive requirements.The BA often documents them with constraints in the businessrequirements document (BRD).

Often, business rules are not standardized or clearly defined, making it

difficult for the BA to capture the AS-IS. For example, business rules maybe embedded in programming code in existing applications, or they maybe implicit in everyday procedures. Even worse, they may exist only inthe minds of a select few individuals at the organization. This situation

presents problems for

Requirements elicitation and documentationBusiness process engineeringSolution selection, development, and implementation

Without existing documentation, the BA has to discover and documentbusiness rules in order to track their effect on the requirements elicited.Some of the sources for business rules are

Organizational decision makers (such as owners, shareholders,directors, managers)

End users and operatorsImplementers

Existing AS-IS models (especially logical data models and usecase scenarios)

Business rules are not absolute; they do change Even if business rules are

What Are BusinessRules? (continued)

Business Rules VersusRequirements

Sources for BusinessRules


50/193


For example, a convenience store business rule might be that vendorsonly restock goods after 6 p.m. During an analysis of reasons behind highoperating costs, the BA might investigate why the business rule exists. Ifno one in the business can provide a reason for the rule, the BA might

suggest that management approve deliveries earlier in the day. Thissimple validation could eliminate an invalid business rule that was

causing significant overtime costs for the vendor and were being passed

on to the store.

As a BA, you may not be able to catalog and track every business rule inyour organization, but you need to have some process in place for

capturing and tracking those business rules that do apply to your businessarea. Failure to do so can result in both the application of contradictorybusiness rules to a process or solution and the inconsistent application of

business rules. By capturing and tracking business rules, you canValidate business rules to ensure they support organizationalgoals

Eliminate contradictory business rules before they are built into asolutionGuide requirements elicitation according to constraints imposedby business rules

Monitor changes to business rules

Determine the relationships among business rules at the variousorganizational levels

Two methods for documenting and tracking business rules are catalogsand decision tables. General business rules are often stored in a centralrepository or catalog. At minimum, the catalog captures a unique ID, thebusiness rule itself, what type of rule it is, and the source of the rule. The

BA can use the catalog ID when referencing business rules in models.

Sources for BusinessRules (continued)

Tracking Business

Rules


51/193


Example:

Business Rule Catalog:

ID Rule Type Source

54 All full-time employees must be at

work performing work-relatedfunctions during the core businesshours of 9:00 a.m. and 3:00 p.m.

Constraint Company

policy

55 All employees must take one 15-

minute break for every 4 hours ofwork.

Constraint Government

regulation(OSHA v.2.5,4:15, p.365)

More complex business rules involving decision logic are better captured

in a decision table. Decision tables show how different outcomes dependon combinations of factors and allow the BA to capture very complicatedrules with multiple conditions and possible actions. These tables are later

used as the basis for condition-testing the system.

Tracking BusinessRules (continued)


52/193

Modeling Techniques (continued)


53/193

g q

Organization Organization model Business interaction model

Location modelStrategy Goal model

Impact model

Process Functional decomposition Event model

Use case diagrams and scenarios Workflow model Process model

Activity diagrams Relationship/input-process-outputInformation/communication

Data flow diagram Logical data model System model

These divisions are not absolute, and some models may function equallywell in more than one category (location models, for example, fit equallywell in any of the categories, depending on their use).

Organization Models

Models in the organization category define and structure organizationalcomponents of the business and their internal and external relationships.

These models help show what groups need to be considered and howstructure supports organizational goals.

Organization Models (continued)


54/193


The organization model is a hierarchical representation of anorganization and its supporting roles. Organization models (also knownas organizational charts) typically begin with high-level areas and aredecomposed within each branch, division, or line of business. They may

or may not involve the identification of key personnel.

The business interaction modelis a network representationof all or part

of the business showing organizational boundaries and interactions withinternal and external organizations. This model can be used to show

vendor and client relationships, with the identification of key deliverablesand commitments. In the example below, Whizbang Toys relies on ahighly coordinated supply chain to make its product lines.

Organization Model

Business InteractionModel



55/193


The location model is another network representation that shows variousgeographic locations of interest to the organization. It can be used tohighlight areas of geographic resource and financial investment, marketsegments or customer locations, or physical locations within a specific

facility. Location models may or may not plot locations on an actual map,but the BA needs to recognize that the layout of the model maysignificantly affect the analysis of the data collected.

Location models aid in the recognition of location-dependentrelationships. For example

Businesses with widely dispersed locations must accommodatedifferences in culture, language, legislation, and buying habitsMap-based models can help determine both areas that lackcoverage and those that have too much coverage

Strategy Models

Location Model

Strategy Models (continued)


56/193

gy ( )

The goal model is a hierarchical representation of business goalsassociated with business processes and their activities. The modeltypically begins with strategic goals and decomposes them to specifictactical and operational goals.

In the example below, Gardenation, Inc., has set a strategic goal to be theleading supplier of plastic lawn ornaments in North America by 2007

(S1). To support this strategic goal, the product development group haslaunched a series of tactical projects to produce a variety of products intwo new series: adventure and fantasy (T1 and T2). These tactical goalshave been further decomposed into the operational goals to upgrade

existing design systems and recruit new talent (O1 and O2). The goalmodel helps to ensure that all project goals map back to the mainstrategic goal.

Goal Model

Strategy Models (continued)


57/193

gy

Impact models, also hierarchical, organize the possible effects of achange and aid in the decision-making process. Arranging the possiblecosts, benefits, and risks of a project, they provide a snapshot of theoverall cumulative impact of a proposed effort, providing a basis for the

BA to determine whether the overall effort is worth making.

Process Models

Models in the process category define the processes and activities of thebusiness. This group contains the most varied collection of models anddiagrams (including process models) to show the functions of the

i d i i d l

Impact Model

Process Models (continued)


58/193

Functional decomposition diagrams are hierarchical models that show allthe essential business processes without showing any sequence orrelationships between them. These diagrams simply capture theprocesses. Traditionally, BAs have used these diagrams as the basis for

defining requirements. With the advent of object-oriented (OO)programming, BAs have switched to use case diagrams because they lendthemselves better to OO design.

FunctionalDecompositionDiagram



59/193

The event model is a Gantt chart

5

or calendar representation thatorganizes the business by key events. It can be fiscally oriented (forexample, month-end processing or year-end processing) orproduct/service oriented (following the project life cycle).

Use case diagrams and scenarios are part of the Unified Modeling

Language (UML).

6

They provide a simple, nontechnical way to describethe functionality of a system and can be used either to show the way acurrent system operates or to capture requirements for a proposed

system.

The diagrams (graphics) and scenarios (text) work in tandem to describe

the behaviors of the user and system interface. Not only can the BA usethis modeling technique to initially define user requirements, but the BAcan later refine the model by adding functional and nonfunctionalrequirements.

The diagrams depict users of a system as stick figures: a user being aperson, other system, or an event such as month-end processing. These

stick figures are called actors. The behavior between the actor and thesystem is depicted by an oval: a behavior being a function that the actorneeds to perform, with a title that is an action verbnoun pair. A line isdrawn to show the association between the actors and the use cases.

5 Gantt chart Graphic display of schedule related information Generally

Event Model

Use Case Diagramsand Scenarios



60/193

Use case diagrams depict the boundary of the system as a rectangle,called the subject. The rectangle is titled by the name of the system and issurrounded by the actors that are outside the boundaries of the system.Within the rectangle are the use cases along with lines associating them

with the actors.

Use case diagrams may also show relationships among use cases;however, relationships among actors are never shown.

BAs often create use case diagrams during interviews to initiallydocument an overview of user requirements, and then they follow upwith details by writing use case scenarios.

Use Case Diagramsand Scenarios(continued)



61/193

Use case scenarios flow out of use case diagrams, providing a detailed,step-by-step description of the behavior between the system and an actorin the accomplishment of a single business objective. BAs write use casescenarios as a series of numbered steps. For example, using the order

computer use case shown in the diagram above, a use case scenariomight be as follows:

1.0 The use case starts when the online customer selects Order

Computer

2.0 The online customer enters the product code for the desiredcomputer3.0 The system supplies a product description and price for the

selected computer4.0 The online customer enters credit card payment information

5.0 The online customer selects Submit6.0 If payment is authorized by the credit card company,the system

6.1Marks the orderas confirmed

6.2Forwards paymentinformation to the

accounting system6.3Returns an order

confirmation number to

the online customer

and the use case endsMany variations for each use case scenarios may exist to allow for normal

processing (sometimes called the happy path), alternative processing,and exception processing. These use case scenarios can also be used astest scenarios for the system.

The workflow model represents the business in terms of component

groups and the flow of work among those groups. The BA uses thismodel to describe key functions of departments and divisions, focusingon the identification of key hand-off points and roles. Business level(conceptual) workflow models do not depict the internal workings of

individual processes. They are conceptual overviews of interactions

Use Case Diagramsand Scenarios

(continued)

Workflow Model



62/193

Process models show the decomposition of the workflow into processesand activities. At the business level, they do not show the details ofindividual jobs and tasks. Process models, also called flowcharts, aregraphical models of how information moves through a process. They

begin in the top left corner of the page and move right and down throughthe flow of activities. Each arrow is unidirectional (there should be noendless loops), because every flow should have exactly one start and atleast one finish point. Therefore, every path through the flowchart must

be traceable from the start to one of the end points. Suppose oneflowchart,