Term
|
Definition
UML - relationships between things, such as actors and use cases.
Other common uses are for relationships between classes in a data model. |
|
|
Term
|
Definition
| Factors considered true without proof. BABOK mentions that scope and requirements are affected by scope, assumptions, constraints, and dependencies. |
|
|
Term
|
Definition
| Individual facts about an entity or class. Each attribute has a specific data type and it usually has constraints on the values they can accept. |
|
|
Term
| Attributes, Common Requirements |
|
Definition
| Complexity - How hard Absolute Reference - Unique ID Risks - related to meeting or not meeting the req Author Source - used to specify or approve req Status - Proposed, Accepted, Verified, or Implemented Ownership - who needs the req or the business owner Urgency - When req is needed, only specified separately from the priority when implementation deadline exists Priority - which to implement first Stability - how mature the requirement is |
|
|
Term
|
Definition
| Point established as a reference or checkpoint against which req changes are measured. Approved reqs are baselined |
|
|
Term
|
Definition
| Technique for comparing an organization to its peers and competitors to assess relative strengths and weaknesses. |
|
|
Term
|
Definition
| Technique that promotes divergent thinking, to produce a broad or diverse set of options. It works best by focusing on one problem or issue |
|
|
Term
|
Definition
| Requirements prioritization technique that chooses work based on a budget or fixed deadline, including regular software upgrades. Requirements are prioritized based on what can be accomplished with the available resources, using one of three general approaches. |
|
|
Term
|
Definition
| "Is the 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 to organization to meet it's goals." |
|
|
Term
| Business Analysis Approach |
|
Definition
| Describes the overall process that will be followed to perform business analysis work on a given initiative, how and when tasks will be performed, the techniques that will be used, and the deliverables that should be produced. |
|
|
Term
|
Definition
| "May include information such as a description of the scope of work, the deliverable Work Breakdown Structure, and Activity List, and estimates for each activity and task. It should also describe when and how the plan should be changed in response to the changing conditions. The level of detail associated with the plans is determined by the business analysis approach and the overall methodology" |
|
|
Term
| Business Analysis Planning and Monitoring |
|
Definition
| The tasks and outputs for planning and organizing requirements activities and for monitoring business analysis work to ensure it produces desired outcomes |
|
|
Term
|
Definition
| "Any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysts must analyze and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analysts responsible for eliciting the actual needs of the stakeholders, not simply their expressed desires. |
|
|
Term
|
Definition
| Business operations grouped by functional accountability, business activity, and economic activity. It purpose is to align strategy and execution around the important activities of a business and to create a framework for planning and managing. |
|
|
Term
|
Definition
| Facilitates decision-making by providing information useful for evaluation whether to find projects to solve problems or seize opportunities. They provide justification for projects based on benefits provided vs. costs of generating. |
|
|
Term
|
Definition
| Task Definition: "The business case describes the justification for the project in terms of the value to the be added to the business as a result of the deployed solution, as compared to the cost to develop and operate the solution. |
|
|
Term
|
Definition
| Documents the current state of a problem (also called a problem domain or "As Is") or the extent of a solution (the "To Be" state). Domain models help align the "mental models" of stakeholders and project team members. |
|
|
Term
|
Definition
| Describes a broad target that a business aims for to support its strategy and vision. For example, "increase customer satisfaction levels with the ordering process". |
|
|
Term
|
Definition
| Description of a problem or opportunity and the desired out in terms of benefits or desired state. Once needs are agreed on they guide any recommended solution and business case. |
|
|
Term
|
Definition
| Describes a specific stat or condition the business strives for to support its goals and vision. For example, "reduce customer complaints on late deliveries over the next year by 20%". |
|
|
Term
|
Definition
| "Higher level statement of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objective that the project will achieve, and the metrics that will be used measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis. |
|
|
Term
|
Definition
| Describes a policy, guideline, standard, or regulation upon which the business operates. A Business Rule is a statement that defines or constrains some aspect of the business, and transcends any given project. |
|
|
Term
|
Definition
| A specialized technique for identifying and assessing business rules for comparison of changes needed to meet business needs. |
|
|
Term
|
Definition
| The capacity for accomplishing goals or objectives. The BOK addresses capabilities in terms of the gap between current and desired states in the organization. |
|
|
Term
|
Definition
| Process of controlling changes to the requirements of the systems development component, process improvement, and/or organization change project, in a controlled manner. |
|
|
Term
|
Definition
| A UML method of depicting entities in a solution set, including its attributes, operation and relationships. A class represents a distinct concept within the solution domain, which may represent a physical item or a logical collection of information. |
|
|
Term
|
Definition
| Diagrams showing a set of related classes that exist within the solution domain and the associations that each class has with other classes. |
|
|
Term
|
Definition
| Bring stakeholders to a common understanding of requirements. Task Definition: "Includes conversations, notes, documents, presentation, and discussions. Concise, appropriate, effective, communication requires that business analyst possess a significant set of skills, both soft (communication) and technical (i.e. requirements). |
|
|
Term
| Communication Plan, Business Analysis |
|
Definition
| A plan for what, to whom, and how to communicate about your requirements on a project. It sets the expectations for communications about business analysis among stakeholders. |
|
|
Term
| Communication Plan Considerations |
|
Definition
| * Who is the appropriate audience? * What needs to be communicated? * What is the appropriate delivery mechanism? * When the communication should occur? |
|
|
Term
| Communication Plan Stakeholder Needs |
|
Definition
| * Geographic location * Communication Preferences * Types of Communication needed * Types of Requirements to be elicited * How best to communicate requirements Packages * Time and resource constraints GPC RPT |
|
|
Term
|
Definition
| The KA that covers fundamental competency information not found int eh BABOK, bu BAs are expected to know this information. |
|
|
Term
|
Definition
| Structured process that assesses strengths, weaknesses of current and future competitors based on key characteristics of an industry. It supports SWOT analysis by helping to identify opportunities and threats. |
|
|
Term
|
Definition
| Group of related primitive or detailed data elements recorded in the Data Dictionary. |
|
|
Term
|
Definition
| That BOK term for an entity or class, as the idea is more commonly used. Represents an abstract person, place, thing, process or event for which data is desired. |
|
|
Term
|
Definition
| Managing changes to the features and functions of a product throughout its life, including documenting them. |
|
|
Term
|
Definition
| An imposition on a project that limits choices a project team can make. Typical categories include business, technical, and external. |
|
|
Term
|
Definition
| In scope modeling, a visual depiction of a solution's scope showing a system, external agents (people, other systems, or events) who interact with it, and high-level data flowing into and out of the system. |
|
|
Term
|
Definition
| A change taken to address a problem indicated through performance or other measures. |
|
|
Term
|
Definition
| Commercial Off-the-Shelf Package |
|
|
Term
|
Definition
| For tracing requirements, a coverage matrix is used to manage trace-ability. It can be used to cross reference requirements with other things, such as back to project objectives, or forwarded to test cases. The BOK mentions this tool is used there are relatively few requirements or features to trace. |
|
|
Term
|
Definition
| Create, Read, Update, Delete matrices. Associates user access rights to data. It can also be used to cross-reference data to process to ensure completeness and relevance. |
|
|
Term
|
Definition
| Defines the data used or needed by an organization, including primitive and more complex data definitions. It will usually be elaborated into more detailed models such as a Class Model or Entity Relationship Diagram. |
|
|
Term
|
Definition
| A technique that shows the context of the data that flows into processes, out of them, and is stored by the system. |
|
|
Term
|
Definition
| A technique for depicting the data requirements for a solution using what the BOK calls "concepts" (entities or classes) and the relationship or associations between them, and the attributes they contain. |
|
|
Term
|
Definition
| A technique that explored the important aspects of a decision when there are a limited number of alternatives, such as a choice of business analysis approaches. |
|
|
Term
|
Definition
| Breaking down something higher-level into simpler subsets for the purpose of studying or analyzing it. This technique is often presented using graphical models. |
|
|
Term
|
Definition
| A flaw in a deliverable that either lessens its quality, or causes it to vary from its preferred characteristics. Defective requirements may include: incorrect, incomplete, missing, or incomplete. |
|
|
Term
|
Definition
| Documents or diagrams specified by a process that shows the output of a project or project phase. Includes all outs from business analysis that are agreed-upon "products". |
|
|
Term
|
Definition
| Identify logical relationships, such as which activities have to be completed before subsequent tasks can begin. |
|
|
Term
|
Definition
| Identifies the "lineage" of a requirement by tracing back to the business need, typically by identifying the business or project objective that the requirement supports. |
|
|
Term
|
Definition
| A technique that collects requirements for a an existing ("As-Is") system by studying and summarizing available documentation. It gathers details of a current system in two broad categories: 1) Business Documentation, 2) System Documentation |
|
|
Term
|
Definition
| "The area undergoing analysis. It may correspond to the boundaries of an organization or organizational unit, as well as key stakeholders outside those boundaries and interaction with those stakeholders." |
|
|
Term
|
Definition
| Bring out or draw out requirements, through actively engaging stakeholders. It is done throughout the project and the various elicitation techniques are interconnected. Includes the tasks of "P"repare for Elicitation, "C"onduct Elicitation Activity, "D"ocument Elicitation Results, and "C"onfirm Elicitation Results. PCDC |
|
|
Term
|
Definition
| This Knowledge Area (KA) is focused on actively engaging stakeholders to define requirements. This KA includes details for eliciting requirements for a solution. |
|
|
Term
|
Definition
| Stakeholders, users, subject matter experts who will be providing their requirements. Elicitation is highly dependent on the knowledge of the stakeholders, their willingness to participate in defining requirements, and the group's ability to reach consensus. The business analyst must be certain to include all defined stakeholders during elicitation of requirements. |
|
|
Term
| Elicitation Technique - Document Analysis |
|
Definition
| A means to elicit requirements of a an existing ("As-Is") system by studying available documentation and identifying relevant information such as business rules, entities and attributes. |
|
|
Term
| Elicitation Technique - Interview |
|
Definition
In-depth questioning, producing information that eventually becomes requirements. BABOK describes 2 kinds: 1) Structured - predefined and specific questions
2) Unstructured - ad hoc questions, and generally open ended |
|
|
Term
| Elicitation Technique - Prototype |
|
Definition
| "Mock ups" of screen or report layout for a proposed system, to elicit requirements for it. Paper-and-pencil or electronic. Aim is to uncover and visualize interface requirements before the application is designed or developed. |
|
|
Term
| Elicitation Technique - Observation |
|
Definition
Studying people performing their jobs in their work environment. BABOK mentions 2 types:
1) Passive/Invisible - Observing without questioning
2) Active/Visible - Asking questions and being visible |
|
|
Term
| Elicitation Technique - Focus Groups |
|
Definition
| A means to elicit ideas and attitudes about a specific product, service, or opportunity in a an interactive group environment. The participants share their impressions, preferences, and needs, guided by a moderator. |
|
|
Term
| Elicitation Technique - Requirements Workshops |
|
Definition
| A structured way to capture requirements in a group setting. A workshop may be used to scope, discover, define, prioritize, and reach closure on requirements for the target system. |
|
|
Term
| Elicitation Technique - Interface Analysis |
|
Definition
| Interface analysis is conducted to determine from stakeholders which interfaces (external parties, systems or devices, etc.) are needed. More analysis is needed to uncover details. |
|
|
Term
| Elicitation Technique - Brainstorming |
|
Definition
| A technique that uses the creative powers of ta group to generate many ideas quickly to help solve a problem or resolve an issue. |
|
|
Term
| Elicitation Technique - Survey/Questionnaire |
|
Definition
| A means of eliciting information from many people, anonymously, in a relatively short time. Can collect a broad spectrum of requirements quickly about a subject. |
|
|
Term
|
Definition
| KA Definition - Provides a context for other requirements activities and to identify viable solutions to meet business needs. It helps evaluate current and future states of an organization grasp the changes needed to help it meet its goals and achieve its objectives. |
|
|
Term
|
Definition
| Describes major current and future domains needed to run an organization that integrate into a complete framework. It includes both the organizational (people, processes, operations) and technical (software, hardware, IT) dimensions. |
|
|
Term
|
Definition
| A business object, representing a person, place, thing, process, or event. Used with Entity-Relationship Diagrams (ERDs). |
|
|
Term
| Entity Relationship Diagram |
|
Definition
| Visual representation of a data structure, and includes entities, attributes, and relationships between entities. |
|
|
Term
|
Definition
The process of projecting the time and costs of doing work and delivering a product/solution. The BOK mentions these types of estimates of their enablers to be familiar with:
1) Analogous estimates (top down)
2) Parametric estimates
3) Bottom up estimates
4) Rolling wave estimates
5) Three point estimates
6) Historic analysis
7) Expert judgement
8) Delphi estimates |
|
|
Term
|
Definition
| An external, internal, or temporal occurrence in the business to which the business responds with a process. Events can initiate, interrupt, or terminate a process, and exist outside the process. |
|
|
Term
|
Definition
| Elicitation that occurs in a single event. Includes the techniques of brainstorming, focus group, interview, observation, prototyping, requirements workshops. They need ground rules for maximum success. |
|
|
Term
|
Definition
| Help discover processes by finding business events and their corresponding triggers. Events are used in other techniques. For example see Scope Modeling. |
|
|
Term
|
Definition
| Used to determine the optimal business analysis approach. Expertise may be provided from a wide range of sources including stakeholders in the initiative, organization Centers of Competency, consultants, or associations and industry groups. |
|
|
Term
|
Definition
| In use case modeling, a relationship that extends functionality of a use case at pre-determined "extension points". The BOK disagrees with other descriptions, saying the extending of use case is independent of the base use case it is extending. They equate extend relationships with an alternate flow described in a separate use case for convenience. |
|
|
Term
|
Definition
Someone who guides an elicitation session. Facilitators have the responsibility to:
* Establish a professional and objective tone for the meeting
* Enforce discipline, structure, ground rules for the meeting, and above all keep focused on them.
* Manage the meeting and keep the team on track.
* Facilitate a process of decision making and build consensus, but avoid participating in the content of the discussion.
* Ensure that all stakeholders participate and hear their input.
* Ask the right questions, analyze the information being provided at the session by the stakeholders, and follow up with probing questions, if necessary. |
|
|
Term
|
Definition
| An initial study to determine whether a solution is viable to accomplish a desired income, whether its to solve a problem or to seize and opportunity. |
|
|
Term
|
Definition
| A grouping of related functionality or services that should align with business goals and objectives and meet stakeholder needs. Features contain one or more associated functional on non-functional requirements. |
|
|
Term
|
Definition
| The direction or path of a process. Flows document the primary and alternate paths of a process, and can split at decision points and potentially later merge back together. |
|
|
Term
|
Definition
| Visual image of the work performed in an organization, including who does it and how they collaborate. |
|
|
Term
|
Definition
| A type of diagram used in problem analysis for determining possible causes of business problems. The problem to be solved is places as the "head" of the "fish" and possible causes and sub-causes are the "bones". |
|
|
Term
|
Definition
| A focus group is a technique used to gather qualitative input about a problem, opportunity, product, system, etc. It can be useful when many ideas need to be generated quickly, especially concerning attitudes and beliefs about a product. |
|
|
Term
|
Definition
| A visual way of showing opposing forces that support and oppose a change. The forces for each side are grouped together pointing toward the middle. An estimate of the strength of each opposing force can help with change management. |
|
|
Term
|
Definition
| Identifies the high level functions of an organization or proposed solution and then breaks down those processes into sub-processes and activities. |
|
|
Term
|
Definition
| "Functional Requirements describe the behavior and information that the solution will manage. They describe the capabilities they system will be able to performing terms of behaviors or operations - specific information technology application actions or responses." |
|
|
Term
| Ground Rules (Event Based Elicitation) |
|
Definition
| For event based elicitation, ground rules must be established for maximum success. They establish a code for conduct for the even an allow the facilitator to enforce discipline if need be. Stakeholders should agree to form and frequency of feedback, and for how to approve on the final results. |
|
|
Term
|
Definition
| In process modeling, a formal passing of a process flow from one role to another, often done along with inputs or outputs. |
|
|
Term
|
Definition
| In use case modeling, a relationship that provides access from one or more use cases to shared functionality in a separate use case. It may be an incomplete use case, and the uses cases that refer to it are dependent on it. |
|
|
Term
|
Definition
| To be a compelling force on or produce effects on others. Proactively shift thinking, actions and even emotional states of other people. |
|
|
Term
|
Definition
| A connection between two components, whether people or systems. |
|
|
Term
|
Definition
| A technique that helps define boundaries of a system by defining the interface to users, other systems, or system components that provide functionality, inputs, and outputs. |
|
|
Term
|
Definition
| A technique that involves systematic questioning of stakeholders to learn about their needs, root causes of them, and stakeholders' requirements. Interviews may be formal or informal, structured on unstructured, and by individual or group. |
|
|
Term
|
Definition
| Typically used by BAs to represent the functional requirements. |
|
|
Term
|
Definition
| A technique that compiles things that both went well and could be improved on projects or project phases. Includes generating preventative actions, done to improve future performance. |
|
|
Term
| Maintain Requirements for Re-Use |
|
Definition
| Task Definition - "Manage knowledge of requirements following their implementation. Identify requirements that are candidates for long-term usage by the organization. These may include requirements that an organization must meet to on an ongoing basis, as well as requirements that are implemented as part of a solution." |
|
|
Term
| Manage Business Analysis Performance |
|
Definition
| Task Definition: "To manage the performance of business analysis activities to ensure they are executed as effectively as possible. This task covers determining which metrics will used to measure the work performed by the business analysis. It includes how to track, asses, and report on the quality of the work and take steps to correct any problems that may arise. |
|
|
Term
| Manage Requirements Traceability |
|
Definition
| Task Definition: "Create and maintain relationships between business objectives, requirements, other team deliverables, and solution components to support business analysis or other activities." |
|
|
Term
| Manage Solution Scope and Requirements |
|
Definition
| Similar to scope management in project management, this task is concerned with obtaining approval for initial scope, and managing changes to scope throughout a project. |
|
|
Term
| Maslow's Hierarchy of Needs |
|
Definition
Physiological, Safety, Love/Belonging, Esteem, Self Actualization
PSLES |
|
|
Term
|
Definition
| Information sent between objects in a sequence diagram shown as an arrow between objects. The sequence diagram shows the stimuli flowing between objects. Messages become stimuli that trigger actions and are called events in UML. |
|
|
Term
|
Definition
| Data about data, such as ranges or other constraints on attribute values, code values, volumes of data instances, etc. |
|
|
Term
|
Definition
| A standard of measurement, often associated with a goal or the performance of something. It is usually associated with a single point in time. |
|
|
Term
| Metrics and Key Performances |
|
Definition
| A technique for measuring progress and performance. Metrics are meant to measure business performance, like their name implies. Key Performance Indicators measure progress on strategic goals. |
|
|
Term
|
Definition
| "Represent significant events in the progress of a project. Milestones are used to measure the progress of the project and compare actual progress to earlier estimates. Milestones can be used to as a time to celebrate completion or delivery of a major deliverable or section project work. An example of a major milestone is the stakeholders' and sponsor's formal approval of requirements documents" |
|
|
Term
|
Definition
| A template for representing requirements that may combine textual elements, matrices, and diagrams. Serves as an abstraction which represents some or all of the proposed solution. |
|
|
Term
|
Definition
Models can be selected on the categories:
Processes
User Classes, Profiles, or Roles
Rules
Entities (Concepts) and Relationships
Events
PUREE |
|
|
Term
|
Definition
| A requirements prioritization technique using an acronym to divide requirements into four categories: Must have, Should have, Could have, Won't have |
|
|
Term
|
Definition
| "Broadly speaking is an interaction of influences. Such interactions, for example, include the process of resolving disputes, agreeing upon courses of action, bargaining for individual or collective advantage, or crafting outcomes to satisfy various interests. Negotiation involves two basic elements: the process and substance. |
|
|
Term
| Non Functional Requirements |
|
Definition
| "Non functional requirements capture conditions that do not directly relate to the behavior or functionality of the solution, bu rather describe environmental conditions under which the solutions must remain effective or qualities that the system must have. These can include requirements related to capacity, speed, security, availability, and the information architecture and presentation of the user interface." |
|
|
Term
| Non Functional Requirement Types |
|
Definition
Performance Efficiency (PE) - Response time, processing time, throughput, resource utilization
Reliability - Whether system is available when needed. Also includes recoverability (ability to recover from crashes)
Maintainability - How well can be changed to meet future needs
Compatibility - requirements for operating within current system environment
Operability - Specifies that the application functions the way users want and expect
Security - Protecting and restricting data
Transferability - Being able to install and use an application in multiple eviroments |
|
|
Term
| Object Orientated Modeling |
|
Definition
| Views Info Management systems as a collection of classes that pass messages to one another, and which contain both data and the operations used to create and modify those attributes. Data and processes are not modeled separately. |
|
|
Term
|
Definition
| A technique used to elicit requirements by watching people in their natural work environment. This technique is useful as an adjunct to other elicitation methods; e.g. to fill in gaps. |
|
|
Term
|
Definition
| One of the two aspects the BABOK lists as a business need. It is the potential for adding something beneficial to the business, usually in the form of a new product, market or service. |
|
|
Term
|
Definition
| The cost of not using funds for alternative investments. It happens on projects when non-validated requirements get implemented because alternative solutions could have been invested in. |
|
|
Term
|
Definition
| A technique to depict the structure of an organization, its functions, and its people. It shows the "scope" of organization units, the relationship between people of that unit, their roles, and how they interface with other units. |
|
|
Term
| Organizational Process Assets |
|
Definition
| "All materials used by groups within an organization to define, tailor, implement, and maintain their processes." Can include: elements of existing business analysis approaches used by the organization, corporate governance standards, templates. |
|
|
Term
|
Definition
| Based on the Logical Model but are modified to represent the implementation of the solution in a specific technology environment. |
|
|
Term
| Plan Business Analysis Activities |
|
Definition
| Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables. |
|
|
Term
| Plan Business Analysis Communication |
|
Definition
| Describes the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications. |
|
|
Term
| Plan Requirements Management Process |
|
Definition
| Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope. This task determines the appropriate requirements management process for a particular initiative. |
|
|
Term
|
Definition
| In process modeling us BPMN (Business Process Modeling Notation) pools are broad boundaries an may group multiple swim lanes. Common pools are external customers, the internal organization, external vendors, etc. |
|
|
Term
| Prepare Requirements Package |
|
Definition
| Task Definition: "Select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups. This task describes the work required to decide which format(s) are appropriate for a particular project and its stakeholders." |
|
|
Term
|
Definition
| A proactive change made to prevent a possible problem from occurring. |
|
|
Term
|
Definition
| A detailed data element that is grouped with related elements into a Composite element in a Data Dictionary. |
|
|
Term
|
Definition
| The main or simplest scenario that actors follow to accomplish their goal in a use case or business process model. |
|
|
Term
|
Definition
| A technique to ensure problems get resolved in a timely manner and not forgotten. It should also find root causes of problems, to minimize their recurrence. |
|
|
Term
|
Definition
| A series of business steps, performed to accomplish a goal, done in response to a trigger, and which transform inputs to outputs. |
|
|
Term
|
Definition
| A technique for visually documenting work performed in an organization, including who does it and how they collaborate. Process models can be used to discover requirements, inputs/outputs, document the BA approach, and uncover stakeholders. |
|
|
Term
|
Definition
| Another name for scope of the deliverables to be produced by a project, including their features and functions. |
|
|
Term
|
Definition
| PMI Definition: A temporary endeavor undertaken to create a unique product or service. |
|
|
Term
|
Definition
| The work that must be done to accomplish outcomes. |
|
|
Term
|
Definition
| A technique that produces quick and early feedback about requirements using a visual mock up of an interface. Can be "horizontal" for navigation or "vertical" for details. |
|
|
Term
|
Definition
| A matrix for recording stakeholder roles/responsibilities. Stands for Responsibility, Accountability, Consult and Inform |
|
|
Term
|
Definition
| In data modeling, visually shows the significant business connections between two "concepts" (entities or classes). |
|
|
Term
|
Definition
| A place or method for storing or retrieving things. May be short or long term storage. |
|
|
Term
|
Definition
A requirement is:
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 system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3) A documented representation of a condition or capability as (1) or (2). |
|
|
Term
|
Definition
| Describes how stakeholder and solution requirements are analyzed, modeled, and specified for use in the construction of a solution. Objective: define and describe the capabilities of a potential solution to a business problem, so that the project team has a clear understanding of how to design and implement it. |
|
|
Term
| Requirement Analysis Techniques |
|
Definition
These techniques could be used with other KAs, but they are most applicable to Requirements Analysis:
Business Rules Analysis,
Scenarios and Use Cases,
Data Dictionary and Glossary,
Data Flow Diagrams,
Data Modeling,
Process Modeling,
User Stories,
Non-Functional Requirements Analysis,
Scope Modeling,
Sequence Diagrams,
State Diagrams
BUD(3)
PUNS(3) |
|
|
Term
|
Definition
| Describes a set of related functional and non functional requirements. |
|
|
Term
| Requirements Management and Communication |
|
Definition
| Knowledge Area with activities and techniques for managing and communicating requirements throughout the project life-cycle and beyond. An additional task is to record requirements so that the increased knowledge from projects is accessible to assist future work. |
|
|
Term
|
Definition
| Comprehensive requirements document, used for presentation to stakeholders. Requirements may be "packaged" at any point in a project. It facilitates a common understanding of the requirements among all of the stakeholders and documents that understanding for future reference. |
|
|
Term
| Requirements Presentations |
|
Definition
Presentations may be informal or formal. The BA should consult with the Project Manager to ensure that the reason for the presentation is clearly understood. Examples of requirements deliverables for presentation:
* Business Requirements
* Functional Requirements
* Data and process models
* Other "diagrammatic models" |
|
|
Term
|
Definition
Well-written and clear requirements. The BABOK identifies these characteristics: Cohesive, Complete, Consistent, Correct, Modifiable, Unambiguous, Feasible, and Testable.
CCCC MUFT |
|
|
Term
|
Definition
| Project stakeholders verify the accuracy of the requirements |
|
|
Term
|
Definition
| Formalizes agreement by project stakeholders that the content and presentation of the requirements, as documented, are accurate and complete. |
|
|
Term
|
Definition
| An organized arrangement for requirements, including any relationships between them. Similar to, but separate from tracing of requirements. Primarily about how the requirements are organized, which models are used, and relationships (such as dependencies) between requirements. Identifies for stakeholders where a given requirement can be found, and what is scope is. |
|
|
Term
|
Definition
The following classification scheme is used to describe requirements:
* Business Requirements
* Stakeholder Requirements
* Solution Requirements
* Functional
* Non-Functional
* Transition |
|
|
Term
|
Definition
| A technique that elicits requirements in a structured group setting. Can be used for varying uses such as scope, discover, define, review, prioritize, and reach closure on requirements for the solution. Well-run workshops are one of the most effective ways to deliver high quality requirements quickly. |
|
|
Term
|
Definition
| Request for Information - Often a fact finding document, used early in a selection process when the requester is open to a number of possible options. It requests information from vendors about potential solutions to a given need. |
|
|
Term
|
Definition
| Request for Proposal - Used to request proposals to solve a specified business need typically from a small number of potential vendors. The solutions could vary and are part of the proposal. |
|
|
Term
|
Definition
| Request from Quotation - Used to request bids on a specific solution from a number of potential vendors. And RFQ is less formal than a RFP and may be a subset of an RFP. |
|
|
Term
|
Definition
| Events or conditions that could have a positive or negative affect on the objectives or projects. Requirements risks will have an effect on project activities and their estimates, and should be documented. |
|
|
Term
|
Definition
| The process of identifying, assessing, and managing the uncertain areas of a project or business and planning responses to identified risks. |
|
|
Term
|
Definition
| The process of analyzing the probability and impact (probability times impact), with the results of the assessment used to plan risk responses. For example, a Probability of 75% * Impact of 80 (1-100 scale) = a risk ranking of 60, a medium high ranking. |
|
|
Term
|
Definition
Determine the best approach to detail with a given risk, once its been assessed: Mitigate, Avoid, Transfer and Accept - Four risk Responses
MATA |
|
|
Term
|
Definition
| A person's or group's ability to endure risks. The BABOK describes three broad categories: Risk Aversion, Neutrality, and Risk-Seeking. |
|
|
Term
|
Definition
| In process modeling (and other types), the type of person, group, or even a system that participates in a process. |
|
|
Term
|
Definition
| A technique used to uncover the source or "root" cause(s) of business problems. There are several type of analytic tools that can be used, and Fishbone Diagrams and Five Why's are two mentioned in the BABOK. |
|
|
Term
|
Definition
| The extent of a project or solution (product). For solutions, includes things such as features and functions the solution will provide. |
|
|
Term
|
Definition
| One instance of a use case, whether it is a primary or alternate path (or flow) through the use case. |
|
|
Term
|
Definition
| A technique using a graphical depiction of the solution or project scope. Scope models typically show a system, some high-level functionality, and the stakeholders (people, other systems or events) who interact with it. |
|
|
Term
|
Definition
| The person who documents requirements during an elicitation session. They also keep track of issues that were not addressed in the session. |
|
|
Term
|
Definition
| The overall process of designing and developing information systems. The process is typically a multi phase approach beginning with an analysis of initial requirements through the steps of analysis, design, construction, implementation, and eventual maintenance. |
|
|
Term
|
Definition
| A UML diagram and BABOK technique used to model interaction between objects in a system using the sequence of logic for different scenarios. They depict how a use case scenario is executed by the objects of a class diagram, including showing the passage of messages between them. |
|
|
Term
|
Definition
| The term for the output of a proposed or actual project. A solution addresses a business need (problem or opportunity) by changing the current state and is justified with a a business case. |
|
|
Term
| Solution Approach - Define |
|
Definition
| Task Definition: "Describes the general approach that will be taken to create or acquire the new capabilities required to meet the business need. To determine the solution approach, it is necessary to identify possible approaches, determine the means by which the organization is capable of implementing and effectively using a solution of that nature.' |
|
|
Term
| Solution Assessment and Validation |
|
Definition
KA Definition: Ensure that the solution requirements are fulfilled by the technical design and facilitate their implementation.
BABOK Definition: "Describes the tasks that are performed in order to ensure that solutions meet the business need and to facilitate their successful implementation. These activities may be performed to assess and validate business processes, organizational structures, outsourcing agreements, software applications and any other component of the solution." |
|
|
Term
|
Definition
| Describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirements analysis. They are frequently divided into sub categories, particularly when the require describe a software solution: functional and non functional |
|
|
Term
|
Definition
| The deliverables that must be produced to address the business need. Also includes how the solution will affect the business, its operations, and its technology. |
|
|
Term
|
Definition
| Task Definition: "Conceptualize the recommended solution in enough detail to enable stakeholders to understand which new business capabilities an initiative will deliver. The solution scope will change throughout the project, based on changes in the business environment or as the project scope is changed to meet budget, time, quality or other constraints. |
|
|
Term
| Specify and Model Requirements |
|
Definition
The main analysis task, documenting and modeling of requirements using one of four requirement formats: Text, Matrices, Diagrams, and Models
TMDM |
|
|
Term
|
Definition
| A person or group that has a stake or interest in the success of a project. Stakeholders are also important sources for project requirements and can be responsible for one or more project activities or deliverables. |
|
|
Term
| Stakeholder Analysis, Conduct |
|
Definition
| This task covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. |
|
|
Term
|
Definition
| A map that often include lines of communication between stakeholders. Shows the influence of and impact to stakeholders. |
|
|
Term
|
Definition
| BABOK definition: "Stakeholder requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements server as a bridge between business requirements and various classes of solution requirements. They are developed and defined through requirement analysis." |
|
|
Term
|
Definition
| A technique that diagrams various "states" that an entity/class goes through during its lifetime. Transitions move an entity from stat to state based on events or other triggers. |
|
|
Term
|
Definition
| In UML, these are so called extensions to UML to create new elements. They are abstractions that apply to things like Use Case relationships (<> and <>) or to Classes (e.g., <>). |
|
|
Term
| Story Boards/Screen Flows |
|
Definition
| Shows navigation paths between interface components. Provide an early mock-up of proposed business solution functionality. |
|
|
Term
|
Definition
| Structured Analysis views a system primarily as a collection of processes executed by the system, and analysis is therefore process-centric. Another characteristic of this approach is a focus on data that is an input and output from these processes. Data and processes are generally modeled separately. |
|
|
Term
|
Definition
| A technique that uses formal sessions to "communicate, verify and validated requrments." |
|
|
Term
|
Definition
| The time and effort already invested into a project to date. Sunk costs often influence stakeholder into avoiding canceling a project or eliminating an existing solution because of not wanting to "waste" the investment. |
|
|
Term
|
Definition
| A technique that allows collecting a large amount of both qualitative and quantitative information from people, i a fairly short amount of time. Best used when a large number of responses to a limited set of questions are needed quickly. |
|
|
Term
|
Definition
| Segregated bands on process model diagram that show which roles perform which parts of a process. Flows that cross boundaries indicate the passage of work to another role, and usually involve a "handoff" (input or output). |
|
|
Term
|
Definition
| A strategic planning technique, categorizing and organization's Strengths, Weaknesses, Opportunities, and Threats. Also useful for a framework for opportunity analysis, competitive analysis, and business and product development. |
|
|
Term
|
Definition
(Wikipedia) Systems thinkers consider that:
* A system is a dynamic and complex whole, interacting as a structured, functional unit
* Information flows between the different elements that compose the system
* A system is a community situated within an environment
* Information flows from and to the surrounding environment via semi permeable boundaries |
|
|
Term
|
Definition
| In process modeling, visually show a beginning or end point. Often associated with events. |
|
|
Term
|
Definition
| A requirements prioritization technique that fits work into a fixed "box" of time such as 2 weeks or 90 days. Requirements are then prioritized based on the most important requirements that can be accomplished in the time box. |
|
|
Term
|
Definition
| The ability to track a requirement through the development life cycle. It should be bi-directional, to trace requirements backwards to the business need for them, and forward through implementation. Traceability also covers the relationship of requirements to each other. |
|
|
Term
|
Definition
| Relates one set of elements to another set. For example, requirements can be traced to the high-level product description, or test cases can be traced to specific requirements. |
|
|
Term
|
Definition
Requirements for temporary capabilities in or to transition from an existing to a new solution.
KA Definition: "Capabilities that the solution must have in order to facilitate transition from the current stat of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirement types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined." |
|
|
Term
|
Definition
| Unified Modeling Language, as specified by OMG (Object Management Group). It represents a a set of modeling standards for analysis techniques mentioned in the BABOK including Activity, Class, Use Case, State and Sequence Diagrams. |
|
|
Term
|
Definition
| ISO Definition: The extent to which a product can be used by specified users to achieve specified goals with effectiveness efficiency and satisfaction in a specified context of use. |
|
|
Term
|
Definition
| A modeling technique that combines 1) a graphical system overview showing actors, use cases, and their interfaces 2) written descriptions that detail the interactions between actors and the system. |
|
|
Term
|
Definition
| Written series of steps performed by actors or by the solution (i.e., system) that enable an actor to achieve a goal. |
|
|
Term
|
Definition
| A visual representation of the system and its boundaries. They display use cases in scope of the solution, and show which actors interact with the use cases with the solution. Diagrams can also show relationships between use cases and also between actors. |
|
|
Term
|
Definition
| Logical grouping of users by type or classification. |
|
|
Term
|
Definition
| Descriptions that system functionality requirements at a high, narrative level. Written by users, the intent is to establish user ownership requirements. They contain the user role, their goal, and their motivation for the functionality. |
|
|
Term
|
Definition
| Ensures requirements support and implement the business requirements from the Business Case or discovered during Enterprise Analysis. In other words, to validate that the stakeholder, solution, transition requirements meet business needs. |
|
|
Term
|
Definition
| The difference between a planned, budgeted, or expected result, and the actual result. |
|
|
Term
|
Definition
| A technique to evaluate and assess the potential of vendors to meet their commitments when called on to provide products or services for a solution or parts of one. |
|
|
Term
|
Definition
| Ensures requirements are defined clearly enough to allow solution design and implementation to begin. To measure whether they are correctly defined, apply quality standards. |
|
|
Term
| Work Breakdown Structure (WBS) |
|
Definition
| A project planning technique that hierarchically breaks down deliverables and/or activities and tasks of a project into manageable pieces. A WBS can break a project into iterations, phases or releases. It can also can divide deliverables into smaller units called "work packages". |
|
|
Term
|
Definition
| Documents, notes, diagrams, etc. that are by products of a project, and used to record and organize information and help in analyzing requirements. |
|
|
Term
|
Definition
| Visual representation of the flow of work in a business area. |
|
|
