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;
132 Cards in this Set
- Front
- Back
Acceptance Criteria |
The minimal set of requirements that must be met in order for a particular solution to be worth implementing.
Key |
|
Activity |
A unit of work performed as part of an initiative or process |
|
Actor |
A human and nonhuman roles that interact with the system |
|
Actor, Secondary |
An actor who participates but does not initiate a use case
|
|
Allocation |
The forward traceabilily or lineage of of a requirement (in the direction of a solution). |
|
Approach |
A set of processes, templates, and activities that will be used to perform a task. |
|
Association
|
A link between elements or objects in a diagram or between actors in a use case
|
|
Assumption |
Influencing factors that are believed to be true but have not been confirmed to be accurate
|
|
Asynchronous message (signal) |
Allows the object in a Sequence Diagram to continue with its own processing after sending the signal |
|
Average Rate of Return |
Estimate of rate of return on an investment
|
|
Baseline
|
A point-in-time view of requirements that have been reviewed and agreed upon to serve as a basis for further development
|
|
Black Box Test |
Test written without regard to how the software is implemented |
|
Budgeting |
Prioritize requirements, using a fixed number of units of money
Task-Specific |
|
Business Analysis |
A set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals. |
|
Business Case
|
An assessment of the costs, benefits, and risks associated with a proposed initiative |
|
Business Goal |
A state or condition that must be satisfied to reach a vision. Longer-term, ongoing, and qualitative statements of a state or condition that the organization is seeking to establish and maintain. |
|
Business Need |
A type of business requirement that is a statement of a business objective or an impact the solution should have on its environment. It defines the problem for which the business analyst is trying to find a solution. |
|
Business Policy |
A non-actionable directive that supports a goal |
|
Business Rule |
A specific, actionable, testable directive that is under the control of an organization and that supports a business policy
Key |
|
Business Rule, Operative |
A business rule an organization chooses to enforce as a matter of policy. Example: “An order must not be placed when the billing address provided by the customer does not match the address on file with the credit card provider.” |
|
Business Rule, Structural |
Intended to help determine when something is or is not true, or when things fall into a specific category, or a calculation. Example: “An order must have one and only one associated payment method.” |
|
Cardinality |
The number of occurances of one entity in a data model that are linked to a second entity
|
|
Constraint, Business |
Reflects time/budget/resource restrictions |
|
Constraint, Technical |
Architectural constraints |
|
Context Diagram |
A top-level data flow diagram that models the scope of a solution. |
|
Customer |
External stakeholder who make use of the products or services |
|
Data Dictionary |
Standard definitions of data elements, their meanings, and allowable values
Key |
|
Data Entity
|
A group of related information to be stored by the system. |
|
Data Flow Diagram |
A visual representation of how information is moved through a system
Key |
|
Data Model |
Describes the concepts relevant to a domain, the relationships between those concepts, and information associated with them.
Key |
|
Decision Tree |
An analysis model that provides a graphical alternative to decision tables by illustrating conditions and actions in sequence |
|
Defect
|
A deficiency in a produce or service that reduces its quality |
|
Derivation
|
The backwards lineage of a requirement (toward the business goals) |
|
Desired Outcome
|
The business benefits that will result from meeting the business need and the end states desired by stakeholders |
|
Diagram |
A graphical model |
|
Discounted cash flow
|
Future value on a specific data |
|
Domain
|
An area undergoing analysis |
|
Domaine SME |
Stakeholder with in-depth knowledge of a topic relevant to the business need or solution scope |
|
End User |
Stakeholder who directly interacts with the solution |
|
Enterprise
|
An organizational unit, organization, or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers. |
|
Enterprise Architecture
|
A description of an organization's business processes, IT software and hardware, people, operations, and projects, and the relationship between them. |
|
Estimation, Analogous |
Use a similar project as basis. Top-down estimate. |
|
Estimation |
Forecast the possible range of costs and effort associated with any initiative |
|
Estimation, Bottom Up |
Break down into smaller items, estimate those, then aggregate. |
|
Estimation, Historic Analysis |
Use history. Similar to analogous but can be more granular |
|
Estimation, Parametric |
Use parameters. |
|
Estimation, Rolling Wave |
Iterative
|
|
Estimation, Three Point |
Use most optimistic, most pessimistic, and most likely |
|
Evaluation |
The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time |
|
Evaluation Criteria |
The set of requirements that will be used to choose between multiple solutions.
Key |
|
Event
|
Something that occurs to which an organizational unit, system, or process must respond |
|
Expected Value
|
The probability-weighted average of all possible values |
|
Extend |
Stereotype in which one use case inserts additional behavior into another. The extended use case does not need to be a complete use case |
|
Feature |
A cohesive bundle of externally visible functionality |
|
Fishbone Diagram |
A diagramming technique used in root cause analysis. Also called an Ishikawa or cause-effect diagram. |
|
Five Whys
|
A model used in root cause analysis. One iteratively asks why until you reach the root (may or may not be five iterations) |
|
Force Field Analysis |
A graphical model for depicting the forces that support and oppose a change. |
|
Functional Decomposition |
Decompose processes, functional areas, or deliverables into their component parts and allow each part to be analyzed independently |
|
Gap Analysis
|
A comparison of the current state and desired future state in order to identify differences that need to be addressed |
|
Glossary |
Documents terms unique to the domain
Key |
|
Impact Analysis |
Assesses the effects that a proposed change will have on a stakeholder, group, project, or system |
|
Implementation SME |
Stakeholder responsible for designing and implementing potential solutions |
|
Include |
Stereotype in which one use case makes use of the behavior of another. The included use case does not need to be a complete use case |
|
Inspection |
A formal type of peer review that utilizes a pre-defined and documented process, specific participant roles, and the capture of defect and process metrics |
|
Internal Rate of Return |
The interest rate (or discount) when the net present value is equal to zero |
|
Intiative
|
An effort undertaken with a defined goal or objective |
|
Key Performance Indicator |
A metric that measures progress towards a strategic goal or objective.
Key |
|
Lifeline
|
A line in a sequence diagram that shows when an object is created or destroyed. |
|
Methodology
|
An approach that is used over time |
|
Metrics |
A quantifiable indicator that measures progress
Key |
|
Model
|
Any simplified representation of a more complex reality |
|
Monitoring |
A continuous process of collecting data |
|
MuSCoW Analysis |
Prioritize requirements, using MUST, SHOULD, COULD, WOULD
Task-Specific |
|
Net present value |
Future view of costs and benefits converted to today’s value |
|
Objective |
A target or metric that a person or organization seeks to meet in order to progress toward a goal |
|
Operational Support |
Stakeholder who will provide support for the solution once released |
|
Organization
|
An autonomous unit within an enterprise under the management of a single individual or board |
|
Pay Back Period |
The amount of time it takes for an investment to pay for itself |
|
Process Map |
A model that shows business process in terms of input, output, and steps |
|
Process Modeling |
A process describes how multiple people or groups collaborate over a period of time to perform work.
Key |
|
Product |
A solution or solution component that is a result of a project |
|
Project
|
A temporary endeavor undertaken to create a unique product, service, or result |
|
Project Charter |
A document issues by the sponsor that formally authorizes the existence of a project |
|
Project Manager |
Stakeholder who manages the work required to deliver the solution |
|
Prototype |
A visual interface model, a partial or preliminary version of the system |
|
Prototype, Evolutionary versus Exploratory |
Also known as Functional versus Throw-Away. Evolutionary is continuously improved and Exploratory is developed to explore or verify requirements and then thrown away. |
|
Prototype, Horizontal versus Vertical |
Horizontal shows a shallow and possibly wide view of the system's functionality. Vertical is deep, usually a narrow slice of the entire system's functionality. |
|
Quality
|
The degree to which a set of inherent characteristics fulfills requirements |
|
Regulator |
Stakeholder responsible for the definition and enforcement of standards |
|
Request for Information (RFI) v. Request for Proposal (RFP) v. Request for Quote (RFQ) |
All requirements documents issued to solicit vendor input. RFI: Used when seeking different alternatives or when uncertain regarding available options. RFP: Organization seeking formal proposal RFQ: Less formal seeking proposals
|
|
Requirement
|
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2). |
|
Requirement, Business |
A higher-level statement of goals, objectives, or needs of the enterprise. Developed through enterprise analysis. |
|
Requirement, Functional |
Solution requirement that describes behavior |
|
Requirement, Non-functional |
Solution requirement that describes a condition that does not directly relate to behavior. "Quality of Service" |
|
Requirement, Solution |
Describes the characteristics of a solution that meet business requirements and stakeholder requirements. Developed through requirements analysis. |
|
Requirement, Stakeholder |
A statement of the needs of a particular stakeholder of class of stakeholders. Developed through requirements analysis. |
|
Requirement, Transition |
Capabilities that the solution must have in order to facilitate transition from the current to a desired future state. Developed through solution assessment and validation. |
|
Requirement Attribute |
Metadata related to a requirement |
|
Requirement Relationship: Cover |
A requirement relationship that exists when one requirement fully includes another requirement. This is a special case of subset, where the top-level requirement is the sum of the sub-requirements |
|
Requirement Relationship: Effort |
A requirement relationship that exists when a requirement is easier to implement if a related requirement is also implemented. |
|
Requirement Relationship: Necessity |
A requirement relationship that exists when one requirement is only necessary if another is implemented. Unidirectional or bidirectional. |
|
Requirement Relationship: Subset |
A requirement relationship that exists when a requirement is the decomposed outcome of another requirement |
|
Requirement Relationship: Value |
A requirement relationship that exists when including a requirement affects the desirability of a related requirement |
|
Requirements Management
|
The activities that control requirements development, including change control, definition, and traceability |
|
Requirements Workshop |
A productive focused event attended by carefully selected key stakeholders and subject matter experts for a short, intensive period to elicit requirements.
Key |
|
Return on Investment
|
A measure of profitability
|
|
Risk
|
An uncertain event or condition that, if it occurs, will effect the goals or objectives of a proposed change |
|
Scenario |
One way that an actor can accomplish a particular goal
Key |
|
Scope, Project |
The work that must be performed to deliver a product, service, or result |
|
Scope, Solution |
The set of capabilities a solution must deliver in order to meet a business need. |
|
Service |
Work carried out on behalf of others |
|
Sequence Diagram |
A sequence diagram shows how classes and objects interact during a scenario. The sequence diagram shows how objects used in the scenario interact but not how they are related to one another. |
|
Solution |
Meets a business need |
|
Span of Control |
The number of employees a manager is directly or indirectly responsible for |
|
Sponsor |
Stakeholder who Initiates the effort, authorizes work, controls the budget |
|
Stakeholder |
A person who has interests that may be affected by an initiative or influence over it. |
|
State Diagram |
An analysis model showing the life cycle of a data entity or class |
|
Stereotype |
A relationship between use cases
|
|
Stimulus |
A message in a Sequence Diagram that flows between objects, resulting in an event |
|
Structured Walkthrough |
A peer review of a deliverable |
|
Supplier |
External stakeholder who provide products or services |
|
SWOT Analysis |
A SWOT analysis is a valuable tool to quickly analyze various aspects of the current state of the business process undergoing change. |
|
System |
A collection or interrelated elements that interact to achieve an objective |
|
Timeboxing |
Prioritize requirements, using a fixed number of units of time
Task-Specific |
|
Tester |
Stakeholder who determines how to verify the solution meets the solution requirements, plus conducts the verification process |
|
Use Case |
Describes all possible outcomes of an attempt to accomplish a particular goal that the solution will support.
Key |
|
User Story |
Actor, action, achievement |
|
Validation
|
The work done to ensure that the stated requirements support and are aligned with the goals and objectives
|
|
Variance Analysis |
Analysis of discrepencies between planned and actual performance |
|
Verification |
The work done to ensure that requirements are defined correctly and are of an acceptable level of quality. |
|
Vision Statement |
A brief statement that describes the why, what, and who of desired software product from a business point of view. Identifies key stakeholders and describes the impact that meeting the business need will have on them. |
|
Voting |
Prioritize requirements, stakeholders get a fixed number of tokens to distribute
Task-Specific |