AUBusiness Analysis, Requirements &

Business Process Modeling

Prof. J. Alberto Espinosa

Business Analysis & Data Design ITEC-630 Fall 2008

22

Objectives Describe the body of knowledge of business analysis Describe the requirements process Introduction to business process modeling

33

Business Analysis Body of Knowledge

44

What is business analysis?

“The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.”

Source: International Institute of Business Analysis (iiBA)

55

Business AnalysisBody of Knowledge (BoK)

See iiBA: http://download.theiiba.org/default.asp?fileid=26&categoryid=3

Enterprise analysis Requirements planning and management Requirements elicitation Requirements analysis Communication and documentation Solution assessment and validation

66

Enterprise Analysis Enterprise architecture:

–“The explicit description and documentation of the current and desired relationships among business and management processes and information technology.” – U.S. Office of Management and Budget, Circular A-130

–“The blueprint for creating enterprise-wide systems in alignment with business needs”

–It involves preparing all diagram, models and descriptions of: all business processes, functions, information and technology infrastructure

–It often involves analyzing the current architecture, conducting gap analysis and developing a target architecture along with a transition plan

The business analyst needs to understand the enterprise strategies, which provides “the context” in which enterprise analysis is conducted

In modern, complex, dynamic and fast-paced business environments, the enterprise strategy and information technology are tightly aligned, but the strategy evolves rapidly, presenting substantial challenges for business analysts.

In large complex organizations, senior business analysts are key participants in the strategic planning process.

77

Requirements Planning and Management

It involves: Identifying team roles: project manager, business analysts, developers, quality

assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc.

Identifying stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc.

Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes

Define risk monitoring and management approach for each identified risk Define the requirements and system development method (e.g., traditional, object

oriented, unified modeling language—UML, etc.) Define the requirements and system development process (e.g., system development

life cycle, iterative, unified process—UP) Manage requirements change and scope: requirements creep is a big problem Define and collect project metrics and reporting mechanisms Other project planning and project management activities

88

Requirements Elicitation

A “key” BA task – it provides the foundation for solutions to business needs – it helps develop a thorough understanding of the business process that will be automated and the essential needs of the system.

It involves: Eliciting the these essential needs from stakeholders – dependent on the

knowledge and willingness of stakeholders to share information “Trawl” for knowledge: business processes, baseline system, target system Methods: interviews, surveys, focus groups, requirements workshops,

observations, prototyping, written documents, etc. Analyze all interfaces – human and external systems Document (i.e., record) all requirements identified (and the source) –

requirements notes, cards, etc. Establish priorities and verification (measurement) parameters Beware of “scope creep”

99

Requirements Analysis

“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)

It involves: Developing analysis models and artifacts Can be textual or diagrams – beware of over-diagramming And “transitional artifacts” that connect the multiple models – e.g.

CRUD and other matrices Methods: business process analysis, object-oriented (OO) analysis,

structured analysis Requirements: functional, non-functional, project, assumptions,

constraints, etc.

1010

Communication and Documentation

The objective is to develop an accurate understanding of the business problem and clearly articulate the solution.

It involves: Communication skills are critical – two ways: not only clearly articulating

things verbally and in writing, but also listening effectively Selecting the appropriate models, artifacts and other requirements documents

formats. Describing models and text artifacts clearly, accurately and concisely Key deliverable: “requirements specification” representing the BA’s

“demonstrated understanding” of the business and processes that need to be handled by the system and its necessary capabilities.

These specs will serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc.

Preparing effective presentations for clients and stakeholders.

1111

Solution Assessment & Validation

Two key aspects: (1) evaluation if the proposed solution meets business needs (and the architecture analysis) and (2) if the solution was implemented correctly (per requirements)

Evaluate proposed solution, it involves: Requirements reviews to evaluate if they are accurate, complete, clear, non-redundant,

consistent (with architecture and business needs), feasible, correctly prioritized, etc. Obtaining signoff from clients and stakeholders – helps buy in and reduce “feature churn”

Evaluate correct implementation, it involves: Working with Quality Assurance teams Mapping analysis artifacts to design artifacts Mapping implemented system features to requirements artifacts Black box testing of the system implemented – e.g., using test cases Evaluating non-functional requirements and technologies used Evaluating usability and interfaces (human and system)

1212

Requirements

1313

Requirements

In simple terms, requirements are things the product needs to do (i.e., useful functionality for its user) and the capabilities and qualities that it must have (i.e., non-functional)

IEEE definition:

1. A condition or capability needed by a user to solve a problem or achieve an objective

2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents

3. A documented representation of a condition or capability as in (1) or (2)

1414

Requirements Analysis

Find, understand, record and communicate:

• Functional Requirements (behavioral) What the system needs to do: “The work” Your articulation of functional requirements becomes is your

“demonstrated understanding” of the business processes your system needs to automate – Eric Bristow, Deloitte Consulting

• Non-functional Requirements (non-behavioral) – the qualities of the system (e.g., speed, reliability, capacity)

• Project Requirements – costs, deliverables, deadlines, etc.

• Prepared using a “System Requirements Process”

• Articulated in a “System Requirements Specification”

1515

Requirements Analysis isKey to Successful Development

Several studies have documented that requirements errors cost the most and that poor requirements are the main cause of software failure

GAO’92; Faulk’92; Bohem’81; Curtis’88

“The hardest single part of building a software system is deciding what to build. ...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Fred Brooks (1987) No Silver Bullet: Essence and Accidents of SW Engineering

1616

Sources of Requirements

Users, Customers, other Stakeholders (e.g., employees, management, selected customers)

Standards (e.g., GAAP)

Policy/Legal (e.g. government regulations)

System Documentation (e.g. current system being replaced, could be manual)

Business Process Documentation (e.g. current business memos, manuals, practices)

Subject Matter Experts (e.g. experts on the business domain)

1717

Role That Good Requirements Play

For clients: requirements describe what will be developed and perhaps provide a contractual basis for the development

For project manager: provide a basis for project planning and measuring progress

For the developers: provide the functionality to be designed and coded

For testers: provide the basis on which test For users: documentation and training

1818

Capturing Requirementsis Difficult

Need to: Find out what is required by/from the system Understand these requirements and their implications Communicate (text and models) this understanding to

users, customers, designers and other stakeholders Manage them – i.e., record them in a traceable manner

and ensure that as requirements change, they are updated and the impact of the change is understood

Quality and fit – i.e., ensure that system meets the requirements

1919

“Trawling” for Knowledge: Eliciting Requirements

“Running a net through the organization to catch every possible requirement source” (Robertson & Robertson)

With experience, you learn where to fish to find what you want Start with documents from the project “blastoff” meeting with your client Elicit further requirements through: interviews, requirements workshops,

questionnaires, observations, job protocol analysis, prototyping, review of existing documents

Systematically “catch” and record all requirements Document anything that sounds like a requirement using an organized

form or template like: the Volere Requirement Shell

2020

Volere Requirement Shell

2121

Interviews

Interviews should be carefully planned Interview Process model

– Determine who to be interviewed– Prepare for, plan & schedule each interview– Open the interview:

introduction, purpose, permissions (to tape, etc.)– Conduct the interview:

semi-structured, open ended questions, mail questions in advance, let users digress, don’t agree or disagree on anything (just capture)

– Close the interview: summarize things, confirm facts– Follow up: resolve conflicts; close-ended questions

2222

Requirements Workshops

Approx 2 days before each UP iteration Multiple stakeholders participate:

multiple perspectives of the system It fosters clear communications between

Requirement Analysts, users and other stakeholders Fosters sense of participation and project ownership Helps accelerate requirements elicitation process Facilitators are often used Need a scribe to document the discussion Need rules for participation and problem resolution Need a process that fosters preparation Pre-specify expected deliverables Use artifacts that foster communication with the client:

A Business Process Model (or Map) is an excellent tool for this

2323

Business Process Modeling

2424

Business Process Model

The system you are gathering requirements for will automate one or more business processes

Therefore, it is very important that the requirements analysts and clients develop common ground on what these business processes are

The best way to achieve this is to develop a business process model and get the client to sign off on it

The idea is to develop a vision of “the work” that needs to be done, looking ONLY at the business aspects of the process

A business process model (BPM) fosters communication between the requirements team and the client; and within the team

It provides an excellent starting base to begin to articulate the system requirements

2525

Cross Functional FlowchartBPM Symbols

Process Name

Phase 1 Name Phase 2 Name

Sw

im L

ane

or

Fun

ctio

nal

Ban

d N

ame

Sw

im L

ane

or

Fun

ctio

nal

Ban

d N

ame

Sw

im L

ane

or

Fun

ctio

nal

Ban

d N

ame

Sw

im L

ane

or

Fun

ctio

nal

Ban

d N

ame

Process 1

Begining

EndDecision 1

Process 2 if Decision 1 is Yes

Process 2 if Decision 1 is No

Process Flow Yes

No

Annotations: use this symbol to embed comments

Database operation

Printed output

Page 2

Connect from/to another page

2626

Some BPM Diagramming Rules

All BPM diagrams have one start and one end symbols. If there are two or more distinct sub-processes, it is OK to

break up the BPM into two sub-models, but each must have a start and end symbols.

If you have many sub-processes you can create one master BPM that includes “Pre-Defined Process” symbols and then create a separate BPMs for each of these pre-defined sub-processes.

You can include many symbols in the diagram to add clarity to your process descriptions. Some symbols just add clarity (e.g., comment, database store, printout), whereas others have very specific rules on how to use them.

More BPM guidelines: http://www.edrawsoft.com/flowchart-symbols.php

2727

Some BPM Guidelines

BPMs are used to document business processes, NOT systems actions – focus on understanding and documenting what people do and what the key processes are, rather than what the system solution will do.

That is, you need to understand the business processes before you can suggest a solution.

However, it often helps to distinguish the baseline BPM (what the client does) from the target BPM (what the client wants). You can add notations and other symbols to distinguish baseline from target processes

Similarly, it sometimes helps to distinguish processes that are carried out manually from those that are handled by applications. So, you can also add notations and other symbols to distinguish manual from system driven processes

More importantly, this is NOT hard science – if you can do anything to add descriptive clarity to your BPM, by all means

2828

Some Rules for BPM Symbols

Process Step (box): can have more than one input but only have one output; if you think you need two outputs you probably need a decision symbol that evaluates which output path to follow; the input and output lines must connect to another symbol (process box, decision, start, end, etc.); NEVER leave process steps alone—they must have input(s) and output.

Pre-Defined Process (box with double vertical borders): use this symbol to indicate complex process steps that need to be further explained in more detail—it is not a bad idea to put a page reference next to these symbols that connect the diagram to BPM that diagrams the sub-process

Decision (diamond): have one input and at least two possible outcomes; it may have more than two outcomes but this may point to more complex process steps that are better described in a “pre-defined process”; all outcomes must be labeled (e.g., “yes”, “no”, “option 1”)—NEVER leave decision outcomes unlabeled

Functional bands or swim lanes: show which functions, departments or roles are associated with a symbol; when flowcharts have functional bands the diagram becomes a “cross-functional flowchart”

Page connector: use this symbol when your diagram spans more than one page; ALWAYS label the symbol with a page number that matches the actual page where the related diagram is

You can add other symbols to add clarity (e.g., database, printout, etc.); Label these symbols as needed for clarity

2929

Car Rental Operations

Paperwork Delivery

Ope

ratio

nsO

pera

tions

Bus

ines

s O

ffice

Bus

ines

s O

ffice

Ren

tal C

lerk

Ren

tal C

lerk

Clie

ntC

lient Enter

agency

Retrieve docs

Approve rental?

Record approval

Yes

Notify Client

No

Vehicle Options

Select Vehicle

Inquire Status

Check Status

Vehicle Available?

No

Vehicle Ready?

Yes

Report Status to

Client

No

Find Vehicle Location

Yes

Prepare Contract

Submit Contract

Sign Contract

Record Contract

Notify Location to Client

Give Car Keys & Contract to

Client

Leave Agency

BPM ExampleCross-Functional Flowchart

3030

Master BPM ExampleEach Pre-Defined Sub-Process Box Has its Own BPM Diagram

Master Business Process Model

Start Phase 1 Phase 2 End

Bus

ines

s P

roce

ss 3

Bus

ines

s P

roce

ss 3

Bus

ines

s P

roce

ss 2

Bus

ines

s P

roce

ss 2

Bus

ines

s P

roce

ss 1

Bus

ines

s P

roce

ss 1

Begin

End

Decision A

Decision B

Option A

Option B

No More

Please Proceed

Sub-Process 1.1

P.2

Sub-Process 2.1

P.3

Sub-Process 3.2

P.4

Sub-ProcessStep A

Sub-ProcessStep B

“Pre-Defined Process” symbol used for more complex process steps with a page connector. In this case P.3 should have a

separate BPM showing all the steps of this pre-defined process

Regular process step symbol used for simpler steps

Page symbol to help navigate to the sub-process BPM

Which sub-process?

3131

Project Baselining Flow Chart

Initiation Phase Baseline Phase

Pro

ject

Dir

ecto

rB

usi

nes

s O

ffice

Pro

ject

M

ana

ger

(PM

)

Start

1New project

developed and approved

3Receives project information from

PM

8Enter Project Data

5Enters project data

into Finance Module

2Enter Priority Data

7Receives award information from

Acquisitions

9Prepares Project

Schedule and cost Baseline Report

10Is Prioritization

required?

No

Yes

4Back to PM

No

End

Cross-Functional FlowchartBPM Example

3232

The Requirements SpecificationRobertson & Robertson’s “Volere Template”

Project Drivers: purpose, stakeholders, actors

Project Constraints: constraints, glossary, assumptions

Functional Requirements: use cases, class diagrams

Non-functional Requirements: “ilities” & other qualities

Project Issues: off-the-shelf, costs, risks, etc.

Template for this course’s project: an adaptation of the Volere Template