Business Analysis
Download
Report
Transcript 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
[email protected]
Hampton Sublett PMO Group
[email protected]
Hope You Enjoyed the Presentation!