- A solution addresses a requirement; a requirement addresses a need
- Requirement Types
- Business Requirements
- Stakeholder Requirements
- Solution Requirements
Need, Requirement, and Solution
Reply
Monthly Archives: April 2018
PBA Tools and Techniques
(Source: PMI Business Analysis for Practitioners – A Practice Guide)
- Goals and Objectives
- Corporate strategies translate goals identified in business plans into actionable plans and objectives.
- Goals are typically broad-based and may span one or more years. (organization or strategy level, long-term)
- Objectives, on the other hand, are used to enable goals; these are more specific and tend to be of shorter term than goals, often with duration of 1 year or less. (project or tactical level, short-team/less than 1 year)
- Objectives describe business value; requirements describe how to achieve it.
- Problem Analysis
- the first step of problem analysis is to clarify the need by finding the root cause.
- the second step is describing the problem or situation so everyone in the organization sees the need in the same way.
- fishbone & five why
- Situation Statement
- a clear, agreed-upon business need is the foundation of the entire project.
- creating a situation statement is a way to get consensus on the business need.
- Market Analysis
- Competitive Analysis
- Benchmarking
- Job Analysis
- used to identity the job requirements and competencies required to perform effectively in a specific job or role
- Decomposition Model (aka decomposition diagram)
- Business Analysis: used to identify business analysis tasks, activities, and deliverables by detailing out the business analysis work.
- Stakeholder Analysis: used to analyze the organization with the goal of discovering stakeholder groups.
- IT Projects: to break down solutions into solution components to further understand their features.
- Solution Evaluation Metrics and Acceptance Criteria
- Business goals and objectives
- Key Performance Indicators
- Customer Metrics
- Sales and Marketing Metrics
- Operational Metrics
- Functionality
- Measurable Acceptance Criteria
- nonfunctional requirements
- service-level agreement
- Evaluation Techniques
- Surveys and focus group
- Results from exploratory testing and user acceptance testing
- Results from day-in-the-life (DITL) testing
- Results from integration testing
- Expected vs actual results for functionality
- Expected vs actual results for nonfunctionality requirements
- Outcome measurements and financial calculation of benefits
Bruce Passed PMI-ACP Exam on 9th Apr
After attending a 40-hour instructor-led course and 60 hours of study, Bruce passed the PMI-ACP Exam today. This is the second milestone for Bruce’s learning plan of 2018.
The following is the preparation list for this exam:
- PMI-ACP Certification ExamPrep Course from Advanced Business Consulting Inc.
- Pluralsight Online Courses
- RMC PMI-ACP Exam Prep
- PMI Agile Practice Guide
- Agile Project Management with Scrum by Ken Schwaber
- Exploring Scrum: The Fundamentals Paperback by Dan Rawsthorne, Doug Shimp
- User Stories Applied: For Agile Software Development by Cohn, Mike
- User Story Mapping: Discover the Whole Story, Build the Right Product by by Jeff Patton
Agile Mindset
Agile is a mindset for a high-performance team with commitments to willingly respond or harness changes and continuously deliver valuable products for customer’s satisfaction and competitive advantages through collaboration with them.
A high-performance team is cross-functional and self-organizing. Continuous delivery suggests delivering products iteratively and incrementally; that is, to deliver products with added values in a short timescale frequently or in a sustainable pace.
- Lean Thinking
- Agile Mindset
- Methodology (Approaches or Methods)
- DSDM
- Crystal
- XP
- Kanban
- Framework
- Scrum (Scrum Guide 2017)
- Authors
The Flip Side of Your User Story Card
User Story
User stories are usually written down with index cards for further conversation and confirmation. Odds are we feel quite comfortable with the typical user story format evolved over time at Connextra as the following:
As a [type of user]
I want to [do something]
So that I can [get some benefit]
With this simple template, we can start off conversation for details and define acceptance criteria for confirmation. It’s about time to write the acceptance criteria onto the flip side of your user story card.
When describing the acceptance criteria, using Gherkin syntax as follows is beneficial both to the user and developer.
Given [preconditions or context]
When [actions]
Then [results]
A user can develop the acceptance criteria in plain English using Gherkin syntax with quite limited keywords, while the developer can incorporate it into the testing framework, such as SpecFlow, Cucumber, Fit/FitNesse, and the like, to automate the testing and documentation work.
References