Business Analysis

A Business Analyst ……..
 Provides solutions to:
 Process improvement
 Organizational change
 Technology components
 Utilize their techniques, skills, and abilities required to
clearly define a problem faced by the business, working
with the development team the BA determines the
scope of the solution to the problem.
A Business Analyst is Not……
 Project Manager
 Organizational Developer
 Quality Assurance
 Technical Designer
 Coder, Tester and Implementer
Knowledge Areas
1. Enterprise Analysis
2. Business Analysis Planning and Monitoring
3. Elicitation
4. Types of Requirements
5. Solution Assessment and Validation
6. Requirements Management and Communication
1. Enterprise Analysis
 Define & Document Business Problem and Need
 Assess Capability Gaps
 Determine Solution Approach
 Define Solution Scope
 Define Business Case
2. Business Analysis Planning and Monitoring
 Plan BA Approach
 Conduct Stakeholder Analysis
 Plan BA Activities
 Plan BA Communication
 Plan Requirements Management Process
 Manage BA Performance
3. Elicitation/Requirements Gathering
is the practice of collecting the requirements of a system from users, customers
and other stakeholders.
 Prepare for Elicitation
 Conduct Elicitation Activity
 Document Elicitation Results
 Confirm Elicitation Results
4. Types of Requirements
Business Requirements
• Sounds Like a high-level business goal or objective.
• Example: “Expand the number of customers we have by 50% next year.
• Why it’s important: Establishes the business case for the project.
Types of Requirements
Use Case
• Sounds like the name of a process, collection of individual steps.
• Example: “Customers will be able to plan an adventure.”
• Why it’s important: Use cases are containers for functional requirements in context.
Types of Requirements
Quality Attribute
• Sounds like a quality characteristic that a system should posses, e.g.
performance, security, etc.
• Example: The system should be able to accommodate 100 simultaneous users.
• Why it’s important: The system should ensure a certain quality of service to
users.
Types of Requirements
Data Definition
• Sounds like information the system will create, update, read, or delete.
• Example: If I enter a name I want to see their address.
• Why it’s important: A system can’t work without data.
Types of Requirements
Functional Requirement
• Sounds like a single statement of one individual function. (Will, or Shall
statements)
• Example: With the correct 4 digit pin the system will allow the user access the
ATM machine.
• Why it’s important: These are the detailed functional requirements of the
system.
Types of Requirements
External Interface
• Sounds like getting information from or giving information out.
• Example: Perform a search, get a result.
• Why it’s important: Almost every system communicates with something
else in the universe.
Types of Requirements
Design Constraint
• Sounds like a limitation of the solution or implementation.
• Example: “The UI has to function with IE8 and above.”
• Why it’s important: Design constraints must be considered when the solution
is determined.
Types of Requirements
Solution Idea
• Sounds like a solution or statement of design.
• Examples: We will only be able to accept electronic applications.
• Why it’s important: Work backwards from the solution idea to the
underlying business requirements. “What's the problem we are trying to
solve?”
Types of Requirements
Business Rule
• Sounds like a policy determined by management, or some regulatory agency,
that limits what people or an automated system can do.
• Example: “Customers must be registered before they can use the ATM
machine.
• Why it’s important: System must ensure compliance with all business rules.
5. Solution Assessment and Validation
 Assess and Contribute Proposed Solutions
 Allocate Requirements
 Assess Organizational Readiness
 Define Transitional Requirements
 Validate Solutions
 Evaluate Solution Performance
6. Requirements Management and Communication
 Manage Solution Scope and Requirements
 Manage Requirements Traceability
 Maintain Requirements for Re-use
 Prepare Requirements Package
 Communicate Requirements
Defining Project Roles
 Business Domain
 Solution Domain
 Project Sponsor
 Software Developer
 Product Owner
 Software Tester
 User (Actor)
 Application Architect
 Subject Matter
 Database Administrator
Expert(SME)
 Network
Architect/Engineer)
Typical Role of BA
 ROI (Return on Investment)
 Key Facilitator
 Liaison Between Business Organization and Solution
Developers
 Examine Business Problem and Needs
 Ensure Needs Are Valid, Understood and Met
 Identify, Validate, and Document Requirements
 Ensure Solutions Satisfy those Needs
 Advocate for the Business
Summary: The Business Case
 Good Requirements are Essential for Project Success
 Its Important to Know What a Good Requirement Sounds Like
 There is a Cost Associated With Missed or Ambiguous
Requirements that can be quite large
 Getting Requirements Right Can Save Substantial Rework, Time,
and Money
 Requirements Engineering Involves Developing and Managing
Requirements
Cost of Requirements Errors*
Relative Cost to Repair A Defect at Different Project Life Cycle Phases
200
$200 Post Release
180
160
140
120
100
80
60
40
20
0
*Adapted from Managing Software Requirements, Dean Leffingwell and Don Widrig.
Organizing Requirements
 Creating a Requirements Document is really about
packaging the requirements
 Create a requirements set or package that reflects the
requirements for a particular system, sub-system, or a
number of systems together
 Define requirements that are applicable to the entire system;
global requirements
 Define requirements that are specific to sub-systems and eventually to
individual use cases
Software Tools
 Contour
Conclusion
 IIBA International Institute of Business Analysis
 Questions?
 My contact information
 blevin@ucdavis.edu
 Hampton Sublett PMO Group
 hsublett@ucdavis.edu
 Hope You Enjoyed the Presentation!