business analysis tools, techniques, templates and tips february 17, 2008 prepared by daugherty...

Business AnalysisTools, Techniques, Templates and Tips

February 17, 2008

Prepared by Daugherty Business Solutions for confidential review

• What is Business Analysis?• Role of the Business Analyst• IIBA• Industry Standards

– Software Tools– Metrics– Methods– Techniques

Agenda



What is Business Analysis?

The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems.


What is Business Analysis?

Solutions may include: Systems development Process improvement Organizational change

Business analysis is distinct from, but may include, these related functions: Financial analysis Project management Quality assurance Organizational development Testing Training Documentation development


What is a Business Analyst?

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems.

The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.


The Role of the Daugherty Business Analyst

Four areas* of responsibility:

Requirements Gathering and Reconciliation

Analyze, Solve Business Problems, Test

Leadership

Specific Line of Service (LOS) Knowledge

*Daugherty Role Description – Business Analyst III

Prepared by Daugherty Business Solutions for confidential reviewPage 6


The Role of the Daugherty Business Analyst – Requirements Gathering and Reconciliation

Serve as subject matter expert and or lead large sessions of several business analysts to analyze, diagnose, and resolve complex problems using diverse methods and tools.

Prioritize integrated requirements to ensure that requirements are complete and documented.

Advise client users on application design alternatives and business process change opportunities.

Connect user needs to emerging technology in order to acquire or design tools, techniques and approaches that allow client users to realize optimal project delivery results.



The Role of the Daugherty Business Analyst – Analyze, Solve Business Problems, Test (Part 1)

Shape requirements into valuable business solutions and presentations using strong documentation skills.

Deliver integrated business systems support to users (internal and external to IT), applying an expert understanding of the business issues and the impact of technology.

Advocate the initiation of projects, when necessary, to achieve business and IT objectives.

Oversee the development of the business cases and solution proposals in support of improved functionality with regard to Return on Investment (ROI) and long-term firm benefit.

Lead the root cause analysis and resolution for complex problems.



The Role of the Daugherty Business Analyst – Analyze, Solve Business Problems, Test (Part 2)

Provide reliable top-down and bottom-up estimates.

Effectively and efficiently use all applications in the Microsoft Office Suite to deliver created documents.

Lead Change Control and Scope Management efforts.

Lead test planning and all test cycles using proven testing techniques.

Successfully identify, address, manage and escalate Risks and Issues.

Experienced in one or more project management tools such as MS Project.



The Role of the Daugherty Business Analyst – Leadership

Effectively leads a team of several business analysts.

Maintain experience in tracking and managing projects using MS Project or similar PM software.

Coach less senior Business Analysts in analysis techniques, problem solving and business knowledge.



The Role of the Daugherty Business Analyst – Specific Line of Service (LOS) Knowledge

Custom Application Development: Maintains strong SQL skills with the ability to write complex SQL statements to analyze data and create prototypes.

Business Intelligence: Has experience working on a few data warehouse and/or data reporting projects but requires guidance in more complex situations. Maintains strong SQL skills with the ability to write complex SQL statements to analyze data and create prototypes. Can interpret data models (conceptual, logical, physical)

ERP Integration: Maintains strong understanding and technical skills in multiple modules (FI, CO, SD, MM, PP, HR). Completed multiple full life cycle projects. Understanding of SAP business processes and solution for multiple clients and/or industries.



A Knowledge Framework for the Business AnalystA Knowledge Framework for the Business Analyst



What is the IIBA?

The International Institute of Business Analysis (IIBA) is an international not-for-profit professional association for Business Analysis professionals.

The IIBA vision is to be the leading world-wide professional association that develops and maintains standards for the practice of business analysis and for the certification of practitioners.

The Business Analysis Body of Knowledge (BABOK) is the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice.



There are six knowledge areas defined, that combined, cover the core areas where the IIBA will set professional standards for those performing business analysis:

IIBA Areas of Knowledge



IIBA Areas of Knowledge –Enterprise Analysis

Early project activities for capturing the necessary view of the business to provide context to requirements, such as:

Creating and maintaining the Business Architecture Conducting feasibility studies to determine the optimum business

solution Identifying new business opportunities Scoping and defining the new business opportunity Preparing the Business Case Conducting the initial Risk Assessment Preparing the Decision Package


IIBA Areas of Knowledge – Requirements Planning and Management

Defines the resources and tasks associated with the planning and management of requirements gathering activities throughout the requirements process.

Activities include: Identifying key roles Selecting requirements activities Managing the requirements scope Ongoing communication of the requirements gathering status


IIBA Areas of Knowledge – Requirements Elicitation

This knowledge area defines standard techniques used to collect the requirements of the system.

Eliciting requirements is a key task in business analysis - it is essential that the requirements be complete, clear, correct, and consistent.

The business analyst should understand the commonly used techniques to elicit requirements, should be able to select appropriate technique(s) for a given situation, and be knowledgeable of what is required to prepare, execute and complete each technique.


IIBA Areas of Knowledge – Requirements Analysis and Documentation

Requirements analysis defines the methods, tools and techniques used to:

Structure the raw data collected during Requirements Elicitation Identify gaps in the information Define the capabilities of the solution, which must be documented

The objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it.


IIBA Areas of Knowledge –Requirements Communication

The collection of activities and considerations for expressing the output of the requirements analysis and documentation to a broad and diverse audience.

An ongoing, iterative activity that is done in parallel with Requirements Gathering and Requirements Analysis and Documentation.

Includes presenting, communicating, verifying, and gaining approval of the requirements from the stakeholders and implementers of the project.


IIBA Areas of Knowledge –Solution Assessment and Validation

Once the solution has been identified, the BA must contribute to the activities of three groups, monitoring and assisting them where needed to support the project.

Technology Team: Detailed design Phase/Iteration plans Review deliverables Usability Rollout strategies

Quality Assurance Team: Understand QA tasks Answer questions Review test plans

Business Stakeholders: User acceptance testing Defect resolution Production rollout Training Documentation Change requests

Business Analysis Software Tools and Metrics



Software Tools

Requirements Management Analyst Pro - Goda Software Blueprint - Blueprint Systems Contour - Jama Software CaliberRM - Borland Doors - Telelogic Optimal Trace - Compuware Rational Suite - IBM Serena RTM - Serena

Modeling Visio - Microsoft System Architect - Telelogic Enterprise Architect - Sparx Systems RAVEN - Ravenflow SmartDraw - smartdraw.com

Other Ideascope - Orasi

Stakeholder surveys

iRiseApplication simulation platform

iServer - Orbus SoftwareRepository

ProVision Enterprise – MetaStormRepository

Reconcile – CompuwareProject goal tracking

Metrics to Consider

• Feature availability– Map of system requirements (use cases, business rules, stories, etc.) to releases.

This will allow the BA to communicate clearly to the stakeholders regarding the progression of the product.

• # of features that are new in current release• # of features remaining• % of features implemented to date

• Defect tracking– It is one thing to say a feature is available in a release. It is another to say it is

working correctly. There needs to be an effective way to track known defects and their resolutions.

• # of resolved defects• # of open defects• % of features with no defects

• Test coverage– The BA needs to be able to identify what cases have been tested against a given

release.• % of test cases run as compared to the number that could run• % of test cases passing based on the number that should pass• % of test cases that have never run or passed


Business Analysis TechniquesBusiness Analysis Techniques(presented in order of IIBA Phases)(presented in order of IIBA Phases)


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9Zachman FrameworkZachman Framework

Resource: http://www.zifa.com

Provides common language and common structure for describing an enterprise.

The columns represent the questions that must be answered to design a business entity - what, how, where, who, when, why.

The rows describe the different perspectives of the enterprise - scope, business model, system model, technology model, detailed representations.


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9Zachman Framework – Business Analysis ActivitiesZachman Framework – Business Analysis Activities

Resource: The Bridge, Fall 2006

Describes general scope of Business Analysis Activities in the Zachman Framework.

The empty cells fall outside the scope of the BA role.

What (Data)

How(Function)

Where(Location)

Who(People)

When (Time)

Why(Motivation)

ScopeLevel 1

Entity Process List

Locations of the Enterprise

List of Organizations / Divisions

Major Business Events or Cycles

Business Strategy

Business ModelLevel 2

Entity / Relation-ship

Overall Process Model

Inter-actions between locations

Organization Chart, List of Roles

Detailed Schedule

Business Plan Project Objectives

System ModelLevel 3

Logical Data Model

Detailed Process Description

Detailed Interaction Model

Entity History Processing

Business Rule Model

Technology ModelLevel 4

User Interface Design and Flow

Business Rule Spec-ification

Detailed Representa-tionLevel 5

Detailed UI, Security

Business Rule Design

Functioning EnterpriseLevel 6


Techniques Techniques and the and the Zachman Zachman FrameworkFramework

1,2,3,4,5 refers to the Framework level that the technique addresses

Asterisk(*) indicates that the technique can address

Technique What (Data)

How(Function)

Where(Location)

Who(People)

When (Time)

Why(Motivation)

Activity Diagram 2,3 3 *

Business Process/ Workflow Diagram * 1,2,3 3 *

Business Rules * * 3,4,5

Class Model 1,2,3

CRUD MATRIX * 5 4,5

Data Dictionary 3

Data Flow Diagram * 1,2.3 * * *

Data Transformation and Mapping *

Deployment Diagram 1,2

Entity Relationship Diagrams 1,2,3 *

Event Identification * 1,2 *

Flowchart 2,3 3,4 *

Goal Oriented Requirements Language * 1,2,3

Metadata Definition * * *

Sequence Diagram * 5 3

State Machine Diagram * * 1,2,3

Story boards / Screen Flows 3,4,5

Use Cases 1,2,3 2,3,4 * *

User Interface Designs 3,4,5

User Profiles 1,2 *

User Stories * * *

Work Approach and Techniques Catalog Work Approach and Techniques Catalog


Zachman Framework The POLDAT Framework Component Business Model Business Process Model /

Process Flow Diagram Class Model Use Case Model Business Scenario Knowledge Management Organizational Chart Geographic Map

Data Flow Diagrams Technology Architecture Diagram Domain Model Six Sigma Root Cause Analysis Work Breakdown Structure Brainstorming Business Process Reengineering Cause and Effect


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9The POLDAT FrameworkThe POLDAT Framework

Resource: http://dk.country.csc.com/da/kl/uploads/181_1.pdf

Each element in the POLDAT hexagon in the previous figure represents a domain of change.

If equilibrium is to be retained when a change project is launched within one area, change must also take place in the other five areas.


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9Component Business ModelComponent Business Model

Resource: http://www-935.ibm.com/services/us/igs/cbm/html/bizmodel.html

IBM's Component Business Model is a simplified way of looking at an enterprise, showing activities across lines of business.

Identifies which components of the business really create differentiation and value.

Identifies opportunities to improve efficiency and lower costs across the entire enterprise.

Identifies the components where you can realize the greatest impact.


Enterprise Analysis – BABOK 2.2.9, 2.3.8Enterprise Analysis – BABOK 2.2.9, 2.3.8Business Process Model / Process Flow DiagramBusiness Process Model / Process Flow Diagram

Resource: http://www.sparxsystems.com.au/downloads/whitepapers/The_Business_Process_Model.pdf

A business process is a collection of activities designed to produce a specific output for a particular customer or market.

A process model captures the activities performed in a business process, and the inputs, outputs, and resources used of those activities.

Not constrained by functional areas or business units.

Also known as Activity Models.


Enterprise Analysis – BABOK 2.2.9, 5.12.2Enterprise Analysis – BABOK 2.2.9, 5.12.2Class ModelClass Model

Resource: http://www.sparxsystems.com.au/downloads/whitepapers/The_Logical_Model.pdf

The Class Model is at the core of object-oriented development and design.

Static view of the objects and classes that make up the design/analysis space.

Expresses both the persistent state of the system and the behavior of the system.

Three diagrams shown here: class definition, class inheritance, and package definition.


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9Use Case ModelUse Case Model

Resource: http://www.sparxsystems.com.au/downloads/whitepapers/The_Use_Case_Model.pdf

A Use Case represents a discrete unit of interaction between an "actor" and the system.

An actor is a human or machine entity that interacts with the system to perform meaningful work.

A Use Case may 'include' or 'extend' another Use Case with its own behavior.

The complete set of Use Cases defines the whole functionality of the new system.


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9Business ScenarioBusiness Scenario

Resource: http://www.opengroup.org/architecture/togaf8-doc/arch/chap34.html

A good business scenario is representative of a significant business need or problem.

Used to derive the characteristics of the architecture directly from the high-level requirements of the business.

A business scenario describes:• Processes and applications• Business and technology

environment• Actors• Desired outcome


Enterprise Analysis – BABOK 2.2.9Enterprise Analysis – BABOK 2.2.9Knowledge ManagementKnowledge Management

Resource: http://www.systems-thinking.org/kmgmt/kmgmt.htm

The process of transforming intellectual property into a permanent asset.

Systematically managing, storing and using the vast array of knowledge that has emerged within an organization.

With on-demand access to managed knowledge, every situation is addressed with the sum total of everything anyone in the organization has ever learned about a situation of a similar nature.

A collection of data is not information. A collection of information is not knowledge. A collection of knowledge is not wisdom. A collection of wisdom is not truth.Fleming, Neil. Coping with a Revolution: Will the Internet Change Learning?


Enterprise Analysis – 2.3.8Enterprise Analysis – 2.3.8Organizational ChartOrganizational Chart

Resource: http://en.wikipedia.org/wiki/Organizational_chart

Represents the structure of an organization in terms of rank.

Three types of organizations:

Hierarchical - every entity in the organization, except one, is subordinate to a single other entity.

Matrix - people with similar skills are pooled for work assignments, and report to multiple managers.

Flat - few or no levels of intervening management between staff and managers.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Geographic MapGeographic Map

Resource: http://local.live.com

A map is a visual representation of an area—a symbolic depiction highlighting relationships between elements of that space

Depicts the physical locations of business entities.

One of an array of techniques used to capture the current state of the business.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Data Flow DiagramsData Flow Diagrams

Resource: http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9

Depicts a system as a network of functional processes, connected to one another by pipelines and holding tanks of data.

Describes the major types of information required by the business processes that will be impacted.

Used particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Technology Architecture DiagramTechnology Architecture Diagram

Resource: http://www.agilemodeling.com/artifacts/deploymentDiagram.htm

Depicts the interfaces between current business technologies.

Shows the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another.

Also known as Deployment Diagrams.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Domain ModelDomain Model

Resource: http://martinfowler.com/eaaCatalog/domainModel.html

An object model of the domain that incorporates both behavior and data.

Each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.

Most useful when business logic is very complex.

Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Six SigmaSix Sigma

Resource: http://www.isixsigma.com/tt/

Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating "defects" in manufacturing and service-related processes.

Six Sigma = Six standard deviations from the mean = 3.4 defects per million

Over 25 tools and templates described on website below.


• Problem: Problem: – The Washington Monument was disintegratingThe Washington Monument was disintegrating

• Why? Why? – Use of harsh chemicals.Use of harsh chemicals.

• Why? Why? – To clean pigeon poop.To clean pigeon poop.

• Why so many pigeons? Why so many pigeons? – Presence of many spiders to eat.Presence of many spiders to eat.

• Why so many spiders? Why so many spiders? – Presence of many gnats to eat.Presence of many gnats to eat.

• Why so many gnats? Why so many gnats? – They are attracted to the light at dusk.They are attracted to the light at dusk.

• Solution: Solution: – Turn on the lights at a later time.Turn on the lights at a later time.

Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Root Cause AnalysisRoot Cause Analysis

Resources: http://www.systems-thinking.org/rca/rootca.htm

http://www.isixsigma.com/library/content/c020610a.asp

A class of problem solving methods aimed at identifying the root causes of problems or events.

It is better to correct or eliminate root causes instead of addressing immediately obvious symptoms.

The 5 Why's - the practice of asking, five times, why the failure has occurred in order to get to the root cause(s) of the problem.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Work Breakdown StructureWork Breakdown Structure

Resource: http://www.netmba.com/operations/project/wbs/

The foundation of project planning.

Hierarchical structure depicting the breaking down of a complex project into individual components.

May be organized around deliverables or phases of the project life cycle.

Work Packages, at lowest level, can be completed independently, facilitating resource allocation, assignment of responsibilities, and measurement and control of the project.


Enterprise Analysis – BABOK 2.3.8, 4.3Enterprise Analysis – BABOK 2.3.8, 4.3BrainstormingBrainstorming

Resource: http://www.mindtools.com/brainstm.html

Popular tool to develop highly creative solutions to a problem

Helps to break out of established patterns of thinking, and develop new ways of looking at things

Effective group brainstorming uses experience and creativity of all members of the group.

Encourages sharing crazy thoughts, immune from criticism, that are refined into useful and original ideas.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Business Process ReengineeringBusiness Process Reengineering

Resource: http://www.isixsigma.com/me/bpr/

Continuous Process Improvement is for gradual, incremental improvements to an existing process.

BPR is different - it assumes the current process is broken.

BPR is a clean slate perspective enabling the designers of business processes to disassociate themselves from today's process, create a vision for the future, and design new business processes.


Enterprise Analysis – BABOK 2.3.8Enterprise Analysis – BABOK 2.3.8Cause and EffectCause and Effect

Resource: http://www.skymark.com/resources/tools/cause.asp

Ishikawa Diagram - used to explore potential or real causes that result in a single effect.

Causes arranged according to level of importance or detail, depicting relationships and hierarchy of events.

Used to search for root causes, identify problem areas, compare relative importance of causes.

Also known as Fishbone diagram


Tools and Techniques Catalog Tools and Techniques Catalog Requirements Planning and ManagementRequirements Planning and Management


Consult Reference Material Questionnaire to Identified

Stakeholders Interview Stakeholders to Solicit

Description Business Analyst Work Division

Strategy Coordination of Information within

the Team Knowledge Transfer

Requirements Risk Planning Requirements Risk Monitoring Requirements Risk Control Use documentation from past

requirements activities to estimate duration

Measure and Report on Requirements Activity

Manage Requirements Change

Requirements Planning and Management – BABOK 3.2.4Requirements Planning and Management – BABOK 3.2.4Consult Reference MaterialConsult Reference Material

Use existing project reference materials to identify people associated with the project and determine if they are project stakeholders.

This listing will be reviewed by project management to identify the project stakeholders.


Requirements Planning and Management – BABOK 3.2.5Requirements Planning and Management – BABOK 3.2.5Questionnaire to Identified StakeholdersQuestionnaire to Identified Stakeholders

Resource: http://www.surveysystem.com/sdesign.htm

A questionnaire sent to identified stakeholders will determine if any additional stakeholders exist.

Questions should be open ended and require more than a Yes or No response:

• Who is initiating the change that will result from the project?

• Who owns the problem(s) to be solved or goals to be achieved by the project?

• Who is directly impacted by the project?

• What are their roles?

• Who executes activities in the immediate business process affected by the project?


Requirements Planning and Management – BABOK 3.2.7Requirements Planning and Management – BABOK 3.2.7Interview Stakeholders to Solicit DescriptionInterview Stakeholders to Solicit Description

An discussion with each stakeholder will solicit information used to document the stakeholder description.

Questions are intended to describe each stakeholder’s involvement in the project, their authority in the project, and how the project will impact them.

Requires direct contact with the stakeholder, either face to face, via telephone, or video teleconferencing.


Requirements Planning and Management – BABOK 3.3.2Requirements Planning and Management – BABOK 3.3.2Business Analyst Work Division StrategyBusiness Analyst Work Division Strategy

Allocation of activities among Business Analysts according to some distinct characteristic, such as:

• Subject Matter Expertise• Complexity• Previous Work Experience

with Stakeholders• Geography and Culture• Area of Interests• Physical Limitation• Availability


Requirements Planning and Management – BABOK 3.3.3Requirements Planning and Management – BABOK 3.3.3Co-ordination of Information within the TeamCo-ordination of Information within the Team

Team has platform for sharing understanding, information and tools needed to successfully deliver requirements.

New members receive training and/or "welcome package”.

• Organization Standards and Policies

• Methodology• Processes/Procedural Knowledge• Document Templates• Terminology• Functional and Non-Functional

Requirements


Requirements Planning and Management – BABOK 3.3.4Requirements Planning and Management – BABOK 3.3.4Knowledge TransferKnowledge Transfer

A systematic approach to capture, collect and share tacit knowledge in order for it to become explicit (documented) knowledge.

• Verbal• Non Verbal• Structured Walk-Through/Peer

Reviews• Status Meetings• Debriefing Meetings• Central Repository• Mentorship


Requirements Planning and Management – BABOK 3.4.3Requirements Planning and Management – BABOK 3.4.3Requirements Risk PlanningRequirements Risk Planning

Resource: http://www.cvr-it.com/PM_Templates/Risk_Management_Plan_Template.doc

Provides information about each identified risk so that it can be managed in a methodical and logical manner.

The following is determined for each risk:

• Likelihood• Impact• Intervention Difficulty• Precision of Assessment• Mitigation Strategy• Action Plan• Contingency Plan• Risk Response Plan


Requirements Planning and Management – BABOK 3.4.4Requirements Planning and Management – BABOK 3.4.4Requirements Risk MonitoringRequirements Risk Monitoring


Provides a current status of each identified risk so that it can be controlled in a methodical, logical, and timely manner.

Execute the following steps:• Perform weekly checks of risk

status (red, yellow, green).• Determine observed

assessment if risk materializes.

• Determine how to react to a risk when it materializes.

• Ensure action plan is in place.• Document the monitoring

results.


Requirements Planning and Management – BABOK 3.4.5Requirements Planning and Management – BABOK 3.4.5Requirements Risk ControlRequirements Risk Control


Careful control can lead to reducing the impact of risks throughout the requirements process.

Prevents surprises that would induce working in reactive, fire-fighting mode.

• Describe Impact• Execute Mitigation Strategy• Execute Action Plan• Execute Contingency

Plan/Corrective Action• Document Lessons Learned


Requirements Planning and Management – BABOK 3.7.5Requirements Planning and Management – BABOK 3.7.5Use documentation from past requirements activities to Use documentation from past requirements activities to estimate durationestimate duration

Review documentation and artifacts created from other recent projects within the organization.

Document the duration for each task in the current project, based on the actual duration of a similar task completed in a recent project.


Requirements Planning and Management – BABOK 3.9Requirements Planning and Management – BABOK 3.9Measure and Report on Requirements ActivityMeasure and Report on Requirements Activity

In order to make effective decisions about the project, accurate, meaningful data is required.

Metrics collection and analysis must be regularly monitored and measured.

• Are we on schedule?

• How are we doing compared to the budget?

• What is the quality of the product?

• Do we have enough people assigned to the project?


Requirements Planning and Management – BABOK 3.10Requirements Planning and Management – BABOK 3.10Manage Requirements ChangeManage Requirements Change

Plan Requirements Change• Who should be involved• How administered

Understand the changes• Identify issues• Impact Analysis

Document the changes• Formal change request• Links to other requirements

Analyze change requests• Prioritize• Submit for approval


Tools and Techniques Catalog Tools and Techniques Catalog Requirements ElicitationRequirements Elicitation


Brainstorming Document Analysis Focus Group Interface Analysis Interviews Observation Prototyping Requirements Workshops Reverse Engineering Survey / Questionnaire

Requirements Elicitation – BABOK 2.3.8, 4.3Requirements Elicitation – BABOK 2.3.8, 4.3BrainstormingBrainstorming

Resource: http://www.mindtools.com/brainstm.html

Popular tool to develop highly creative solutions to a problem

Helps to break out of established patterns of thinking, and develop new ways of looking at things

Effective group brainstorming uses experience and creativity of all members of the group.

Encourages sharing crazy thoughts, immune from criticism, that are refined into useful and original ideas.


Requirements Elicitation – BABOK 4.4Requirements Elicitation – BABOK 4.4Document AnalysisDocument Analysis

Elicit requirements of an existing system by studying available documentation and identifying relevant information.

When to use this technique:• Existing business rules to be

included in new system• Subject matter experts not

available during elicitation process.


Requirements Elicitation – BABOK 4.5Requirements Elicitation – BABOK 4.5Focus GroupFocus Group

Resource: http://www.useit.com/papers/focusgroups.html

A focus group is a means to elicit ideas and attitudes about a specific product, service or opportunity in an interactive group environment.

The participants share their impressions, preferences and needs, guided by a moderator.

Qualitative Research - session results are analyzed and reported as themes and perspectives, rather than numerical findings.


Requirements Elicitation – BABOK 4.6Requirements Elicitation – BABOK 4.6Interface AnalysisInterface Analysis

Resource: http://www.sei.cmu.edu/domain-engineering/context_diag.html

Interface analysis helps to clarify the boundaries of the system.

It distinguishes which system provides specific functionality along with the input and output data needs.

By clearly separating the requirements for each system, while defining the shared interface requirements, a basis for successful interoperability is established.

A comprehensive glossary and data dictionary is critical.


Requirements Elicitation – BABOK 4.7Requirements Elicitation – BABOK 4.7InterviewsInterviews

A systematic approach to elicit information from a person or group of people in an informal or formal setting by talking to the person, asking relevant questions and documenting the responses.

Two basic types• Structured - pre-defined

questions.• Unstructured - open-ended

discussion.


Requirements Elicitation – BABOK 4.8Requirements Elicitation – BABOK 4.8ObservationObservation

Conducting an assessment of the subject matter expert’s work environment, watching them perform their work.

Some people have their work routine down to such a habit that they have difficulty explaining what they do or why.

Two basic approaches:

Passive/invisible - take notes, but do not ask questions.

Active/visible - ask questions, and participate in work process.


Requirements Elicitation – BABOK 4.9Requirements Elicitation – BABOK 4.9PrototypingPrototyping

Resource: http://www.agilemodeling.com/artifacts/uiPrototype.htm

Visualize interface requirements before the application is designed, using mock-ups of screens and reports.

Business users find prototyping to be a comfortable means to identify and verify their interface needs.

Horizontal: shallow view of system with no business logic.

Vertical: deep slice of entire functionality.

Throw-away: paper and pencil.

Evolutionary: functioning system.


Requirements Elicitation – BABOK 4.10Requirements Elicitation – BABOK 4.10Requirements WorkshopsRequirements Workshops

Resource: http://www.brcommunity.com/p-b121b.php

One of the most effective ways to deliver high quality requirements quickly.

Not a traditional meeting, rather a focused event attended by key stakeholders.

A facilitator guides the meeting, and a scribe documents requirements and outstanding issues.


Requirements Elicitation – BABOK 4.11Requirements Elicitation – BABOK 4.11Reverse EngineeringReverse Engineering

Analyzing a system/product to identify underlying business processes, data and rules.

Extracting implemented requirements from the code.

Appropriate when existing system has inadequate documentation and it is necessary to understand what the system actually does

Black Box: Study system without examining internal structure.

White Box: System inner workings are studied.


Requirements Elicitation – BABOK 4.12Requirements Elicitation – BABOK 4.12Survey / QuestionnaireSurvey / Questionnaire

Resource: http://www.surveysystem.com/sdesign.htm

Means of eliciting information from many people in a relatively short time.

Send surveys to project team, marketing, subject matter experts, stakeholders, users

Collect information about customers, products, work practices and attitudes.

Open-ended questions may provide more detail and a wider range of responses, but are more difficult to quantify and summarize.


Tools and Techniques Catalog Tools and Techniques Catalog Requirements Analysis and DocumentationRequirements Analysis and Documentation


Flowchart Sequence Diagram State Machine Diagram Workflow Models Prototyping Storyboards / Screen Flows Use Case Description Use Case Model User Interface Designs User Profiles User Stories

Business Rules Class Model CRUD Matrix Data Dictionary Data Transformation and

Mapping Entity Relationship Diagrams Metadata Definition Activity Diagram Data Flow Diagram Event Identification

Requirements Analysis and Documentation – BABOK 5.12.1Requirements Analysis and Documentation – BABOK 5.12.1Business RulesBusiness Rules

Resource: http://www.agilemodeling.com/artifacts/businessRule.htm

Business rules describe a policy, guideline, standard, or regulation upon which the business operates.

Usually captured as a textual statement defining the rule exactly and unambiguously.

Because each rule may impact several processes, they are documented separately in a Business Rule Catalog.

The Catalog is managed continuously, and may be supported by software.


BR ID

Condition

Rule

H M L OS

Business Context ID

Business Context Step ID

1 When shipment is within X hours of departure,

Then no changes can be made to the request.

H 1 1.1

2 Only if there is another acceptable destination for the shipment,

Then the shipment request can be changed after the packaging lead time.

H 1 1.1

3 If the request is for an “out of pattern” shipment,

Then it will be handled as an exception by NNNN.

M 1 1.2

4 If the shipment request is LTL,

Then its priority will be lowered to allow for consolidation.

L 1 1.3

Business Rules

FC ID

Provide Capability To…

H M L OS

Business Context ID

Business Context Step ID

1 View both Inbound and Outbound shipments requests simultaneously.

H 1 1.0

2 Have specific shipping planning lead times for different customers, suppliers, routes, and shipment types

H 1 1.1

3 Allow shipment requests to be adjusted after they are made/received.

H 1 1.1

Functional Capabilities


Requirements Analysis and Documentation – BABOK 5.12.2Requirements Analysis and Documentation – BABOK 5.12.2Class ModelClass Model

Resource: http://www.sparxsystems.com.au/downloads/whitepapers/The_Logical_Model.pdf

The Class Model is at the core of object-oriented development and design.

Static view of the objects and classes that make up the design/analysis space.

Expresses both the persistent state of the system and the behavior of the system.

Three diagrams shown here: class definition, class inheritance, and package definition.

Requirements Analysis and Documentation – BABOK 5.12.3Requirements Analysis and Documentation – BABOK 5.12.3CRUD MatrixCRUD Matrix

Resource: http://databaseanswers.org/data_migration/crud_matrix.htm

The CRUD (Create, Read, Update, Delete) Matrix cross-references user groups against the entities managed within a system.

For each data element, it states which user groups are allowed to create, read, update, delete, or list those entities.

Used by the development team to implement system security.


Requirements Analysis and Documentation – BABOK 5.12.4Requirements Analysis and Documentation – BABOK 5.12.4Data DictionaryData Dictionary

Resources: http://en.wikipedia.org/wiki/Data_dictionary

Centralized repository of information about data. such as meaning, relationships to other data, origin, usage, and format.

Ensures that all stakeholders are in agreement on format and content.

Contains definitions of each primitive data element and indicates how those elements combine into composite data elements.


Requirements Analysis and Documentation – BABOK 5.12.5Requirements Analysis and Documentation – BABOK 5.12.5Data Transformation and MappingData Transformation and Mapping

Resources: http://en.wikipedia.org/wiki/Data_transformation

Required to make existing data records available in a new business process.

Identify data issues, business rules issues and a framework for moving data with minimal disruption to the users.

Must include the following:• High level data model• Data business rules• Data cleansing plan• Environment plan


Requirements Analysis and Documentation – BABOK 5.12.5Requirements Analysis and Documentation – BABOK 5.12.5Entity Relationship DiagramsEntity Relationship Diagrams

Resource: http://www.threesl.com/pages/reference/diagrams/entity-relationship-diagram.php

Visual representation of the entities of interest to the solution, the information that must be retained about each entity, and the relationship between them.

Useful in describing the structure of the business and its rules.

Four main components:• Entities• Attributes• Unique Identifiers• Relationships


Requirements Analysis and Documentation – BABOK 5.12.7Requirements Analysis and Documentation – BABOK 5.12.7Metadata DefinitionMetadata Definition

Resource: http://www.niso.org/standards/resources/UnderstandingMetadata.pdf

Metadata is structured information about an information resource - “Data about data”.

Three types of metadata:• Descriptive - attributes to

identify a resource, such as title or author.

• Structural - how compound objects are put together, such as pages and chapters

• Administrative - information manage a resource, such as file type and date created.


Requirements Analysis and Documentation – BABOK 5.13.1Requirements Analysis and Documentation – BABOK 5.13.1Activity DiagramActivity Diagram

Resource: http://www.agilemodeling.com/style/activityDiagram.htm

Graphically represents the flow of a sequence of activities, and the logic that controls the flow.

Useful whenever it is necessary to communicate the details of a complex process.

Key Features:

Activities (rectangles)

Flow (arrow-headed line)

Start and End points (filled circle)

Branches and Merges (diamond)

Forks and Joins (bar)

Responsibility (swim-lanes)



Requirements Analysis and Documentation – BABOK 5.13.2 Requirements Analysis and Documentation – BABOK 5.13.2 Data Flow DiagramsData Flow Diagrams

Resource: http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9

Depicts a system as a network of functional processes, connected to one another by pipelines and holding tanks of data.

Describes the major types of information required by the business processes that will be impacted.

Used particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates.

Requirements Analysis and Documentation – BABOK 5.13.3Requirements Analysis and Documentation – BABOK 5.13.3Event IdentificationEvent Identification

What are the events to which the system must provide a response?

Three types: external, temporal, internal

What processes are required to provide a complete response to this event?

These processes may then be documented, and further analyzed, using a process modeling technique.


Requirements Analysis and Documentation – BABOK 5.13.4Requirements Analysis and Documentation – BABOK 5.13.4FlowchartFlowchart

Resource: http://en.wikipedia.org/wiki/Flowchart

One of the seven basic tools of quality control.

Graphically represents the flow of a sequence of activities, and the logic that controls the flow.


Requirements Analysis and Documentation – BABOK 5.13.5Requirements Analysis and Documentation – BABOK 5.13.5Sequence DiagramSequence Diagram

Resource: http://www.agilemodeling.com/style/sequenceDiagram.htm

A sequence diagram shows how a use case scenario is executed by the class model.

The classes required to execute the scenario are displayed on the diagram, as are the messages they pass to one another (triggered by steps in the use case).

The sequence diagram shows how objects used in the scenario interact but not how they are related to one another.


Requirements Analysis and Documentation – BABOK 5.13.6Requirements Analysis and Documentation – BABOK 5.13.6State Machine DiagramState Machine Diagram

Resource: http://www.agilemodeling.com/style/stateChartDiagram.htm

A State Machine Diagram specifies a sequence of states that an object goes through during its lifetime, in response to events, and also the responses that the given object makes to those events.

Also known as a State Chart Diagram

States - boxes with round corners

Transitions - line with arrow

Events - labels on the lines


Requirements Analysis and Documentation – BABOK 5.13.7Requirements Analysis and Documentation – BABOK 5.13.7Workflow ModelsWorkflow Models

Resources: http://www.agilemodeling.com/style/activityDiagram.htm

Visual representation of the flow of work in a business area.

Includes:• Business activities• Sequential flow of activities• Persons performing the work• Key business decisions• Start and end points

Used to clarify use cases and find opportunities for process improvement.


Requirements Analysis and Documentation – BABOK 5.14.1Requirements Analysis and Documentation – BABOK 5.14.1PrototypingPrototyping


Visualize interface requirements before the application is designed, using mock-ups of screens and reports.

Business users find prototyping to be a comfortable means to identify and verify their interface needs.

Horizontal: shallow view of system with no business logic.

Vertical: deep slice of entire functionality.

Throw-away: paper and pencil.

Evolutionary: functioning system.


Requirements Analysis and Documentation – BABOK 5.14.2Requirements Analysis and Documentation – BABOK 5.14.2Storyboards / Screen FlowsStoryboards / Screen Flows

Resource: http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm

A storyboard provides a simple simulation of an interface or a use case using commonly available office tools, e.g., white board, markers, index cards, post-it™ notes, scissors, or transparency film.

This is a low cost modeling technique that provides early design feedback from users and is quicker than providing a working, coded user interface prototype.


Requirements Analysis and Documentation – BABOK 5.14.3Requirements Analysis and Documentation – BABOK 5.14.3Use Case DescriptionUse Case Description

Resource: http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases

Use Case Descriptions are written as a series of steps performed by actors or by the system that enable an actor to achieve a goal.

The primary or basic flow represents the simplest way to accomplish the goal of the use case.

Special circumstances and exceptions that result in a failure to complete the goal of the use case are documented in alternate flows.



Requirements Analysis and Documentation – BABOK 5.14.4Requirements Analysis and Documentation – BABOK 5.14.4Use Case ModelUse Case Model

Resource: http://www.sparxsystems.com.au/downloads/whitepapers/The_Use_Case_Model.pdf

A Use Case represents a discrete unit of interaction between an "actor" and the system.

An actor is a human or machine entity that interacts with the system to perform meaningful work.

A Use Case may 'include' or 'extend' another Use Case with its own behavior.

The complete set of Use Cases defines the whole functionality of the new system.

Requirements Analysis and Documentation – BABOK 5.14.5Requirements Analysis and Documentation – BABOK 5.14.5User Interface DesignsUser Interface Designs


Modeling of user interaction with specific system elements.

Improves usability by involving users early in the requirements process.

General ideas, not a detailed design implementation.

Allows users to state their preference for navigating a specific element, how to achieve their goals, and how to accomplish their work.


Requirements Analysis and Documentation – BABOK 5.14.6Requirements Analysis and Documentation – BABOK 5.14.6User ProfilesUser Profiles

Resource: http://www.usabilitynet.org/tools/taskanalysis.htm

Gather all known information about end users of the proposed business solution, and break them into specific profiles.

Highlight differences in user groups that require different user interface solutions or use cases.

The goal is to propose business solutions that provide positive and effective user experiences.

Related to Task Analysis.


Requirements Analysis and Documentation – BABOK 5.14.7Requirements Analysis and Documentation – BABOK 5.14.7User StoriesUser Stories

Resource: http://www.agilemodeling.com/artifacts/userStory.htm

High-level definition of a requirement, containing just enough information so developers can produce a reasonable estimate of the effort to implement it.

Used by the project team to:• Get agreement between

project stakeholders on key features

• Gain time estimates needed to accomplish the coding of that feature.

• Facilitate feature prioritization for each release cycle.



Appendix

Development Methodology Example

INCEPTIONINCEPTION ELABORATIONELABORATION

Confirm Vision of

Company / Organization

Confirm Vision of

Company / Organization

• Vision Statement

Estimate& Plan

Elaboration

Estimate& Plan

Elaboration

• Elaboration work plan

• Detailed Use Cases• Screen Flow

Diagrams• Sequence

Diagrams• Screen Designs• Business Rules &

Functional Capabilities

• Supplemental Specifications

• System Components

• Class Models• Entity Relationship

Diagrams• Orthogonal View

• Business & Project Objectives

• Critical Success Factors

Confirm Near-Term Business

Objectives

Confirm Near-Term Business

Objectives

• Business Context Scope Diagram

• Business Activity Diagrams & Outlines

• Business Rules & Functional Capabilities

• Gap Analysis

Model BusinessModel

Business

Identify Actors & Use

Cases

Identify Actors & Use

Cases

• Inventory of Actors & Use Cases

• Use Case Diagram(s) and Descriptions

Understand the business

Establish System Scope & Approach

Plan Elaboration

Analyze Requirements

& Design Solution

Establish Architectural

Approach

Establish Architectural

Approach

• Existing technology and application standards

• Packaged software/tool assumptions

• Architecture framework and design patterns

• Key non-functional system characteristics

Define Architecture

& Components

Define Architecture

& Components

Analyze Use CasesAnalyze

Use Cases

Project Management / Requirements ManagementSoftware Quality Assurance / Software Configuration Management

Plan Construction

Build & TestSolution

Deliver Solution

• Identify Resources

• Resource Allocation & Leveling

• Develop Iteration Plan & Project Plan

• Class Models• Business Logic• Screens, Reports• Views, SP’s• Physical

Databases• Test Scripts• Builds

• Team Culture• “Construction

Week”• Deliverables

Set

Iterative Design,

Development and Testing

Iterative Design,

Development and Testing

User Acceptance

Testing

User Acceptance

Testing

Manage FeedbackManage

Feedback

• Test Strategy & Approach

• Test Plans, Cases, & Results

• Environment setup

• Initial Components

Estimate & Plan

Construction

Estimate & Plan

Construction

Change Managemen

t

Change Managemen

t

Establish Construction

Approach

Establish Construction

Approach

Perform Initial One-Time

Tasks

Perform Initial One-Time

Tasks

Package Components

& Deliver

Package Components

& Deliver

Transition Planning

Transition Planning

Training and Support

Training and Support

Documentation

Documentation

CONSTRUCTIONCONSTRUCTION TRANSITIONTRANSITION

Id, Eval, Select, &

Implement Packages

Id, Eval, Select, &

Implement Packages

Prototype Use Cases & Architecture

Prototype Use Cases & Architecture

Phase Control Points

Phase Approval Requirements

Inception Scope Review – The scope is reviewed with the stakeholders to ensure agreement on system boundaries

Elaboration Requirements Review – The goal is to ensure the detailed requirements of each system feature accurately reflects the stakeholder’s vision. In a methodology like RPM, this is done at the end of elaboration. In a methodology like XP or RUP, this is done during each iteration for the features that part of that iteration.

Construction Test Case Review – The goal of this review is to ensure what will be tested matches the requirements. In some methodologies, this is done concurrently with development but must be finished prior to finishing development. In other methodologies, this must be complete on a feature by feature basis prior to the start of development.

Test Result Review – The goal of this review is monitor the results of the tests and ensure an adequate amount of the system is tested.

Transition User Acceptance Review – The BA should work with the stakeholders to determine the final readiness of the product. This typically happens prior to each release. However, some methodologies have this occur at the end of each iteratioin whether it results in a release or not.

INCEPTIONINCEPTION ELABORATIONELABORATION CONSTRUCTIONCONSTRUCTION TRANSITIONTRANSITION

business analysis tools, techniques, templates and tips february 17, 2008 prepared by daugherty...

Documents

daugherty business solutions

business problems

business needs

business processes

business issues

business analysts

valuable business solutions

business analysis tools