• 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/49

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;

49 Cards in this Set

  • Front
  • Back
  • 3rd side (hint)
It defines a set of requirements that must be met for a new solution to be acceptable to its stakeholders. Evaluation criteria are metrics and indicators used to assess how an operational solution meets its objectives over time.
a. Acceptance and Evaluation Criteria Definition
b. Stakeholder Map
c. Organization Modeling
d. Requirements Documentation
a. Acceptance and Evaluation Criteria Definition
9.1 Acceptance and Evaluation Criteria Definition
Comparing organizational practices or processes against best-in-class practices or processes of peer organizations to identify opportunities for improvement.
a. Benchmarking
b. Vendor Assessment
c. Organization Modeling
d. Problem Tracking
a. Benchmarking
9.2 Benchmarking
Generating creative ideas and options to solve a problem or meet a business need in a noncritical group environment.
a. Interviews
b. Focus Groups
c. Brainstorming
d. Survey/Questionnaire
c. Brainstorming
9.3 Brainstorming
Modeling and analyzing the business principles and processes that define, constrain, and/or enable business operations.
a. Process Modeling
b. Business Rules Analysis
c. Data Modeling
d. Scenarios and Use Cases
b. Business Rules Analysis
9.4 Business Rules Analysis
Collections of definitions used to explain the terminology used by the business and the data relevant to each business domain.
a. Metrics and Key Performance Indicators
b. Acceptance and Evaluation Criteria Definition
c. Elements & Usage Considerations
d. Data Dictionary and Glossary
d. Data Dictionary and Glossary
9.5 Data Dictionary and Glossary
Drawings used to visually represent how information moves through a system by showing the external entities, processes, data storage, and data flow.
a. Data Flow Diagram (DFD)
b. Sequence Diagrams
c. Root Cause Analysis
d. Decision Analysis
a. Data Flow Diagram (DFD)
9.6 Data Flow Diagram (DFD)
Describing and diagramming the concepts relevant to a business area, the relationships between these concepts, and information associated with them.
a. Process Modeling
b. Business Rules Analysis
c. Data Modeling
d. Scenarios and Use Cases
c. Data Modeling
9.7 Data Modeling
Examining and modeling the possible consequences of different decisions to make the optimal decision under uncertain conditions.
a. Data Flow Diagram (DFD)
b. Sequence Diagrams
c. Root Cause Analysis
d. Decision Analysis
d. Decision Analysis
9.8 Decision Analysis
Eliciting the requirements for an existing system by studying available documentation and identifying any other relevant information.
a. Metrics and Key Performance Indicators
b. Acceptance and Evaluation Criteria Definition
c. Elements & Usage Considerations
d. Data Dictionary and Glossary
c. Elements & Usage Considerations
9.9 Elements & Usage Considerations
Developing the possible range of costs and effort associated with business analysis work on your project.
a. Metrics and Key Performance Indicators
b. Functional Decomposition
c. Estimation
d. Scope Modeling
c. Estimation
9.10 Estimation
Collections of people used to elicit ideas and attitudes about a specific product, service, or opportunity in an interactive environment.
a. Interviews
b. Focus Groups
c. Requirements Workshops
d. Survey/Questionnaire
b. Focus Groups
9.11 Focus Groups
Decomposing business processes, functional areas, or deliverables into smaller parts in order to analyze the parts independently.
a. Metrics and Key Performance Indicators
b. Functional Decomposition
c. Estimation
d. Scope Modeling
b. Functional Decomposition
9.12 Functional Decomposition
Clarifying the boundaries and interfaces between solutions and solution components and defining the requirements describing how they will interact with one another.
a. SWOT Analysis
b. Interface Analysis
c. State Diagrams
d. Scope Modeling
b. Interface Analysis
9.13 Interface Analysis
Conversations used to elicit information from a person or group of people in an informal or formal setting by asking questions and documenting the responses.
a. Interviews
b. Focus Groups
c. Requirements Workshops
d. Survey/Questionnaire
a. Interviews
9.14 Interviews
Learning about and improving a project or process by compiling and documenting successes, opportunities for improvement, failures, and recommendations for improving performance.
a. Interviews
b. Oberservation
c. Lesson Learned Process
d. Structured Walkthrough
c. Lesson Learned Process
9.15 Lesson Learned Process
Measurements used to indicate the performance of solutions, solution components, and other matters of interest to your stakeholders.
a. Metrics and Key Performance Indicators
b. Acceptance and Evaluation Criteria Definition
c. Elements & Usage Considerations
d. Data Dictionary and Glossary
a. Metrics and Key Performance Indicators
9.16 Metrics and Key Performance Indicators
Describing qualities and characteristics of a system or solution, such as usability and performance.
a. Interface Analysis
b. Elements & Usage Considerations
c. Prototyping
d. Non-Functional Requirements Analysis
d. Non-Functional Requirements Analysis
9.17 Non-Functional Requirements Analysis
Eliciting requirements by conducting an assessment of the stakeholder's work environment.
a. Interviews
b. Oberservation
c. Lesson Learned Process
d. Structured Walkthrough
b. Oberservation
9.18 Oberservation
Describing roles, responsibilities, and reporting structures that exist within an organization.
a. Benchmarking
b. Vendor Assessment
c. Organization Modeling
d. Problem Tracking
c. Organization Modeling
9.19 Organization Modeling
Formally tracking the management and resolution of defects, issues, problems, and risks throughout the project life cycle.
a. Benchmarking
b. Vendor Assessment
c. Organization Modeling
d. Problem Tracking
d. Problem Tracking
9.20 Problem Tracking
Visually modeling the sequential flow and control logic of a set of related activities or actions.
a. Process Modeling
b. Business Rules Analysis
c. Data Modeling
d. Scenarios and Use Cases
a. Process Modeling
9.21 Process Modeling
Building a partial or preliminary version of a system or solution as part of your requirements development activities.
a. Interface Analysis
b. Elements & Usage Considerations
c. Prototyping
d. Non-Functional Requirements Analysis
c. Prototyping
9.22 Prototyping
Structured and facilitated meetings for a carefully selected group of stakeholders to collaborate and define/refine requirements.
a. Interviews
b. Focus Groups
c. Requirements Workshops
d. Survey/Questionnaire
c. Requirements Workshops
9.23 Requirements Workshops
Assessing an identified risk and deciding on a response to that risk.
a. Risk Analysis
b. User Stories
c. Scenarios and Use Cases
d. Problem Tracking
a. Risk Analysis
9.24 Risk Analysis
Performing a structured examination of an identified problem to understand the underlying causes of that problem.
a. Data Flow Diagram (DFD)
b. Sequence Diagrams
c. Root Cause Analysis
d. Decision Analysis
c. Root Cause Analysis
9.25 Root Cause Analysis
Stories used to describe the tasks a system or solution will perform for actors and the goals that the system will achieve for those actors.
a. Process Modeling
b. Business Rules Analysis
c. Data Modeling
d. Scenarios and Use Cases
d. Scenarios and Use Cases
9.26 Scenarios and Use Cases
Defining the boundaries of a business domain or solution.
a. SWOT Analysis
b. Interface Analysis
c. State Diagrams
d. Scope Modeling
d. Scope Modeling
9.27 Scope Modeling
Drawings used to show how objects interact during a scenario and the messages they exchange with one another.
a. Data Flow Diagram (DFD)
b. Sequence Diagrams
c. Root Cause Analysis
d. Decision Analysis
b. Sequence Diagrams
9.28 Sequence Diagrams
Drawings used to show the life cycle of a data entity or class.
a. SWOT Analysis
b. Interface Analysis
c. State Diagrams
d. Scope Modeling
c. State Diagrams
9.29 State Diagrams
An organized peer review of a deliverable, looking for errors and omissions.
a. Interviews
b. Oberservation
c. Lesson Learned Process
d. Structured Walkthrough
d. Structured Walkthrough
9.30 Structured Walkthrough
A set of written questions to stakeholders to collect responses from a large group in a relatively short period of time.
a. Interviews
b. Focus Groups
c. Requirements Workshops
d. Survey/Questionnaire
d. Survey/Questionnaire
9.31 Survey/Questionnaire
An evaluation of the influencing factors and how they affect a project by looking at strengths, weaknesses, opportunities, and threats.
a. SWOT Analysis
b. Interface Analysis
c. State Diagrams
d. Scope Modeling
a. SWOT Analysis
9.32 SWOT Analysis
High-level, informal, and short descriptions of a solution capability for a stakeholder in one or two sentences.
a. Risk Analysis
b. User Stories
c. Scenarios and Use Cases
d. Problem Tracking
b. User Stories
9.33 User Stories
An evaluation of the ability of a potential vendor to meet commitments regarding providing you with a product or service.
a. Benchmarking
b. Vendor Assessment
c. Organization Modeling
d. Problem Tracking
b. Vendor Assessment
9.34 Vendor Assessment
Describing roles and responsibilities of people performing business analysis work by showing if they are responsible, accountable, consulted, and/or informed about specific tasks and deliverables.
a. RACI Matrix
b. Stakeholder Map
c. Coverage Matrix
d. Force Field Analysis
a. RACI Matrix
2.2 RACI Matrix
A drawing that visually depicts the relationships of stakeholders to the solution and to one another, using either a matrix or an onion diagram.
a. RACI Matrix
b. Stakeholder Map
c. Coverage Matrix
d. Force Field Analysis
b. Stakeholder Map
2.2 Stakeholder Map
Analyzing the differences between planned and actual performance of work activities to see if corrective or preventive actions are required while business analysis work is being done.
a. Variance Analysis
b. Baselining
c. Signoff
d. Requirements Documentation
a. Variance Analysis
2.6 Variance Analysis
Taking a snapshot of requirements at a specific point in time and using it as a basis for further development.
a. Variance Analysis
b. Baselining
c. Signoff
d. Requirements Documentation
b. Baselining
4.1 Baselining
A requirements signoff formalizes agreement by project stakeholders that the content and presentation of documented requirements are accurate and complete.
a. Variance Analysis
b. Baselining
c. Signoff
d. Requirements Documentation
c. Signoff
4.1 Signoff
Using a table or spreadsheet to trace your requirements and track the relationships between them.
a. RACI Matrix
b. Stakeholder Map
c. Coverage Matrix
d. Force Field Analysis
c. Coverage Matrix
4.2 Coverage Matrix
Capturing your project requirements in a formal requirements document or a set of requirements documents.
a. Variance Analysis
b. Baselining
c. Signoff
d. Requirements Documentation
d. Requirements Documentation
4.4 Requirements Documentation
Capturing requirements to use for vendor evaluation and selection purposes by using a Request for Information (RFI), Request for Quote (RFQ), or Request for Proposal (RFP).
a. Requirements for Vendor Selection
b. Requirements Documentation
c. MoSCoW Analysis
d. Voting
a. Requirements for Vendor Selection
4.4 Requirements for Vendor Selection
Evaluating proposed solution alternatives to see if they are technically feasible for the organization and if they deliver the desired business benefits.
a. Feasibility Analysis
b. Problem or Vision Statement
c. Timeboxing/Budgeting
d. Checklists
a. Feasibility Analysis
5.4 Feasibility Analysis
A document that describes the problems found in the current state of the organization and clarifies what a successful solution will do about those problems.
a. Feasibility Analysis
b. Problem or Vision Statement
c. Timeboxing/Budgeting
d. Checklists
b. Problem or Vision Statement
5.4 Problem or Vision Statement
Prioritizing requirements by dividing the requirements into four categories: must, should, could, and won't.
a. Requirements for Vendor Selection
b. Requirements Documentation
c. MoSCoW Analysis
d. Voting
c. MoSCoW Analysis
6.1 MoSCoW Analysis
Prioritizing requirements based on allocation of a fixed resource—timeboxing prioritizes based on the work that can be done in a set period of time, while budgeting prioritizes based upon a fixed amount of money.
a. Feasibility Analysis
b. Problem or Vision Statement
c. Timeboxing/Budgeting
d. Checklists
c. Timeboxing/Budgeting
6.1 Timeboxing/Budgeting
Prioritizing requirements by allocating a fixed amount of resources for your stakeholders to distribute across a set of proposed features or requirements.
a. Requirements for Vendor Selection
b. Requirements Documentation
c. MoSCoW Analysis
d. Voting
d. Voting
6.1 Voting
Lists used to verify that important items are included in your final requirements deliverables to ensure consistent project approaches and outcomes.
a. Feasibility Analysis
b. Problem or Vision Statement
c. Timeboxing/Budgeting
d. Checklists
d. Checklists
6.5 Checklists
Graphically depicting and analyzing the forces that support and oppose an organizational change, such as implementation of a new solution.
a. RACI Matrix
b. Stakeholder Map
c. Coverage Matrix
d. Force Field Analysis
d. Force Field Analysis
7.3 Force Field Analysis