Business Analysis Guidebook/Glossary

From Wikibooks, open books for an open world
Jump to navigation Jump to search

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 -