top of page

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.

Business Standards

User-Centered Design (UCD) – a design philosophy and process, based on the users' requirements, desires, and limitations.

Low-Fidelity Mockups - intentionally basic mockups that allows you to focus on design and flow rather than intricate details. This can be used as a means to match designs to requirements without granular details and development effort. Low-fidelity mockups can help to prototype with just the basic requirements that are gathered when guidelines are unavailable. The negative is that low-fidelity mockups are not robust enough to provide the level of fidelity required to use with development tools. stakeholders feel comfortable to suggest changes, because they do not perceive development as being wasted.

UML Deployment Diagram - a node can represent a physical or server resource.

Subsystem - Each component of a Functional Decomposition Diagram (FDD)

Composite Structure - A class with ports that allow interaction between parts of a system.

 

Interview - used to help identify all stakeholders and project goals.

 

Brainstorming - A technique intended to produce a broad or diverse set of options generated by a free‐thinking group of people together

 

Focus Group – conducted to help avoid requirements that are unclear.

 

Scope and Content – these must be determined for each document to have a successful requirements and design specification process.

 

Business Process Re‐engineering (BPR) - BPR aims to help organizations fundamentally rethink how they do their work in order to dramatically improve customer service, cut operational costs, and become world-class competitors. BPR helps companies radically restructure their organizations by focusing on their business processes from the ground up. A business process is a set of logically related tasks performed to achieve a defined business outcome. Re-engineering emphasizes a holistic focus on business objectives and how processes relate to them, encouraging full-scale recreation of processes rather than iterative optimization of sub-processes.

Business Process Re‐engineering (BPR) vs Business Process Management (BPM) - Business Process Re‐engineering uses radical, one step changes, while Business Process Management is evolutionary and continuous.

 

Surveys – this technique can be used to quickly gain knowledge from the user community.

 

Functional Prototype – demonstrates the design, aesthetics, functionality and technologies of the application based on the specs as opposed to hand drawn prototypes.

 

Meta‐Repository Structure - table in a database that contains Information describing other tables.

 

Structured Walkthrough – provides the opportunity to communicate, verify, and validate requirements.

Parking Lot - way to offload work that nobody participating in the session wants to tackle. 

 

JAD - “Joint Application Design”

 

JAD Session Optimal Outcome - to organize the project so it can effectively move forward on time and on budget.

 

JAD Phases - The generic phases of the JAD life cycle include:

                        Define Objectives - In this research and preparation phase, the facilitator articulates the preliminary meeting                                          agenda, produces high-level data/process models and outcomes and shares them   with the participants for review.

                        Session Preparation - This phase involves the facilitator researching the session objectives to get a holistic insight                                  and prepare the session’s logistics.

                        Session Conduct - The JAD session is conducted in this phase, and the progress is reviewed. Prototypes can be                                      presented in the sessions to resolve conflicts among the stakeholders.

                        Documentation - In this phase, the requirements or design documents are compiled and reviewed and the question                             if there are enough system details within the project specifications is answered.

 

Management Interview – used to help facilitate the JAD team selection process.

 

Business Processes – these processes are reviewed at the start of a JAD session

 

Application Architecture – Driven by functional requirements

Actor – an actor model classes of users

 

Personas – a persona model specific users. A fictional user archetype based on user research.

 

SMART - Specific, Measurable, Achievable, Relevant and Time‐bounded.

 

Unit Testing - The initial phase of testing a software development project

 

Retrospective Meeting – a meeting held after a projects conclusion that help answer what we learn, still puzzles us, can do differently in the future.

 

Activity Diagram vs Flowchart – activity diagrams show flaws in the processing model associated with business requirements as flowcharts do not.

 

Functional Decomposition - a method of analysis that dissects a complex process in order to examine its individual elements. A function, in this context, is a task in a larger process whereby decomposition breaks down that process into smaller, easier to comprehend units. Functional decomposition should be performed deep enough that no more decomposition can be done without adding any extra time and resources. This allo

          Advantages

           - Functional Decomposition is an intuitive process for most people and is readily understood by the customer.

           - Helps to discover duplicate or overlapping activities.

           - Reduces risk by ensuring multiple points of failure 

           - Breaks complex systems into relatively separate components, which can help with scope, development, and planning.

          Disadvantages

           - Is internally focused (what are we currently doing versus what should we be doing)

           - It can be easy to define too much detail.

           - There is no way to be sure that every necessary component has been captured and properly related.

           - It is very easy to conflate a functional diagram with an organizational diagram (especially for stakeholders). This can make               it easy to overlook interdependencies where there may be high levels of coupling to functions that were not diagramed on                 other organizational units, or where multiple organizational units are involved in the function that was diagrammed.

 

Functional Prototype – Allows stakeholders and domain experts to experience the flow and functionality of an application to ensure it meets their needs.

 

Functional Manager – A functional manager oversees a particular functional area of an organization, such as a department or team, a specialist in the managed area. They're responsible for managing, owning and providing the resources for projects.

Functional Decomposition Diagram (FDD) - contains the whole function or project along with all of the necessary sub-tasks needed to complete it without showing event sequence. The more levels beneath the more granular the detail become such as describing how each function would be used within an application.

Process Flow Diagram (PFD) - a type of flowchart that illustrates the sequence of events and relationships between major components at an industrial plant.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Implementation Cost - The costs associated with an implementation should not outweigh its benefits

 

Entity‐Relationship Diagrams (ERD) – A diagram with the goal to visualize relationships between data groups and elements.

 

MoSCoW- an analysis technique that categorizes requirements into “must, should, could, and will not” categories

 

Focus Group – an information gathering technique used during requirements gathering.

Class Diagram

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Context‐ Sensitive - help in an application provides information associated with the state the application is currently in.

 

JSON (JavaScript Object Notation) - an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays (or other serializable values).

 

Business Analyst – responsible for bridging the gap between IT and the business using data analytics to assess processes, determine requirements, sign off on functional requirements, and deliver data-driven recommendations and reports to executives and stakeholders.

 

Facilitator and Scribe – both are responsible for producing the final document in a JAD session.

 

Functional Requirements - product features /capabilities that developers must implement within the system to enable users to perform their tasks. Describes the behavior of a software system/ product. To update requirements that have not previously been documented, contact the subject matter experts and have them update the functional requirements to document the requirements that you have discovered.

 

Functional Business Requirements – When functional business requirements are not met, you can offcer to reevaluate the requirements and update the functional prototype.

 

User Requirements – requirements that the user must follow. This can be completing training to passing all required online certification exams.

 

Use Case – Built based on the gathering of functional requirements.

 

Software Procurement – during software procurement, the final step must always be to request for management approval for the purchase.

 

Use Case Diagram – shows which system functions are performed by which actor.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Trailblazer/Pilot – an initiative used to validate your new process improvements.

 

Risk – In software development risk is considered to be positive or negative. If identified, calculate a number of slack days to add to the project plan. Change to: Assign a risk assessment value to each identified risk using some well-defined scale.

 

Tool Selection Process – a tool management plan process that consist of components such as tool survey, demonstration, and vendor product evaluation.

 

Data Flow Diagram (DFD) - maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination. Demonstrates that a software system will produce the desired outputs, based on certain inputs.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Card Sorting – A technique used to organize items into logical groupings.

 

Six Sigma - a process that makes use of statistics and data analysis to analyze and reduce errors or defects. This improves the quality of process outputs while reducing manufacturing defects.

 

Business Value - based on cost benefit analysis of their relative value to the organization. The most valuable requirement will be targeted for development first. Common when enhancing an existing solution that already meets specified minimum requirements, or when delivering the solution incrementally.

 

Project Life Cycle - the sequence of phases through which a project progresses. It includes initiation(concept), planning, execution, and closure.

 

Gathering Requirements - gathering requirements implies that the requirements are to be well-known.

 

Eliciting Requirements - eliciting implies the analyst needs to work to get the required information.

 

Scrum - one of the agile methodologies designed to guide teams in the iterative and incremental delivery of a product. Often referred to as “an agile project management framework,” its focus is on the use of an empirical process that allows teams to respond rapidly, efficiently, and effectively to change

 

Inspections - A formal process which involves a careful and detailed execution with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material.

 

CASE Tools - The set of application programs to automate software development lifecycle activities and are used by managers in a project, engineers and analysts to build a software system is called CASE tools and the software development cycle stages can be simplified using several tools such as design, analysis, project management, database management, documentation, etc. and the use of these tools speeds up the project development to obtain desired results. This is typically used during a JAD session by a scribe and or a modeler to capture the models generated.

Digital Timing Diagram - represents a set of signals in the time domain.

 

 

 

 

 

 

 

 

 

 

 

Logical Data Dictionary - describe data in terms that business representatives more easily understand.

 

Physical Data Dictionary - describe data in terms of physical data structure, type, format, and length.

 

Rational Unified Process (RUP) - an agile software development methodology. RUP splits the project life cycle into four phases. During each of the phases, all six core development disciplines take place: business modelling, requirements, analysis and design, implementation, testing, and deployment. The main goal of RUP is to create high quality software with a predictable budget and time frame. The RUP approach is used to quickly get requirements from stakeholders that might not know the requirements.

 

Technical Requirement Document - consolidates the entire product development workflow and presents it straightforwardly and readable. Your company’s product’s functionality, features, and purpose must show up in the technical requirement document. A prerequisite to documenting technical requirements is to identify the technical subject matter expert(s) who can help to contribute in the capture and development of the requirements. The help create the technical requirements document, technical subject matter experts who can contribute to capturing the requirements.

 

Defining System Specification - Defining and documenting system specification s consist of 5 steps

  1. Make a system specification outline

  2. Define the purpose and expectations of the product

  3. Create an overview of a finished system

  4. Get very specific about your specifications 

  5. Obtain customer approval of the system specification

 

Root Cause Analysis (RCA) – a structured examination of the aspects of a situation to establish the underlying causes and effects of an issue. A factor that caused a nonconformance and should be permanently eliminated through process improvement.

 

Software Requirement Specification (SRS) - a document that describes what the software will do and how it will be expected to perform. It also describes the functionality the product needs to fulfill the business goals and needs of all stakeholders.

 

Enterprise Service Bus (ESB) – a software pattern for implementing a service-Oriented Architecture allowing for communication between a collection of interacting applications.

 

Acceptance Criteria – describes the metrics that are used to help determine if a given set of requirements meet the initial vision and provides unit tests that can be used to verify if the final code meets the criteria of the requirement.

 

Observational Techniques – used to uncover hidden assumptions and existing business processes.

 

Product Backlog – features that are not being built in a current spring are shuffled to adjust the priority for future sprints.

 

Sequence Diagram - a Unified Modeling Language (UML) diagram that illustrates the sequence of messages between objects in an interaction. A sequence diagram consists of a group of objects that are represented by lifelines, and the messages that they exchange over time during the interaction. Sequence diagrams can graphically show the various conditions the proposed system can be in at various points in time. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Requirements Management Plan - a document that is typically created alongside the primary project plan as a piece of the scope management process. Its primary purpose is to define the process to manage the full life cycle of requirements.

 

Requirements Traceability Matrix (RTM) - a document that demonstrates the relationship between requirements and other artifacts. It's used to prove that requirements have been fulfilled. And it typically documents requirements, tests, test results, and issues.

 

 

 

 

 

 

 

 

 

 

 

 

Scope/Feature Creep - what happens when changes to include additional functionality are made to already agreed to requirements without any control procedure like change requests. Those changes also affect the project schedule, budget, costs, resource allocation and might compromise the completion of milestones and goals. 

 

Rapid Application Development (RAD) life cycle – 

  1. Requirements Planning - Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements. It ends when the team agrees on the key issues and obtains management authorization to continue.

  2. User Design - users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs.

  3. Construction – focuses on program and application development task similar to the SDLC. Detailed entity-relationship diagrams, process decomposition diagrams, and screen and report layouts are all defined

  4. Cutover - resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training. Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner

 

Defects - defects deal with functionality that is not delivered as specified.

 

Change Control - a process—either formal or informal[1]—used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. Change controls deal with specifications that were not correct to start with or changed during development, It can be described as a set of six steps:

  1. Record/classify

  2. Assess / analyze

  3. Plan

  4. Build / test

  5. Implement

  6. Close/ gain acceptance

 

Identified Risks - evaluated throughout the life cycle of the project at regular intervals.

 

After-Action Report – after action reports should identify What went wrong, why the problem happened, how to avoid these problems in the future, and what went right and how can it be applied to improve future projects. Blame is indirectly apportioned to the one developer, contrary to the goals of an after‐action report

 

UI Specifications – During the creation of User Interface specifications, consider context and data of users within the application. If the UI does not function consistently, it will increase the users' cognitive dissonance.

 

Context-Sensitive Help - this type of help within an application provides users information associated with the current state of the application.

 

Risk Management and Integration Plan - a document that provides information in regards to monitoring, circumventing, controlling, and influencing the impact of potential time and budget slip factors.

 

Training Material – documents and courses used to ensure users will know how the software functions. For constant evolution and improvement tests, surveys, and feedback forms can help to make sure training material in updated over time.

jQuery Shake() – technology choices are specified as part of the business requirement.

Environment planning requirements development phase – determine support timeframe for planned environment.

Stakeholder – an individual, group or organization that’s impacted by the outcome of a project or a business venture. Stakeholders have an interest in the success of the project and can be within or outside the organization that’s sponsoring the project. before a project can move forward, a detailed project plan outlining development timelines is needed. Stakeholders can be informed that the manual process will suffice long‐term and that the new requirement can be delivered in a future release.

Relational Database – a database that has a relationship between data elements that can be paired with a data dictionary to describe its schema.

 

Data Dictionary - a collection of names, definitions, and attributes about data elements that are being used or captured in a database, information system, or part of a research project. This includes description, context, data domain, and usage details.

 

Confidentiality, Integrity, and Availability (CIA) - The CIA triad is a common model that forms the basis for the development of security systems. They are used for finding vulnerabilities and methods for creating solutions. Security objectives for an application can be generated based on its characteristics by examining each business requirement determined during analysis.

 

Code Versioning – the same code that was validated in the QA environment should be the code that is delivered to the production environment.

 

Business Needs – identified business needs align with the vision or strategic mission of the business.

FTP - The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network.

Agile SCRUM – a development methodology that can be used with sprints below the set timeframes for expected changes to requirements.

UX Principal – design need to be simplified and easy to understand by users. Error messages must be written in a language that users would understand.

 

Spiral Development Model - a systems development lifecycle (SDLC) method used for risk management that combines the iterative development process model with elements of the Waterfall model.

 

Timeboxing - a goal-oriented time management strategy to help you increase productivity and reduce procrastination. When you create a “timebox,” you’re setting a goal to finish a particular task within a certain time frame. You can use timeboxing to schedule individual tasks, help your team get organized, manage meetings more effectively, or all in.

 

User Stories - an informal, general explanation of a software feature written from the perspective of the end user or customer. high‐level user story describes proposed feature in one or two sentences and written in plain language allowing developers to immediately envision the high‐level technical solution.

 

Generated Documents – Document completeness revie, compatibility with standards review, first-level consistency check review, second-level consistency check review, code logic review.

 

A/B Testing - (also known as bucket testing, split-run testing, or split testing) is a user experience research methodology. A/B tests consist of a randomized experiment that usually involves two variants (A and B), although the concept can be also extended to multiple variants of the same variable. It includes application of statistical hypothesis testing or "two-sample hypothesis testing" as used in the field of statistics. A/B testing is a way to compare multiple versions of a single variable, for example by testing a subject's response to variant A against variant B, and determining which of the variants is more effective.

 

Business Process - a collection of linked tasks that find their end in the delivery of a service or product to a client. A business process has also been defined as a set of activities and tasks that, once completed, will accomplish an organizational goal. If a business process is replaced with a new software system with results being the same it means the business process was inefficient and wasn't optimized before being implemented in the new system.

Screenshot 2024-02-20 at 5.50.50 PM.png
Screenshot 2024-02-20 at 5.52.32 PM.png
Screenshot 2024-02-20 at 5.54.29 PM.png
Screenshot 2024-02-20 at 5.56.07 PM.png
Screenshot 2024-02-20 at 5.57.44 PM.png
Pasted Graphic 2.tiff
Screenshot 2024-02-20 at 6.01.28 PM.png
Screenshot 2024-02-20 at 6.02.42 PM.png

About Us

Keyboard
Keyboard

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.

Get in Touch

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!”

bottom of page