Categories: Uncategorized
Tags: analyst, communication, education
Starting a new project, joining a new company or settling into a new role always has its fair share of acronyms to nut out and key words to become familiar with. The world of business analysis is no different. We asked our Redvespa consultant team to pull together a list of the common BA terms they use every day – a great list for new BAs, project teams and any BAs needing a refresher.
Have we missed some? Let us know by leaving a blog comment.
BA Acronyms
BABOK - Business Analysis Body of Knowledge (reflects current generally accepted practices)
CBAP – Certified Business Analysis Professional (professional certification for BAs with at least 7500 hours of hands-on BA experience)
CCBA – Certification of Competency in Business Analysis (professional certification for BAs with at least 3750 hours of hands-on BA experience)
IIBA – International Institute of Business Analysis (independent non-profit professional association for BAs)
BA – Business Analyst
BI – Business Intelligence (business information and business analysis that lead to decisions and actions and that result in improved business performance)
BPMN – Business Process Modelling Notation (an international standard for drawing process maps and building models)
CM – Change Manager
COTS – Commercial Off The Shelf (typically software)
DFD – Data-flow diagram (dynamic modelling technique that shows how data is shared among the various activities and entities in a system)
PIV – Post Implementation Verification – testing conducted after implementation to ensure that the changes have been accepted into the production environment
PM – Project Manager
RACI – Responsible, Accountable, Consulted, Informed (a framework for assigning stakeholder responsibilities)
RFI/RFP – Request For Information/Request For Proposal (standard business process to collect written information about the capabilities of various suppliers)
RMP – Requirements Management Plan – a document that defines how a project’s requirements will be managed. This includes requirements change controls and traceability.
ROI – Return On Investment (performance measure used to evaluate the efficiency of an investment)
RUP - Rational Unified Process (iterative software development process framework)
SDLC – Software Development Life Cycle (process of creating or altering an information system)
SME – Subject Matter Expert (a person who provides many important requirements, and in certain situations, may need to approve requirements)
SWOT – Strengths, Weaknesses, Opportunities, Threats (SWOT analysis is an extremely useful tool for understanding and decision-making for all sorts of situations in business and organisations)
UAT – User Acceptance Tests – tests executed by a select group of end users to ensure that the delivered system is acceptable.
UML – Unified Modelling Language (general-purpose modelling language in the field of object-oriented software engineering)
WBS – Work Breakdown Schedule (deliverable-oriented, hierarchical decomposition of project elements that defines the total work scope of the project)
BA common terms
Baseline requirements – a list of requirements that have been approved at a specific point in time, they are often used as the basis for future requirements.
Business architecture - part of the enterprise architecture that shows the structure of the enterprise (that is, divisions, locations, etc.) and its product or service strategy.
Business case – a document that captures the benefits and costs of the proposed project.
Business process mapping – pictorial presentation of a process.
Business process modelling – usually attaching numbers/flow information to a map at a most basic level.
Business process management – an enterprise view and governance of the approach and results.
Business requirements - stated from the viewpoint of the business function and using that terminology (also known as a High Level Requirement).
Business risk – eventualities that could threaten the project; positive (opportunities) or negative impacts the project could have on the business.
Business rules – static modelling technique that looks at the rules governing business processes and decisions (regulation, company policy, etc.).
Cause-and-effect diagram – combines brainstorming and concept mapping to identify and consider a range of causes and impacts relative to a problem; also referred to as a fishbone diagram or an Ishikawa diagram.
Critical path – the longest path through the project network; the sequence of activities that defines the minimum time required to complete the project.
Cost/benefit analysis – technique focused on the identification of the associated costs and the related benefits.
Defect – an error in requirements caused by incorrect, incomplete, missing or conflicting requirements (also known as a software bug).
Document analysis – requirement elicitation method that studies available documentation to leverage existing material; can be time-consuming and often information may be out of date.
Domain – the area or business unit that you are working in.
Elicitation – techniques used to extract requirements information from people, as well as from other sources.
Enterprise analysis – one of six knowledge areas identified by the BABOK; analysing needs and opportunities from the overall organisational perspective and recommending projects to improve specific business processes and systems.
Functional design – observable behaviours of the solution; as opposed to technical design.
Functional requirements – define what the system must be able to do; describe both the systems behaviour in detail and the information the system will manage.
Interface – a point in which a system or systems interact and communicate with a user.
Gap analysis – understanding the differences between two or more states of play, two or more applications, two or more sets of data etc, and making recommendations based on this understanding.
Modelling – representations of a business or solution that often include a graphic component along with supporting text and relationships to other components.
Non-functional requirements – a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours.
Prototype – a mock up of the proposed solution which can be used to demonstrate the flow of screens, it can range from a paper prototype through to a working mock up. Often used to verify requirements prior to development.
Scope – identifies the boundaries for a piece of work and sets the expectations for the project team and stakeholders as to what will be delivered.
Scope creep - changes that occur during a project that are neither recognised, evaluated, nor approved.
Sponsor – the stakeholder(s) responsible for funding the project, they often make the final decision when stakeholders can’t agree.
Stakeholder - people or organisations that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project, or who can exert influence in project decisions.
Traceability – information that shows stakeholders the relationships between individual requirements and their sources; allows a BA to manage scope creep and ensure all requirements have been met.
Use-case - a list of steps, typically defining interactions between a role (known in UML as an “actor”) and a system, to achieve a goal. The actor can be a human or an external system.
User story – usage-modelling technique that is similar to use case descriptions, but with much less detail.
Validation – checking requirements to be sure that they are correct, complete, and feasible.
Verification – checking requirements to ensure that they have been written and specified well; should be done before validation.
Workflow models – dynamic modelling technique that diagrams the flow of activities among responsible parties.
References
- A Guide to the Business Analysis Body of Knowledge, Version 2.0
- www.en.wikipedia.org
- Global Knowledge Training LLC – “A Business Analyst’s Glossary for Project Management Terminology”
2 comments
biranchi kumar parhi May 21, 2012 at 9:56 PM
Before Prototypes comes the Wire frame which the skeleton of how the product/website would look like. These are non-click able presentation of how the product/website is suppose to look like. Generally we elaborate functional requirements and Quality team writes test cases based on these wire frames created and included in Functional requirement document.
Blair (Luvleyday) May 25, 2012 at 11:33 AM
Missing my favourite, Cluster = really bad situation