Welcome to PMP Glossary
PMP Glossary is an educational and professional service that provides a comprehensive glossary of terms and concepts related to Project Management Professional (PMP) certification. It targets students and individuals studying to be project managers, offering definitions and explanations to help prepare for the PMP exam and enhance their understanding of project management principles and practices. Browse our website to explore our resources and take a step forward in your project management career today.
System Standards
Data Flow Diagram - the preferred graphic technique to capture business processes
Software Process Model - the framework within which project‐specific software processes are designed
Structured Analysis and Design - is a diagrammatic notation that is designed to help people understand the system. The basic goal of SA/SD is to improve quality and reduce the risk of system failure. It establishes concrete management specifications and documentation. It focuses on the solidity, pliability, and maintainability of the system. A major step in the structured design process is the creation of structured specifications. A major step in the structured analysis process is the studying of current business environment. The transform analysis step is to group together the modules/processes that transform a particular set of data or a particular data structure.
Structured Requirements Definition - a process for defining and documenting the requirements for a project or system in a clear and organized manner. This process typically includes the identification of stakeholders, the elicitation of requirements from those stakeholders, the analysis and validation of the requirements, and the documentation of the requirements in a format that is easily understood by all stakeholders. The goal of Structured Requirements Definition is to ensure that all stakeholders have a clear understanding of what the project or system is intended to do, and that the requirements are accurate, complete, and consistent. During the requirements design phase the preparing of requirements definitions document is created. Defining what the application will do takes place in the logical definition phase.
Post Implementation Review - during post implementation review software developers review documentation to ensure the system is performing as designed.
Fishbone Diagram - A fishbone diagram is a visualization tool for categorizing the potential causes of a problem. This tool is used in order to identify a problem’s root causes. Typically used for root cause analysis, a fishbone diagram combines the practice of brainstorming with a type of mind map template. It should be efficient as a test case technique to determine cause and effect.
Expert system interface - Natural language processing interfaces, a system interface that has the ability to comprehend human sentences and paragraphs, voice recognition, and voice data entry.
Problem Analysis - problem analysis is broken down to 4 basic elements problem, effects, results, and benefits. Developing a new system that will reduce error rate of sales order during the data entry process by a percentage would list results and benefits.
Functional Audit - An audit prior to software delivery to verify that the requirements were met.
Systems Implementation and Support - in a direct cutover strategy there are outside requirements that must be implemented on specific dates such as income tax withholding rules.
Secondary Clients - both internal and external, have a strong influence on the project scope but no direct control
In-house system training - this form of training is preferred when a system is developed internally.
Pilot Implementation Strategy - a method for testing and evaluating a new system, process, or technology in a limited, controlled environment before rolling it out on a larger scale. The pilot implementation allows for testing the system's functionality and performance, identifying and resolving any issues that arise, and gathering feedback from users.The new system is released in a single site, thoroughly tested, then ported to other sites.
Timed box approach (Timeboxing) - Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. Divides the set of all requirements for a given system into subsets, each of which is implemented as a version of the system.
Input Controls - The goal of input controls is to help screen out and corrode bad data before it enters the system.
Object-Oriented (OO) Analysis - the focus is on capturing the structure and behavior of information systems into small modules that combines both data and process. The main aim of Object Oriented Design (OOD) is to improve the quality and productivity of system analysis and design by making it more usable. Not a step in OO approach is determine the class hierarchy so inheritance can be factored in. First technical milestone classes and class hierarchy have been reviewed and accepted. Task measures cannot be referred to as an object in object oriented analysis
Object-Oriented (OO) Spiral - Customer communication, planning, risk analysis, engineering (construction & release), customer evaluation.
Rapid Application Development (RAD) - a software development methodology that emphasizes rapid prototyping and iterative development. The goal of RAD is to deliver a working version of the software to the customer as quickly as possible. This is achieved by using a combination of pre-built components, visual programming, and automatic code generation. RAD approach typically includes these phases:
Requirements gathering and analysis: Identifying the requirements of the system and how they will be implemented.
Prototyping: Creating a working prototype of the system that can be tested and refined.
Construction: Building the system using pre-built components and automatic code generation. The RAD team prepares documentation and train the users.
Deployment and maintenance: Deploying the system to the customer and maintaining it over time.
RAD is a useful method for developing systems that have a well-defined and stable set of requirements, and can be a good fit for projects with tight deadlines and limited resources. It also allows for involving users and stakeholders in the development process, ensuring that the final product meets their needs.Software Restructuring - the modification of software to make the software easier to understand and to change, or less susceptible to error when future changes are made. "Software" includes external and internal documentation concerning source code, as well as the source code itself. It focuses on the design details of individual software modules, and on local data structures defined within modules to help implement a standard way of solving problems. There is conformity to modern software engineering practices and standards. The Application generation phase reuses and/or generated reusable components
Decision Tables - powerful tools for expressing complex logical relationships in an understandable manner. The y are used to define clearly & concisely the decision statement of a problem in a tabular form. A decision table is a table of conditions for defining a problem & the actions to be taken. Advantages of Decision Tables: 1) When the condition are numerous, then the decision table help to visualize the outcomes of a situation. 2) Decision tables summarize all the outcomes of a situation & suggest suitable actions. 3) They provide more compact documentation. 4) Decision tables can be changed easily. 5) Decision table has a standard format. The need for flow-charting is eliminated is not an advantage.
Process Architecture Guidelines - there are several guidelines that can be used when developing and using a process architecture and its process models. Keep the process model fixed is not a guideline. Some of these guidelines include:
1. Keep it Simple: The process architecture and its process models should be as simple as possible, while still providing the necessary information.
2. Use Industry Standards: The process architecture and process models should adhere to industry standards and best practices to ensure they are easily understood and can be easily integrated with other systems.
3. Be Consistent: The process architecture and process models should be consistent in terms of naming conventions, symbols, and overall structure.
4. Use Visual Aids: The process architecture and process models should use visual aids, such as flowcharts, diagrams, and swim lane diagrams, to help convey information and make it easier to understand.
5. Be Adaptable: The process architecture and process models should be adaptable to changes in the organization or industry.
6. Provide Traceability: The process architecture and process models should provide traceability from the high-level processes to the lower-level activities.
7. Incorporate Feedback: The process architecture and process models should incorporate feedback from stakeholders and end-users to ensure they meet their needs.
8. Communicate: The process architecture and process models should be communicated to all stakeholders, including management, developers, and end-users.
Stakeholders - Anyone who could be materially affected by the implementation of a new system or application. The primary invitees to a software requirements startup meeting. People who are affected by the project, its deliverables or objectives, or project activities.
Component Based Systems - System Evolution - the long term goal of implementing component based systems. Reuse of existing components is a short consideration when implementing component based systems.
Gradual Cutover - a cutover strategy where the new and old system run concurrently with new system increasing number of transactions in increments over time.
Software Component Reuse - must be supported by an environment that encompasses component database, library management system, software component retrieval system, CASE tools. The intent of software engineering in the component reuse process is to extract artifacts for reuse during the development of a new system.
Joint Application Development (JAD) Phases:
Project Definition - identifies the purpose, scope, objectives, assumptions, and open issues of the project by interviewing the managers from the users' departments.
Research - focuses on collecting more detailed information about user requirements. In this phase, the work flow and preliminary specifications of data elements, screens, and reports are obtained by interviewing users. Interviewing executive sponsors, managers, and users
Preparation -
The JAD Session - addresses work flow, data elements, screens, reports, and open issues. Because JAD is designed mainly for functional (end user) requirements, there are some steps not suitable for discussing security requirements.
The Final Document -
Project Management Communication Methods:
1) Paper (hard copy) communication
2) Electronic communication, such as email
3) Meetings
4) One‐on‐one discussions - used when there are issues with a team member.
User Manuals - a collection of guides with information on how product works. Usually containing specific instructions for using each system component.
Branch Analysis - a technique used to evaluate the different outcomes that could result from a specific decision or set of actions. It involves creating a diagram or flowchart that shows the different branches or paths that can be taken based on a particular decision point, and the outcomes or consequences of each path. Branch analysis uses path test, junction test, and loop test.
Title String - a short and descriptive phrase or sentence that summarizes the main topic or purpose of a document, webpage, or other content. Display contents of current title entry function.
Critical Success Factor - Plan contains detailed specifications of the action steps for project implementation. This can be tied in to meet objectives in a technology impact analysis.
Software Quality Assurance (SQA) - a process that assures that all software engineering processes, methods, activities, and work items are monitored and comply with the defined standards. These defined standards could be one or a combination of any like ISO 9000, CMMI model, ISO15504, etc. SQA incorporates all software development processes starting from defining requirements to coding until release. Its prime goal is to ensure quality. A SQA organization would file if senior management always backs the development team on quality issues as this would allow software defects to be released this compromising QA.
Requirement Management Process - process of gathering, analyzing, verifying, and validating the needs and requirements for the given product or system being developed. Successful requirements management ensures that completed deliverables meet the expectations of the stakeholders. Requirements can be managed using documents, however, complex systems or products in highly regulated industries mitigate risk by using trusted requirements management tools. Establishing a basis for software development and project management through documentation and control is not an objective of this process. is a parallel process to the software development process. The software development process can be divided into stages of requirements, proposal, design, code, and verification. The verification stage covers various testing activities. A process of systematically eliciting, organizing, and documenting requirements for a complex system.
Pruning the Tree - As you complete a set of calculations on a node, all you need to do is record the results. All the calculations that lead to that result can be ignored from now on and effecting that branch of the tree can be discarded.
Software Process Change - is not simple. To achieve tangible results, it needs to be treated like a development task . The first step in the software process change process is identifying key problems. A basic principle for software process change is that software process changes are retained with conscious effort and periodic reinforcement. Track progress of the work being down is a software process change task.
Data Flow Diagram - a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data-flow diagram has no control flow — there are no decision rules and no loops. Specific operations based on the data can be represented by a flowchart. Data flow diagram does not contain design screens
Gantt Chart - a tool for graphically depicting a schedule. It can be used to plan, record, and document scheduled, and to track actual results against a schedule. They also are very useful for planning larger projects.
Requirements elicitation - the process of communicating and collaborating with key stakeholders to assemble the insight and identify the project’s needs. Storyboarding is not a requirements elicitation tool. Records requirements sources
Potential System Constraints - a list of contains consist of economic, technical, system (eg. Should we maintain compatibility with existing solutions?), environmental , scheduled and resources.
Denormalization - the process of altering the logical database design to include the redundant data
Testing - the fifth step in the system development life cycle intended to ensure that the system does what it was designed to do.
A front-end process intended to exercise the system and its components to locate, investigate, and correct errors and bugs.
Problem analysis - a series of steps for identifying problems, analyzing them, and developing solutions to address them. It's an inquiry or investigation into the causes of an error, failure, or unexpected incident.The goal of problem analysis is to gain a better understanding of the problem being solved before development begins: Gain agreement on the problem definition, Understand the root causes - the problem behind the problem, Identify the stakeholders and the users, Define the system boundary, Identify the constraints to be imposed on the solution. Developing pseudo code for the system analyst is not a required action.
Logical database design - a database design in which the objective is to define the user’s understanding of the data, and how the various data elements and composites are interrelated.
Refining system definition - The requirements information is reviewed and the methods for defining the system are executed
Common attributes - a set of items that can be defined for the potential object, and will apply to all occurrences of the object.
Business Process Reengineering - is the practice of rethinking and redesigning the way work is done to better support an organization's mission and reduce costs. Organizations re-engineer two key areas of their businesses. First, they use modern technology to enhance data dissemination and decision-making processes. Then, they alter functional organizations to form functional teams. Business functions can be performed independently
Deliverable Code - A tangible output of human effort provided by a developer to a customer. An entity that results from the software development process that transitions into a physical deliverable.
3C Model - known as the "context, concept, and content" Model, is a systems analysis tool that helps identify and understand the relationships and interactions between different components within a system. Content component provides the implementation detail for a component.
Five Levels of Software Process Maturity - Initial, repeatable, defined, managed, optimizing. Predictable processes take place within in managed level.
Audit plan - the specific guideline to be followed when conducting an audit, and helps track project action items to closure.
Groups - in a decision table, when used, each rule must have a perform entry to specify which group of rules will be applied.
Size estimate - first step to completing a sizing estimate is to estimate the size of each product element.
Information Strategy Planning (ISP) - The fundamental objective of Information Strategy Planning (ISP) is to develop a plan for implementing business systems to support business needs.
-The objectives of the Information Strategy Planning stage are to:
- Establish an information strategy based on an evaluation of the business strategy and define strategic business objectives.
- Establish a development plan of user-oriented systems to meet business information needs and priorities.
- Define an information architecture for the future development of compatible data-sharing systems.
- Establish a technical strategy for the best use of new information technology.
- Define the most effective organization of the information system function within the enterprise.
Constraints - anything that slows a system down or prevents it from achieving its goal. You could think of a constraint as a bottleneck in your processes that impedes your progress. There are many, many different types of constraint. A restraining factor that could guild the manner in which a system model is created and the approach taken when the model is implemented.
User need vs system feature - a need is the process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.
Economics of Software Reuse - Does the creation or acquisition and operation of a reuse repository meet or exceed the trade‐offs.
Model Combination - provides development teams with assurance that all system requirements are filled by a subsystem or a set of subsystems.
Software Process Standards - Process standards provide the basis for process and quality measurements.
Team Problem Solving Guidelines - Define the problem, analyze the problem, develop solutions to consider, choose a solution, implement action plan, evaluate and adjust by checking for new problems create by your action plan.
Software Development Process (SDLC) -
1) Analysis and Planning
2) Requirements
3) Design and Prototyping
4) Software Development
5) Testing
6) Deployment/Release to Production.
Database - an architectural style that provides a centralized control of all operational data to all information sharing among components in the system.
Enterprise Modeling - first dimension enterprise modeling addresses the organizational structure and the functions performed by the organization, this contributes toward creating a three-dimensional view of a business.
Control Panel - used to program and configure the system monitoring service. Alarm, sensor, telephone number, and master password.
Business model environment - one that is building a new order entry, inventory, and fulfillment system.
Customer requirement vs technical/project requirement - it identifies what must be provided and not how it is to be provided.
Implementation - the process of completing the system and turning it over to the user. This includes site preparation (equipment installed, upgrades to existing equipments are made and equipment and software is tested), documentation preparation, personnel training, system cutover, system release
Software Project Planning - a project management process step that uses requirements and estimates as the basis for project plans.
Prototyping - one of the considerations is that even if it is only intended as a quick experiment, the prototype objective should be clearly established before starting the build.
Decision benefit - cost of each option minus cost from the value of the outcome
Data modeling - a entity relationship diagram used in JAD that help capture and define all the data required and make strategic and tactical decisions.
Business Object Models - describes the entities “departments, paychecks, systems” and how they interact to deliver the functionality necessary to realize the business use cases.
Business Use-Case Model - consist of business actors and business use cases, which the actors representing roles external to the business (for example, employees and customers) and the business use cases representing processes. Examples of a business use-case model might be “customer, employee, software developer”. Ensure that customers, end users, and developers have a common understanding of the organization.
Data exchange model - Mechanisms that enable users and applications to interact and transfer data (e.g., drag and drop, cut and paste) should be defined for all reusable components. The data exchange mechanisms not only allow human-to-software and component-to-component data transfer but also transfer among system resources (e.g., dragging a file to a printer icon for output).
Formality and hierarchy of software team - you can determine the formality and hierarchy if a software team by the level of technical expertise that the team possesses overall.
Implementation process - a process that requires a complete set of user documentation, system documentation, software documentation, and operations documentation
Screen Design - to display database readings when the user backs up one or more screen is not considered when designing a screen.
Entity Process Models (EPM) - provide a useful representation of the software process because they are often more accurate than task-based models for complex processes because they deal with real objects that persist and evolve through a relatively small sequence of conditions.
Physical audit - The objective of the physical audit is to provide an independent evaluation of a software product's configuration items to confirm that all components in the as-built version map to their specifications. Specifically, this audit is held to verify that the software and its documentation are internally consistent. This is done prior to software delivery to help determine if the software and documentation are consistent as listed in the requirement specifications.
Problem Statement - a statement of a current issue or problem that requires timely action to improve the situation.An element that is not required os the benefits of the proposed solutions.
Sub-specification - With each item listed in inventory, there will be a unique identifier, description, stock‐on‐hand, and the number of warehouse units.
Work Breakdown Structure - a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.” There are two types of WBS: 1) Deliverable-Based and 2) Phase-Based. The most common and preferred approach is the
Deliverable-Based approach. The main difference between the two approaches are the Elements identified in the first Level of the WBS. It will help subdivide the project into tasks where you define, estimate, and track each one.
Startup (kickoff) meeting - a critical opportunity for stakeholders to learn about and discuss a project's details. Ensure you select a meeting date and time well in advance so that invitees can make necessary arrangements. key elements consist of Stakeholders, presentation, time frames, responsibilities, chain of command, quality plan, and concerns.
Engineering Framework - Tasks required to build one or more representations of the application.
Scope - a well-defined boundary, which encompasses all the activities that are done to develop and deliver the software product. (Ex: how does the software integrate into the larger system.)
Waterfall Methodology - a breakdown of project activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. During a postmortem this methodology can be used to ensure requirements are accurate.
With two conditions and two outcomes (True or False) per condition, there are 2^2 = 4 possible combinations (True-True, True-False, False-True, and False-False). If we add four more conditions to the decision table, each with two outcomes (True or False), the number of possible combinations increases to 2^6 = 64. So, if there are six conditions with True or False outcomes, there are 64 possible combinations.
Equations to know 1{X}^x Project changes and requirements are unknown when documenting the adjustments required to the standard process to produce a basic overall project process.
PM are not responsible for identifying quality records and that should be the responsibility of the technical support/quality assurance teams.
About Us


Our Mission and Values
At PMP Glossary, we believe that education is a lifelong journey. That's why we're dedicated to providing the most comprehensive and up-to-date PMP reference material to our clients. Our team consists of experienced project management professionals who are passionate about sharing their knowledge and expertise with others. Contact us today to learn more about our services and start your journey towards becoming a certified project manager.
Client Testimonials
What Our Clients Say
At PMP Glossary, we take pride in our work and strive to exceed our clients' expectations. Here are some of the reviews we've received from our satisfied clients. If you've worked with us before, we'd love to hear your feedback!
Avery Smith
“PMP Glossary helped me prepare for the PMP exam and provided me with valuable insights into project management principles. Their resources are comprehensive and easy to understand, and their team is always available to answer any questions I have. I highly recommend their services to anyone studying for the PMP exam.”
Jessie Brown
“I was struggling to understand some of the key concepts in project management, but PMP Glossary's resources helped me clarify my doubts and gain a deeper understanding of the subject. Their team is knowledgeable and supportive, and their services are top-notch. I would definitely recommend them to anyone looking to enhance their project management skills.”
Skyler Adelson
“PMP Glossary's resources are a game-changer for anyone studying for the PMP exam. They provide a comprehensive glossary of terms and concepts that are essential for success on the exam, as well as valuable insights into project management best practices. Their team is professional, knowledgeable, and always willing to help. I'm so glad I found them!”