• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/44

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

44 Cards in this Set

  • Front
  • Back
Scope management process
1. Planning - Plan Scope Management
2. Planning - Collect Requirements
3. Planning - Define Scope
4. Planning - Create WBS
5. M&C - Validate Scope
6. M&C - Control Scope
Scope baseline
- Project scope statement
- the WBS
- WBS dictionary
that is approved at the end of planning
Work breakdown structure (WBS)
- graphical picture showing all the scope on the project, broken down into manageable deliverables called work packages
- work packages should consists of nouns (things, rather than actions)
- deliverable-oriented
- foundation upon which the project is built
- is very important and should exist for every project
Project scope statement
- Primary output of the Define Scope process
- "Here is what we will do on this project"
WBS dictionary
- provides a description of the work to be done for eafch WBS work package
- prevents scope creep
- output of Create WBS process
Requirements documentation
- output of the Collect Requirements process
Requirements traceability matrix
- output of the Collect Requirements process
- links requirements to the objectives and/or other requirements to ensure the strategic goals are accomplished
How to create a WBS
1. Project name goes at the top of the WBS
2. Next level is typically same as project life cycle
3. Later levels break the project into smaller pieces
4. Decompose until reaching the level appropriate to manage the project
Benefits of a WBS
- provides a structured vision for the project and ensures no deliverables are forgotten
- Helps prevent changes
- Helps identify risks
- helps get buy-in from team
Uses of a WBS
- Control scope creep
- communications tool
- help new team members see their roles
Requirements management plan
- 1 of 2 management plans for scope management knowledge area
- describes methods to use to identify requirements
- how to analyze, prioritize, manage, and track changes to requirements
- output of Plan Scope Management process
Scope management plan
- 1 of 2 management plans for scope management knowledge area
- 3 parts:
1. how scope will be planned
2. how scope will be executed
3. how scope will be controlled
- output of Plan Scope Management process
Work package
- Deliverables decomposed as smaller pieces from WBS
Activity
- A particular piece of work scheduled for the project
- Under a work package??
Product scope
- requirements that relate to the product of the project
- answers the question "What end result is needed?"
- example: a train terminal that meets these technical specifications
Project scope
- the work the project will do to deliver the product of the project
- encompasses the product scope
example: a train terminal that meets these technical specifications AND all the work needed to deliver the train terminal
Decomposition
- You can decompose the project using a WBS
Control account
- Tool that provides a way to manage and control costs, schedule, and scope at a higher level than the work package in a WBS
- Each work package in the WBS would be assigned to only one control account
Product analysis
- analyze the objectives and description of the product and turn them into tangible deliverables
- tool that allows PM to make sure the product and project scope are understood and accurate
Verified deliverables
- PM may need to determine and define deliverables as part of the project rather than receiving a completed list from the customer
Data collection techniques
- Effort to collect requirements
Interviews
- data collection technique for collecting requirements
- expert interviews
Focus groups
- data collection technique for collecting requirements
- discuss as a group directed by moderator
Facilitated workshops
- data collection technique for collecting requirements
- bring together stakeholders with different perspectives to talk about the product and define requirements
Brainstorming
- data collection technique for collecting requirements
- Meet to encourage participants to build on each other's ideas
Nominal group technique
- technique to rank ideas during brainstorming
- Simple ranking of the most useful ideas generated during the brainstorming session
Multi-criteria decision analysis
- technique to rank ideas during brainstorming
- criteria are quantified into several factors to help rank ideas
Context diagrams
- technique for organizing data collected
- frequently used to define and model scope
- highlights the product and its interfaces with people, processes, or systems
Delphi technique
- group decision-making technique
- group communicates with experts back and forth until the group moves towards an agreement (based on the info the experts provide)
Mind maps
- technique for organizing data collected
- diagram of ideas or notes looking like several trees radiating out of a central core word or words
Affinity diagrams
- technique for organizing data collected
- ideas generated are grouped by similarities with a title for each group
- can also group by categories of requirements
Questionnaires and surveys
- data collection technique for collecting requirements
- typically used for large groups
Observation
- data collection technique for collecting requirements
- job shadowing/participating in work to help identify requirements
Prototypes
- data collection technique for collecting requirements
- model presented to stakeholders for feedback to update requirements
Benchmarking
- data collection technique for collecting requirements
- comparing your organization to what another organization is doing in the same industry
- can be time consuming, costly, and inhibit creativity
Group decision-making
- data collection technique for handling conflicting requirements
1. Unanimous - everyone in group agrees
2. Dictatorship - single person makes the decision for the entire group
3. Majority - decision that more than 1/2 members support
4. Plurality - decision that has largest number of supports (if highest choice is less than 1/2 group)
5. Consensus - General agreement about a decision - even those that don't fully support eventually accept whatever most support
Requirements categories
- sometimes used in affinity diagrams
Business requirements
- Type of requirement category
- Why was the project undertaken? What business need is the project intended to address?
Stakeholder requirements
- Type of requirement category
- What do stakeholders expect from and want to gain from the project?
- must be balanced against project objectives
- prioritize requirements and resolve conflicts
Solution requirements
- Type of requirement category
- What does the product need to look like?
1. Functional requirements (how the product should work)
2. Nonfunctional requirements (what will make the product effective?)
Transition requirements
- Type of requirement category
- what type of handoff procedures/training are needed to transfer the product to the customer or organization?
Project requirements
- Type of requirement category
- What are the expectations for how the project will be initiated, planned, executed, controlled, and closed?
Quality requirements
- Type of requirement category
- What quality measures does the product need to meet?
Technical requirements
- Type of requirement category
- How will the product be built? What are the product specifications?