Business Analysis Key Terms

A Business Analysis key terms glossary

8/80 Rule A common rule within project management, it states that the smallest item in the scope decomposition should take no more than 80 hours and no fewer than 8 hours of labor to create. It prevents requirements packages from being too large or too small to manage.
A Guide to the Business Analysis Body of Knowledge (BABOK) The BABOK book is published by the IIBA and supports and defines the business analysis role, processes, and generally accepted practices of the community. The CBAP examination is based largely on the BABOK.
Absolute reference A requirements attribute where each identified requirement will have its own unique identifier that’s used only once within the project. If a requirement is removed from the project, so too is the absolute reference of the requirement.
Acceptance criteria This requirements attribute defines the conditions that prove the requirement has been delivered.
Action plan This business analysis plan defines what the risk responses are and which members of the business analysis team will own which risks.
Active stakeholder The business analyst seeks to understand the reason behind every step in the business process to fully understand the process. Sometimes the business analyst will actually get involved in the work as an active stakeholder to fully understand the process and how the person completes the process.
Activity Based Costing Examines the true cost of any business process the project may invoke. It examines the performance of resources, the activities the resources will complete, and includes the cost-effectiveness of nonhuman resources, such as equipment and facilities.
Agile An SDLC (System Development Life Cycle) methodology that uses quick execution; daily meetings; isolated, protected developers; and adaptability to changes. The model uses small increments of planning and execution of the requirements. The benefit of this model is that the team can quickly create deliverables for the project stakeholders. The downside of this model is that an early mistake can cause huge ramifications and rework throughout the project.
Allocation ready Refers to the requirement that can be allocated to a phase, portion, or area of the project where it can be readily created. A requirement that can’t be allocated usually is a sign that the requirement is too vague.
Alternate solutions More than one choice for a solution that may satisfy the project requirements.
Alternative identification An approach to consider all of the available and possible solutions and then to pare down the solutions to the most likely and feasible options.
Analytic Hierarchy Process This approach uses both qualitative (subjective) and quantitative (in-depth) analysis for each solution to compare and contrast each solution based on a series of comparisons.
Application architect This role defines the technical direction for the project solution, creates the architectural approach, and serves as project expert for the project solution structure.
Application areas Software-driven solutions for workstations, servers, mobile devices, and the Internet.
Appraisal Review of a team member’s work performance and contribution to the business analysis duties.
Approval requirements Identify who will need to sign off on the project scope, project documents, costs, and schedules of the deliverables.
Assume To assume the risk is to accept the risk. This business analysis risk response is an acceptance of the risk event and is used when the identified risk event is particularly low in probability and impact.
Assumption Anything that you believe to be true, but you’ve not proven to be true.
Attainable A requirements attribute that documents the feasibility for the current project—that it can be created, implemented, and supported by the organization. It is possible for a requirement to be technically attainable but not feasible for the current project based on the work, time, cost, or other factors the requirement would demand.
Audit requirements Projects may require data about the data they produce in case they’re audited by an outside agency. This “data about data” is called metadata, and while it’s a pain in the neck to create and consider, it’s required for consistency and often by law, depending on the industry the project is taking place in.
Author of the requirement This requirements attribute simply defines the individual who demanded or is the author of the requirements.
Author peer reviewer This person completes peer review of the requirements documentation to ensure that it meets the quality expected by the organization and inspects the requirements documentation for completeness. The author peer reviewer is often another business analyst.
Avoid Avoid the risk by changing processes and activities to circumvent the risk event.
Balanced scorecard A management approach that tracks and grades financial performance, customer satisfaction, internal processes, and enterprisewide learning and innovation.
Barrier Anything that prevents communication from occurring at optimum levels.
Benchmarking Benchmarking compares two or more systems, states, services, products, or things to determine the best viable choice.
Benefit/cost ratio (BCR) models Examine the benefit-to-cost ratio.
Bidders conference A meeting of all the vendors and the buyer to review the SOW (Statement of Work) and the procurement document. This is an opportunity for the bidders to ask questions about the project and for the buyer to clarify as needed.
Black box reverse engineering Examines the structure and workings of a system without physically breaking down its internal structure.
Brainstorming session A facilitated meeting with a group of stakeholders to attack a problem or opportunity with as many ideas as possible. The term “brainstorm” was created by advertising guru Alex Osborn in 1939.
Budget estimate Based on the details of the project scope but it is somewhat unreliable. It has a range of variance of –10 percent to +25 percent on average.
Business analyst An individual who identifies the business needs of the organization’s clients and stakeholders, helps determine solutions to business problems, and completes requirements development and requirements management. The business analyst also facilitates communications among clients, project stakeholders, and the defined solutions team.
Business architecture The intangible structure that constitutes a business entity. It is the culture, enterprise environmental factors, business structure, and policies that guide and direct the selection, funding, and management of programs and projects.
Business case A document that reports on the value that the business will gain by investing in the initiative.
Business Domain Model A visual representation of how the business does or should work with regard to the project requirements. It defines each business process that is affected by the project, how the process should work, and how the process interacts with other processes, functions, and project-affected users in the organization.
Business process analysis A solution development methodology that examines and documents how the work is currently done in comparison to how the work should be done once the solution has been created. Business process analysis is also known as business process mapping, business process reengineering, business process transformation, and business process modeling.
Business Process Description Defines the project at a high level of what the project should create. This document includes a summary of the current business model, all of the known user requirements, and any of the functional requirements that have been defined.
Business process model Sometimes called an activity model, this captures all of the activities within a business, the inputs and outputs of each activity, and the required resources to complete each activity.
Business process reengineering This approach studies the current flow of business processes, looks for strength, weaknesses, opportunities, and threats (SWOT), and considers everything from minor adjustments to entire new designs to investigate improvements.
Business Requirements Document A snapshot of the requirements documentation that will serve as the requirements scope baseline (synonymous with Specification System Requirements Document). This document clearly defines the behavior of a project solution for the customers and end users. It’s most commonly used for software development projects, and it’s based on the business requirements defined early in the business analysis activities.
Business scenarios A hypothetical situation that portrays how the organization processes are to operate. Business scenarios can depict typical operations, planned processes, and responses to situations when things don’t go as planned.
Business sponsor An individual who has the positional power and decision-making ability to launch new projects and organizational initiatives, and to grant resources to business analysts and project managers.
Buy-versus-build decision A financially driven approach to determine which solution is the most cost-effective for the project. This approach also evaluates other factors, such as employee time, efficiency, and support to make the best decision for purchasing or creating a solution.
Cause-and-effect diagram Sometimes called a fishbone or Ishikawa diagram, it can help facilitate root cause analysis. The diagram can be massive, as each contributing factor must be reviewed to determine what things, events, and processes may be contributing to it. In most cases, a combination of contributing factors creates the problem the organization is experiencing.
CBAP Code of Ethical Conduct and Professional Standards An IIBA document that defines the expected ethical and professional standards for all CBAPs.
Certified Business Analysis Professional (CBAP) An individual who has the required education, professional development, and work experience, and who has proven it by passing a business analysis exam governed by the International Institute of Business Analysis.
Class model Demonstrates the attributes, operations, and relationships to entities within the solution. Classes are physical resources, solution concepts, a collection of data, a function of the solution, or an action.
Closed-ended questions Used in interviews and surveys, these questions can gain specific information, be multiple-choice answers, or provide yes or no answers.
Closing The final project management process group, where the project’s phase or entire scope has been completed, and the project manager performs administrative closure. This includes sign-off from the customer on the scope validation, final findings, and then the project manager archives all of the project documentation.
Coaching Helping other people think about the actions they’re required to do in order to achieve the things they want in their life. Through activities, conversations, interviews, and exercises, coaches help people realize what it is they want to do in their personal and professional lives, and then inspire those people to take action to accomplish their goals.
Coercive power When the project team believes the project manager can punish them for poor performance in the project, they may feel coerced into doing their assignments.
Communications formula The formula N(N – 1)/2, where N represents the number of project stakeholders. It shows the number of communication channels in the project.
Communications management plan This plan defines who needs what information, when it is needed, and in what modality the stakeholders are expecting the communication. This plan can set requirements and conditions, such as cost and schedule variances, within the project that will prompt communication.
Communications Requirements Matrix Identifies the stakeholders and their communication interactions with other stakeholders.
Competitive analysis This is a marketplace study to determine the feasibility of a proposed solution as compared with competition.
Complete A requirements attribute that documents that the requirements are fully defined, which means that all constraints, assumptions, potential risks, attributes, and conditions of the project are documented.
Completing the Solution Assessment and Validation This business analysis knowledge area works with the project manager, technology team, project team, and stakeholders to analyze the detailed design documents. You’ll define the logical phases of the project, the technical design, and the quality assurance activities.
Complexity This requirements attribute defines the scale, complexity definition, or overview on how difficult the requirement will be to implement.
Component business model This is the most common business model and was formulated by IBM. It provides a direct and traditional view of an enterprise, providing nomenclature to lines of business, functional units, departments, groups, and other organizational resources.
Compromising Requires that all parties in the conflict must give up something. The decision made is a blend of both sides of the argument. Because neither party really wins, it is considered a lose-lose solution. The business analyst can use this approach when the relationships are equal and no one can truly “win.”
Configuration management requirements Configuration management is the documentation, control, and management of the features and functions of the project deliverable. Configuration management defines the product scope and what the customer can expect as a result of the project work.
Conflicting requirements When two or more requirements conflict in scope, time, cost, or objective. Conflicting requirements should be documented in the Requirements Issues Log, and a conflict resolution process should begin. Updates to the resolution should be documented in the issues log as well.
Consistent A requirements attribute where the requirement meshes with all of the other requirements in the project. You may find inconsistent requirements when a key stakeholder is forcing a particular requirement into the project as a mandate.
Constraint Anything that limits your option. Time and cost limits are examples of constraints.
Contingency plan Should a risk event become an issue, then there should be a contingency action, sometimes called a correction action, to respond to the issue. The contingency plan also defines what the risk triggers are.
Continuing Development Units (CDUs) CBAPs must earn 60 CDUs per three-year cycle to maintain their CBAP status. CDUs can be earned through education, professional activities, and professional development.
Control chart A quality control chart to track trends in project execution.
Correct A requirements attribute where the requirements describe the functionality that is to be created by the project. The author of the requirements is the individual who must fully define the correctness of the project requirement.
Cost benefit analysis Measures the early known cost and benefits to create a cost benefits ratio of each potential solution. The cost benefit ratio will be elaborated during the business case creation.
Cost management plan Defines how the project will be estimated, budgeted, and how changes to cost will be managed.
Cost of conformance to quality These are expenses that must be spent to achieve the expected level of quality by the organization. Consider training, correct materials, additional resources, and in some instances safety, inspections, and compliance issues. This is also known as the cost of conformance to requirements.
Cost of nonconformance to quality These are the costs of not conforming to the expected level of quality. For example, if the project team doesn’t have the correct training, then the project may take longer to complete, cost more due to errors and omissions, and customers may reject the deliverables.
Cost of nonconformance to requirements Monies that an organization will pay in fines, lawsuits, loss of sales, and loss of customers should they not achieve the expected quality in the project. Consider a project that does not provide the project team with the proper safety tools or training. If someone gets injured, then there’ll be repercussions. These costs also include time delays, waste of materials, loss of team morale, and poor deliverables.
Cost variance reports Whenever there is a variance in the project cost, the project manager should create a cost variance report. This report explains what the cost variance is, why the variance has occurred, and what the project manager is doing to prevent the problem from occurring again.
COTS Examines in-house creation versus a commercial off-the-shelf (COTS) solution.
Crashing Adding labor to a project to reduce the project’s duration. Crashing adds costs because of the expense of added labor.
Critical path The longest path in a project network diagram to project completion. No delays are allowed on the critical path, or the project will be late for delivery.
CRUD Matrix This is a table that uses the acronym CRUD to define the level of access that resources have to an information system. CRUD stands for Create, Read, Update, or Delete. It’s the permissions assigned to resources for system information.
Current state assessment Part of the feasibility study to determine the current status of the organization. An understanding of the current organizational status can be compared with the desired future status of the company.
Data dictionary Describes the data used by the system. The data dictionary defines the name of the data, data aliases, values and meanings, and description of the system data.
Data flow diagrams The type and traffic of information within the organization is captured and displayed.
Database analyst This role designs, creates, and maintains databases for the project.
Database areas Include database servers, data management, data security, and accessibility.
Decision Analysis This statistical reasoning approach allows the study team to measure and compare the probabilities of each identified solution outcome.
Decision tables A matrix that illustrates the logic of decisions and leads the study team to a recommended option based on the qualifiers the table identifies and the initial feasibility study requirements for the proposed solution.
Decoder The device that decodes the message as it is being received.
Defect repair validation The inspection of the work that has been repaired to ensure that it reaches or exceeds the quality expectations the project manager and the customer will have of the solution.
Definitive estimate Based on the WBS (Work Breakdown Structure). The definitive estimate is the most accurate cost estimate, but it requires the WBS to create; it has a typical range of variance from –5 percent to +10 percent.
Deliverable A document that clearly identifies the project deliverables the customer is expecting and that the project is to produce for the stakeholders.
Dependent task This task cannot start until other tasks are completed; this is sometimes called a successor task.
Developer This role is the technical resource within the project and may serve as a designer, tester, coder, application developer, or other job title. Developers help plan the operational transfer of the deliverable to the user.
Document analysis A requirements elicitation technique that examines current documentation of project, product, organization, service, or process to help determine how these things could become better or contribute to the existing business problem solution or opportunity.
Domain modeling Domain modeling charts the area of organization that’s under construction, analysis, or creation so that all stakeholders can visualize the areas that are affected.
Effort-driven activities The more effort you apply to the activity, the faster the job will get done.
Encoder The device that encodes the message to be sent.
End user The recipient and user of the project’s deliverables.
Endorsed Education Provider (EEP) Educational providers, such as training centers or colleges, that have paid a fee to the IIBA to have their materials reviewed and endorsed by the IIBA as being accurate business analysis courses. EEPs may provide professional development courses and seminars that offer continuing development units.
Enhancing This risk response seeks to modify the size of the identified opportunity. The goal is to strengthen the cause of the opportunity to ensure that the risk event does happen. Enhancing a project risk looks for solutions, triggers, or other drives to ensure that the positive risk will happen so the rewards of the risk can be realized by the performing organization.
Enterprise analysis The business analysis activities that help define and identify business opportunities for an organization.
Enterprise environmental factors Part of the business architecture, the definition of the policies, procedures, and rules that project managers and employees must follow. Enterprise environmental factors are unique to each organization.
Enterprise governance group A committee of organizational leaders that ensures groups, functional departments, projects, and other members of the organization are following the established organizational rules, procedures, and business directives of the organization.
Entity relationship diagram This is a visual mapping of the system’s data, its input and outputs, and its relationship to the enterprise. The entity relationship diagram links the data to operations such as customers, invoices, accounts payable, and products. It can visualize the whole organization and the relationships among the organization: customers, suppliers, vendors, employees, management, and resources like data, facilities, and equipment. This is an ideal model to capture communication requirements and channels within an organization.
Environment impact analysis Each option is measured for its impact on the environment in consideration of culture, compliance, regulation, and laws.
Evolutionary prototype Sometimes called a working prototype, an operating prototype that will eventually evolve into the delivered solution. Each addition to the system evolves it another step until it reaches the complete scope of requirements and the project is closed.
Execution The third project management process group, where the project plans are executed. The project manager ensures that the work is done with quality, that the project team are completing their assignments, and that the outcomes of the work are documented.
Executive sponsor Responsible for the project funding, go/no-go decisions, resource support, and approves schedules, budgets, and chief decisions. This role may also be known as the solution owner, project sponsor, or champion.
Executive team These people constitute the organization’s upper management who create the vision, leadership, direction, strategy, and tactics for the organization.
Expert power This power exists when the project team and stakeholders recognize the project manager as an expert in the discipline the project centers on.
Explicit knowledge Documentation, written instruction, charts, graphs, and openly shared information that any business analyst could use in her requirements management activities.
Exploiting Not all risks are bad; some risks you actually want to happen. When you want to take advantage of a positive risk, you exploit the risk. Some examples of positive risk exploitation: adding resources to finish faster than planned, increasing quality to recognize sales and customer satisfaction, and utilizing a better way of completing the project work.
External systems interfaces Links between internal systems and external systems, such as vendors, regulatory agencies, and technical interfaces.
Feasibility study The research of the possible solutions to determine each solution’s likelihood of meshing with the business architecture, the organizational mission, and reaching financial, operational, and technical achievability.
Feasible A requirements attribute where the requirements are confirmed to be feasible for the project to accomplish based on the organization’s resources, competencies, expected budget, and timeline for the project.
Feedback loop A conversation between two or more speakers centering on one specific topic.
First-Time First-Use Penalty States that the first time you try something new, you can’t know how long it’ll take to complete and what the financial impact of the project may be, because you’ve never attempted the activity before.
Fixed duration Activities where it doesn’t matter how much effort you add to the project, it’ll still take a fixed amount of time to complete.
Flowchart A structured analysis chart that shows the flow of information from one process to another.
Focus group A structured, facilitated meeting to gather ideas and to determine opinions and feelings about a product, service, problem, or opportunity.
Forcing When the person in the conflict with the most power forces the decision. The decision made may not be the best decision for the project, but it’s fast. As expected, this autocratic approach does little for relationship building and is a win-lose solution. You know a solution is being forced when someone with seniority or power makes a decision without considering the other parties’ objections and concerns.
Formal power This power, sometimes called positional power, is when a project manager is formally assigned the position of project manager. The project team may recognize the project manager as someone in charge of the project, but not necessarily someone who has any real power on the project.
Formal requirements presentation A structured meeting to review requirements status, changes, and progress. Formal presentations are often hosted by the business analyst for all of the stakeholders to attend.
Formal requirements review A meeting that brings together all of the stakeholders to identify any errors or omissions in the identified requirements. Should no errors exist, requirements sign-off is needed.
Forming When the project team first comes together and team members are getting to know about each other. The group is simply forming based on the needs and competencies the project demands and the availability of the people in the organization to satisfy those needs.
Function Requirements that define how something should behave. Functional decomposition identifies the high-level functions of a system, organization, or service and breaks them down into subfunctions and activities. Functional decomposition ensures that all of the active characteristics of the proposed solution are identified, documented, and can be tracked. Functional decomposition aims to capture all of the processes within the system, software, or service the project is to create.
Functional requirements Define the specific operations and characteristics of a system. The definition of specific components, and expectations for how those components are to operate. These requirements describe how the solution will function, what it will do, and what its expected outcomes are. This is usually a more technical document than the URD (User Requirements Document), but it should mesh with the users’ requirements.
Future value Determine the future value of an amount of funds based on the present value of the funds. The formula for future value is FV = PV (1 + I)n, where FV is future value; PV is present value; I is the interest rate; and N is the number of periods.
Geographical maps Show the physical location of the business units that can help address logistical concerns such as shipping, travel, communication, and IT issues.
Global Balanced Scorecard for U.S. Government A scorecard that measures government agency performance, customer perception, financial and internal responsibilities, and innovation.
Globalization and localization Projects that span multiple countries must consider all of the laws, languages, and cultural issues of each country the project interacts with. You’ll also have to consider time zone issues, languages, and monetary concerns such as the exchange rate.
Gold plating An unscrupulous process of adding extra features that may drive up costs and alter schedules. The project team should strive to deliver what was expected.
Hard logic The identification of activities that must be completed in a particular order.
Hardware areas Include servers, workstations, laptops, and devices like printers, cameras, and peripherals.
Hardware devices interfaces Identification of links between any hardware device that may be affected by the proposed project. Consider servers, workstations, kiosks, and printers.
Horizontal method prototyping A quick, shallow, and wide view of the system without any real functionality behind the prototype. Easy to create, modify, and explain.
Hygiene agents From Herzberg’s Theory of Motivation, these elements are the expectations all workers have: job security, a paycheck, clean and safe working conditions, sense of belonging, civil working relationships, and other basics associated with employment.
Implementation plan Sometimes called the operational transfer plan, it defines how to move the solution from the ownership of the project to operations. The implementation plan should address how the solution will move from the project life cycle into the product life cycle.
Incremental An SDLC method that uses a granular approach for quicker deliverables, easier risk management, and easier change control on the smaller segments of the project work. This approach can also use a series of waterfalls for phases and deliverables rather than one large waterfall model. This model is ideal for large projects.
Independent task This task is not reliant on other activities, and no other activities are reliant on this task completing.
Informal requirements presentations Somewhat structured, but less formal and more conversational in nature.
Information architect This role, sometimes called the data modeler, helps assess the data requirements of a project, identifies data assets, and helps the project team complete data modeling requirements.
Infrastructure analyst This role designs the hardware, software, and technical infrastructure required for the project’s application development, operation requirements, and the project’s ongoing solution.
Initial project risks Any initial risks that have been identified should be referenced and/or recorded here.
Initial Work Breakdown Structure The Work Breakdown Structure (WBS) is a key deliverable in project management, and the initial WBS can help the project manager and project team do more detailed planning, estimating, and risk assessment.
Initiating The first project management process group where the project is charted with a broad vision of what the project is to create. The project manager is named and given autonomy over the feasibility study project.
Integrated change control Project management process of examining all areas of the project and how a proposed change may affect time, cost, scope, quality, human resources, communication, risk, and any procurement issues.
Interface analysis Defines and documents all of the links between two or more components in a system.
Internal rate of return A complex formula to calculate when the present value of the cash inflow equals the original investment.
International Institute of Business Analysis The IIBA is a nonprofit entity headquartered in Toronto, Canada. IIBA aims to develop and propel the business analysis role and career through its mission “to develop and maintain standards for the practice of business analysis and for the certification of its practitioners.” The IIBA is the governing body for the CBAP examination and certification.
Invitation for Bid (IFB) A procurement document from the buyer to seller, where the seller is to provide just a price for the solution.
Issue A negative risk that has come to fruition. Issues are conditions that you’ll have to react to in order to offset the negative impact of the negative risk.
Issue log A document that identifies the attributes of each issue, assigns an issue owner, and tracks the status of the issue.
Issue owner The individual who is closest to the issue and may be tasked with resolving the issue.
Key stakeholders The stakeholders who have decision-making powers over the requirements and the project.
Knowledge management The collection, storage, accessibility, and accuracy of the wealth of information an organization creates.
Known unknowns Conditions and events that will likely go wrong with the project; you just aren’t certain what those things maybe. It’s a way to anticipate risks, issues, and problems that you haven’t clearly identified due to the nature of the project work.
Leadership The alignment, motivation, and inspiration of people to achieve.
Legal requirements Projects and solutions must adhere to the relevant laws. It shouldn’t be a surprise here, but there may be some industry-specific laws the business analyst should consider or seek legal advice on when there’s a question of legality.
Life cycle costing The estimated amount of cost for the organization to support the deliverables the project has created per year, quarter, or whatever period the stakeholders designate.
Logical view The business requirements for the organization, documented, clearly defined, and agreed upon by the project stakeholders.
Market Part of the organizational environment. The condition of the market is an excellent example of an environmental regulation that you have little control over. Market conditions can affect how you buy and sell, price your services and goods, and have an impact on whether the project is even launched or allowed to proceed.
Maslow’s Hierarchy of Needs A hierarchy of needs to identify what people need in their lives and what they work for. There are five different layers: physiological, safety, social, esteem, and self-actualization.
McGregor’s Theory of X and Y States that management believes there are two broad perspectives of workers: good and bad. X is bad; these people need to be watched all the time, micromanaged, and distrusted. Y is considered good. Y people are self-led, motivated, and can accomplish new tasks proactively.
Measurable and testable A requirements attribute that confirms the requirements are not described with subjective, unquantifiable terms and metrics. You’ll need specific tests to measure and show a range of acceptability for satisfying the requirements.
Media The best modality to use when communicating is the one that is relevant to the information that’s being communicated. Some communications demand a formal presentation, where others only warrant a phone call, an ad hoc meeting, or a quick e-mail. The right media is dictated by what needs to be communicated.
Medium This is the device or technology that transports the message.
Meeting management techniques Meetings should have an agenda and order, and someone needs to keep the meeting minutes for the project.
Meeting rules The rules of meeting should be posted, reviewed, and agreed upon before starting. Four simple rules for any meeting are focus, participate, move, and close.
Milestone The significant deliverable of a project phase; it is a timeless project event that shows progress toward completing the project requirements.
Mitigate To mitigate a risk event is to spend more, add time, or take extra steps in the processes to reduce the probability and/or impact of the risk event should it happen. Mitigation is a risk response.
Models A mesh of textual elements, matrixes, and diagrams that present all or a portion of the proposed solution. Models can help stakeholders understand and relate to the requirements more easily than a textual documentation of requirements can.
Moderator The person who actually facilitates the requirements review meeting. This person may be the business analyst, but generally this role is performed by a neutral person who can move the meeting along and stick to the meeting rules. The moderator has the responsibility of ensuring that all participants have reviewed the requirements documentation prior to the start of the meeting and of keeping stakeholders on track during the meeting.
Monitoring and controlling The fourth project management process group, where processes are completed in tandem with project execution. The project work is monitored and controlled.
Motivating agents From Herzberg’s Theory of Motivation, these are the elements that motivate people to excel. They include responsibility, appreciation of work, recognition, the chance to excel, education, and other opportunities associated with work besides financial rewards.
Necessary A requirements attribute that demands all pet requirements, personal agendas, and non-value-added extras be stripped from the project. Each requirement should have value and contribute to meeting defined business goals and objectives as stated in the project charter, vision document, or business case.
Net Present Value Evaluates the monies returned on a project for each period that the project exists; based on the present value formula for each period.
Network areas Include the connectivity and communication among computers, servers, network devices, and telecommunications.
Noise Anything that interferes with or disrupts the message. Anything that distracts you or me from the message is noise.
Nonfunctional requirements Define how a system is supposed to operate. It is the qualities, characteristics, and constraints of any given system.
Norming Once things settle down and leaders, alliances, and acceptance have emerged in the project, the team can go about getting their work done.
Object-oriented analysis of an information system A solution development methodology that dissects a system, specifically an IT system, and shows how information (called messages) is passed from one entity in the system to another. The entities in the system are called classes, and the messages consist of data and information on how the data was created.
Open-ended question Used in interviews and surveys, these questions can’t be answered with a “yes” or “no” and allow the participant to elaborate on the question’s topic.
Organization chart This traditional chart shows how the organization is broken down by department and disciplines. This chart is sometimes called the Organizational Breakdown Structure (OBS) and is arranged by departments, units, or teams. These will show the hierarchical structure of the company and which units of the company are affected by the feasibility study.
Organizational process assets The collection of historical information, templates, processes, procedures, and other documents that support the business analysis duties.
Ownership This requirements attribute defines the business entity or group within the organization that will be the business owner of the requirement once it’s released into production.
Parametric estimate A parameter, such as cost per license or time per installation, that is used to estimate the cost and/or duration of the current project.
Pareto chart A histogram to show the distribution of failures within the project. It shows the categories of defects, range of solution costs, income potential, and other categorization of components from largest to smallest.
Parkinson’s Law States that work expands to fill the amount of time allotted to it.
Passive stakeholder observation Sometimes called invisible observation. When the business analyst observes the stakeholder’s activity without any interaction with the person doing the work.
Payback period The amount of time it takes the project to “pay back” the costs of the project.
Performing This is the ideal state for the project, when all the project team members settle into their roles and go about getting the work done. Petty differences are set aside, and the project team is hard at work accomplishing goals and moving the project toward completion.
Phase A logical grouping of activities that create a deliverable or a set of related deliverables.
Physical view The map of the physical components and structure of the solution. The application developers will then create the physical view, as this information is most specific to what they’ll be creating in project execution.
Planning The second project management process group, where the project is planned based on the determined requirements for scope, time, cost, quality, human resources, communications, risk, and procurement.
POLDAT Technique A requirements gathering and business architecture technique that captures information about processes, organization structure, location, data, applications, and technology.
Political environment Every organization has politics that may influence project decisions. While you may elect not to document these politics directly, consider what individuals may have power over the solution.
Portfolios The organizational management of projects, programs, and undertakings that support the vision, strategy, and tactics of the enterprise. Portfolio management is the measurement, selection, and management of the funds, time, and effort to support the enterprise ventures beyond day-to-day operations.
Predecessor task Other tasks cannot begin until this task is completed, as it precedes them in the order of activities.
Preliminary project scope statement A project initiating document that defines, in broad terms, what the project is to accomplish. This is a document that establishes the boundaries, initial requirements, broad cost and time estimates, and sets the expectations for what the project should do and create for the organization.
Preliminary scope A document that establishes the boundaries, initial requirements, broad cost and time estimates, and sets the expectations for what the project should do and create for the organization.
Present Value A formula that determines the present value of a future amount of money. The present value formula is PV = FV÷(1 + I)n, where FV is future value; PV is present value; I is the interest rate; and N is the number of periods.
Prioritized A requirements attribute that allows each requirement to be assigned a level of priority based on the functional requirements, user requirements, and urgency of the deliverable.
Priority A requirements attribute that defines the order in which the requirements should be implemented. This is particularly useful when creating deliverables in stages for the project customers.
Problem solving A conflict resolution approach that uses a spirit of cooperation among the stakeholders. Problem solving tackles the problem head-on and is the preferred method of conflict resolution. Sometimes this approach is called “confronting” rather than problem solving. Problem solving calls for additional research to find the best solution for the problem, and it’s a win-win solution. It should be used if there is time to work through and resolve the issue. It also serves to build relationships and trust. The business analyst is the facilitator of the problem-solving technique.
Process flow diagram A diagram that captures the inputs and outputs of current (and in some instances, future) processes within the organization.
Process improvement plan This plan defines how the project processes will be monitored and documented for accuracy, efficiency, and improvement.
Procurement management plan When a project needs to purchase materials, services, or other resources, this plan defines the processes and procedures a project manager is to follow within the organization.
Product life cycle The duration of the product in operations. It describes the anticipated duration of the product’s usage, maintenance, and anticipated phasing out of the solution.
Product scope statement This document defines the deliverable the customer is expecting.
Program A program is a collection of projects working together with a common vision to take advantage of benefits that would not be realized if the projects worked independently of each other.
Project A short-term endeavor that will create something unique for the organization. Projects have a definite ending.
Project boundaries The things the project will not deliver.
Project charter A document that authorizes the project to exist within the organization. It should be written by someone with the authority to grant the project manager authority over the resources the project needs to be successful.
Project communications management Project managers, like business analysts, are communicators; projects demand constant communication.
Project cost management The funds that a project requires must be managed, accounted for, and fluctuations in project costs must be communicated.
Project human resources management The management of the project human resources will vary by organization, but it takes people to complete the project work.
Project integration management This special project management knowledge area coordinates the other eight project management knowledge areas.
Project life cycles A project life cycle is the unique life and phases of a project. A project life cycle is unique to each project; for example, the project life cycle of a software development project does not have the same project life cycle as a bridge construction project.
Project management process groups There are five project management process groups that are universal to all projects: initiating, planning, executing, monitoring and controlling, and closing.
Project manager Manages the project management life cycle of a project to ensure that the project team is completing the project work with quality and according to the project objectives and requirements. This role works with the business analyst, executive sponsor, and key stakeholders to gain approval on project deliverables.
Project network diagram A diagram that shows the relationships between activities. Each node in the network diagram represents an activity, and the lines show the predecessors and successors of each activity.
Project phases The incremental progression of the project through logical, work-producing sections of a project. The end of a project phase results in a project deliverable and often coincides with a milestone.
Project procurement management Projects may need to purchase items, hire additional staff, and/or perform work for other organizations through a contractual relationship.
Project quality management Quality management is the assurance that the work is properly planned for project execution and then controlled to ensure the work is completed as it was planned.
Project risk management This knowledge area identifies, documents, and analyzes the project risks in order to create risk responses.
Project scope management This area defines, plans, and controls the project scope based on the business analyst’s requirements.
Project time management Projects require time to do the project work but also to complete the project management activities.
Prototype A basic mockup of what the final project deliverable may look like.
Prototyping This approach creates the highest-risk component of a proposed solution to determine if the solution is feasible in light of the known risk. In other words, the team must create the solution to determine if the actual solution can be created considering the largest known risk.’
Quality According to A Guide to the Project Management Body of Knowledge, quality is a conformance to requirements and a fitness for use. It’s the deliverables, features, and functions that the customer will look at to see how well the features perform and how the solution, as a whole, operates.
Quality assurance (QA) The assurance that the designers, project team, vendors, and any other contributors to the deliverables do their jobs accurately and completely. Contributions to the project scope should map exactly to the project scope—nothing more and nothing less.
Quality assurance analyst This role maps the quality assurance requirements of the organization and the stakeholders to the project, ensures that the project deliverables meet the quality requirements, and works with the project manager and the project team on quality standards compliance.
Quality control (QC) An inspection-driven process that precedes solution assessment, sometimes called scope validation, to detect errors in the project work and make recommendations to correct the errors before the customer sees the deliverable.
Quality management plan If your organization has a quality assurance program, then the requirements of that program will be defined herein; if not, a quality policy will be established for the project, and the quality control and quality assurance expectations will be defined here.
Quality of Service (QoS) Refers to the priority level of applications and how they’ll respond and act on a network. Quality of service is a way to describe the expected level of performance for an application, or in a broader sense, the expectations of reliability for a solution.
RACI chart A chart that defines each role’s participant with the legend of responsible, accountable, consult, and inform for each activity.
Receiver The person who receives the message.
Recorder The person who will record all the comments, suggestions, questions, and prompts for clarification about the requirements document during the formal requirements review meeting.
Referent power This power has a couple of different meanings. First, referent power is when the project manager refers to someone else’s power to push through his project decisions. The second meaning is when the project team members are familiar with the project manager from past work, so there’s already a relationship established between the project team member and the project manager.
Regulations Part of the organizational environment. Your project and proposed solution may have industry regulations that you must adhere to. Consideration of the regulations, even pending regulations, should always be made, as these may hinder or constrain the project’s ability to quickly and cost-effectively meet the identified requirements.
Request for Proposal (RFP) A procurement document from the buyer to seller where the seller is to provide a detailed solution for the buyer. It is often just called an RFP and is part of the procurement process in an organization. It is a request for a vendor to create a fully defined approach for the requirements of the project. It’s a document that asks the vendor to provide a solution for the project—it’s more than just a price request.
Request for Quote (RFQ) A procurement document from the buyer to seller where the seller is to provide just a price for the solution (bids and quotes have the same goal—just provide a price). It is sometimes called an RFQ and asks the vendor to create a price for the already defined requirements.
Requirement elicitation This task determines which stakeholders should be identified as contributors to the requirements gathering process. Based on the stakeholder, type of project, and conditions within the organization, the business analyst will decide which elicitation activities are most appropriate. This is a structured approach to systematically and accurately draw out or confirm the project or opportunity requirements from the project stakeholders and clients.
Requirements analysis and documentation The business analysis activity that defines the modeling and business analysis documentation technique the organization requires. Policies within the organization, business analyst preferences, or industry standards may influence the documentation and modeling approaches the business analyst uses.
Requirements author The person who created the requirements document; typically this is the business analyst. The requirements review meeting can’t happen without this person present.
Requirements communication Communication is a key activity for the business analyst. This activity defines what types of communication, best practices for communication, and the organizational requirements for communication may be. Based on the size of the project, organizational procedures, and requests from stakeholders, the business analyst will document and adapt the communication to what’s best for the project.
Requirements Communication Plan Documents communication requirements for the business analysis activities. It’s a plan to ensure that all of the proper communication channels are identified, documented, and communicated throughout the pre-project activities.
Requirements format The format of and information included in the requirements document; there may be multiple versions of the requirements document, depending on the stakeholders in the project.
Requirements Issue Log Central log to document conflict issues, the attributes of the conflict, the stakeholders involved, and the ramifications of the conflict on the other requirements within the project.
Requirements package The collection of the business analyst’s work results. It is the documentation, formulation, and organization of all the requirements the business analyst has gathered from the stakeholders, packaged in a comprehensive set of project requirements.
Requirements planning and management A business analysis activity that works with the project and organizational stakeholders to determine the required resources to complete the requirements gathering. A business analyst completing these tasks is determining the key roles, managing the requirements scope, and serving as a communicator.
Requirements sign-off The stakeholders signing off on the requirements; demonstrates the stakeholder approval of the identified requirements. Stakeholders can sign off on requirements in ink or electronically—either is acceptable as you’re creating an audit trail of activity.
Requirements traceability A communication process that allows for each project requirement to be traced from its conception in the requirements documentation to its implementation in the project execution phase. Traceability ensures that each requirement is accounted for and its implementation is tracked to execution, costs, and timing.
Requirements Traceability Matrix (RTM) A table that tracks many actions to many requirements of the project. It maps the deliverables to the specific requirements and the verification that the deliverable does or does not satisfy the requirements.
Requirements workshop Sometimes called a Joint Application Design (JAD) workshop, it brings the key stakeholders together to define the requirements for the project. This meeting can be used to clarify the project scope, refine existing requirements, and gain stakeholder consensus on the priorities of the project.
Resource Breakdown Structure (RBS) This hierarchical chart can break down the business problem or opportunity by the type of resources affected by the project. An RBS is an excellent tool for tracking resource utilization, resource costs, and to help formulate questions.
Responsibility Specifies the amount of control a role has over the decision, direction, quality, and accountability of the facets of the project; defines what the role is accountable for.
Responsibility Assignment Matrix (RAM) A RAM chart shows the correlation between project team members and the work they’ve been assigned to complete. A RAM chart doesn’t necessarily have to be specific to individual team members; it can also be decomposed to project groups or units. It’s a table that maps roles to responsibilities.
Reward power When the project team believes that the project manager can reward them for the work they complete on the project, they’ll work accordingly. Reward power is tied to the announcement and ground rules for the project’s reward and recognition system.
Risk An uncertain event or condition that can have a positive or negative effect on the project.
Risk management plan Risks need to be identified, documented, and recorded in the risk register. This plan defines the risk management activities including how risks will be qualitatively and quantitatively analyzed.
Risk response plan There are seven risk responses that a project manager can choose from, and this plan identifies each risk and the appropriate risk response based on the conditions of the project and the attributes of the risk event. The seven risk responses that the risk response plan documents are acceptance, mitigation, transference, avoidance, enhance, exploit, and share.
Risk trigger A warning sign or condition that the risk event is becoming an issue.
Role Defines the function the person plays on the business analysis team or the project team.
Rolling wave planning Uses short bursts of planning and then short sprints of project execution.
Root cause analysis This process investigates causes, contributing causes, and causal factors that are creating the effect to be solved (which may turn out to be a business problem).
Rough order of magnitude (ROM) cost estimate The ROM estimate is a very high-level, unreliable cost estimate that “ballparks” the idea of what the project should cost.
Sapir-Whorf hypothesis Posits that the language a person speaks affects how the person thinks. This theory was created by Edward Sapir and Benjamin Whorf.
Schedule management plan This plan defines how the activity duration estimates will be created, what the project schedule is, and how changes to the schedule will be managed.
Schedule variance reports These reports are generated whenever the project is slipping on the project schedule and provide an explanation of the problem.
Scope management plan Defines how the project scope should be created, decomposed into the WBS (Work Breakdown Structure), executed, monitored, and controlled, and the scope validated.
Scope validation An inspection-driven activity done with the project customer to review and ultimately accept the project deliverables.
Sender The party sending the message is the sender.
Sender-receiver models The flow and rhythm to conversation, formal or informal, composed of feedback loops.
Sharing Sharing a mutually beneficial opportunity between two organizations or projects, or creating a risk-sharing partnership. When a project team can share the positive risk, ownership of the risk is given to the organization that can best capture the benefits from the identified risk.
Six Sigma programs These quality improvement approaches rely on data and statistical analysis to measure accuracy, efficiency, and trend analysis.
Smoothing “Smoothes” out the conflict by minimizing the perceived size of the problem. It is a temporary solution, but can calm relations and boisterous discussions. Smoothing may be acceptable when time is of the essence or any of the proposed solutions will not currently settle the problem. This can be considered a lose-lose situation, since no one really wins.
Soft logic The activities can be completed in any order without affecting the deliverable.
Software Requirements Specification May also be called a System Requirements Specification. This requirements documentation defines the expected behavior and implementation of the software or system the developers will be creating for the project customers. This documentation starts with a definition of the problem domain and the functional requirements that will help create the solution. The document will also include the expected quality of service and will communicate any relevant assumptions or constraints the developers will need to manage as part of the solution.
Solution assessment and validation Once all parties are in agreement on the requirements, then the solution for the requirements can be presented. This activity assesses the proposed solution(s) and validates that the solution can or has met the requirements of the stakeholders.
Solution independent A requirements attribute where the requirements do not define the implementation of the solution but rather only the requirements. The requirements should allow for a broad selection of solution choices, not a specific implementation, resource, or approach.
Solution owner This role approves the project scope statement, phase gate reviews, solution validations, scope changes, and project success criteria. This role may often be the same as the executive sponsor, though sometimes the project customer may serve in this role.
Source This requirements attribute identifies the authorized entity that has the authority to approve requirements and that may need to be involved in the change control process of a project.
Specification System Requirements Document A snapshot of the requirements documentation that will serve as the requirements scope baseline (synonymous with Business Requirements Document).
Spiral An SDLC approach, sometimes called the cinnamon roll, that uses a series of planning, objective determination, alternative identification, and development for the life cycle. It’s ideal for projects that are sensitive to risk avoidance. The downside of this model is that it’s unique for each project and can’t usually be used as a template for future similar projects.
Stability This requirements attribute identifies how stable the requirement is based on its elaboration and supplied detail. At some point the requirement is considered stable enough to start work.
Staffing management plan Defines when the project team members will be brought onto the project, how and when they’ll be utilized on the project, and when they’ll be released from the project.
Stakeholder observation A requirements elicitation approach where the business analyst observes the stakeholder working to determine how the work is actually completed.
Stakeholders This role is fulfilled by anyone who is affected by the outcome of the project deliverables. Stakeholders who make decisions on the project, influence the project requirements, or contribute to the project are sometimes called key stakeholders.
Standards Part of the organizational environment. Standards are guidelines that are usually followed, but you won’t be breaking any laws if you don’t follow them. Your organization may also have standards such as forms, documentation, and processes that must be followed on most projects.
Statement of Work (SOW) A document originating from the buyer to the seller that describes what the buyer is looking to purchase.
Status This requirements attribute is linked to the stability of the requirements, as it keeps track of each requirement and what its current status in the project may be: proposed, accepted, verified, or implemented.
Status report This report communicates how the project is performing overall, what objectives have been accomplished, and what activities are coming up in the project schedule.
Storming As the project team members struggle for power in the project, there may be some conflicts over who’ll lead the project team, who’ll follow the lead, and who’s indifferent as long the project work gets done.
Structured analysis This is a solution development methodology and a software development analysis tool that considers an IT system as a series of processes, and each process contributes to another process within the system. All processes stem from some user interaction. Data is also tracked in structured analysis and is seen as the result of processes and user input.
Structured analysis techniques Methodologies to create systems by using a model to identify the problem, propose solutions, and design a selected solution.
Structured problem-solving techniques Receive and retrieve information within an organization. They keep communication happening, involve stakeholders, and plot out expected responses based on a survey, form, or structured interview.
Structured Systems Analysis and Design Model (SSADM) Classic waterfall methodology, where each phase builds on the work done in the phase prior. SSADM was created in the United Kingdom as a model for developing systems and new applications.
Subprojects A subproject is a smaller project within a larger project. Subprojects are managed as their own project reporting to the project manager of the parent project.
Supplementary quality of service requirements The business analyst and key stakeholders must be in agreement on what the expected level of quality of service for the project deliverable will be.
Supplemental requirements Part of the quality of service requirements that must be considered as part of a project’s requirements, constraints, and quality to meet the expectations of the project customers.
Supply-and-demand A classical interpretation of business, where the amount of supply (high or low) and the demand (high or low) can affect the pricing of the product or service.
Surveys A requirements elicitation technique to quickly gain insight and feedback from a large group of stakeholders. Surveys can be anonymous, or participants could be known for follow-up questions from the survey.
SWOT Analysis The business analysis team can identify the strengths, weaknesses, opportunities, and threats (SWOT) of each requirement to determine if there are risks to be documented.
System Development Life Cycle (SDLC) A generic way of describing the life cycle of an information system and the phases the system goes through.
Systems Standardized process sets within an organization that have identified the flow of activities to reach a desired result. Systems ensure that activities are done the same way, in the same order, every time. They establish a framework for common organizational activities to ensure consistency, thoroughness, and documentation.
Systems thinking An examination of the whole system with the belief that a known symptom is a product of the system as a whole. Actions in one component of a system have effects, even subtle effects, on neighboring components.
Tacit knowledge Assumed information, application by experience, and unstated information. It’s the type of information that a business analyst who’s served for years in the IT industry might take for granted but a new business analyst might crave.
Technology advancement analysis Examines the most recent technical solutions that may be applied to the business problem or opportunity.
Technology architecture diagrams Maps of the topology and relationship of the IT infrastructure.
Test plan Mandatory in most software development applications. Defines how the software will be tested, adjusted, and retested before its release.
Theme Premise of a strategic goal; allows the large organizational goals to be broken down into smaller projects and opportunities.
Throwaway prototype A simple prototype sample that may be just a sketch of the proposed system. It helps the customer and the developer see the system in recognizable components.
Top-down estimate An estimate based on past projects to predict the current cost and/or duration of the current project.
Traceable Each requirement should have the ability to be traced to its origin, owner, and author for additional information and support. Traceable also means that the requirements can be traced to their implementation in the project deliverable. Traceability is useful for audits, quality control, and end-of-project scope validation processes.
Trainer This role works with the project team to understand the deliverables and then teaches the users of the deliverables how to utilize the project’s product. This person may teach, coach, write, and do instructional design to educate the users of the project’s deliverable.
Transference This is the transfer of the risk (and the ownership of the risk) to a third party. The risk doesn’t go away; it’s just becomes someone else’s problem. There’s usually a fee for transference, and great examples include insurance, warranties, guarantees, and fixed-priced contracts with vendors.
Unambiguous A requirements attribute that confirms the requirements documentation is written in such a way that all readers of the requirements documentation arrive at the same understanding of what the requirements demand.
Understandable A requirements attribute for which, like the unambiguous characteristic, the requirements must also be understandable among the project team. Terms, acronyms, and assumptions should be fully defined and explained for the requirements.
Unknown unknowns Unforeseen issues called unknowns that can affect the execution of the project.
Urgency This requirements attribute defines how urgent the requirement is and when the customer needs it to be delivered as part of the solution.
Use case models Captures the business processes by showing how customers, vendors, management, departments, and other enterprisewide stakeholders interact with the business.
User class A categorization of users and how each class will use the solution.
User interfaces People who interact with one another, a system, or data moved between two users.
User Requirements Document Defines what the user expects the solution to do. Users must be in agreement that the business analyst understands and has captured what they want accomplished in the solution.
Utility function The willingness of a person or organization to accept risk. The higher the utility function, the more willing the person or organization are to accept risk.
Verifiable A requirements attribute that provides evidence of completion by testing, examining, or demonstrating its existence upon completion. Each requirement must be verified upon delivery to confirm the completeness of the deliverable.
Vertical method prototyping An approach that creates an in-depth analysis, deep prototype of just one portion of the system’s functionality. Can be costly and time-intensive, but proves the functionality of a system’s key processes.
Vision document A vision document is a high-level view of the project solution. It defines a “vision” of what the project is to create for the organization. Vision documents are ideal for projects that will go through rounds of planning and where the project scope is defined through iterations.
Waterfall An SDLC (System Development Life Cycle) methodology that divides the project into phases. The project manager focuses on control of time, cost, and scope. Intense documentation happens throughout the creation of the software or system. The waterfall approach is not the fastest or most flexible approach, but it does work. A new project team or teams that shift in resources often subscribe to this approach.
WBS dictionary The WBS dictionary is a companion document to the WBS (Work Breakdown Structure) and reflects all of the work packages in the WBS. The WBS dictionary defines all of the components of the WBS, the required resources, and references any information that can explain the deliverable in more detail.
White box reverse engineering Decompiles the software to see how it works by examining the actual coding of the software.
William Ouchi’s Theory Z Sometimes called the Japanese management style, it is based on the participative management style of the Japanese. This theory states that workers are motivated by a sense of commitment, opportunity, and advancement.
Withdrawal This conflict resolution has one side of the argument walking away from the problem, usually in disgust. You can recognize withdrawal when one party refuses to participate in the conflict resolution any longer and surrenders to the other stakeholders. The conflict is not really resolved, and it is considered a yield-lose solution. The approach can be used, however, as a cooling-off period or when the issue is not critical.
Work Breakdown Structure (WBS) The WBS is a visual decomposition of the scope; it is deliverables-based and typically does not include activities.
Work package The smallest item in the WBS; it is the smallest thing that the project team will put effort forth to create.
Work product A work-in-progress version of the requirements presentation.
Writing style The tone, language, and formality of a written topic.
Zachman Framework A matrix, created by John Zachman, that provides structure and helps stakeholders describe complex enterprises. The Zachman Framework uses predefined questions that must be answered for each component of any organization.

Leave a Comment