Business Analysis Guidebook/Glossary
Business Analysis Glossary
A[edit | edit source]
A type of flowchart, part of the UML standard, that depicts activities, their sequence, and the flow of control.
Analysis paralysis An informal phrase applied to when the opportunity cost of decision analysis exceeds the benefits. In software development, analysis paralysis manifests itself through exceedingly long phases of project planning, requirements gathering, program design and modeling, with little or no extra value created by those steps.
An artifact is one of many kinds of tangible by-products produced during the development of software.
As-is modeling Refers to gathering information about the current state of the business area being analyzed; e.g., current processes and data.
Assumptions and Constraints Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
B[edit | edit source]
Business Analyst or Business Analysis
BA Bok Business Analysis Body of Knowledge
BA-COP Business Analysis Community of Practice
BA CoE Business Analysis Center of Excellence
BP/LL Best Practices/Lessons Learned
BRD Business Analysis Requirements Document
Business analysis Business analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.
A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.
Business area A naturally cohesive group of activities that share data and may cross organizational boundaries.
Business case The first document completed during project initiation; it contains the analysis and results of business assessments providing the justification to pursue a project opportunity.
Business process improvement Analyzing a business process to increase its efficiency and effectiveness; identifying and eliminating causes of poor quality, process variation, and non-value-added activities.
Business requirements Higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things as the reason a project was initiated and the things the project will achieve.
Business requirements document The document or artifact that captures gathered requirements and serves to communicate them.
C[edit | edit source]
A suggestion that might be a good thing to do.
Context diagram Represents the entire system as if it were a single process; often used to determine a system boundary or solution scope with stakeholders or SME’s.
Customer The business units at all levels of the organization that identified the need for the product or service the project will develop.
D[edit | edit source]
Data flow diagram
Graphical representation of the flow of data through a manual or automated information system which Illustrates the processes, data stores, and external entities in a business or other system and the connecting data flows.
Data model A model showing data requirements of a business area. An Entity Relationship Diagram is a common type of data model.
E[edit | edit source]
The process of drawing requirements from stakeholders and SME’s.
F[edit | edit source]
A service a solution provides to meet a need. Typically high-level abstractions of solution that will turn into functional or non-functional requirements. They allow for early prioritization and scope management, and for getting a high-level sense of the stakeholders view of the solution.
What the systems/products are, do, or provide from the customer’s point of view.
- G -
- H -
J[edit | edit source]
Joint application development
- K -
- L -
- M -
N[edit | edit source]
Requirements that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have.
O[edit | edit source]
An approach to business or software engineering in which components are made up of encapsulated groups of data and functions which can inherit behavior and attributes from other components, and whose components communicate via messages to one another.
P[edit | edit source]
Pains and pleasures
Pain – something that is currently causing frustration, lack of productivity, poor quality, etc. Pleasure – something that is currently working well. It would be good to continue it.
Product scope The functions or features that characterize a product or service.
The work that must be done to deliver a product with the specified features and functions.
Q[edit | edit source]
QC Quality control
R[edit | edit source]
Conditions or capabilities needed by a stakeholder to solve a problem or achieve an objective.
RFP Request for proposal
RFQ Request for quotations
Requirements work plan Documents the requirements activities a business analyst will perform on a particular project, what deliverables they will produce, and how they will control and manage changes to the deliverables.
S[edit | edit source]
Planned dates for performing activities and for meeting deliverables.
Scope Creep Gradual addition of new requirements to the original product specifications.
SDLC Software development life cycle
Subject matter expert (SME) A person expert in the particular business area being analyzed. SME’s are often the primary source of requirements for a business analyst.
Solution Something that fills a business need. Solutions do not always involve automation; they could involve streamlining a business process, etc.
Statement of work A narrative description of products or services to be supplied under contract.
Stakeholder Individuals and organizations that are involved in, or may be affected by, project activities.
T[edit | edit source]
Refers to analyzing and documenting the potential future state of the business area being analyzed; processes, data, activities, how the activities would be accomplished.
Traceability The ability to map solution components and requirements backward and forward through the development cycle.
U[edit | edit source]
Unified modeling language (UML)
An object-oriented modeling language governed by the Object Management Group (www.omg.org).
Use case diagram An analytical tool consisting of text and models that describes the tasks a system will perform for actors, and the goals the system achieves for those actors along the way.
User acceptance testing User Acceptance Testing is typically the final phase in a software development process in which the software is given to the intended audience to be tested for functionality. UAT is also called beta testing, end-user testing or application testing.
V[edit | edit source]
Reviewing requirements to ensure they are correct.
W[edit | edit source]
Work breakdown structure
Workflow model Describes the tasks, decisions, inputs and outputs, people and tools involved in a specific process.
- X -
- Y -
- Z -