Source: Global Knowledge www.globalknowledge.com
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
Project management has been increasing in visibility both inside and outside the executive office. Now, with the emergence of business analysis as an independent field, understanding and using the correct terminology is more critical than ever.
This glossary is a guide to the most commonly used business analysis and project management terms. It is designed to help you better communicate with business analysis and project management professionals.
one of four possible strategies for response planning with regard to an identified risk; indicates the impact of the risk that can be tolerated at its identified level.
observing in a way that interacts with those being observed (ie, asking questions and having others describe what they are doing and why).
component of work performed during the course of a project; also called a task.
dynamic modeling technique used to show activities and decision points, and the roles assigned to them.
the activities of the project team necessary to collect project records, analyse project success or failure, gather lessons learned, and archive project information for future use; performed when a project ends, when a project is terminated before work is complete, or at the end of each project phase.
includes perform product verification, complete final project performance reporting, obtain formal acceptance of project, perform lessons learned, create project archives, release resources, and celebrate!
responsible for reviewing the requirements for feasibility and using them as a guide in developing the system architecture.
part of the enterprise architecture that shows how the various software applications interact.
things considered real, true, and certain for the purposes of planning; factor believed to be true but not confirmable or factor known to be true but that could change during the project.
one of four possible strategies for response planning with regard to an identified risk; indicates that risk cannot be tolerated to any degree and must be prevented from having any impact on the project.
method of determining the late start time (LST) and late finish time (LFT) for each activity.
project’s point of reference for requirements changes; established at the point of plan approval and should not be changed except in response to significant, approved change in the project scope.
deduces the system’s requirements from its behavior, without examining its code or other technical details.
acronym for remembering project definition elements: Background; Objectives; Scope; Stakeholders; Constraints; Assumptions; Reporting; and Deliverables.
requirement elicitation method that generates creative ideas among a group of people; success is dependent on participants’ creativity.
a person who identifies the business needs of clients and stakeholders to determine solutions to problems; responsible for requirements development and management; acts as a bridge between the client, stakeholders, and the solution team.
part of the enterprise architecture that shows the structure of the enterprise (that is, divisions, locations, etc.) and its product or service strategy.
limitations imposed on the solution related to business activities, (i.e. budget limitations); restrictions on the people who can do the work (skill sets available, etc.).
defines why the project is important to the business and what the business needs to get from the project for the investment to be successful.
stated from the viewpoint of the business function and using that terminology.
eventualities that could threaten the project; positive (opportunities) or negative impacts the project could have on the business.
static modeling technique that looks at the rules governing business processes and decisions (regulation, company policy, etc.).
the functionality of the specified system.
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.
Certified Business Analysis Professional; certification offered by IIBA.
static modeling technique that looks at representations of each entity in a system, showing the attributes and activities of each; describes one or more objects with a uniform set of attributes and services, including a description of how to create new objects in the class.
survey method that limits the responders’ options to pre-selected choices; requires writing questions with great skill and care to avoid ambiguity or bias; provides quantitative data.
one of nine Knowledge Areas identified in the PMBOK® Guide; focuses on ensuring that project information is generated, collected, disseminated, stored, and disposed of in an appropriate and timely manner.
the process of determining what information will flow into and out of the project and who wants or needs that information.
any limitations imposed on the project or solution; typically falls into the categories of time, cost and resources, scope, and quality.
response plan formulated for identified risks if/when a risk is realised.
technique focused on the identification of the associated costs and the related benefits.
one of nine Knowledge Areas identified in the PMBOK® Guide; focuses on planning, estimating, budgeting, and controlling costs so that the project is successful.
identifying schedule compression alternatives along the critical path and taking action to decrease the total project duration; typically accomplished by adding resources to the critical path tasks.
the longest path through the project network; the sequence of activities that defines the minimum time required to complete the project.
static modeling technique that looks at how each data element is created, read, used, and deleted.
person or organisation that will use the project’s product, service, or result.
a person who reviews requirements for feasibility and completeness, and uses them as a guide in developing the system’s database.
static modeling technique that provides a detailed description of each data element, including its source (for primary elements) or how it is derived or computed (for composite elements).
dynamic modeling technique that shows how data is shared among the various activities and entities in a system.
static modeling technique that shows the changes data elements go through.
provides information that the decision makers need to make a decision about the proposed project; almost always includes both a document and a presentation.
provides a structure within which you can identify options and investigate the potential outcome of following these various options.
decision support tool that uses a graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility.
process of breaking something down into smaller constituent pieces; most effectively accomplished through the use of a work breakdown structure (WBS).
any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project; the solution due to the customer at the end of a project.
consensus-based estimating technique using anonymous inputs from the team working on the project.
logical relationship between two schedule activities.
a person who reviews requirements for feasibility and ensures understanding; responsible for creating a product that satisfies the requirements.
requirement elicitation method that studies available documentation to leverage existing material; can be time-consuming and often information may be out of date.
actual amount of time to complete the activity or the actual time on task; measured as elapsed work time, includes resources
first date the project can be finished by; determined by adding the time to complete all of the activities on the critical path.
amount of actual work in an activity; measured in hours or staff days.
Early Finish Time; earliest point in time in a project network an activity can finish.
leadership-based model of change including: Urgency; Guiding Coalition; Vision and Strategy; Communication; Empowerment; Short-Term Wins; Consolidation and Production; and Anchor New Approaches.
techniques used to extract requirements information from people, as well as from other sources.
analysing needs and opportunities from the overall organisational perspective and recommending projects to improve specific business processes and systems.
Entity Relationship Diagram; static modeling technique that looks at the data entities in a system and how they relate to each other.
Early Start Time; earliest point in time in a project network an activity can begin
dynamic modeling technique that shows the events the system must respond to, and what its response should be to each.
used with an incremental development life cycle to discover precisely what should be built, rather than trying to specify it in full detail before development begins.
ultimate authority on the project.
results from clients, sponsors, and the team, each holding different views of the project.
dependencies that exist between schedule activities and factors outside of the project, like the output from another project or goods and services provided by vendors.
attempts to reduce the overall project schedule by overlapping activities that would normally be done in sequence; requires an increase in planning and coordination between the overlapped tasks.
service the system/solution provides to fulfill one or more stakeholder needs; typically high-level abstractions of a solution that turn into functional or non-functional requirements; allow for early priority and scope management and for getting a high-level sense of the stakeholders view of the solution.
unexpected project costs; costs of implementing or operating the proposed process.
similar to start-to-start relationships, except that the point of relationship is at the end of the activity; predecessor activity must be completed in order for the successor activity to be completed.
most common; the predecessor must be 100-percent completed before the successor can begin.
amount of time an activity can be delayed without affecting the project end date.
requirement elicitation method that involves an interactive session with a carefully selected group of people; can be an effective way to capitalise on the synergy of a group if all participants feel free to interact.
relatively simple but powerful means of comparing the forces that favor and oppose a given decision; provides a basis for weighing the importance of the forces affecting the decision; provides a range of options for carrying out decisions.
in a network diagram, allows you to calculate the EST and EFT for each activity.
the amount of time an activity can be delayed without affecting successor activities.
observable behaviors of the solution; as opposed to technical design.
define what the system must be able to do; describe both the systems behavior in detail and the information the system will manage.
mockup of a broad area of a system that has little or no actual capability to do work; often used to review user interfaces or work flows.
one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on organising and managing the project team members.
special set of conditions or capabilities that are needed only during system rollout or implementation.
a person who reviews requirements for feasibility and completeness and then uses them to derive the system’s information needs.
part of the enterprise architecture that shows how data flows within the organisation.
a person who reviews the requirements for feasibility and uses them as a guide in establishing the operational infrastructure that is necessary to support the solution.
focuses on the processes that integrate the various elements of project management that are identified, defined, combined, unified, and coordinated in the project management process groups.
requirement elicitation method that offers the opportunity for rich communication by meeting with either an individual or group of people.
waiting time inserted between the activities in a relationship (i.e. downtime).
partial overlapping of activities; essentially a head start for one activity, relative to the other in the relationship.
identified at the end of each stage of the project and collected for cumulative analysis; gathers and documents what went right and wrong, what should be done differently, and what would you recommend to others.
Late Start Time; the latest time an activity can begin without jeopardising the project end date.
also referred to as hard dependencies or hard logic; characterised by a required order in the relationship between the activities.
significant point or event in the project; point in time of significant accomplishment in the project.
one of four possible strategies for response planning with regard to an identified risk; indicates that the risk cannot be tolerated at its identified impact level, but cost acceptable steps can be taken to reduce the risk impact down to a tolerable level; always results in residual risk.
representations of a business or solution that often include a graphic component along with supporting text and relationships to other components.
adage in Western culture that broadly states “things will go wrong in any given situation, if you give them a chance”; or shorter “anything that can go wrong, will”.
type of high-level requirement that is a statement of a business objective, or an impact the solution should have on its environment.
required system capabilities that do not describe functionality; examples include the number of end users, response times, fail-over requirements, usability, and performance; also known as supplementary requirements.
approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another.
requirement elicitation method that involves watching people as they go about their jobs; can be an effective way to gain an understanding of how work is done in the production environment; can be time consuming and may disrupt work.
allow the respondent to write out answers in their own words; are more difficult to analyse quantitatively than closed-ended surveys.
focused on the development and execution of programs that sustain the organisation and move it forward.
relationships in which the project manager has some influence over the sequence of the relationship; often referred to as soft logic dependencies or discretionary dependencies.
technique for calculating the importance of a number of options relative to one another; especially useful when you do not have objective data to base the decision on.
also called the 80/20 rule; based on Pareto’s study of the concentration of wealth in Italy that found 80 percent of the wealth was held by 20 percent of the people.
used for finding the changes that will yield the greatest benefits; particularly useful in situations with many competing alternatives.
concept that states “work will always expand to fill available time”; padding or expanding estimates simply encourages procrastination.
observing in a way that does not disturb the workers being observed.
Precedence Diagramming Method; places activities in boxes and shows the precedence relationship with arrows; also known as AoN (Activity on Node) or EoN (Event on Node).
Program Evaluation Review Technique; uses multiple points of estimate for the same activity to derive a weighted average estimate for the activity.
a collection of logically related project activities, usually culminating in the completion of a major deliverable.
set of interrelated actions and activities performed to achieve a specified set of products, results, or services.
solution, or component of a solution, that is the result of a project.
based on the product scope and requirements; give insight into whether the product being built will achieve its goals.
(for project managers) unique, non-routine endeavor requiring an investment decision that has defined and agreed upon objectives and a start and end date; (for business analysts) specific, detailed, and coordinated steps through which programs accomplish the changes defined to enact the strategic plans.
document issued by the project initiator or sponsor that formally authorises the existence of a project, and provides the project manager with the authority to apply organisational resources to project activities.
person ultimately responsible for the project, including ensuring that the final product satisfies the requirements.
based on the project’s goals and give insight into whether the project is likely to achieve those goals.
definition of what the project will accomplish.
things that may impact the project’s ability to meet stakeholder expectations; uncertainty (both positive and negative) that matters to the project.
usage modeling techniques that mocks up a user interface, or the flow of screens or forms in a user interface, for review.
a person who reviews the requirements to ensure that they are testable and that they meet quality standards and policies; responsible for testing the product after it is developed to see if the requirements were indeed satisfied.
explain the way in which the system must provide the functional requirements (i.e. response times, security, usability, and maintainability); often called nonfunctional requirements.
planned and systematic quality activities to ensure requirements are met.
monitoring specific results for compliance with relevant quality standards.
one of nine Knowledge Areas identified by the PMBOK Guide; focuses on ensuring that the project will satisfy the needs for which it was undertaken.
phase of identifying relevant quality standards and how to satisfy them.
Responsibility Assignment Matrix; structure that relates the project organisational breakdown structure to the WBS to ensure that each element of the scope of work is assigned.
includes skilled human resources (specific disciplines, either individually or in teams), equipment, services, supplies, commodities, materials, budgets, or funds.
technique used to address resource overloads and ensure that resources are expected to perform realistically.
total amount of assigned work within a timeframe.
condition or capability needed by a stakeholder to solve a problem or achieve an objective.
knowledge making sense of the information that is elicited, organising it, and documenting it in appropriate forms (that is, words, tables, models, and prototypes); describes how business, functional, and nonfunctional requirements can be assessed, documented, and presented.
defines the methods, tools, and techniques used to structure the raw data collected during requirements elicitation; identifies gaps in the information and defines the capabilities of the solution.
characteristic of a requirement that captures additional information, such as priority or level of risk.
involves providing requirements information to those who need it, when they need it, in the form that they need.
defines the communication activities during a project used to ensure that requirements information is available to all project members when it is needed, and in a usable form.
a forum (like a JAD) where stakeholders and SMEs get together to provide information about the target system.
captures and communicates gathered requirements.
the collection of activities and approaches for capturing the requirements of a target system from requirements information from various sources and stakeholders.
all the items that comprise the requirements for a project; defined based on the stakeholders for whom they are built and their needs and preferences.
knowledge that includes producing a plan for determining requirements activities on a project, and keeping those activities on track; includes managing changes to individual requirements and project scope
analysing an existing system to understand what it does and why.
method of identifying requirements by interviewing developers, reading code, and testing applications.
Request For Proposal.
Request For Quote.
risk response strategy that takes action to reduce the probability and/or impact of a risk.
Return On Investment.
system view of change including seven stages: Old Status Quo; Foreign Element (change); Chaos; Transforming Idea; Integration; Practice; New Status Quo.
sum of the products, services, and results to be provided as a project.
changes that occur during a project that are neither recognised, evaluated, nor approved.
specifically indicate what work falls outside of the project boundaries.
indicate what the project is about and what it will do.
one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project includes all the work required, and only the work required, to successfully complete the project.
Software Development Life Cycle.
part of the enterprise architecture that shows the security needs and practices within the organisation.
dynamic modeling technique that shows the exact steps for a specific scenario; shows objects participating in interactions and the messages exchanged.
formal, written approval gained throughout the project management processes at the end of a phase.
focuses on collaborating with the technical and quality assurance teams to ensure that the solution built satisfies the requirements and collaborating with business users to plan acceptance and rollout of the solution.
major supplier of requirements information, and is often an approver of the requirements; also referred to as the customer.
person or group that provides the financial resources for the project.
persons 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.
the predecessor activity that must begin in order for the successor to be completed; relatively rare.
predecessor task that must be started before the successor task may be started.
dynamic modeling technique that shows all the states the system can be in, and the possible transitions among those states.
exist in a system if the same input generates different responses in different situations; for example, a hotel has two states: “vacancy” and “no vacancy”, and a request for a room generates different results in those two states.
usage modeling technique used to mock up a user interface, or the flow of screens or forms in a user interface; differs from a prototype in that these are not functional systems, rather they are often drawings.
systematic and formalised effort to establish organisational purposes, objectives, and policies, and to develop plans to implement them.
has a detailed agenda and formal set of questions.
a person who provides many important requirements, and in certain situations, may need to approve requirements.
requirement elicitation method that allows you to collect information from many people in a relatively short period of time.
method of identifying project benefits.
component of work performed during the course of a project, also called activity.
limitations imposed on the solution related to business activities (i.e. architecture decisions that are made).
technological changes that could impact the project or technologies that may not work as expected.
state requirements in terms that the implementation team needs (i.e. system or software requirements).
part of the enterprise architecture that shows how different technologies support the business.
prototype used to answer specific questions as a basis for development but is not meant to be used in the final system.
one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project is completed in a timely manner.
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.
exist between requirements when more detailed requirements are associated with the higher level requirements (i.e. needs and features); can also exist between detailed requirements and design models/test cases.
one of four possible strategies for response planning with regard to an identified risk; indicates that the risk cannot be tolerated but the cost of elimination is too great, so ownership of risk response and impact are shifted to a third party.
notes the relevant constraints of time, scope, and cost/resources that are shared by all projects; provides a basis for planning project controls.
has only a loose agenda, depending more on ad hoc interaction.
usage modeling technique that identifies the specific steps that will happen in a particular transaction (or use case) along with entry and exit conditions and other relevant information; usually necessary to describe the use cases depicted in a use case diagram.
usage modeling technique that captures all actors and use cases involved with a system or product.
usage-modeling technique that is similar to storyboards and screen flows, but used much earlier in the analysis process.
usage-modeling technique that lists the end users of a system, including relevant attributes of each.
subset of business requirements that address the needs of specific users to do their jobs.
usage-modeling technique that is similar to use case descriptions, but with much less detail.
checking requirements to be sure that they are correct, complete, and feasible.
checking requirements to ensure that they have been written and specified well; should be done before validation.
detailed view or functional model of a narrow area of a system; often used to test the feasibility.
Work Breakdown Schedule; deliverable-oriented, hierarchical decomposition of project elements that defines the total work scope of the project.
works just like normal Delphi, except that the successive estimating rounds focus on the inputs that PERT requires.
examines the program code and other technical details to determine not just what it does, but why and how it does those things.
deliverable or project work component at the lowest level of each branch of the WBS.
dynamic modeling technique that diagrams the flow of activities among responsible parties.
requirement elicitation method that involves a structured meeting with a group of people to generate many ideas in a short period.
