CAPM MOD 5 Flashcards

(120 cards)

1
Q

identifies the best approach to organize tasks, elicit requirements, analysis and solution eval, must determine rigor and detail needs to roll out project (size, criticality, complexity) what tools? How to get project requirements? How to find stakeholders?

A

Business analysis planning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

comparing your org against established industry standards. This helps provide info when data can’t be collected or isn’t enough

A

Benchmarking

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q
  • Determining and analyzing project requirements
  • Tailoring and evaluating activities required to deliver proposed solution
    o Catalog everything that needs to get done
    o Identify who is involved and how to best work with them
    o How to track progress
  • Identify stakeholders – who impacts success?
  • Understand and engage stakeholders – group them by their needs and determine best way to get info from them and their engagement level
  • Requirement management – identify requirements and process for validating, verifying, and approving requirements. Define procedure for changing requirement. Want to have requirements and tasks for achieving them in proposal
  • Evaluation = define plan to evaluate success
  • Project approach – choose predictive, adaptive, or hybrid
    o Adaptive won’t need extensive business analysis plan upfront since there is an opportunity to do this throughout the project since things are expected to change and won’t know all the info up front
A

Business anlysis planning steps

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

covers planning decisions for both product and project requirements. Details how change of requirements is dealt with in a project

A

Requirements management plan

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

describes how requirements will be elicited, analyzed, and documented throughout project. provides “how to details” like tools to model requirements.

A

business analysis plan

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

analyze current business problem or opportunity. Talk to sponsor, read business charter to learn more. Asks what a business needs to do to get from A to B
* What project solution addresses problem or opportunity?
* Is the proposed solution a good use of organized resources?
* What value will be realized? May be monetary, environmental, or social

A

Needs Analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Aspire, Business case, create charter, develop plan, execute plan, finish plan (ABCDEF)

A

phases of business needs analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

people consulted during __ are sponsor, product owner, SMEs, end users, solution team
is an iterative process to revisit frequently

A

Needs analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

review existing documentation
assess org goals and objectives
clarify needs, problems, objectives
evaluate various options
create solution scope
draft situation statement
conduct solution cost-benefit analysis

A

Tasks performed during needs analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

identify problem or opportunity
assess current state
determine future state
determine viable options and recommend solution
facilitate product roadmap development
support charter development
assemble business case

A

Processes of needs analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Business analysis planning
needs analysis
requirements elicitation and analysis
traceability and monitoring
solutions evaluation

A

The 5 business analysis areas

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

output of identifying problem or opportunity. Problem/opportunity A has the effect of B with the Impact of C.
o Must have three parts – description of problem or opportunity, effect of problem or opportunity, and the potential impact of solving problem or seizing opportunity. Even if not proved out yet, still must have the impact of solving problem or seizing opp.

A

situation statement

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q
  • Document analysis: analyze existing documentation and identify relevant product info
  • Interviews: formal or informal directly from stakeholders
  • Observation: see how process is performed or product is used in the environment
  • Questionnaire: designed to accumulate info from many respondents quickly
A

Data collection techniques

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q
  • Pareto diagram: 80/20 rule; communicates results of root cause analysis
  • Process flow: describe business processes and ways stakeholders interact with those processes
  • Value stream map: identify process steps that add value (value stream) and those that don’t (waste)
  • Root cause analysis: various techniques that determine underlying reason for variance, defect, or risk
  • Ishikawa diagram: cause and effect/fishbone diagram – depict problem and it’s root causes since most problems have many contributing factors
  • Five whys: someone seeking to understand problem asks “why” as many as 5 times
  • SWOT analysis: strategic conversation in reaction to changes in the marketplace or organization (strengths, weaknesses, opportunities, threats)
A

tools to access current states and find root cause to problems and factors leading to opportunity

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

80/20 rule; communicates results of root cause analysis

A

Pareto diagram

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

describe business processes and ways stakeholders interact with those processes

A

process flow

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

identify process steps that add value (value stream) and those that don’t (waste)

A

Value stream map

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

various techniques that determine underlying reason for variance, defect, or risk

A

root cause analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

cause and effect/fishbone diagram – depict problem and it’s root causes since most problems have many contributing factors

A

Ishikawa diagram

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

someone seeking to understand problem asks “why” as many as 5 times

A

5 whys

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

strategic conversation in reaction to changes in the marketplace or organization (strengths, weaknesses, opportunities, threats)

A

SWOT Analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Affinity diagram: shows categories and subcategories of ideas that cluster or have an affinity with one another
Feature model: visual representation of all features of a solution arranged in tree or hierarchy structure
Gap analysis: technique to compare as-us and to-be states of a business
Kano analysis: model and analyze product features from the viewpoint of the customer
Process flow: depict current state and model changes in the process that would be seen in potential future options
Alignment model: helps team link business strategy to product strategy
Solution capability matrix: examine capabilities and solution components in one view and identifies capabilities to address in the new solution
Gap analysis: Once current “as is” situation’s capabilities, identify gaps or missing capabilities that exist between current and needed states. Those will be added as “to be” futures.
Outcome of accessing the current and future states should be SMART (specific, measurable, attainable, relevant, time-based) business goals and objectives and description of required capabilities and features.

A

Tools for defining future states

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

visual representation of all features of a solution arranged in tree or hierarchy structure

A

feature model

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

technique to compare as-us and to-be states of a business
Once current “as is” situation’s capabilities, identify gaps or missing capabilities that exist between current and needed states. Those will be added as “to be” futures.

A

gap analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
model and analyze product features from the viewpoint of the customer
Kano analysis
26
depict current state and model changes in the process that would be seen in potential future options
process flow
27
helps team link business strategy to product strategy
alignment model
28
examine capabilities and solution components in one view and identifies capabilities to address in the new solution
Solution capability matrix
29
Outcome of accessing the current and future states should be ______ business goals and objectives and description of required capabilities and features.
SMART (specific, measurable, attainable, relevant, time-based)
30
tool that compares portfolio components, programs, or project benefits to costs. * Used to find most viable option * Part of portfolio or program management activities – must understand Financial analysis and use at least one of those techniques to make the assessment o Valuation techniques estimate option returns  Internal rate of return – estimation of investments’ projected annual yield including initial and ongoing costs – want it to be high. Signifies IR where NPV of all cash flow equal zero  Net present value = higher the better. Insight into whether investment will provide value  Payback period = time needed to recover an investment. Want to be low  Return on investment = % return on initial investment. * Total projected benefits/cost of investment
Cost benefit analysis
31
estimation of investments’ projected annual yield including initial and ongoing costs – want it to be high. Signifies IR where NPV of all cash flow equal zero
Internal rate of return
32
higher the better. Insight into whether investment will provide value
NPV
33
time needed to recover an investment. Want to be low
Payback period
34
% return on initial investment.
ROI
35
pulling info from sources Techniques include: * Brainstorming – generate ideas in short time * Facilitated workshop – structured meeting led by facilitator working towards stated objective * Interviews – info from team members * Personas modeling – descriptions of customers goals, requirements, concerns, and frustrations to help guide development team
Ellicitation
36
generate ideas in short time
brainstorm
37
structured meeting led by facilitator working towards stated objective
facilitated workshop
38
getting info from team members
interview
39
descriptions of customers goals, requirements, concerns, and frustrations to help guide development team
persona modeling
40
coming up with features that provide immediate value. Only focus on features deemed to be highest value.
Feature injection discussion/analysis
41
1. determine business value 2. determine features that help create that business value 3. Spot examples – talk through examples to see variations and help broaden product scope
Three steps of ellicitation
42
summarized output of feasibility analysis for review
Feasibility study results
43
provide one solution that best addresses business need
Recommended solution option
44
high-level view of product features and their build and delivery order. Communication product vision and its lifecycle highlighting how it evolves. And tells how product supports organizational strategy Characteristics of roadmap: easy to understand, milestones are assigned approximately rather than specific dates, the entire period of the project is visible
Product roadmap
45
Feature model – all features of solution in a tree of hierarchical structure. Workshop to turn into product roadmap Product visioning – high-level direction for product release. Team agrees on vision for product Story mapping – orders user stories by business value and user action
roadmap development models
46
all features of solution in a tree of hierarchical structure. Workshop to turn into product roadmap
feature model
47
high-level direction for product release. Team agrees on vision for product
product visioning
48
orders user stories by business value and user action
Story mapping
49
Items in ____ Strategy info – how product supports org strategy Portfolio – what portfolio is belongs to and how it relates to other products in porfolio Initiatives – different projects related to product currently being considered or in progress Product vision – intended customers and how needs are to be met Success criteria – metrics to determine success Market forces – issues that influence or shape product development Product releases = identify release dates and themes/high level features each one will include Features – capabilities product will provide paired with product releases set by group Timelines – time window when feature sets are expected to be delivered.
Items in a roadmap
50
process of synthesizing well-researches and analyzed info to support selection of best portfolio components, programs, or projects to address business goals and objectives
assembling a business case
51
items in a __ __ should include: 1. Problem/opportunity = situation statement, what is causing us to take action? what stakeholders are affected? 2. Analysis of the situation = root cause of problem or contributors to opportunity, relevant data, how solution supports business goals 3. Recommendation = results of feasibility analysis of each option. Address risks, concerns, etc.. Can rank solution alternatives and list recommended solution with recommendation 4. Cost-benefit analysis = related to recommended option showing why it’s most viable 5. Evaluation = plan for measuring benefits realization. Also how it contributes to goals and objectives
Items in a business case
52
collaborating on charter with sponsoring entity and stakeholders using business analysis knowledge, experience, and product info acquired during needs analysis and business case development.
Supporting project charter development
53
Business (what why) + project (how when) = solution value (business benefits)
Domain summary
54
business analyst revisits change needs analysis domain and previous decisions to make sure they still apply if something like a M&A happens
external change factors
55
* Define objective = for each elicitation activity – what kind of info is needed from stakeholders to illustrate value and benefit of XYZ * Determine participants * Identify resources – existing systems or documents * Identify questions * Set agenda and distribute any prework or info needed * Schedule elicitation activity
elicitation preparation
56
* Elicit requirements * Analyze, decompose, elaborate requirements * Evaluate product option and prioritize requirements * Create requirements baseline * Sign off on requirements * Write requirement specifications * Validate requirements * Specify acceptance criteria o Also: o Supporting executive decision making o Apply influence successfully o Assist in negotiation or mediation o Resolve conflict and negotiate with stakeholders o Define conflicts and explain techniques to prioritize
Requirement elicitation domain and analysis domain steps
57
* Brainstorming: generate ideas o Generate ideas quickly o But usually only high level ideas – don’t go deep * Document analysis: analyze existing documents to see what’s required o See current state or possible future solution o But can be time consuming, inaccurate, outdated, nonexistent * Requirements workshop: facilitated focused section with cross functional stakeholders. Product requirements are defined here. Included SMEs and selected stakeholders, informal meetings if adaptive. Goal is to capture solution scope o Large, structured, cross functional o But length of workshop can be a time burden, must find time for them all to gather, depends on facilitators experience to make it successful * Focus group = bring together stakeholders, SMEs about proposed product, service, or result o Validate solutions o But only limited to the problems focus group was given to discuss * Interviews = elicit info from stakeholders with prepared questions or 1-2 then open discussion o Can get reqs from small stakeholders and can reduce confusion about outcomes o Input from limited pool and could be bias * Observation = directly viewing people doing processes o Passive – observe without interrupting o Active – observe and ask Qs o Participatory = do the process o Simulation = use tool to simulate the activity  Can get reqs from small stakeholders and can reduce confusion about outcomes  Input from limited pool and could be bias + knowledge work isn’t tangible and can be tough to observe * Surveys = written questions to quickly gather info from large groups. Best for closed questions o Workshops are better for many open ended questions o Can rank in order of importance, Easy to deliver, can get info over large geographical space o But need to crafy questions correctly, too many qs can lead to fatigue, response rates could be low * Prototyping/storyboarding o Prototype: Obtain early feedback on model of expected product before producing it. Good for cheaper products
Elicitation techniques
58
facilitated focused section with cross functional stakeholders. Product requirements are defined here. Included SMEs and selected stakeholders, informal meetings if adaptive. Goal is to capture solution scope
requirements workshop
59
types of ___ as elicitaion technique o Passive – observe without interrupting o Active – observe and ask Qs o Participatory =do the process o Simulation = use tool to simulate the activity  Can get reqs from small stakeholders and can reduce confusion about  Input from limited pool and could be bias + knowledge work isn’t tangible and can be tough to observe
Observation
60
prototype intended for concepts; not final product
low fidelity
61
prototype created to represent final finished product; may have limited capability
high fidelity
62
prototype discarded once interface is confirmed
throwaway
63
prototype that's actual product in progress
evolutionary
64
prototyping technique that involves showcasing sequence or navigation through series of images or illustrations
storyboarding
65
1. Ensure stakeholders understand the requirements 2. Present requirements in sufficient detail 3. Ensure stakeholders see business value of project
requirement analysis objective
66
1. Determine analysis approach – what data to analyze, which models to produce, how to verify, validate, and priotize requirements 2. Create and analyze model – create use case for stakeholders can understand it better 3. Define and elaborate on requirements – choosing type of life cycle 4. Define acceptance criteria – agree on what proves one or more solution components were developed successfully 5. Verify requirements – meets quality requirements 6. Validate requirements – meets with business objectives 7. Prioritize requirements
Requirement analysis key processes:
67
1. Scope – define project scope by structuring and organizing the business domain being analyzed 2. Process – describe step-by-step movement of data, resources, or documents in the context of the organization 3. Rule – show business constraints that a proposed solution must enforce. Specific directive that is defined and managed 4. Data – document data stores and the flow of data 5. Interface – show relationships within a solution to understand it’s interfaces and details
business analysis models
68
specifies requirements in details and describes what features are in or out of scope. Then gets approved by project sponsor.
scope statement
69
define scope by structuring and organizaing business domain being analyzed
scope model
70
describe step-by-step movement of data, resources, or documents in the context of the organization
process model
71
show business constraints that a proposed solution must enforce. Specific directive that is defined and managed
rule model
72
document data stores and the flow of data
data model
73
show relationships within a solution to understand it’s interfaces and details
interface model
74
shows applicable systems, their relationships, and the data passed between them
ecosystem map
75
representations of a system and human interaction within a solution
context diagram
76
process flow diagram narrative use cases user stories story map
process models
77
models that portray steps people perform on their jobs or when implementing a solution
process flow diagram
78
INVEST Independent negotiable valuable estimable small testable
acronym to ensure user stories are ready for construction
79
show current requirements picture with the time on the x-axis and business value based details and priority on the y-axis stuff at top of story map is more important than stuff at the bottom
story map
80
business rules catalog decision tree
rule models
81
business rules and their related attributes like ID, title, description, constraints, references
business rules catalog
82
graphic model of choices to uncover solution
decision tree
83
a way to model rules where decision scenario combinations that can reveal new requirements
decision tale
84
entity relationship diagram data flow diagram
data models
85
diagram poppular for diagramming tool for data driven applications - like relationships in tableau
entity relationship diagram
86
lists data fields and attributes ex: credit card number - number and first name - text
data dictionary
87
shows the data inputs and outputs for each process in the project
data flow diagram
88
wireframe user interface flows display action response model
interface models
89
2-D representation of an interface - like a template for a website you're building that shows where stuff should go
wireframes
90
usually combined with wireframes/screen mockup - can identify user interface page elements and requirements
display action response models
91
display specific user interfaces and widely-used screens in a functional design and plots how to navigate between them
user interface flows
92
model that describes detailed requirements for a single report
report table
93
____ are composed of user stories
Epics
94
1. Trace requirements 2. Monitor requirements 3. Update requirements 4. Communicate requirement status 5. Manage change to requirements
key tasks of traceability and monitoring
95
requirements can be traced to the solution back to business needs – if not linked to business need – it’s out of scope
Bidirectional
96
In an adaptive project- a _____ is used instead of traceability matrix
product backlog
97
* Business needs, goals, objectives * Work breakdown structure deliverables * Product design and development components * Test cases * Requirements * Ise cases and acceptance tests * Models and diagrams related to requirements
traceable artifacts
98
process of evaluating proposed changes by assessing risks, required work, scheduling, and cost implications, see if there are conflicts in requirements If it’s changed o Compares to requirements baseline and existing solution components
impact analysis
99
1. Evaluate solution performance – determines whether solution is delivering the intended business value 2. Determine solution evaluation approach – determine how, when, and by whom performance will be measured for the organization or solution 3. Evaluate acceptance results and address defects – identify and resolve product problems. Compare defined acceptance criteria against the solution and decide what to do 4. Obtain solution acceptance for release – decide whether to release solution into production and whether to transfer product knowledge like risks, issues, workarounds. Solution sign offs occur here 5. Evaluate deployed solution – evaluate process success after solution implementation – access/monitor after if’s been implemented
solution evaluation domain processes
100
concrete conditions that have to be met for business stakeholders or customers to accept the item
acceptance criteria
101
____ is is the work of determining whether product or service developed meets initial requirements. It occurs before the project and during the project by the business analyst. Acceptance criteria is created before the project occurs.
solution evaluation
102
_____ will evaluate deployed solution, correct defects, and decide who will conduct evaluation. Only ____ can accept the deliverables
business analyst; clients
103
___ ___ development is when developers write test case before writing code. As solution is developed, it is validated against the test case
test driven development
104
___ ____ development work begins in the iteration before actual solution development. Business analyst, customers, and tests write acceptance criteria for user stories
acceptance driven development
105
___ ___ development behavior of final software or solution is documented before the developers begin to write actual code.
behavior driven development
106
* Actual project cost – can be put into financial evaluations like net present value or ROI * Metrics derived from measurement of cost, effort, duration – Project performance * Change requests – indicators of project volitility * Rejection of requirements – not always clear who can reject requirements. Sometimes it only those who can sign off on requirements that can reject them
evaluation criteria
107
108
108
in ___ approach entire project is tested at the end of the project. End of life cycle, evaluation activities occur such as user acceptance, testing, and solution release.
predictive
109
in ___ approach test solution incrementally. Test iteration when you deliver viable product increment
adaptive
110
___ asks "are we building the right product” * Ensures requirements solve problem * Ensures requirements accurately reflect intent of stakeholders * Happens before implementation
validation
111
____ answers the question “are we building the right product * Ensures constructed product conforms to specification * Reviews the requirements for errors and quality * Performed by solution team members to ensure requirements meet quality standards
verification
112
testing Peer-reviews – one or more coworkers review work completed by business analyst Inspections – formal and rigorous review in which anyone close to work inspects completeness, consistency, and conformance to internal and external standards * Walkthroughs * Day in life testing
verification process
113
one or more coworkers review work completed by business analyst
peer review
114
– formal and rigorous review in which anyone close to work inspects completeness, consistency, and conformance to internal and external standards * Walkthroughs * Day in life testing
inspection
115
= involves external stakeholders and ensures product is ready for delivery upon completion of solution
validating scope
116
internal quality control process that ensures product functionality as specified through quality checks
verifying deliverable/quality
117
___ strategy team decided on whether to release partial or full solution into production
implementation strategy
118
involves communicating and archiving knowledge about the product, risks, known issues, and workarounds
transitioning knowledge
119