1. Improving Business Analysis and Requirements Engineering.
Presented by:
Morris Oslin, Trissential, LLC
May, 8, 2008
Michelle:
How many BAs do we have?
How PMs?
How many do both?
Who’s a Resource Manager?

2. Objectives
Identify what exactly business analysis is in terms of it’s relationship to requirements
What makes good software requirements
What drives good requirements
Roles and Processes in the Business Analysis Maturity model
Realize the need for separation of duties of roles
Describe the pitfalls of combining the roles
Provide suggestions for avoidance
Skills and Tools in the Business Analyst Maturity model
Case Study of Business Analysis/Requirements
Basic Improvement Roadmap
Dave:
Understand that there are reasons for both the PM and BA roles
Discuss some real world examples of what can go wrong when combing the roles
Discuss ways to prevent the dual role situation or survive it if you aren’t successful avoiding it
Provide some insights into where the industry is going with the BA role
Summarize the key points and learnings
We have a lot to cover in the time we have. For the sake of time, please hold your questions. Michelle and I will be available afterwards to discuss your questions. 2

3. Business Analysis- Definitions
According to
Business analysis helps an organization to improve how it conducts its functions and activities in order to reduce overall costs, provide more efficient use of resources, and better support customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary, non-value added work. The person who carries out this task is called a business analyst or BA.
Those Business Analysts who work solely on developing software systems may be called IT Business Analysts or Technical Business Analysts.Significant Cultural Drivers affecting the software project:
According to Trissential good requirements are focused on creating software products by being:
Traceable to the business- map to an explicit business architecture.
Consumable by the technical staff- used entirely and the only source

4. Business Analysis and Requirements- Current State
Google “Business Analysis Requirements” you get:
A lot of different training (people)
A lot of different processes
A lot of tools
Which is best?
Most are excellent choices
Which people training, process and tools are best for my organization so we can produce requirements that are traceable and consumable?
It Depends!

5. Business Analysis in the Organizational Model
Effective Strategy & Planning
Mind share
Business, IT, Cultural Drivers
Business Processes and Static Model
Efficient Management
Accepted Business
Requirements
Approach
Exceptional Execution
Implemented
Mindshare
Requirements Ownership
Business Excellence
Benefit
Validation
Business Analyst Software Product Development
Business Analyst Leadership
©2006 Trissential. All Rights Reserved.

6. Business Analysis in Governance Model & Processes – E1
Determine Strategy
Identification
Categorization
Evaluation
Selection
Prioritization
Portfolio Balancing
Authorization
Review & Reporting
Strategic Change
Bus & IT
Executives
Business
Architecture
Facilitate Governance Decisions
Technology Form & Fit
Program
Architecture
Technology
Architecture
Decompose Strategy
Why, Why, Why
What’s the Pain/Gain
Create the Business Case and ROI
Model the business as Static and In-motion (process)

7. Business Analysis in the Project Management Model –E2
Business Requirements
Requirements Approach (based on Bus. Reqs., User Profiling, and SDLC used on project)
User and Stakeholder Identification and Profiling
Business Analysis Leadership

8. Business Analysis in Product Development Model- E3
and System Analysis
Quality
Assurance and Testing
Change
Mgmt
Requirements
Engineering
Application
Architecture (as needed)
Business Analyst Software Product Development

9. Business Analysis – Requirements Continuum
The Drivers of Good Requirements
Where does an organization think they are on the Requirements continuum?
Where is the organization really at on the Requirements continuum?
Where does the organization want to be on the Requirements continuum?
Fluid
Rigid
Extreme
Agile:
Solution based story
Agile Lite/Iterative:
Story with business case
Formal
RUP:
Use Case
driven
Defense
Department
(IEEE SRS and
Spiral approach)
Waterfall-
Requirement
Lists orientated
RUP Lite:
Use Case driven

10. Business Analysis – Requirements Continuum
What are the business drivers that affect the Requirements? (E1)
Explicit versus implicit
business knowledge
Product speed to market
Increase Product Profit Margins
Operational Scalability
Regulatory Compliance
Cut Operational Costs
Increase Product Market Share
Keep the lights on
Increase Customer Satisfaction

11. Business Analysis – Requirements Continuum
What are the project and cultural drivers that affect the Requirements? (E2)
Executive Sponsorship
Business Engagement
Physical Location of Project Team(s)
Culture Maturity
(ex: Requirements capability)
New or Existing Business
Project Governance: Scorecard and Project Reporting
Residual Knowledge of the Business Architecture

12. Business Analysis – Requirements Continuum
What are the technology drivers that affect the Requirements?(E3)
System Complexity:
Standalone vs. Integrated
Development Tools:
Example Agile and XML work well
Residual Knowledge of the Technology Architecture
New or existing Technology
Development Costs
Resource Skill Sets
Technology Support Costs
Resource Demand
Outsourcing

13. Business Analysis – Requirements Continuum
So what should the Requirements Continuum be set at for my organization?
The Requirement approach must be chosen on the Situational Needs of the project to produce good requirements.
The Business Drivers, Technology Drivers, and Cultural/Project Drivers all work together to move the Requirements location on the continuum based on priority.
The three Drivers fit right into the Essential Business Model.
The Requirements Engineering Process, Tools, and People (Analysts and Technical staff) must fit the chosen Requirements approach.

14. Business Analysis - Roles & Responsibilities
Business Architecture
Business
Analysis
Software Product Development
Quality
Assurance
Requirements
Engineering
Change
Mgmt
Software
Development
Business Analysis Leadership

15. Business Analysis - Role Comparison
PM (E2)
BA (E3)
Business Domain Expert (E1)
Overall Project Plan Development
Overall Project Scope
Management
Overall Project Time
Project Cost Management
Project Quality Management
Project Risk Management
Project Procurement
Project Communications
Project Human Resource
Create Business Policies
Create Business Rules
Provide and approve Business
Architecture
Requirements
Provide and approve User
Approve Functional Requirements
Understand Non Functional
Requirements Process Expert
Facilitate Requirements
Gathering
Lead Requirements
Analysis
Develop
Supplementary
Documentation
Partner with IT to
Define Functional
& Non- Functional
Requirements
Compose Business
Rules for Rule
Execution
Manage Business Rules
Identify Business
Policies
Rules from
Develop Business
Requirements
Manage the
recorded
Business
Architecture
Project Plan Development (Requirements Phase)
Project Plan Execution (Requirements Phase)
Project Time Management (Requirements Phase)
Apply Business Architecture: Scope Planning, Scope Definition
Document Business Requirements
Drive Requirements Review/Approval
Drive Resolution of Requirements Issues
Scope Change
Michelle:
It’s common to assume that a BA and PM are interchangeable. There are skills that a true BA and a true PM share, which are represented in the overlap. Most of these are “art” skills – communication, building relationships and negotiation – all things they are very good it. They also understand SDLC (Software Development Lifecycle), which means that know what work needs to be done and when.
BUT – there are other skills that are specific to each discipline that are vastly different.
From a PM perspective, big picture means looking at ALL work. The PM directs the team and controls the work – changing resources as needed if the critical path changes. The PM’s responsibility is to help people get their work done by removing the obstacles that exist (organizational, political). Most PM’s focus on time, cost and scope/quality – the triple constraint as that’s what their sponsor’s focus on.
These skills are more managerial in nature – unlike the skills necessary for a BA…
Dave:
A Business Analyst lives in the details.
Further clarify the information
Build consensus on what the system will do and look like.
Ask lots of questions. A favorite word of the BA is “WHY?”
Listen to not only what the client says, but what do they mean.
Focus is developing the PRODUCT, not running the PROJECT
Business Architect (E1)
Business Architect (E1) 15

16. Role Delineation Ideation Discovery Development Wrap Up 16 16 Team
Begin Project
Develop Scope
Develop Phase Schedule & Budget
Create Schedule & Cost Baseline
Gain Approval for Scope Statement
Ensure Budget & Schedule Tolerances
Manage WBS, Issues, Project Changes
Analyze Project Results
Close Project BA BA BA BA
Develop Scope
Identify & Engage stakeholders & SMEs
Elicit How, What, Why from SMEs
Develop Detailed Requirements
Identify Business Issues
Manage Requirements changes
Verify Requirements
Ensure Product Delivery
Michelle introduces it and does the Ideation phase for PM
Dave:
Ideation phase for BA:
BA works with the PM to define the scope of the project.
BA identifies the business areas impacted by the project
Works with the PM to have SMEs assigned to the project.
Discovery phase for BA:
Identify business processes.
Each process, detail out the requirements – iterative process of requirements elicitation, analysis, representation and validation
Use facilitated sessions wherever possible
Culmination approval by the SMEs of the requirements packet.
PM ---- progress of the sessions
Michelle does the Discovery and Development phases for PM.
Development for BA:
Review session.
Design
Prototypes
Issues --- negotiate a solution
Changes to the requirements -----
Documented,
Estimated by the development team as to the impact to the project
Signed off by the business before they are considered part of the project.
Wrap up for BA:
user acceptance testing
training
communication to users of implementation. 16 16

17. Industry Insights Where does the BA role live?
Historically IT
Shifting towards business
Jury’s still out
Where is the BA role going?
Recognition
Training/Certification
What are the future trends?
IIBA as household name
Degreed programs
Indispensable role
Dave: 17 17

18. BA Processes Source: IIBA BABOK®
___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Source: IIBA BABOK®

19. Business Analysis- Maturity Levels
Process
Role
Business Architecture models managed well.
Focus Is On Continuous Improvement of BA Process/ Tools with Training.
Strategic Competitive Advantage gained from reuse of Business Architecture from projects.
5 Optimizing
Business Analyst Role Separation practiced.
Senior Management and IT support Business Architecture and uses it themselves.
Senior BA’s engaged in early Program and Project Management.
4 Comprehensive
Business Analysis Approach selection is routine
Development staff regularly consumes Business Analysis Artifacts.
Consistent use of Documented Business Analysis Processes as selected by project.
Requirements traceable to the business.
Business Architecture Published on Project basis but not managed for reuse.
Business Analyst Role Separation is recognized with Business Architecture done for all projects with consistent IT & business support 3
Consistent
Business Analysis approach to projects is based on business, IT, and cultural drivers with some difficulty in deciding.
Inconsistent use of documented Business Analysis processes on projects.
Business Analysis tools reused across projects.
Business Analyst Role Separation recognized but not as difference maker
Business Architecture initiated occasionally with some business and IT support 2
In-consistent
Development Staff may not always consume Business Analysis Artifacts
Artifacts Business Analyst Role Separation not recognized
Entrepreneurial/Heroic BA efforts
Business Analysis approach is one size fits all.
Each project has it’s own Business Analysis tools.
OJT Business Analyst training. 1
Ad Hoc

20. Business Analyst- Skills Comparison
PM (E2)
BA (E3)
Business Architect (E1)
“Big Picture” Thinker
Possesses management skills
Communicates well with
Business Executives
“Big Picture” Thinker
Directs the project team
Helps people get things done
Conscience of time and $$
Removes issues/barriers
Possesses management skills
Manage
Business Analysis
Process
Manage Requirements
Artifacts
Communicates well
Understands SDLC
Manages interpersonal relationships well
Negotiates
Applies Business
Architecture
Communicates well
with SMEs
Manages
interpersonal
relationships well
Interprets Business
Architecture
Details
Correctly
Michelle:
It’s common to assume that a BA and PM are interchangeable. There are skills that a true BA and a true PM share, which are represented in the overlap. Most of these are “art” skills – communication, building relationships and negotiation – all things they are very good it. They also understand SDLC (Software Development Lifecycle), which means that know what work needs to be done and when.
BUT – there are other skills that are specific to each discipline that are vastly different.
From a PM perspective, big picture means looking at ALL work. The PM directs the team and controls the work – changing resources as needed if the critical path changes. The PM’s responsibility is to help people get their work done by removing the obstacles that exist (organizational, political). Most PM’s focus on time, cost and scope/quality – the triple constraint as that’s what their sponsor’s focus on.
These skills are more managerial in nature – unlike the skills necessary for a BA…
Dave:
A Business Analyst lives in the details.
Further clarify the information
Build consensus on what the system will do and look like.
Ask lots of questions. A favorite word of the BA is “WHY?”
Listen to not only what the client says, but what do they mean.
Focus is developing the PRODUCT, not running the PROJECT 20

21. Business Analyst - Maturity Levels
Tools
Skills
5 Bus. Architect
Pictorial business model first (As is, to be).
Static and process pictorial models of the business.
Produce textual view of requirements last.
Advanced VISIO, WBI Modeler, Enterprise Architect, playbooks as modeling tools.
Integrated Requirement management with modeling tools.
Management Practice
Business Modeling Standardized (UML, IDEV, in VISIO or basic modeling tools).
Multiple formats: Use Cases, Stories, SRS.
Requirements management tools.
Problem first then solution approach.
Business or System processes in a business model.
Processes and Scenarios identified in the business model.
Textual and Pictorial view of requirements.
4 Structure
Processes/scenarios identified by system users .
Typically problem first then solution approach..
Random Business or System scenario driven.
Textual representation of requirements.
Capture Business Requirements, User Requirements, Functional and Non-functional requirements in single standard format
Requirements published with tools: Rational products, TFS, Web… 3
Categorization
Solution first approach-start with screens.
Some business knowledge needed for effective interview.
Difficult to know when analysis is done.
Textual list of requirements with some process links.
Go ask who, what, when, where, why this way…..
Suggested Questions and formats
Requirements shared in network file system 2
Guidance
Provided
Solution first approach-technology priority.
Good personal interviewing skills required.
Extensive business knowledge for effective
interview.
Difficult to know when analysis is done.
Textual list of requirements,
No suggested questions
Plan interview, conduct interview, recap interview
Requirements stored for personal use 1
IT waiter/waitress

22. Business Analysis Case Study
Case Study: Midsize Service Company
Significant Business Drivers affecting the software project:
Quick time to market
Changing economic conditions affected project funding
Subject matter experts and stakeholders in remote locations
Significant Cultural Drivers affecting the software project:
Departments affected by the software were not mature, nor expected to be mature, in their own processes. This forced IT to own major business processes.
Project Management Office was immature and typically produced product owners.
IT had traditionally produced software products then shown the business when it was done. IT managed much of the business model especially in operations.
Significant IT Drivers affecting the software project:
IT was not well versed in the new technologies = coders that don’t do design
Developers, BA’s, and PM were contracted resources
Accountability of Developers to PM was limited

23. Business Analysis Maturity Level- Midsize service company
Process
Role
Business Architecture models managed well.
Focus Is On Continuous Improvement of BA Process/ Tools with Training.
Strategic Competitive Advantage gained from reuse of Business Architecture from projects.
5 Optimizing
Business Analyst Role Separation practiced.
Senior Management and IT support Business Architecture and uses it themselves.
Senior BA’s engaged in early Program and Project Management.
4 Comprehensive
Business Analysis Approach selection is routine
Development staff regularly consumes Business Analysis Artifacts.
Consistent use of Documented Business Analysis Processes as selected by project.
Requirements traceable to the business.
Business Architecture Published on Project basis but not managed for reuse.
Business Analyst Role Separation is recognized with Business Architecture done for all projects with consistent IT & business support 3
Consistent
Business Analysis approach to projects is based on business, IT, and cultural drivers with some difficulty in deciding.
Inconsistent use of documented Business Analysis processes on projects.
Business Analysis tools reused across projects.
Business Analyst Role Separation recognized but not as difference maker
Business Architecture initiated occasionally with some business and IT support 2
In-consistent
Development Staff may not consume Business Analysis Artifacts
Artifacts Business Analyst Role Separation not recognized
Entrepreneurial/Heroic BA efforts 1
Ad Hoc
Business Analysis approach is one size fits all.
Each project has it’s own Business Analysis tools.
OJT Business Analyst training.

24. Role Comparison- Midsize service company
PM (E2)
BA (E3)
Business Domain Expert (E1)
Overall Project Plan Development
Overall Project Scope
Management
Overall Project Time
Project Cost Management
Project Quality Management
Project Risk Management
Project Procurement
Project Communications
Project Human Resource
Create Business Policies
Create Business Rules
Provide and approve Business
Architecture
Requirements
Provide and approve User
Approve Functional Requirements
Understand Non Functional
Requirements Process Expert
Facilitate Requirements
Gathering
Lead Requirements
Analysis
Develop
Supplementary
Documentation
Partner with IT to
Define Functional
& Non- Functional
Requirements
Compose Business
Rules for Rule
Execution
Manage Business Rules
Identify Business
Policies
Rules from
Develop Business
Requirements
Manage the
recorded
Business
Architecture
Project Plan Development (Requirements Phase)
Project Plan Execution (Requirements Phase)
Project Time Management (Requirements Phase)
Apply Business Architecture: Scope Planning, Scope Definition
Document Business Requirements
Drive Requirements Review/Approval
Drive Resolution of Requirements Issues
Scope Change
Michelle:
It’s common to assume that a BA and PM are interchangeable. There are skills that a true BA and a true PM share, which are represented in the overlap. Most of these are “art” skills – communication, building relationships and negotiation – all things they are very good it. They also understand SDLC (Software Development Lifecycle), which means that know what work needs to be done and when.
BUT – there are other skills that are specific to each discipline that are vastly different.
From a PM perspective, big picture means looking at ALL work. The PM directs the team and controls the work – changing resources as needed if the critical path changes. The PM’s responsibility is to help people get their work done by removing the obstacles that exist (organizational, political). Most PM’s focus on time, cost and scope/quality – the triple constraint as that’s what their sponsor’s focus on.
These skills are more managerial in nature – unlike the skills necessary for a BA…
Dave:
A Business Analyst lives in the details.
Further clarify the information
Build consensus on what the system will do and look like.
Ask lots of questions. A favorite word of the BA is “WHY?”
Listen to not only what the client says, but what do they mean.
Focus is developing the PRODUCT, not running the PROJECT
Business Architect (E1)
Business Architect (E1) 24

25. Business Analyst Maturity Levels- midsize service company
Tools
Skills
5 Bus. Architect
Pictorial business model first (As is, to be).
Static and process pictorial models of the business.
Produce textual view of requirements last.
Advanced VISIO, WBI Modeler, Enterprise Architect, playbooks as modeling tools.
Integrated Requirement management with modeling tools.
Management Practice
Problem first then solution approach.
Business or System processes in a business model.
Processes and Scenarios identified in the business model.
Textual and Pictorial view of requirements.
Business Modeling Standardized (UML, IDEV, in VISIO or basic modeling tools).
Multiple formats: Use Cases, Stories, SRS.
Requirements management tools.
4 Structure
Processes/scenarios identified by system users .
Typically problem first then solution approach..
Random Business or System scenario driven.
Textual representation of requirements.
Capture Business Requirements, User Requirements, Functional and Non-functional requirements in single standard format
Requirements published with tools: TFS, Web 3
Categorization
Solution first approach-start with screens.
Some business knowledge needed for effective interview.
Difficult to know when analysis is done.
Textual list of requirements with some process links.
Go ask who, what, when, where, why this way…..
Suggested Questions and formats
Requirements shared in network file system 2
Guidance
Provided
Solution first approach-technology priority.
Good personal interviewing skills required.
Extensive business knowledge for effective
interview.
Difficult to know when analysis is done.
Textual list of requirements,
No suggested questions
Plan interview, conduct interview, recap interview
Requirements stored for personal use 1
IT waiter/waitress

26. Skills Comparison- Midsize service company
“Big Picture” Thinker
Possesses management
skills
Communicates well with
Business Executives
PM (E2)
BA (E3)
Business Architect (E1)
“Big Picture” Thinker
Directs the project team
Helps people get things done
Conscience of time and $$
Removes issues/barriers
Possesses management skills
Manage
Business Analysis
Process
Manage Requirements
Artifacts
Communicates well
Understands SDLC
Manages interpersonal relationships well
Negotiates
Applies Business
Architecture
Communicates well
with SMEs
Manages
interpersonal
relationships well
Interprets Business
Architecture
Details
Correctly
Michelle:
It’s common to assume that a BA and PM are interchangeable. There are skills that a true BA and a true PM share, which are represented in the overlap. Most of these are “art” skills – communication, building relationships and negotiation – all things they are very good it. They also understand SDLC (Software Development Lifecycle), which means that know what work needs to be done and when.
BUT – there are other skills that are specific to each discipline that are vastly different.
From a PM perspective, big picture means looking at ALL work. The PM directs the team and controls the work – changing resources as needed if the critical path changes. The PM’s responsibility is to help people get their work done by removing the obstacles that exist (organizational, political). Most PM’s focus on time, cost and scope/quality – the triple constraint as that’s what their sponsor’s focus on.
These skills are more managerial in nature – unlike the skills necessary for a BA…
Dave:
A Business Analyst lives in the details.
Further clarify the information
Build consensus on what the system will do and look like.
Ask lots of questions. A favorite word of the BA is “WHY?”
Listen to not only what the client says, but what do they mean.
Focus is developing the PRODUCT, not running the PROJECT 26

27. So what should I do to improve at business analysis?
Typical Business Analysis Assessment Context
Business Analysis Processes & Tools
Business Architecture to support Project, Program and Portfolio Management
Business Analyst Knowledge, Application (Usage)
Execution of Business Analysis output in software development
Business Analysis Maturity Level Assessment
Business Analyst Maturity Level Assessment
Business Analysis Improvement Roadmap 27

28. Business Analysis Assessment Scope
Business and System Analysis – the organizational glue of software development
People-
BA roles
Process
Tools
Essential Model Domain
Portfolio X X X E1
Program X X X E2
Project X X X E2
Analysis X X X E3 e l
Development X X X E3
Testing X X X E3
Project Management Office 28

29. Basic Improvement Roadmap- People
Recognize and Value Business Analyst role separation to gain project efficiencies
BA function is not a stepping stone to PM nor Business Architect roles
Projects need all three roles for success
Each position requires different abilities
Don’t wait for role delineation; be a catalyst for change
IF in the “multiple role”, create safeguards to reduce project risk
Business Analysis, Business Architecture, and Project Management are Essential!
Michelle:
The communication skill/trait is usually the #1 reason that sponsors assign a resource to play the BA/PM dual role on a project. While a true BA and a true PM have this skill in common, there are distinct differences.
The PM is the “hub” of communication in the wheel of the project. He or she interfaces with sponsor, executives, resource managers, and all members of the project team to get work done.
The PM does not interface with the business; however, as the skills needed to gain the information necessary to deliver the project are much different than the information sharing that takes place from a project perspective.
Dave:
While the PM is a hub, the Business Analyst is a bridge
“Gets into the heads” of the SMEs
Take Project team questions ---- back to the business staff to clarify ---- back to IT team.
Speak both languages “business” and “technical”.
BA’s communicate with the Project Manager
Statuses
Requirement changes
Business issues PM can manage -- scope, timeline and cost.

30. Basic Improvement Roadmap- Process
Formalize the set of sustainable Requirement Development processes, by SDLC, based on business, IT and Cultural drivers.
Train BAs and PMs on the multiple processes chosen.
Avoid producing Requirement Artifacts that are not used by Developers by monitoring on a project level basis.
Business Architecture
Strategy Communication
Business Model updates
Business
Analyst Focus
Business Model
Business Analysis Process
Bug fixes
Requirements Development Process based on SDLC chosen for project
Requirements traceable to
Business and consumable
by technical developers
Project Management Execution
___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Build/Test
Requirements
Design
Install
Objectives
Products
Product Lifecycle
PM Focus

31. Basic Improvement Roadmap –Tools
Business Architecture
Identify the tools that match the level of reusable business architecture that can be used to describe the business based on business, IT, and cultural drivers. These drivers should also be identified and prioritized for greatest impact.
Requirements Development
Identify the common set of requirement development tools that match the level of detail required on a project by project basis.
All tools should enable requirements that are traceable to the business and consumable by the IT staff.

32. Questions & Discussion Morris Oslin 952-595-797032 32