Business Analysis Guidebook/Glossary
Business Analysis Glossary
A
[edit | edit source]Activity diagram
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.
Artifact
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]BA
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.
Business analyst
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]Candidate solution
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]Elicit
The process of drawing requirements from stakeholders and SME’s.
F
[edit | edit source]Features
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.
Functional requirements
What the systems/products are, do, or provide from the customer’s point of view.
- G -
- H -
- I-
J
[edit | edit source]JAD
Joint application development
- K -
- L -
- M -
N
[edit | edit source]Non-functional requirements
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]Object-oriented modeling
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.
Project scope
The work that must be done to deliver a product with the specified features and functions.
Q
[edit | edit source]QA
Quality assurance
QC
Quality control
R
[edit | edit source]Requirements
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]Schedule
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]To-be modeling
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]Validate
Reviewing requirements to ensure they are correct.
W
[edit | edit source]WBS
Work breakdown structure
Workflow model
Describes the tasks, decisions, inputs and outputs, people and tools involved in a specific process.
- X -
- Y -
- Z -