d
| Term | Description |
|---|---|
| decision analysis | An approach to decision making that examines and models the possible consequences of different decisions, and assists in making an optimal decision under conditions of uncertainty. |
| decomposition | A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components. |
| defect | A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality. |
| definitional business rule | A rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge, or information. Also known as a structural rule. |
| deliverable | Any unique and verifiable work product or service that a party has agreed to deliver. |
| design | A usable representation of a solution. For more information see Key Terms (p. 14) and Requirements and Designs (p. 19). |
| document analysis (business analysis) | An examination of the documentation of an existing system in order to elicit requirements. |
| domain | The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem. |
| domain subject matter expert | A stakeholder with in-depth knowledge of a topic relevant to the business need or solution scope. |
| DSDM | See dynamic systems development method. |
| dynamic systems development method (DSDM) | A project delivery framework which focuses on fixing cost, quality, and time at the beginning while contingency is managed by varying the features to be delivered. |
e
| Term | Description |
|---|---|
| elicitation | Iterative derivation and extraction of information from stakeholders or other sources. |
| end user | A stakeholder who directly interacts with the solution. |
| enterprise | A system of one or more organizations and the solutions they use to pursue a shared set of common goals. |
| enterprise architecture | A description of the business processes, information technology, people, operations, information, and projects of an enterprise and the relationships between them. |
| enterprise readiness assessment | An assessment that describes the enterprise is prepared to accept the change associated with a solution and is able to use it effectively. |
| entity-relationship diagram | A graphical representation of the entities relevant to a chosen problem domain and the relationships between them. |
| estimate | A quantitative assessment of a planned outcome, resource requirements, and schedule where uncertainties and unknowns are systematically factored into the assessment. |
| evaluation | The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time, and to identify ways to improve the solution to better meet objectives. See also indicator; metric, monitoring |
| event (business analysis) | An occurrence or incident to which an organizational unit, system, or process must respond. |
| evolutionary prototype | A prototype that is continuously modified and updated in response to feedback from stakeholders. |
| experiment | Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact. |
| external interface | An interaction that is outside the proposed solution. It can be another hardware system, software system, or a human interaction with which the proposed solution will interact. |
f
| Term | Description |
|---|---|
| facilitation | The art of leading and encouraging people through systematic efforts toward agreed-upon objectives in a manner that enhances involvement, collaboration, productivity, and synergy. |
| feasibility study | An evaluation of proposed alternatives to determine if they are technically, organizationally, and economically possible within the constraints of the enterprise, and whether they will deliver the desired benefits to the enterprise. |
| feature | A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders. |
| fishbone diagram | A diagramming technique used in root cause analysis to identify underlying causes of an observed problem, and the relationships that exist between those causes. Also known as an Ishikawa or cause-and-effect diagram. |
| focus group | A group formed to elicit ideas and attitudes about a specific product, service, or opportunity in an interactive group environment. The participants share their impressions, preferences, and needs, guided by a moderator. |
| force field analysis | A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces, depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces. |
| functional requirement | A capability that a solution must have in terms of the behavior and information the solution will manage. |
g
| Term | Description |
|---|---|
| gap analysis | A comparison of the current state and desired future state of an enterprise in order to identify differences that need to be addressed. |
| goal | See business goal. |
| governance process (change) | A process by which appropriate decision makers use relevant information to make decisions regarding a change or solution, including the means for obtaining approvals and priorities. |
h
| Term | Description |
|---|---|
| horizontal prototype | A prototype that is used to explore requirements and designs at one level of a proposed solution, such as the customer-facing view or the interface to another organization. |
i
| Term | Description |
|---|---|
| impact analysis | An assessment of the effects a proposed change will have on a stakeholder or stakeholder group, project, or system. |
| implementation subject matter expert | A stakeholder who has specialized knowledge regarding the implementation of one or more solution components. |
| indicator | A specific numerical measurement that indicates progress toward achieving an impact, output, activity, or input. See also metric. |
| initiative | A specific project, program, or action taken to solve some business problem(s) or achieve some specific change objective(s). |
| input (business analysis) | Information consumed or transformed to produce an output. An input is the information necessary for a task to begin. |
| inspection | A formal review of a work product by qualified individuals that follows a predefined process, and uses predefined criteria, for defect identification and removal. |
| interface | A shared boundary between any two persons and/or systems through which information is communicated. |
| interoperability | Ability of systems to communicate by exchanging data or services. |
| interview | Eliciting information from a person or group of people in an informal or formal setting by asking relevant questions and recording the responses. |
| Ishikawa diagram | See fishbone diagram. |
| iteration (business analysis) | A single instance of progressive cycles of analysis, development, testing, or execution. |
k
| Term | Description |
|---|---|
| knowledge area (business analysis) | An area of expertise that includes several specific business analysis tasks. |
l
| Term | Description |
|---|---|
| lessons learned process | A process improvement technique used to learn about and improve on a process or project. A lessons learned session involves a special meeting in which the team explores what worked, what didn’t work, what could be learned from the just-completed iteration, and how to adapt processes and techniques before continuing or starting anew. |
| life cycle | A series of changes an item or object undergoes from inception to retirement |
m
| Term | Description |
|---|---|
| matrix | A textual form of modelling used to represent information that can be categorized, cross-referenced, and represented in a table format. |
| metadata | A description of data to help understand how to use that data, either in terms of the structure and specification of the data, or the description of a specific instance of an object. |
| methodology | A body of methods, techniques, procedures, working concepts, and rules used to solve a problem |
| metric | A quantifiable level of an indicator measured at a specified point in time. |
| mission statement | A formal declaration of values and goals that expresses the core purpose of the enterprise. |
| model | A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding. |
| monitoring | Collecting data on a continuous basis from a solution in order to determine how well a solution is implemented compared to expected results. See also metric; indicator. |
n
| Term | Description |
|---|---|
| need | A problem or opportunity to be addressed. |
| non-functional requirement | A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole. |
