1. Project Charter The project charter documents the project purpose, project overview, assumptions, constraints, and high-level requirements that the project is intended to achieve.

2. Project Management Plan The project management plan components used in planning scope management mainly include: ●Quality management plan: The way in which the organization's quality policies, methods, and standards are implemented on projects affects the way in which project and product scope are managed. ●Project life cycle description: Defines a series of stages that the project goes through from start to completion. ● Development approach: The development approach defines whether the project uses a predictive, adaptive or hybrid development approach.

3. Business environment factors The business environment factors that can affect the planning scope management process mainly include: organizational culture, infrastructure, personnel management systems and market conditions.

4. Organizational process assets Organizational process assets that can affect the planning scope management process mainly include: policies and procedures, historical information and lessons learned knowledge base, etc.

1. Expert judgment Areas involved in the planning scope management process include: past similar projects; information on specific industries, disciplines, and application areas, etc.

2.Data analysis A data analysis technique suitable for this process is alternatives analysis. Alternative analysis techniques are used to assess, collect requirements, detail project and product scope, create products, confirm scope and control scope in various ways.

3.Meeting The project team can participate in project meetings to develop the scope management plan. Attendees include the project manager, project sponsor, selected project team members, selected stakeholders, leaders of each scope management process, and other necessary personnel.

1. Scope Management Plan The scope management plan is the component of the project management plan that describes how the project scope will be defined, developed, monitored, controlled, and validated. The scope management plan guides the following processes and related work: ① Develop project scope statement; ②Create WBS based on detailed project scope statement; ③Determine how to approve and maintain scope benchmarks; ④Formally accept the completed project deliverables. Depending on the needs of the project, a scope management plan can be formal or informal, very detailed or high-level.

2. Demand management plan The requirements management plan is a component of the project management plan that describes how requirements will be analyzed, documented, and managed. The main contents of the demand management plan include: ①How to plan, track and report various demand activities; ② Configuration management activities, such as how to initiate changes, how to analyze their impact, how to trace, track and report, and change approval authority; ③Requirements prioritization process; ④Measurement indicators and reasons for using these indicators; ⑤Reflect which demand attributes will be included in the tracking matrix, etc.

1. Project management documents The project management document that affects the requirements gathering process is the document generated by the business case, which describes the necessary, expected and optional standards that should be met to meet business needs.

2. Project Charter The project charter documents the project overview and the high-level requirements that will be used to develop detailed requirements.

3. Project management plan Project management plan components used in gathering requirements include: ●Scope management plan: Contains information on how to define and develop the project scope. ●Requirements management plan: Contains information on how to collect, analyze and record project requirements. ●Stakeholder participation plan: Understand the communication needs and participation level of stakeholders from this plan in order to evaluate and adapt to the stakeholder's participation level in required activities.

4. Project documents Project documents that can be used as input to the requirements collection process mainly include: ●Assumption log: Identifies assumptions about the product, project, environment, stakeholders, and other factors that will affect requirements. ●Stakeholder register: Used to understand which stakeholders can provide demand-related information and record the stakeholders' needs and expectations for the project. ●Lessons Learned Register: Provides effective requirements gathering techniques, especially for projects using agile or adaptive product development methods.

5. Agreement The agreement will contain project and product requirements.

6. Business environment factors The business environment factors that will affect the demand collection process mainly include: organizational culture, infrastructure, personnel management system, market conditions, etc.

7. Organizational process assets Organizational process assets that will affect the requirements collection process mainly include: policies and procedures; historical information and lessons learned knowledge base containing past project information, etc.

1. Expert judgment During the process of collecting requirements, opinions should be sought from individuals or groups with relevant professional knowledge or relevant training in the following areas: Including: feasibility study and assessment; requirements elicitation; requirements analysis; requirements documents; project requirements from similar previous projects; diagramming techniques; guidance; conflict management, etc.

2. Data collection Data collection techniques that can be used in the project management plan process include: brainstorming, interviews, focus groups, questionnaires, and benchmarking.

3.Data analysis A data analysis technique that can be used in the requirements gathering process is document analysis. Document analysis refers to the review and evaluation of any relevant document information. In this process, document analysis is used to obtain requirements by analyzing existing documents and identifying information related to requirements. Documents that can be analyzed and help obtain requirements include: agreements; business plans; business process or interface documents; business Rule base; current processes; market literature; issue log; policies and procedures, regulatory documents such as laws, codes, ordinances, etc.; invitations to propose; use cases, etc.

4. Decision making Decision-making techniques suitable for the requirements gathering process mainly include: ●Voting: It is a decision-making technology and process for evaluating multiple future action plans in order to achieve a certain desired result. This technique is used to generate, categorize and rank product requirements. ●Autocratic Decision Making: With this approach, one person is responsible for making decisions for the entire group. ●Multi-criteria decision analysis: This technology uses a decision matrix to establish multiple criteria such as risk level, uncertainty and value benefit with a systematic analysis method to evaluate and rank many ideas.

5. Data presentation Data representation techniques that can be used in the requirements collection process mainly include: ● Affinity Diagram: A technique used to group a large number of ideas for further review and analysis. ●Mind map: Integrate the ideas obtained from brainstorming into a picture to reflect the commonalities and differences between ideas and stimulate new ideas.

6.Interpersonal and team skills Interpersonal and team skills that can be used in the requirements gathering process include: ●Nominal group technique: is a technique used to facilitate brainstorming by ranking the most useful ideas through voting for further brainstorming or prioritization. The nominal group technique is a structured form of brainstorming that consists of four steps: ①Ask a question or problem to the group, and everyone writes down their own thoughts after pondering; ②The host records everyone’s thoughts on the flip chart; ③Discuss various ideas collectively until all members reach a clear consensus; ④ Individuals vote privately to determine the priority of various ideas, usually using a 5-point scale, with 1 being the lowest and 5 being the highest. To reduce the number of ideas and focus on them, several rounds of voting can be conducted. After each round of voting, the votes are counted and the person with the highest score is chosen. ●Observation and conversation: refers to direct observation of how individuals perform work (or tasks) and implement processes in their respective environments. When product users are difficult or unwilling to articulate their needs, observation is particularly necessary to understand the details of their work. Observation, also known as "job shadowing," typically involves a sideline observer observing how a business expert performs his or her work, but can also be observed by a "participant observer," who experiences how a process or procedure works by actually executing it. implemented to uncover hidden needs. ●Facilitation: Facilitation is used in conjunction with theme workshops to bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile differences in requirements among stakeholders. Because of the characteristics of group interaction, effectively guided workshops help build trust, improve relationships, and improve communication among participants, thereby helping stakeholders reach consensus. Additionally, workshops enable problems to be identified and resolved earlier than in separate meetings.

7. System interaction diagram A system interaction diagram is a visual depiction of the product scope that visually displays business systems (processes, equipment, computer systems, etc.) and how they interact with people and other systems (actors).

8.Prototype method The prototyping method involves building a model of the intended product and soliciting early feedback on requirements before actually manufacturing the product. Prototypes include miniature products, computer-generated two- and three-dimensional models, physical models, or simulations. Because a prototype is a tangible object, it allows stakeholders to experience a model of the final product rather than being limited to discussing abstract requirements descriptions. The prototype method supports the concept of progressive detailing and requires an iterative process from model creation, user experience, feedback collection to prototype modification. After enough feedback loops, enough requirement information can be obtained through the prototype to enter the design or manufacturing phase. Storyboarding is a prototyping technique that illustrates a sequence or navigation path through a series of images or diagrams. Storyboards are used in a variety of projects across a variety of industries, such as film, advertising, instructional design, and agile and other software development projects. In software development, storyboards use mockups to illustrate the navigation path of a web page, screen, or other user interface.

1.Requirements document Only requirements that are clear (measurable and testable), traceable, complete, coordinated, and willing to be recognized by key stakeholders can be used as a baseline. Categories of requirements generally include: 1. Business needs: The high-level needs of the entire organization, for example, to solve a business problem or seize a business opportunity, and the reason for implementing the project. 2. Stakeholder needs: Stakeholder needs. 3. Solution requirements: The features, functions, and characteristics that a product, service, or result must have to meet business needs and stakeholder needs. Solution requirements are further divided into functional requirements and non-functional requirements: ①Functional requirements: describe the functions that the product should have, such as the actions, processes, data and interactions that the product should perform; ②Non-functional requirements: It is a supplement to functional requirements and is the environmental conditions or quality requirements required for the normal operation of the product, such as reliability, confidentiality, performance, security, service level, supportability, retention or removal, etc. 4. Transition and readiness needs: such as data conversion and training needs. These requirements describe the temporary capabilities required to transition from the "current state" to the "future state." 5. Project requirements: Actions, processes or other conditions that need to be met by the project, such as milestone dates, contractual responsibilities, constraints, etc. 6. Quality requirements: Any conditions or standards used to confirm the successful completion of project deliverables or the achievement of other project requirements, such as testing, certification, validation, etc.

2. Requirements tracking matrix ●The requirements tracing matrix is ​​a table that connects product requirements from their sources to the deliverables that satisfy the requirements. ●Use the requirements tracking matrix to link each requirement with business goals or project goals to help ensure that each requirement has business value. The requirements tracking matrix provides a way to track requirements throughout the project life cycle, helping to ensure that each approved requirement in the requirements document is implemented and delivered at the end of the project. The requirements tracking matrix also provides a framework for managing product scope changes. ●The content of tracking requirements includes: ①Business needs, opportunities, goals and objectives; ②Project goals; ③Project scope and WBS deliverables; ④Product design; ⑤Product development; ⑥Test strategy and test scenarios; ⑦High-level requirements to detailed requirements, etc. The relevant attributes of each requirement should be recorded in the requirements tracking matrix. These attributes help clarify the key information of each requirement. ●Typical attributes recorded in the requirements trace matrix include unique identification, text description of the requirement, reason for including the requirement, owner, source, priority, version, current status and status date. To ensure stakeholder satisfaction, additional attributes such as stability, complexity, and acceptance criteria may need to be added.

1. Project Charter The project charter contains a high-level description of the project, product features, and approval requirements.

2. Project management plan The project management plan component used in defining scope is the scope management plan, which documents how the project scope will be defined, validated, and controlled.

3. Project documents Project documents that can be used as input to the define scope process include: ●Assumption log: Identifies the assumptions and constraints related to the product, project, environment, stakeholders, and those that will affect the project and product scope. ●Requirements document: identifies the requirements that should be included in the scope. ●Risk Register: Contains response strategies that may affect the project scope, such as reducing or changing project and product scope to avoid or mitigate risks.

4. Business environment factors Business environment factors that will affect the scope definition process mainly include: organizational culture, infrastructure, personnel management systems, market conditions, etc.

5. Organizational process assets Organizational process assets that can affect the scope definition process mainly include: policies, procedures and templates used to develop project scope statements; project files from previous projects; lessons learned from previous phases or projects, etc.

1. Expert judgment During the scope definition process, individuals or groups with knowledge or experience on similar projects should be solicited for input.

2.Data analysis A data analysis technique that can be used in the scope definition process is alternatives analysis. Alternatives analysis can be used to evaluate various ways of achieving the needs and objectives stated in the project charter.

3.Decision making A decision-making technique that can be used to define the scope process is multi-criteria decision analysis. Multi-criteria decision analysis is a technique that uses systems analysis methods with the help of a decision matrix to establish multiple criteria such as requirements, schedule, budget, and resources to improve project and product scope.

4.Interpersonal and team skills A classic example of an interpersonal and team skill is facilitation. Use facilitation skills in workshops and focus groups to coordinate key stakeholders with different expectations or different expertise to achieve cross-functional consensus on project deliverables and project and product boundaries.

5. Product analysis (for products produced by the project) Product analysis can be used to define products and services and involves asking and answering questions about the product or service to describe the purpose, characteristics, and other aspects of the product to be delivered. Every application area has one or more generally recognized methods for transforming high-level product or service descriptions into meaningful deliverables. Start by capturing high-level requirements and then refine them to the level of detail required for the final product design. Product analysis technology mainly includes: product decomposition, demand analysis, system analysis, system engineering, value analysis, value engineering, etc.

1. Project Scope Statement The detailed project scope statement includes the following contents (listed directly or referenced from other documents): ●Product Scope Description: Gradually refine the product, service or outcome characteristics described in the project charter and requirements documents. ●Deliverables: Any unique and verifiable products, results or service capabilities that must be produced to complete a certain process, phase or project. Deliverables also include various auxiliary results, such as project management reports and documents. The description of the deliverables may be brief or detailed. ●Acceptance criteria (acceptance of outputs and processes): a series of conditions that must be met before the deliverables pass acceptance. ●Project Exclusions: Identify what is excluded from the project. Clearly stating what is outside the scope of the project helps manage stakeholder expectations and reduce scope creep. While there is some degree of overlap in the content of the project charter and the project scope statement, their level of detail is completely different. The project charter contains high-level information, while the project scope statement is a detailed description of the components of the scope that need to be progressively detailed over the course of the project.

2. Project files (updated) Project documents that can be updated during the define scope process include: ● Assumption log: As more assumptions or constraints are identified along with this process, the hypothesis log is updated. ●Requirements document: The requirements document can be updated by adding or modifying requirements. ●Requirements tracking matrix: The requirements tracking matrix should be updated along with the updates to the requirements documents. ● Stakeholder register: If more information about existing or new stakeholders is collected during the scope definition process, it is recorded in the stakeholder register.

1. Project Management Plan The project management plan component used in creating a WBS is the scope management plan. The scope management plan defines how the WBS will be created based on the project scope statement.

2. Project documents Project files that can be used as input to the WBS creation process mainly include: ●Requirements document: Describes in detail how various single requirements meet the business needs of the project. ●Project scope statement: describes the work that needs to be performed and the work that is not included in the project.

3. Business environment factors Enterprise environmental factors that will affect the process of creating a WBS include WBS standards for the industry in which the project is located, which can serve as external reference materials for creating a WBS.

4. Organizational process assets The organizational process assets that can affect the process of creating WBS mainly include: policies, procedures and templates used to create WBS; project files of previous projects; lessons learned from previous projects, etc.

1. Expert judgment During the creation of the WBS, input from individuals or groups with knowledge or experience on similar projects should be sought.

2. Decompose Decomposition is a technique for progressively dividing the project scope and project deliverables into smaller, more manageable components. ●The work package is the lowest level of work in WBS, and its cost and duration can be estimated and managed. ●The degree of decomposition depends on the degree of control required to achieve efficient management of the project. ●The level of detail in a work package will vary depending on the size and complexity of the project. ●There are many ways to create a WBS, with common methods including a top-down approach, using organization-specific guidelines, and using WBS templates. A bottom-up approach can be used to merge lower-level components.

1. Scope benchmark The scope baseline is the approved scope statement, WBS, and corresponding WBS dictionary, which can only be changed through a formal change control process, and is used as a basis for comparison. The scope baseline is an integral part of the project management plan. 1) Project scope statement The project scope statement includes a description of the project scope, key deliverables, assumptions, and constraints. 2)WBS The WBS is a hierarchical breakdown of the entire scope of work that the project team needs to perform to achieve the project goals and create the required deliverables. Each level down the work breakdown structure represents a more detailed definition of the project work. 3) Work package The lowest level of the WBS is the work package with a unique identification number. These identification numbers provide a hierarchical structure, known as account coding, for layer-by-layer aggregation of cost, schedule, and resource information. Each work package is part of a control account, which is a management control point. At this control point, scope, budget, and schedule are integrated and performance is measured compared to earned value. A control account contains two or more work packages, and each work package is associated with only one control account. 4) Planning package The planning package is a work breakdown structure component that is lower than the control account and higher than the work package. The work content is known, but the detailed progress activities are unknown. A control account can contain one or more planning packages. 5) WBS dictionary The WBS dictionary is a file that details deliverables, activities, and progress information for each component in the WBS. The WBS dictionary provides support for WBS, where most of the information is created by other processes and then added to the dictionary at a later stage. The content in the WBS dictionary generally includes: account code identification, work description, assumptions and constraints, responsible organization, schedule milestones, related schedule activities, required resources, cost estimates, quality requirements, acceptance criteria, technical references, Agreement information, etc.

2. Project files (updated) The project files that can be updated during the WBS creation process mainly include: ● Assumption log: updated as more assumptions or constraints are identified during the creation of the WBS. ● Requirements Document: Requirements documents can be updated to reflect changes proposed and approved during the creation of the WBS.

1. Project Management Plan The project management plan components used in confirming scope mainly include: ●Scope management plan: defines how to formally accept completed deliverables. ●Requirements management plan: describes how to confirm project requirements. ●Scope baseline: Compare the scope baseline with actual results to determine whether changes, corrective actions, or preventive measures are necessary.

2.Project files Project documents that can be used as input to the scope validation process mainly include: ●Requirements document: Compare requirements with actual results to determine whether changes are necessary and corrective or preventive measures should be taken. ●Requirements tracking matrix: Contains information related to requirements, including how to confirm requirements. ●Quality report: The content of this report can include all quality assurance matters managed by the team or that need to be reported, suggestions for improvement, and an overview of situations discovered during the quality control process. All of these need to be reviewed before acceptance of the product. ●Lessons Learned Register: Lessons learned early in the project can be applied to later stages to improve the efficiency and effectiveness of acceptance of deliverables.

3. Job performance data Work performance data may include the degree to which requirements are met, the number of inconsistencies, the severity of inconsistencies, or the number of verifications performed during a time period.

4. Verified deliverables Verified deliverables are those that have been completed and checked as correct by the control quality process.

1. Check (output results and project process,) Conduct activities such as measurement, review and validation to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes also called reviews, product reviews, inspections, etc.

2.Decision making A decision-making technique that can be used in the scope validation process is voting, which is used to form conclusions when acceptance is being conducted by the project team and other stakeholders.

1. Acceptance deliverables Deliverables that meet the acceptance criteria should be formally signed off by the client or sponsor. Formal documentation should be obtained from the client or sponsor demonstrating formal acceptance of the project deliverables by stakeholders. These documents will be submitted to the closing project or phase process.

2. Change request Deliverables that have been completed but have not passed formal acceptance and the reasons for failure should be documented. Change requests may need to be made for these deliverables and corresponding defect remediation work must be carried out. Change requests should be reviewed and handled by the Control Scope process.

3. Job performance information Work performance information includes project progress information, such as which deliverables have been accepted and which have failed and why. This information should be recorded and passed on to stakeholders.

4. Project files (updated) Project documents that can be updated during the scope confirmation process mainly include: ●Requirements document: record the actual acceptance results and update the requirements document. Special attention needs to be paid to situations where the actual results are better than the original requirements, or where the original requirements have been abandoned. ●Requirements tracking matrix: Update the requirements tracking matrix based on the acceptance results, including the acceptance methods used and their usage results. ● Lessons Learned Register: Update the Lessons Learned Register to record challenges encountered, how the challenge could have been avoided, and good deliverable acceptance practices.

1. Project management plan The project management plan components used in control scope mainly include: ●Scope management plan: records how to control project and product scope. ●Requirements management plan: records how to manage project requirements. ●Change management plan: Defines the process for managing project changes. ●Configuration management plan: defines which configuration items are configuration items, which configuration items require formal change control, and the change control process for these configuration items. ●Scope baseline: Compare the scope baseline with actual results to determine whether changes, corrective actions, or preventive measures are necessary. ●Performance measurement baseline: When using earned value analysis, the performance measurement baseline is compared with actual results to determine whether changes, corrective actions, or preventive actions are necessary.

2. Project documents Project documents that can be used as input to the control scope process mainly include: ●Requirements Document: Used to detect any deviations from the agreed project or product scope. ●Requirements tracking matrix: helps to explore the impact of any changes or any deviations from the scope baseline on the project goals. It can also provide the status of controlled requirements. ● Lessons Learned Register: Lessons learned early in the project can be applied to later stages to improve scope control.

3. Job performance data Work performance data may include the number of change requests received, the number of change requests accepted, or the number of deliverables verified, validated, and completed.

4. Organizational process assets Organizational process assets that can affect the scope of control process mainly include: existing, formal and informal policies, procedures and guidelines related to scope control; available monitoring and reporting methods and templates, etc.

data analysis Data analysis techniques that can be used for the control scope process include: ●Deviation analysis: used to compare the baseline with actual results to determine whether the deviation is within the critical value range or whether corrective or preventive measures are necessary. ●Trend analysis: Aims to examine changes in project performance over time to determine whether performance is improving or deteriorating. Determining the cause and extent of deviations from the scope baseline and deciding whether corrective or preventive measures need to be taken are important tasks of project scope control. How to reduce scope creep (passive) and gold plating (active) in scope management: ●Increase user engagement ●Reduce incomplete and changing requirements ●Use modern software to assist project scope management

1. Job performance information The work performance information produced by the control scope process is interrelated and contextualized information about how project and product scope is being implemented against the scope baseline, including classification of changes received, scope deviations identified and their causes, deviations Impact on schedule and cost, and predictions of future scope performance.

2. Change request After analyzing project performance, change requests may be made to the scope and schedule baselines, or other components of the project management plan. Change requests need to be reviewed and processed through the implementation of the overall change control process.

3. Project Management Plan (Updated) Any changes to the project management plan are raised in the form of a change request and processed through the organization's change control process. Project management plan components that may require change requests include: ●Scope management plan: Update the scope management plan to reflect changes in the way scope is managed. ●Scope baseline: After changes to the scope, scope statement, WBS, or WBS dictionary are approved, corresponding changes need to be made to the scope baseline. Sometimes scope deviations are so severe that the scope baseline needs to be revised to provide a realistic basis for performance measurement. ● Schedule Baseline: After changes to scope, resources, or schedule estimates are approved, corresponding changes need to be made to the schedule baseline. Sometimes schedule deviations are so severe that schedule baselines need to be revised to provide a realistic basis for performance measurement. ●Cost Baseline: After changes to scope, resources, or cost estimates are approved, corresponding changes need to be made to the cost baseline. Sometimes cost deviations are so severe that the cost baseline needs to be revised to provide a realistic basis for performance measurement. ●Performance measurement baseline: After changes to scope, schedule performance, or cost estimates are approved, corresponding changes need to be made to the performance measurement baseline. Sometimes performance deviations are so severe that a change request is required to revise the performance measurement baseline to provide a realistic and feasible basis for performance measurement. basis.

4. Project files (updated). Project documents that can be updated during the control scope process mainly include: ●Requirements document: The requirements document can be updated by adding or modifying requirements. ●Requirements tracking matrix: The requirements tracking matrix should be updated along with the updates to the requirements documents. ●Lessons Learned Register: Update the Lessons Learned Register to record effective techniques for control coverage, as well as the causes of deviations and corrective actions selected.