A Fuzzy QFD-Based Methodology for Systematic Generation IT Project Management Plan and Scope Plan Elements

Abstract

The study presents a methodology that supports the development of the Information Technology Project Management Plan (PMP) and Scope Plan (SP) elements by formulating structured sentences from Quality Function Deployment (QFD) outputs produced through the House of Quality (HoQ) matrix. Rather than proposing QFD as a new planning tool, the novelty lies in systematically mapping HoQ results to newly structured PMP and SP elements based on established standards and then transforming these results into planning statements through an integrated fuzzy logic layer. Additionally, the introduced fuzzy logic component addresses the uncertainty, prioritization needs, and subjectivity inherent in stakeholder inputs. This enables more accurate and consistent assistance in formulating plan elements, while strengthening the alignment between customer needs and project deliverables. Finally, the usefulness of the proposed methodology is demonstrated through an applied IT project case study that evaluates selected elements and highlights the concrete benefits of improving planning efficiency.

1. Introduction

The quality of early planning documents, especially the Project Management Plan (PMP) and Scope Plan (SP), is an important factor for successful project execution in software development. These documents determine the project’s objectives, constraints, stakeholder expectations, and technical direction. However, the creation of PMP and SP elements remains largely manual and subjective, often resulting in inconsistencies, limited traceability between stakeholder requirements and technical decisions, and variable planning quality depending on individual experience.

Progress in model-driven engineering (MDE), transformation chains, and artificial intelligence has raised automation to a higher level throughout various stages of the software development lifecycle. Nevertheless, most of these improvements focus on design, testing, or code generation, whereas the initial planning phase has received comparatively little automation support. As a result, there remains a gap in techniques that systematically produce PMP and SP content that is both valid and directly traceable to stakeholder requirements.

To address this gap, this paper proposes an approach that combines Quality Function Deployment (QFD) with fuzzy logic to support the structured generation of statements in PMP and SP elements. QFD, through the House of Quality (HoQ) matrix, establishes a formal connection between stakeholder needs and technical characteristics. Fuzzy logic complements this structure by handling the uncertainty, prioritization, and subjectivity present in stakeholder inputs. Together, these techniques provide a systematic way of converting qualitative expectations into coherent, prioritized, and traceable planning statements.

The increasing need to improve planning accuracy and stakeholder alignment raises a central research question for this work:

“How can the HoQ model, enhanced with fuzzy logic, be leveraged to generate traceable and prioritized PMP and SP elements from stakeholder requirements?”

To answer this question, the study makes the following contributions:

• Reorganization of PMP and SP elements according to established project management standards to ensure clarity, structure, and consistency across planning documents.
• Systematic mapping of PMP and SP elements to HoQ steps, enabling the identification of components that can be derived directly from QFD data and establishing a traceable link between stakeholder needs and planning outputs.
• Integration of fuzzy logic into the HoQ framework to prioritize stakeholder needs and mitigate the uncertainty and subjectivity associated with linguistic or qualitative inputs.
• Development of structured sentence-generation guidelines that transform fuzzy-enhanced HoQ outputs into textual descriptions of selected PMP and SP elements.
• Validation of the methodology through an applied IT project case study, demonstrating feasibility and practical benefits in planning efficiency, consistency, and traceability.

While the proposed fuzzy QFD methodology is conceptually applicable to a wide range of project types, this study focuses on IT projects due to their distinctive characteristics. IT projects are typically characterized by high requirement volatility, frequent stakeholder-driven changes, strong regulatory and compliance constraints, and a strong dependence on structured requirement-to-technical mappings. These properties make early-phase planning particularly sensitive to uncertainty and subjectivity, providing a rigorous and representative context for validation. The methodology itself is not limited to IT projects; however, the IT domain offers a realistic and demanding environment in which the benefits of fuzzy QFD-based PMP and SP generation can be clearly demonstrated.

The integration of QFD and fuzzy logic provides a systematic and traceable approach to deriving PMP and SP elements directly from stakeholder requirements, while improving alignment between customer expectations and project deliverables. The rest of the paper reviews the theoretical foundations of QFD and fuzzy logic, details the proposed methodology, and presents a case study that illustrates its practical application and effectiveness in improving planning accuracy and efficiency.

In contrast to existing QFD-based approaches that stop at prioritization or technical requirement translation, this research extends the process further by converting HoQ outputs into standardized PMP and SP text elements through fuzzy-logic-driven reasoning. This ensures that every generated planning statement remains traceable to stakeholder inputs, quantitatively prioritized, and aligned with recognized project management standards. In this sense, the contribution of the work is not the introduction of QFD to project planning, but the integration of mapping, fuzzy inference, and structured text synthesis into a unified and reproducible framework.

2. Background

This chapter reviews the key theoretical concepts underlying the study, including the Project Management Plan, Scope Plan, Quality Function Deployment, fuzzy logic, and the Mamdani inference engine.

2.1. IT Project Management Plan (PMP)

The Project Management Plan (PMP) serves as the foundational document that guides the execution and control of an IT project. Project management is defined as the application of knowledge, skills, tools, and techniques to project activities to meet project requirements [1]. According to the Project Management Institute (PMI), the PMP establishes the basis for all project work and acts as the authoritative reference for planning, monitoring, and decision-making throughout the project lifecycle [2].

The PMP integrates the processes of planning, organizing, monitoring, and controlling project activities to ensure objectives are met within the time, cost, and performance constraints specified [3]. Good project management practices focus on delivering results that are on time, within budget, and in accordance with the expectations of the stakeholders [1]. In PMBOK, 7th edition (2021) [4], PMI defines the PMP as an overarching document that collects several important parts of plans for the synchronized execution of the project [4]. These plans can consist of, but are not limited to

• Change control plan.
• Communications management plan.
• Cost management plan.
• Procurement management plan.
• Quality management plan.
• Requirements management plan.
• Resource management plan.
• Risk management plan.
• Scope management plan.
• Schedule management plan.
• Stakeholder engagement plan.

In practice, the PMP serves as the project’s architectural blueprint, defining the execution, quality control, and monitoring framework, as well as the project closure [4]. Additionally, the project management processes are facilitated by ISO/IEC/IEEE 15288 and 12207 [5], as well as PMI standards, which define the structure and requirements for a conforming PMP [5]. These standards position the PMP as a baseline document that directs project execution and continuous improvement while maintaining a complete and traceable change history. IEEE identifies the key components of a PMP as follows:

• Front Matter—Project identification, approvals, and change history.
• Project Overview—Purpose, scope, objectives, assumptions, constraints, deliverables, schedule, and budget.
• References and Definitions—All referenced documents and terminology.
• Project Context—Process model, tools, infrastructure, acceptance criteria, and communication structures.
• Project Planning—Estimation, staffing, scheduling, budgeting, procurement, and Work Breakdown Structure (WBS) development.
• Project Assessment and Control—Methods for monitoring and controlling requirements, scope, schedule, budget, quality, subcontractors, and closeout.
• Product Delivery—Distribution, documentation, packaging, and acceptance verification.
• Supporting Processes—Risk management, configuration management, quality assurance, measurement, verification, validation, and review/audit plans.
• Additional Plans—Domain-specific plans such as safety, security, maintenance, or training.

2.2. IT Scope Plan (SP)

The Scope Plan (SP) defines how the project scope will be identified, developed, verified, and controlled throughout the project lifecycle. Project scope establishes what is included in the Project Manager’s deliverables and, equally importantly, what falls outside the project boundaries [1]. As a management document, the Scope Plan provides the principles and procedures for ensuring consistent scope definition and control [2].

A well-defined scope is crucial when it comes to controlling project complexities and preventing risks that originate from unclear or negligent alterations. To prevent any misalignment, project goals and scope should be written down clearly, sanctioned by the stakeholders, and kept alive over the execution [1]. PMBOK, 7th edition (2021) [4], states that the Scope Plan usually contains three main sections:

• Scope Definition and Development
  • Specifies how the project scope (work performed) and product scope (features and functions) will be defined.
  • Establishes processes for analyzing, documenting, and managing requirements.
  • Describes how major deliverables and acceptance criteria are derived from the scope statement.
  • Uses decomposition typically through a Work Breakdown Structure (WBS) to break down work into manageable components.
  • In adaptive approaches, defines how high-level epics and features are refined into user stories and backlog items.
• Scope Monitoring and Control
  • Defines how the scope baseline (scope statement, WBS, and WBS dictionary) is established and maintained.
  • Sets mechanisms to prevent scope creep and ensure that only approved changes are incorporated into the baseline.
  • Describes validation processes for confirming stakeholder acceptance of completed deliverables.
• Validation and Acceptance
  • Outlines the procedures for formal acceptance of deliverables by stakeholders.
  • Ensures that acceptance criteria such as the Definition of Done or explicit quality thresholds are applied consistently during validation.

Requirements engineering plays a critical role by offering systematic processes for identifying, analyzing, and validating these evolving requirements, thereby supporting overall project success [6]. Scope change control and requirements management act as the primary mechanisms for assessing proposed changes, ensuring that modifications are evaluated for their impact on project objectives before approval [5]. Through these processes, the Scope Plan provides a structured framework that maintains alignment between stakeholder expectations and project deliverables throughout the project lifecycle.

Although PMP and SP frameworks are applicable across industries, their formulation in IT projects is particularly sensitive to requirement volatility, integration complexity, and compliance constraints, which motivates the use of structured, traceable approaches such as QFD.

2.3. Quality Function Deployment (QFD)

Quality Function Deployment (QFD) is a customer-driven methodology designed to systematically integrate quality into products, services, and processes from early design through delivery [6,7]. The main aim of QFD is to translate customer demands into measurable technical requirements that can be quantified [8], and it also makes sure the requirements are the basis of decision-making through the whole product or system life cycle [6,8]. It allows the project teams to examine the impact of technical features on customer satisfaction, to give importance to the various requirements, and to uphold a clear difference between project elements that are within the scope and those that are out of it [2,7].

Originally conceptualized by Yoji Akao in the late 1960s and formally introduced in 1966, QFD was first applied in practice at the Kobe shipyards of Mitsubishi Heavy Industries in 1972, where it appeared as “quality tables” [8,9]. It aligns closely with the principles of Concurrent Engineering by involving marketing, engineering, manufacturing, and quality assurance teams throughout the development process. QFD is typically structured into four major phases, each represented through matrix-based analysis that links customer needs to corresponding technical or process characteristics [10]:

• Product Planning (House of Quality)—Led by marketing, this phase captures customer needs, competitive benchmarking, and organizational capabilities.
• Product Design—Managed by engineering, translating customer requirements into part specifications and detailed design features.
• Process Planning—Overseen by manufacturing engineering, defining production methods, critical process parameters, and operational requirements.
• Process Control—Driven by quality assurance, establishing measurement systems, preventive maintenance schedules, and quality monitoring mechanisms.

The process flows from planning to manufacturing, and customer expectations are deployed in a systematic way; thus, product quality is improved and development risks are minimized [10].

The House of Quality (HoQ)

The House of Quality (HoQ) is a foundational tool within the QFD methodology that is designed to systematically translate customer desires into measurable engineering targets and product specifications [11]. The HoQ matrix is typically composed of several interconnected sections, forming a house-like diagram as shown in Figure 1 [12].

• Step 1: Customer Requirements—“Voice of the Customer” (VOC): These are the customer’s desires, needs, or desired qualities, typically listed on the left vertical axis of the matrix [1].
• Step 2: Regulatory Requirements: Management or regulatory standards applicable to the project are not part of the main diagram. This research introduces a method for documenting and linking these requirements with the main HoQ matrix.
• Step 3: Customer Importance Ratings: This section quantifies the relative importance of each customer requirement, often derived from customer surveys or feedback on a Likert scale [11].
• Step 4: Customer Rating of the Competition: Customer evaluations of competing products or services to identify strengths, weaknesses, and opportunities.
• Step 5: Technical Descriptors—“Voice of the Engineer” (VOE): Measurable technical attributes that translate customer needs into engineering terms. These descriptors can be benchmarked against competitors or newly created to ensure that product specifications align with customer requirements.
• Step 6: Direction of Improvement: The technical descriptor should increase, decrease, or be maintained, guiding the team on how improvements should progress to meet customer needs.
• Step 7: Relationship Matrix: Strength of relationships between customer needs and technical descriptors, rated as weak (1), moderate (3), or strong (9), to show how well each need is addressed.
• Step 8: Organizational Difficulty: Organizational difficulty of each attribute, considering internal conflicts or constraints that may affect implementation.
• Step 9: Technical Analysis of Competitor Products: Analyzing competitor products by comparing technical attributes, often through reverse engineering, to identify specific competitor benchmarks.
• Step 10: Target Values for Technical Descriptors: Sets target values for each technical descriptor, defining benchmark levels that guide design and comparison.
• Step 11: Correlation Matrix: Evaluates the relationships between technical descriptors to identify strong and negative connections.
• Step 12: Absolute Importance: Evaluates each technical descriptor by combining relationship strength with customer importance, identifying which aspects matter most to the customer.

2.4. QFD’s Contribution to Improving Accuracy and Consistency in PMP and SP

QFD is uniquely positioned to support the generation of PMP and SP elements because it systematically transforms vague stakeholder expectations into explicit, measurable, and verifiable technical requirements. This translation, mediated through the HoQ, creates a structured foundation for automation by converting subjective inputs into objective data that can drive planning decisions [8]. The resulting engineering targets are prioritized using quantitative measures such as absolute importance, providing the analytical basis for allocating resources, defining verification methods, and sequencing project activities and core components of PMP sections relating to scope, schedule, and quality assurance [1,7].

Unlike generic planning frameworks, QFD’s primary output is a set of prioritized, measurable engineering targets [5]. Also, a key advantage is its emphasis on traceability. Each customer requirement is linked through the HoQ to corresponding technical specifications and, ultimately, to project deliverables. This traceable chain supports automated requirements management and helps maintain alignment between generated plan components and stakeholder expectations, reducing the risk of requirement drift or misinterpretation [7].

In Agile software development and startup environments, QFD complements iterative, customer-driven frameworks by translating User Stories into measurable technical attributes. Through the relationship matrix, QFD computes Offset values that represent customer satisfaction and guide sprint prioritization. These values enable teams to deliver high-impact features earlier, improving responsiveness and product relevance. Practical applications such as Check4Green, Vitraly, and Lemur demonstrate how QFD improves planning accuracy, prioritization, adaptability, and organizational clarity in startup settings [13].

QFD has not only been applied to product planning but also to software process models in a formal way in order to improve project governance. The combination of Capability Maturity Model Integration (CMMI)-QFD provides a systematic way of ranking process improvements according to maturity goals that are tied to business needs. Using QFD, five critical process areas: Project Monitoring and Control, Requirements Management, Project Planning, Requirements Development, and Processes that lead to improvement actions such as standardizing project reports and management plans [14].

Similarly, integrating QFD with the Project Management Maturity Model (PMMM) enables continuous quality improvement in cloud environments. Customer requirements for distributed systems, e.g., automated data backup, cost calculation, and resource integration, constitute the “WHATs” of the House of Quality (HoQ) and the project management processes (“HOWs”) that are associated with these needs in order to define the quality relationship that can be measured [15]. This combined approach supports sustainable process enhancements and the deployment of project practices that have already been developed and tested.

Finally, because QFD explicitly links requirements to verification criteria, it naturally supports the automated generation of SP sections related to acceptance criteria, validation methods, and success metrics [16]. Thus, the HoQ does more than inform project planning; it provides the structured, quantifiable input required for automated, traceable, and stakeholder-aligned creation of PMP and SP elements.

2.5. Fuzzy Logic

Fuzzy logic is frequently integrated with QFD in order to improve decision-making in project management [11]. This method changes uncertain linguistic descriptions into fuzzy numbers, which are then subjected to mathematical operations [17]. Fuzzy logic is found to be the most suitable tool for dealing with imprecise, subjective, and uncertain information, as it can provide mathematical solutions unlike the traditional crisp values, which are often insufficient in these areas. In contrast to traditional mathematical logic, which cannot handle subjective terms like “very important” and “strong relationship” effectively, fuzzy logic turns statements into numeric values that can be computed [17].

Fuzzy set theory, when applied alongside QFD and Knowledge Management Systems (KMSs), supports decision-making by improving the quality of design solutions, particularly in domains where assessments are highly subjective, such as building design [18]. It also enables the application of mathematical operators and computational procedures directly to fuzzy domains [19].

The Mamdani Fuzzy Inference System

The Mamdani fuzzy inference system, also known as the Mamdani–Assilian controller—was introduced by E. H. Mamdani and S. Assilian in their 1975 study “An Experiment in Linguistic Synthesis with a Fuzzy Logic Controller” [20].The purpose of their work was to translate human control strategies into a fuzzy logic-based model that could be executed automatically, originally demonstrated on a steam engine controller.

The system operates using four core procedures:

• Fuzzification, where numerical inputs are transformed into fuzzy sets;
• Rule evaluation, which applies IF–THEN rules, typically using the minimum operator;
• Aggregation, where outputs from all rules are combined using the maximum operator;
• Defuzzification, where a crisp output value is derived to represent the final decision.

The Mamdani model demonstrated strong capability for handling nonlinear systems and became one of the most widely adopted frameworks for fuzzy reasoning [20].

3. Related Works

This section synthesizes key contributions in the domain of fuzzy logic-integrated Quality Function Deployment (QFD), focusing on how the current literature uses fuzzy methodology to deal with uncertainty, rank needs, and enable decisions. The author traces the basics and restrictions that underlie the creation of the suggested fuzzy QFD technique by scrutinizing instances in project scheduling, design evaluation, and software development.

3.1. Fuzzy QFD for Project and Process Optimization

Shih-Ming Yang, Yu-Chuan Liu, and Ting-Yu Yen [21] proposed a cross-disciplinary application of fuzzy logic and QFD that successfully addressed Critical Chain Project Scheduling Under Uncertainty. They represented project uncertainties as customer attributes (CAs) and project activities as engineering characteristics (ECs) within the HoQ framework, respectively. To express the uncertainty levels, they used linguistic terms such as Very Low, Low, Medium, High, and Very High, which were later converted into fuzzy numbers to calculate the “degree of fuzziness” of each activity. This value was then used to help decision-making determine the amount of buffer time, thus allowing the schedule to more readily adjust to different levels of certainty. Their findings indicated that the QFD–fuzzy scheduling method leads to a noticeable reduction in the project’s total duration compared to PERT methods and the critical chain strategy in general.

Lian-Yin Zhai, Li-Pheng Khoo, and Zhao-Wei Zhong [17] developed a rough set-based QFD framework to address imprecise and incomplete information in product development. Their approach uses fuzzy set theory, Symmetrical Triangular Fuzzy Numbers (STFNs), to represent linguistic assessments of customer needs and technical attributes. Their approach ensures the accuracy and reliability of design decisions by integrating fuzzy weighted averages and expected value operators in situations where input information is uncertain.

Natee Singhaputtangkul [18] designed a decision-support tool that applies Fuzzy Set Theory to a QFD structure and thus makes building design evaluation easier. The tool incorporates a “Fuzzy Room” that has fuzzy computation algorithms and an inference engine so that decision-makers can convert unclear or qualitative requirements into more systematic evaluations. Consequently, it is easier to prioritize building materials and design options, which improves the overall process of dealing with uncertainty and subjective judgments among designers.

One recent study by Matheus Henrique Kupka, Anderson Luis Szejka, and Eduardo de Freitas Rocha Loures [22] applies fuzzy QFD as a structured mechanism for evaluating and prioritizing innovation projects under conditions of ambiguity and incomplete stakeholder information. In this work, the authors develop a Maturity Analysis and Prioritization framework for Innovation Projects (MAPIP), where qualitative expert judgments regarding project benefits, feasibility, viability, and strategic alignment are expressed using linguistic terms and converted into fuzzy numbers. These fuzzy values are then integrated into the House of Quality, with project evaluation criteria positioned on the WHAT side and maturity assessment parameters on the HOW side, allowing relationships to be quantified with fuzzy relationship weights. By aggregating and defuzzifying these assessments, the model computes priority indices that effectively rank projects according to strategic potential and readiness for implementation, demonstrating robustness in prioritizing projects with multiple characteristics under uncertainty.

Another study by Majdi Beseiso and Gulshan Kumar [23] extends the application of fuzzy QFD from single project evaluation to project portfolio selection by integrating fuzzy logic, Quality Function Deployment, and a Genetic Algorithm (GA). The proposed method consists of three stages: (1) eliciting expert evaluations of organizational objectives and selection criteria in fuzzy form; (2) using fuzzy QFD to prioritize these criteria by converting linguistic assessments into fuzzy numbers and calculating weighted importance values across the HoQ matrix; and (3) applying a GA-based optimization model that evaluates candidate projects concurrently, using a fitness function designed to account for both criteria priorities and interdependencies among projects. This integrated fuzzy QFD–GA framework produces portfolio rankings that are more rational, consistent, and explainable compared with traditional deterministic decision methods, particularly in contexts with incomplete and ambiguous information.

3.2. Fuzzy QFD for Design Prioritization and Decision Support

Yigit Kazancoglu and Murat Aksoy [19] applied fuzzy-logic-based QFD to identify and prioritize critical factors in e-learning design under subjective, uncertain expert judgments. Their model uses linguistic variables such as VH (Very High), H (High), M (Medium), L (Low), and VL (Very Low), which are converted into Triangular Fuzzy Numbers (TFNs) to evaluate customer requirements (WHATs), relationships with technical requirements (HOWs), and interrelationships among HOWs. These fuzzy assessments are aggregated using the geometric mean, and the resulting values are defuzzified through the Converting Fuzzy data into Crisp Scores (CFCS) method to produce crisp priority scores. Their approach systematically reduces vagueness in expert input and highlights the most influential design factors.

Further contributions in the literature extend the use of fuzzy QFD into broader decision-support applications. Farahbod Mohammadi, Mohammadali Kazerooni Sadi, Fatemeh Nateghi, Arham Abdullah, and Martin Skitmore [9] introduced a hybrid QFD–Cybernetic Analytic Network Process (CANP) methodology for project manager selection, integrating QFD’s customer-oriented prioritization with the CANP’s analytical structure to enhance decision-making accuracy. Studies have advanced QFD by incorporating fuzzy Analytic Network Process (ANP) models, enabling the evaluation of interdependent criteria under uncertainty. Moreover, fuzzy optimization models have been used in QFD to handle linguistic preferences, provide support for the selection of subjective criteria, and facilitate the process of comparing different design solutions when there is uncertainty in the decision-making process.

One study by Ashish K. Sharma, Neha Purohit, and Shruti Thakur [24] introduces a web-based fuzzy QFD decision support system designed to assist in the early stages of product and system design. In this framework, customer requirements expressed using linguistic terms (e.g., high, medium, low) are converted into fuzzy numbers, which are then mapped into the House of Quality to generate technical attribute priorities. The web platform allows stakeholders to input qualitative requirements and visualize fuzzy relationship strengths between customer needs and design features. By applying fuzzy aggregation and defuzzification, the system produces a ranked list of prioritized design attributes, enabling collaborative decision-making in scenarios where precise numerical data are absent. This work demonstrates the potential of integrating fuzzy computation into digital QFD platforms to improve transparency and consistency in design trade-off decisions, particularly in multidisciplinary design teams.

3.3. Fuzzy QFD in Software Engineering and Requirements Analysis

Hao-Tien Liu [25] introduces a Product Design and Selection (PDS) method that combines Fuzzy Quality Function Deployment (QFD) with Fuzzy Multi-Criteria Decision-Making (MCDM) techniques. This method addresses uncertainty and imprecision in customer requirements and design evaluations. In Phase 1, customer requirements are translated into Engineering Characteristics (ECs) using fuzzy set theory, and linguistic variables are represented as Triangular Fuzzy Numbers (TFNs). The model applies α-cut operations, pairwise comparisons, competitive analysis, and adjustment of EC importance based on improvement ratios. The ECs are then ranked using Chen and Lu’s fuzzy ranking method. Phase 2 (Fuzzy MCDM) is directed at selecting the best prototype among the Phase 1 outcomes and factors such as cost, technical difficulty, and extensibility. The decision problem is modeled as a Fuzzy Linear Programming (FLP) model, then transformed into a crisp Linear Programming (LP) problem in order to find the best solution. Sensitivity analysis of α-cut values allows coverage of different confidence levels, ensuring a flexible and informed product development system.

A Fuzzy Analytic Hierarchy Process (AHP)–QFD integrated approach has been suggested by Tuli Bakshi, Bijan Sarkar, and Subir Kumar Sanyal [26] for software project selection under uncertainty. The proposed technique employs classical AHP and QFD within a fuzzy setting to enhance both accuracy and consistency. The method incorporates three stages: (1) Fuzzy AHP (f-AHP) for linguistic evaluation of Customer Requirements (CRs) utilizing TFNs and Chang’s extent analysis method; (2) translation of CR weights into Technical Requirements (TRs) through the HoQ to compute overall performance scores and project rankings; (3) sensitivity analysis of design, implementation, and maintenance costs to assess economic robustness. This model places subjective judgments on the same level as objective measures, allowing for project selection that is free of bias and flexible in uncertain situations.

Collectively, these studies indicate that fuzzy QFD remains an evolving and relevant research direction across software engineering, product design, and decision-support domains. However, none of this work addresses the automated transformation of HoQ outputs into standardized Project Management Plan (PMP) or Scope Plan (SP) elements, which distinguishes the focus of the present research.

3.4. Research Gap

The literature confirms that fuzzy Quality Function Deployment (QFD) is a robust and well-established mechanism for handling uncertainty, managing subjective judgments, and translating qualitative stakeholder input into prioritized technical outputs. Existing studies have successfully applied fuzzy QFD in domains such as product design, software engineering, project selection, scheduling, and decision support, demonstrating its effectiveness in requirement prioritization and evaluation under uncertainty.

Recent studies published between 2020 and 2025 further confirm that fuzzy QFD remains an active research area. However, the focus of this body of work remains predominantly on prioritization, selection, and design optimization problems, where QFD outputs are used primarily as ranking or decision-support indicators. The downstream utilization of House of Quality (HoQ) results, particularly their transformation into structured, standards-aligned project management documentation, has received limited attention.

In particular, no prior study explicitly addresses the systematic transformation of QFD outputs into formal project management artifacts such as the Project Management Plan (PMP) or the Scope Plan (SP). Moreover, existing approaches do not establish a traceable and computational pipeline that links stakeholder requirements, fuzzy QFD inference, and the generation of planning text that conforms to recognized project management standards.

This gap motivates the present study, which develops and validates a fuzzy logic-enhanced QFD framework aimed specifically at generating traceable, prioritized, and stakeholder-aligned PMP and SP elements directly from HoQ data. By extending fuzzy QFD beyond prioritization toward structured document synthesis, the proposed methodology advances the practical applicability of QFD in IT project planning and contributes a novel, reproducible approach to early-phase project documentation.

4. Materials and Methods

This section discusses the methodological procedures used to develop the fuzzy QFD-based framework for generating sentences for PMP and SP elements. It details how QFD outputs were structured, processed, and mapped to specific project management components to support formulating.

4.1. Mapping QFD to PMP and SP Elements

This section presents a structured methodology to map elements of the PMP and SP to the 12 steps of the House of Quality (HoQ). While QFD has been widely used across industries, this methodology specifically targets IT projects, which are characterized by high requirement volatility, complex system integration, and regulatory constraints. The novelty of this approach lies in systematically identifying which PMP and SP sub-elements can be generated from structured HoQ inputs, providing a traceable foundation for subsequent automation.

To begin, both the PMP and SP were decomposed into detailed sub-elements based on globally recognized standards, including the PMBOK Guide [4], IEEE Std 16326:2019 [5], Latvian Standards LVS 75:1996 (SP) [27] and LVS 67:1996 (PMP) [28]. This decomposition included sections such as the scope statement, risk management, deliverables, assumptions, stakeholder roles, and requirements breakdown.

Next, each of these sub-elements was evaluated regarding its possible alignment with the data in the HoQ structure and aligned with fuzzy logic prioritization. A three-level classification was used to guide this screening:

• Direct Match: There is a rather strong correspondence between a sub-element and one or several steps of HoQ, and so one can be generated within the given methodology;
• Partial Match: An indirect alignment in that HoQ data partially supports this, but needs to collect data from external sources.
• No Match: Sub-elements out of the scope of the proposed QFD and fuzzy methodology, such as resource assignment, budget, scheduling, and approval from an organization.

The sub-elements of the PMP and SP were systematically evaluated against all 12 HoQ steps, and the results were recorded as per the degree of correspondence in a traceable scheme of “Yes,” “Partially,” or “No.” These comparisons can be seen in

Table 1. Availability of relevant data and feasibility of generation PMP.

Title	Subtitle	Third-Level Subtitle	Generation from HoQ
1. Overview	1.1 Project Summary	1.1.1 Purpose, Scope, and Objectives	Yes
		1.1.2 Assumptions and Constraints	Yes
		1.1.3 Schedule and Budget Summary	No
	1.2 Project Deliverables		Yes
	1.3 Evolution of the Plan	1.3.1 Updates and Adaptation Strategies	No
	1.4 References		No
	1.5 Definitions		No
2. Project Organization	2.1 Process Model		Partially
	2.2 Project Organizational Structure (Internal interfaces)		No
	2.3 Organizational Boundaries and Interfaces (External interfaces)		No
	2.4 Project Roles and Responsibilities		No
3. Management Processes	3.1 Project Scope and Priorities	3.1.1 Project Initiation	Yes
		3.1.2 Estimation	Partially
		3.1.3 Resource Acquisition	No
		3.1.4 Project Staff Training	No
	3.2 Assumptions, Dependencies, and Restrictions	3.2.1 Assumptions	Partially
		3.2.2 Dependencies	Partially
		3.2.3 Restrictions	Partially
	3.3 Risk Management (Identification, assessment, and mitigation plans)	3.3.1 Risk Identification	Yes
		3.3.2 Risk Assessment	Yes
		3.3.3 Risk Mitigation Plans	No
	3.4 Monitoring and Control Mechanisms	3.4.2 Reporting Plan	No
		3.4.3 Quality Assurance	Yes
		3.4.4 Performance Measurement	Yes
	3.5 Staffing Plan	3.5.1 Staffing Strategy	No
	3.6 Project Work Plans	3.6.1 General Overview	Yes
		3.6.2 Work Activities	Yes
		3.6.3 Schedule Allocation (Timetable	No
		3.6.4 Resource Allocation	Partially
		3.6.5 Budget Allocation	Partially
	3.7 Control Plan (Project Assessment and Control)	3.7.1 Requirements Management	Yes
		3.7.2 Schedule Control	No
		3.7.3 Budget Control	Partially
		3.7.4 Quality Control Plan (Measurement)	Yes
		3.7.5 Communication Plan	No
		3.7.6 Project Measurements and Metrics Collection Plan	Partially
		3.7.7 Project Closeout	No
	3.8 Change Management (Structured approach for handling project changes)		No
4. Technical and Supporting Processes	4.1 Methods, Tools, and Techniques		Partially
	4.2 Software Documentation		No
	4.3 Project Support Functions	4.3.1 Software Configuration Management (SCM)	No
		4.3.2 Software Quality Assurance	Yes
		4.3.3 Process Improvement	No
	4.4 Reviews and Audits		Partially
	4.5 Verification and Validation		Yes

and

Table 2. Availability of relevant data and feasibility of generation SP.

Title	Subtitle	Third-Level Subtitle	Generation from HoQ
1. Introduction	1.1 Purpose of Scope Management	1.1.1 Define project needs and alignment with objectives	Yes
		1.1.2 Address key challenges and scope risks	Yes
	1.2 Scope Plan Coverage	1.2.1 Key scope management activities	Partially
		1.2.2 Applicability across project phases	No
	1.3 Project Context	1.3.1 Industry and regulatory considerations	Partially
		1.3.2 Stakeholder roles and constraints	No
2. Scope Statement	2.1 Project Objectives	2.1.1 High-level goals and success criteria	Yes
		2.1.2 Alignment with business strategy	Partially
	2.2 Deliverables	2.2.1 Key outputs and specifications	Yes
		2.2.2 Deadlines and dependencies	No
	2.3 Boundaries	2.3.1 Inclusions and exclusions	Partially
		2.3.2 Scope change management process	No
	2.4 Acceptance Criteria	2.4.1 Success metrics and testing approach	Yes
		2.4.2 Sign-off procedures	No
3. Scope Management Process	3.1 Scope Planning	3.1.1 Approach and roles	No
		3.1.2 Tools and timeline	No
	3.2 Scope Definition	3.2.1 Deliverables and constraints	Yes
		3.2.2 Assumptions validation	Partially
	3.3 Scope Control	3.3.1 Change management workflow	No
		3.3.2 Impact analysis and baseline updates	Partially
4. Requirements and Work Breakdown	4.1 Stakeholder Requirements	4.1.1 Key needs and prioritization	Yes
		4.1.2 Functional vs. non-functional specs	Yes
	4.2 Work Breakdown Structure (WBS)	4.2.1 Major components and deliverables mapping	Yes
		4.2.2 WBS dictionary (roles/resources)	No
5. Roles and Responsibilities	5.1 Stakeholder Accountability	5.1.1 Key roles and decision-making authority	No
		5.1.2 Reporting structure	No
6. Assumptions and Constraints	6.1 Key Assumptions	6.1.1 Resource and timeline assumptions	No
		6.1.2 External factors (market/regulatory)	Partially
	6.2 Constraints	6.2.1 Budget, time, and resource limits	Partially
		6.2.2 Mitigation strategies	Partially
7. Risk Management	7.1 Scope Risks	7.1.1 Scope creep and misalignment risks	Yes
		7.1.2 Monitoring tools (e.g., risk matrices)	No
	7.2 Mitigation Plans	7.2.1 Change control processes	No
		7.2.2 Regular Risk Monitoring reviews	No
8. Verification and Closure	8.1 Scope Verification	8.1.1 Acceptance criteria and testing	Partially
		8.1.2 Documentation and stakeholder sign-off	No
	8.2 Appendices	8.2.1 Glossary and references	No
		8.2.2 Supporting documents	No

for all main topics and subtopics up to the third-level hierarchy.

Finally, the validated matches were compiled into a structured comparison matrix in

Table 3. PMP vs. HoQ steps that contain relevant data.

Element	S1	S2	S3	S4	S5	S6	S7	S8	S9	S10	S11	S12
1.1.1 Purpose, Scope, and Objectives	✓		✓		✓		✓	✓		✓		✓
1.1.2 Assumptions and Constraints		✓			✓			✓		✓		✓
1.2 Project Deliverables	✓		✓		✓		✓			✓		✓
3.1.1 Project Initiation	✓	✓			✓			✓				✓
3.1.2 Estimation					✓			✓		✓		✓
3.2.1 Assumptions		✓			✓			✓		✓		✓
3.2.2 Dependencies					✓			✓		✓	✓	✓
3.2.3 Restrictions		✓			✓			✓		✓		✓
3.3.1 Risk Identification		✓			✓			✓		✓	✓	✓
3.3.2 Risk Assessment	✓	✓			✓		✓	✓		✓	✓	✓
3.4.3 Quality Assurance		✓			✓			✓		✓	✓	✓
3.4.4 Performance Measurement	✓	✓			✓		✓			✓	✓	✓
3.6.1 General Overview (Project Work Plans)	✓		✓		✓		✓			✓		✓
3.6.2 Work Activities	✓		✓		✓		✓	✓		✓		✓
3.6.4 Resource Allocation	✓				✓		✓	✓		✓		✓
3.6.5 Budget Allocation	✓				✓		✓	✓		✓		✓
3.7.1 Requirements Management	✓	✓	✓		✓		✓			✓		✓
3.7.3 Budget Control	✓				✓		✓	✓		✓		✓
3.7.4 Quality Control Plan (Measurement)	✓	✓	✓		✓		✓	✓		✓	✓	✓
3.7.6 Project Measurements and Metrics Collection Plan	✓	✓			✓		✓	✓		✓	✓	✓
4.1 Methods, Tools, and Techniques	✓				✓		✓			✓		✓
4.3.2 Software Quality Assurance	✓	✓	✓		✓		✓	✓		✓	✓	✓
4.4 Reviews and Audits	✓	✓	✓		✓		✓					✓
4.5 Verification and Validation	✓	✓	✓		✓		✓			✓	✓	✓

and

Table 4. SP elements vs. HoQ steps that contain relevant data.

Element	S1	S2	S3	S4	S5	S6	S7	S8	S9	S10	S11	S12
1.1.1 Define project needs and alignment with objectives	✓		✓		✓		✓
1.1.2 Address key challenges and scope risks		✓						✓		✓	✓	✓
1.2.1 Key scope management activities	✓				✓	✓	✓	✓
1.3.1 Industry and regulatory considerations		✓
2.1.1 High-level goals and success criteria	✓		✓		✓		✓					✓
2.1.2 Alignment with business strategy	✓		✓		✓		✓					✓
2.2.1 Key outputs and specifications					✓		✓	✓		✓		✓
2.3.1 Inclusions and exclusions	✓				✓			✓				✓
2.4.1 Success metrics and testing approach	✓				✓		✓	✓		✓		✓
3.2.1 Deliverables and constraints	✓	✓			✓		✓	✓		✓		✓
3.2.2 Assumptions validation	✓				✓		✓	✓				✓
3.3.2 Impact analysis and baseline updates	✓	✓			✓		✓	✓		✓	✓	✓
4.1.1 Key needs and prioritization	✓		✓		✓		✓			✓		✓
4.1.2 Functional vs. non-functional specs	✓	✓	✓		✓		✓			✓		✓
4.2.1 Major components and deliverables mapping	✓				✓		✓	✓		✓		✓
6.1.2 External factors (market/regulatory)	✓	✓			✓			✓				✓
6.2.1 Budget, time, and resource limits					✓			✓				✓
6.2.2 Mitigation strategies	✓	✓	✓		✓			✓				✓
7.1.1 Scope creep and misalignment risks	✓				✓		✓	✓			✓	✓
8.1.1 Acceptance criteria and testing	✓	✓			✓		✓			✓		✓

. This matrix illustrates which HoQ steps, as shown in Figure 1—HoQ steps, provide the underlying data for generating specific PMP and SP elements. Specify the exact QFD inputs that must be extracted to enable fuzzy computation and derive fundamental project components like objectives, deliverables, assumptions, and risk responses. The matrix also highlights planning areas where QFD does not apply, indicating the need for complementary project management tools.

The following tables, Table 3 and Table 4, represent the mapping of PMP and SP elements (in the first column) to the 12 HoQ, as in Steps S1–S12 (Figure 1). A checkmark (✓) indicates that the corresponding PMP or SP element contains relevant data derived from, or influenced by, the respective HoQ steps. This traceable scheme ensures that the mapping is reproducible and not ad hoc.

4.2. A Fuzzy Logic-Based Methodology for QFD to Generate PMP and SP Elements

Producing meaningful PMP and SP content from the HoQ requires more than predefined sentence templates. The HoQ contains subjective judgments and imprecise numeric evaluations such as customer importance, regulatory links, and technical difficulty, that become misleading if treated only as fixed numeric thresholds. Fuzzy logic is therefore introduced to reason over this uncertainty first, after which the results can be converted into crisp planning outputs.

To address this challenge, the proposed methodology applies fuzzy logic to structure the interpretation of HoQ inputs. Membership functions and fuzzy rules are used to manage the mixture of qualitative and quantitative data, following the computational framework described by Kulkarni’s Computer Vision and Fuzzy-Neural Systems (2001) [29], and adapting it to project-planning needs. This enables custom logic for each plan element, for example, Quality Assurance, Project Deliverables, or Requirements so that generated content remains contextually meaningful and reflects the unique priorities of each section. By evaluating the combined influence of multiple HoQ attributes, the system dynamically generates sentences that are targeted, contextually relevant, and priority-aware, far beyond what static templates or rigid rules can provide.

The five-phase process shown in Figure 2 extends traditional QFD by incorporating fuzzy logic to translate HoQ data into practical project-planning elements. In this way, customer needs are prioritized, technical linkages are clarified, and requirements are evaluated to support more robust PMP and SP generation.

4.2.1. Phase 1: Collect and Label Information from HoQ

The methodology begins by systematically extracting data from the QFD structure, specifically the HoQ matrix, which forms the foundation for subsequent processing. As a working example, a filled HoQ for a Travel Planning application is used, as shown in Figure 3, and

Table 5. Regulatory requirements.

No	Regulatory Requirement	Connected VoE	Importance
Reg1	Compliance with General Data Protection Regulation (GDPR)	VoE6	0.8
		VoE7	0.6
		VoE8	0.7
Reg2	Payment Card Industry Data Security Standard (PCI DSS) compliance	VoE6	1.0
Reg3	Accessibility standards (e.g., WCAG 2.1 Level AA)	VoE1	0.9
Reg4	Mobile app store policies (Google Play and Apple App Store)	VoE1	0.8
		VoE6	0.7
		VoE9	0.9
Reg5	Travel industry regulations (e.g., EU/US travel insurance and itinerary rules)	VoE4	0.6
		VoE5	0.7
Reg6	Geo-location data use consent	VoE5	0.9
		VoE7	0.6
Reg7	Electronic Transactions Act/E-signature compliance	VoE6	0.8
Reg8	Third-party API terms of service (e.g., Google Maps, Booking.com APIs)	VoE3	1.0
		VoE5	0.7
Reg9	Consumer protection laws (e.g., refund policy transparency, misleading content)	VoE2	0.6
		VoE4	0.7

shows Step 2: Regulatory Requirements.

The project provides an improved structure of the traditional QFD by introducing a new Step 2 (Regulatory Requirements) table layout, in which regulations are systematically mapped to the relevant customer needs (VoEs) and assigned an importance score, as shown in Table 5. In this step, a 0–1 scoring scale is used by design (rather than the traditional 1–10 scale) because it is easier to integrate into fuzzy inference, simplifies weighting, and reduces subjective dispersion. This scale is therefore not the result of mathematical normalization, but a deliberate modeling choice that keeps the regulatory assessments clear and comparable.

By linking regulations to VoEs and weighting their relevance, the most critical compliance aspects are prioritized in subsequent technical responses and planning decisions. This structured approach increases traceability, ensures stronger legal alignment, and improves the regulatory coverage of the PMP and SP elements generated from the HoQ.

In this process, the way each data point was labeled is presented in

Table 6. HoQ data label summary.

Step	Title	Example Label
1	Customer Requirements (VoC)	VoC1: Easy-to-Use Interface
2	Regulatory Requirements	Reg1: GDPR Compliance
3	Importance Ratings	VoC1: 9
5	Voice of Engineer (VoE)	VoE1: User-friendly UI/UX design
6	Improvement Directions	VoE1: ▲1
7	Relationship Matrix (VoC–VoE)	(VoC1, VoE1): ⊙9
8	Organizational Difficulty	VoE1: 3
10	Technical Targets	target1: Avg. usability score ≥ 85/100
11	Correlation Matrix (VoE–VoE)	(VoE1, VoE2): +1
12	Absolute Importance	VoE1: 184.4

, with examples shown in a summarized form.

4.2.2. Phase 2: Fuzzification—Convert Numbers into Words Using Fuzzy Sets

In this phase, the numerical inputs extracted from the House of Quality (HoQ) are transformed into linguistic fuzzy variables to enable fuzzy inference. For each HoQ-derived attribute (e.g., Customer Importance, Absolute Importance, Regulatory Importance), a set of linguistic terms such as Low, Medium, and High is defined. Each linguistic term is represented using a triangular membership function, selected due to its computational efficiency, transparency, and widespread use in fuzzy QFD applications. A triangular membership function is defined by three parameters (a, b, c) and calculates the membership degree, μ(x), for an input value x, as illustrated in Figure 4 and mathematically expressed in Triangular Membership Function (1) [29].

$$triangle\left(x;a,b,c\right)=\left\{\begin{array}{c}0,\hspace{1em}\hspace{1em}x\le a\\ {\displaystyle \frac{x-a}{b-a}},\hspace{1em}\hspace{1em}a\le x\le b\\ {\displaystyle \frac{c-x}{c-b}},\hspace{1em}\hspace{1em}b\le x\le c\\ 0,\hspace{1em}\hspace{1em}c\le x\end{array}\right.$$

(1)

• a denotes the lower bound at which membership begins (μ = 0),
• b represents the peak value with full membership (full belonging),
• c denotes the upper bound where membership returns to 0, and
• x is the input value (crisp input value) (e.g., the regulatory influence score).

Calibration of Fuzzy Set Boundaries

The numerical boundaries (a, b, c) for each fuzzy set were not selected arbitrarily. Instead, they were determined using a data-driven calibration procedure grounded in the observed value ranges of the constructed HoQ. For each attribute, the minimum and maximum values appearing across all technical features were first identified. These empirical bounds were then conservatively extended to rounded limits to ensure robustness and prevent boundary effects during inference.

The resulting value range was partitioned into overlapping Low, Medium, and High regions following standard fuzzy set design principles, with deliberate overlap between adjacent sets to allow smooth transitions rather than crisp thresholds. This calibration was subsequently reviewed and validated through expert assessment to ensure that the linguistic semantics accurately reflected practical interpretations of low, moderate, and high importance within the project management context.

This approach constitutes a calibrated fuzzy modeling strategy, rather than a statistical normalization process. Variables originally defined on fixed scales (e.g., 1–10 importance ratings) retain their native ranges, while derived quantities (e.g., Absolute Importance from Step 12) are fuzzified relative to their observed HoQ distributions.

The complete set of input variables, their calibrated ranges, and the corresponding triangular membership parameters are summarized in

Table 7. Fuzzy sets for each HoQ attribute and their purpose.

Attribute	HoQ Step	Input Range/Values	Fuzzy Sets (a, b, c)	Purpose
Customer Importance	Step 3	1–10	Low: (1, 1, 4) Medium: (2, 5, 8) High: (6, 10, 10)	Represents how critical each customer’s need is, based on stakeholder input.
Relationship Strength	Step 7	1, 3, 9 (Discrete Values)	Weak: (0, 1, 3) Moderate: (1, 3, 9) Strong: (3, 9, 9)	Measures how strongly technical responses satisfy customer needs.
Organizational Difficulty	Step 8	1–10	Easy: (1, 1, 4) Medium: (2, 5, 8) Hard: (6, 10, 10)	Estimates the level of effort or complexity in implementing technical features.
Absolute Importance	Step 12	81.8–561	Low: (0, 0, 200), Medium: (100, 300, 500) High: (400, 600, 600)	Combines customer demand and relationship weight to prioritize VoEs.
Regulatory Importance	Step 2	0.0–1.0 (Designed scale)	Low: (0.0, 0.0, 0.4) Medium: (0.2, 0.5, 0.8) High: (0.6, 1.0, 1.0)	Quantifies the relevance of regulatory links to specific VoEs.
Improvement Direction	Step 6	−1, 0, +1 (Discrete, Linguistic)	Decrease (▼) Maintain (●) Increase (▲)	Indicates whether technical features should be reduced, held constant, or improved.
Correlation Trade-Offs	Step 11	−1, 0, +1 (Discrete, Linguistic)	Negative Neutral Positive	Evaluates interactions between technical features (used in fuzzy rule design only).

Note: Step 11 (Correlation Matrix) was excluded from fuzzification but is applied later in section-specific fuzzy rules to detect trade-offs or reinforcements.

. Through this structured fuzzification process, crisp QFD data are transformed into a linguistic representation suitable for rule-based fuzzy inference while preserving traceability to the original stakeholder assessments.

4.2.3. Phase 3: Fuzzy Rule Application—Define Specific Rules for Each Element

The fuzzy membership degrees computed in Phase 2 serve as inputs for a Mamdani-style fuzzy inference engine [20]. In this phase, these fuzzified HoQ attributes are combined through structured IF–THEN rules to evaluate the priority and emphasis of individual PMP and SP elements.

Rather than employing a single global rule base, the system uses multiple independent rule bases, each dedicated to a specific PMP or SP element. This modular design ensures that the logic governing one planning component (e.g., risk identification) remains independent from others (e.g., scope activities or quality assurance), thereby improving clarity, traceability, and extensibility.

The fuzzy rules follow a general structure:

IF [Condition 1] AND/OR [Condition 2] THEN [Output]

Rule evaluation applies standard fuzzy logic operators: the minimum (AND) operator for condition intersection and the maximum (OR) operator for condition union. As a result, individual rules may partially fire (e.g., with strength 0.6), allowing multiple rules to contribute simultaneously to the output fuzzy sets. Figure 5 illustrates the Mamdani-style inference mechanism, including rule evaluation, aggregation, and output generation.

The aggregation of rule outputs follows the max–min composition principle, where each rule’s firing strength limits the contribution of its consequent fuzzy set. All activated consequents are combined into a single aggregated fuzzy output, expressed mathematically as Formula (2) Max–min aggregation of fuzzy rules in Mamdani inference [29]:

$${\mathit{\mu }}_{\mathit{a}\mathit{g}\mathit{g}}\left(\mathit{x}\right)=\mathit{m}\mathit{a}\mathit{x}[\mathit{min}\left({\mathit{\mu }}_{\mathit{A}1}\left(\mathit{x}\right),{\mathit{w}}_1\right),\mathit{min}\left({\mathit{\mu }}_{\mathit{A}2}\left(\mathit{x}\right),{\mathit{w}}_2\right),..,\mathit{min}\left({\mathit{\mu }}_{\mathit{A}\mathit{n}}\left(\mathit{x}\right),{\mathit{w}}_{\mathit{n}}\right)]$$

(2)

Rule Design Logic and Systematic Derivation

To avoid ad hoc rule creation, the rule bases were developed using a structured and repeatable design procedure. First, the most influential HoQ attributes relevant to each PMP or SP element were identified (e.g., Customer Importance and Absolute Importance for goal definition, Regulatory Importance for risk-related elements). Second, domain-relevant linguistic relationships were elicited using structured “what-if” reasoning (e.g., What should occur when importance is high, but implementation difficulty is also high?). Third, these qualitative relationships were translated into IF–THEN rules and iteratively refined using pilot data from the case study.

The underlying logic of rule construction follows a requirement-to-action prioritization taxonomy commonly applied in QFD-based planning models. In this taxonomy, stakeholder-driven importance attributes (e.g., Customer Importance, Absolute Importance) determine whether an element should be emphasized, relationship strength determines how strongly it contributes to project objectives, and feasibility or constraint-related attributes (e.g., Organizational Difficulty, Regulatory Importance) determine how the element should be framed within planning documents. Encoding this logic through fuzzy rules ensures that prioritization decisions are explicit, consistent, and traceable to the HoQ structure.

Each PMP or SP element is associated with its own output fuzzy sets (e.g., Low, Medium, High), defined on context-appropriate scales corresponding to the role of that element in planning documents. This modular structure ensures reproducibility and allows rule bases to be adapted or extended for different project types without affecting the overall framework.

Table 8. Example rule bases for selected PMP and SP elements.

Element (from PMP/SP)	Main HoQ Inputs Used (Step IDs)	Example Rule Logic	Output Meaning
PMP—1.1.1 Purpose, Scope, and Objectives	S3 (Customer Importance), S7 (Relationship Strength), S12 (Absolute Importance)	IF Importance is High AND Relationship is Strong AND Absolute Importance is High THEN Emphasis_Level is High	Determines how prominently an objective is described
PMP—3.3.1 Risk Identification	S2 (Regulatory Importance), S7 (Relationship Strength), S8 (Difficulty), S11 (Correlation), S12 (Absolute Importance)	IF Regulatory Importance is High AND Difficulty is High THEN Risk_Level is High	Highlights features that require explicit risk statements
Scope Plan—1.2.1 Key Scope Management Activities	S7 (Relationship Strength), S6 (Improvement Direction), S8 (Difficulty)	IF Relationship is Strong AND Improvement Direction is Increase THEN Activity_Priority is High	Chooses which activities appear as core scope tasks
Scope Plan—2.1.1 High-level Goals and Success Criteria	S3 (Customer Importance), S7 (Relationship Strength), S12 (Absolute Importance)	IF Importance is High AND Absolute Importance is High THEN Goal_Strength is High	Determines which goals receive detailed success criteria

(Note: These examples illustrate the systematic mapping and do not represent the full rule set).

presents representative rule examples for selected PMP and SP elements, indicating the main HoQ inputs used, example IF–THEN logic, and the intended semantic meaning of the output.

The aggregated fuzzy outputs generated in this phase are passed to Phase 4, where they are defuzzified into crisp priority scores. These scores determine both the inclusion of PMP and SP elements and their relative prominence in the final documents. The resulting priority levels directly drive the textual synthesis logic implemented in Phase 5, where structured templates generate detailed or concise planning statements based on the computed priorities.

4.2.4. Phase 4: Defuzzification—Convert Fuzzy Outputs into a Clear Number Using Centroid Method

After fuzzy rule evaluation in Phase 3, the aggregated output for each element (e.g., Work Activity Priority, Risk Level) is a fuzzy set; defuzzification transforms this fuzzy set into a single, actionable crisp value. This value directly informs decisions such as

• Whether a technical feature should be included in a specific PMP or SP element (e.g., Quality Assurance)
• How strongly a requirement should be prioritized in terms of deliverables, objectives, or quality standards

The methodology uses the widely accepted centroid (center of gravity) method. This method finds the center of mass of the aggregated output fuzzy set, providing a balanced crisp output. It is mathematically defined for a continuous function by Formula (3): [29].

$$\mathit{O}\mathit{u}\mathit{t}\mathit{p}\mathit{u}\mathit{t}={\displaystyle \frac{{\int }_{\mathit{a}}^{\mathit{b}}\mathit{u}\left(\mathit{x}\right).\mathit{x}\mathit{d}\mathit{x}}{{\int }_{\mathit{a}}^{\mathit{b}}\mathit{u}\left(\mathit{x}\right)\mathit{d}\mathit{x}}}$$

(3)

• u(x) is the aggregated membership function of the output variable.
• x is the output domain (e.g., priority score from 0 to 10).
• a, b are the lower and upper bounds of the output range.

The centroid method, while defined mathematically as a continuous integral, is nonetheless practically computed by a discrete approximation. Since the output membership functions are of a piecewise-linear (triangular) type, the centroid is quickly and efficiently computed through the discretization summation in Formula (4) with a small step size (e.g., ∆x = 0.1): [29]

$$\mathit{O}\mathit{u}\mathit{t}\mathit{p}\mathit{u}\mathit{t}\approx {\displaystyle \frac{\sum _{\mathit{x}=0}^{10}\mathit{x}.\mathit{u}\left(\mathit{x}\right).∆\mathit{x}}{\sum _{\mathit{x}=0}^{10}\mathit{u}\left(\mathit{x}\right).∆\mathit{x}}}$$

(4)

This discretized approach is widely adopted in fuzzy logic literature due to its simplicity, accuracy, and computational efficiency.

The result is a crisp number (e.g., 7.9 out of 10 for Work_Activity_Priority). This score is then interpreted based on the output fuzzy sets defined in Step 3 (e.g., Low: 0–4, Medium: 2–8, High: 6–10) to make final decisions on inclusion and prominence, which are enacted in Phase 5.

4.2.5. Phase 5: Textual Synthesis of PMP and SP Elements

The final phase in the fuzzy QFD methodology converts the defuzzified priority scores into structured, interpretable language statements for inclusion in the PMP and SP documents. These synthesized statements explicitly define the role, priority, and justification for each technical feature (Voice of the Enterprise—VoE).

Each PMP or Scope element receives a prioritized list of VoEs based on their crisp scores from Step 4. These are grouped using the following threshold logic:

• High Priority (≥6.0): Direct inclusion as a core objective or key task.
• Medium Priority (3.0–5.9): Included as supporting content or a secondary requirement.
• Low Priority (<3.0): Excluded or deferred for future consideration.

The prioritized VoEs are processed using list-based templates that combine them with related customer needs (Voice of the Customer—VoC) and regulatory references. The templates follow a structured syntax to ensure consistency and clarity:

“[Action] [VoE feature] ([Score]) [linked to] [VoC/Regulation] [Justification]”

This template is designed for a single PMP element. Different PMP or Scope elements require their own specific templates. Additionally, multiple templates can be used for a single element to address priorities or other considerations, such as categories.

Example: “Prioritizes Live API Integration (7.5) for real-time updates (VoC3), ensuring responsive time < 2 sec for API calls to airlines, hotels, and maps (target3).”

Each generated statement maintains full traceability to the source QFD data by including references to:

• Original VoC and VoE identifiers.
• Relevant regulatory influences (if applicable).
• The final crisp priority score.

This ensures transparency and allows for direct validation against the original HoQ matrix. The template-based approach is scalable and can be adapted for various PMP and SP elements.

Note on Automation: While this study utilizes structured templates for text generation, full Natural Language Generation (NLG) is beyond its scope. The output of this phase is designed to be compatible with future integration into advanced NLG systems for the complete automation of planning documents.

5. Results

This section reports the results generated by the proposed methodology, beginning with an overview of the case study context and followed by the computed fuzzy values and synthesized selected PMP and SP element outputs.

5.1. Case Study Overview

To validate the suggested approach, a case study of a Travel Planning application was undertaken. Stakeholder requirements and importance ratings were elicited through expert-driven requirement analysis during the conceptual design phase of the application, following standard requirement elicitation practices used in IT project planning, and are used here as a representative dataset to demonstrate the methodology.

This was chosen for the practical aspect of the application in the IT sector, where well-formed stakeholder requirements existed, regulatory constraints, and technical specifications. In contrast, the application presents a diverse set of features, such as itinerary generation, booking management, geo-location services, and secure payments, so it would stand as a typical example of a medium-to-large-scale IT project.

The HoQ constructed for this application is presented in Figure 3 and its regulatory requirements in Table 5. To demonstrate the methodology’s application, two representative elements from standard project documentation were selected for generation:

• PMP—Quality Assurance, addressing how technical priorities and regulatory mandates, derived from the QFD, are translated into concrete quality assurance strategies and activities;
• SP—Key Needs and Prioritization: This emphasizes how stakeholder requirements and identified priorities are systematically captured, quantified, and organized, providing a structured basis for translating high-level needs into actionable scope definitions.

These two elements provide concrete examples of the applicability and validity of the proposed fuzzy QFD methodology in generating project documentation, aligned with standards.

5.2. Generate PMP and SP Elements

For each element, specific sections of the HoQ (Figure 3 and Table 5) were used as inputs, demonstrating the traceability and tailored application of the QFD data. The mapping between the QFD steps and the target elements follows the logic established in the methodology section.

5.2.1. PMP Element Quality Assurance

To demonstrate the fuzzy QFD process, this section presents the detailed calculation for VoE1 (“User-friendly UI/UX design”) using three representative inputs from the complete set of six QFD sources in

Table 9. HoQ steps used for QA and their purpose.

Input Variable/HoQ Step	Purpose in QA
Regulatory Requirements/S2	Compliance verification priority
Voice of Engineer/S5	Feature to be quality-assured
Organizational Difficulty/S8	QA implementation complexity
Technical Targets/S10	QA acceptance criteria
Correlation Matrix/S11	Integrated testing needs
Absolute Importance/S12	QA focus priority

employed for Quality Assurance. This approach maintains clarity while illustrating the core methodology; presenting all VoEs and inputs would be prohibitively lengthy. The complete implementation utilizes all six inputs for a comprehensive priority assessment.

The fuzzy inference system for the Quality Assurance (QA) section utilized the same variables and triangular membership functions previously defined in Table 7. The same fuzzy sets were applied specifically to the QA-related attributes of the HoQ, as presented in

Table 10. Fuzzy sets and calibrated ranges for selected HoQ attributes.

Variable	Range	Fuzzy Sets (a, b, c)
Regulatory Relevance	0–1	Low: (0.0, 0.0, 0.4) Medium: (0.2, 0.5, 0.8) High: (0.6, 1.0, 1.0)
Technical Difficulty	0–10	Easy: (1, 1, 4) Medium: (2, 5, 8) Hard: (6, 10, 10)
Absolute Importance	0–600	Low: (0, 0, 200) Medium: (100, 300, 500) High: (400, 600, 600)
Output: QA Priority	0–10	Low: (0, 0, 4) Medium: (3, 5, 7) High: (6, 10, 10)

.

For VoE1 (“User-friendly UI/UX design”), the following values were extracted from the HoQ:

• Absolute Importance: 142 (from Step 12)
• Technical Difficulty: 3 (from Step 8)
• Regulatory Relevance: 0.80 (from Step 2)

The fuzzification results are summarized in

Table 11. Summarized fuzzification results for VoE1 (“User-friendly UI/UX design”).

Input Variable	Value	Low	Medium	High
Absolute Importance	142	0.29	0.21	0.00
Technical Difficulty	3	0.67	0.33	0.00
Regulatory Relevance	0.80	0.00	0.00	0.50

:

In Step 2, the fuzzification process represents each input variable using linguistic terms such as Low, Medium, and High, based on their defined membership functions. This step establishes the fuzzy representation of the variables required for further processing in the inference stage. The summarized results for each input variable are shown in Table 11. The following are the calculation details:

• Absolute Importance = 142 (0–600 scale):
  • Low (0, 0, 200): On descending slope → μ = (200 − 142)/(200 − 0) = 58/200 = 0.29
  • Medium (100, 300, 500): On rising slope → μ = (142 − 100)/(300 − 100) = 42/200 = 0.21
  • High (400, 600, 600): 142 < 400 → μ = 0.00
• Technical Difficulty = 3 (1–10 scale):
  • Easy (1, 1, 4): On descending slope → μ = (4 − 3)/(4 − 1) = 1/3 ≈ 0.67
  • Medium (2, 5, 8): On rising slope → μ = (3 − 2)/(5 − 2) = 1/3 ≈ 0.33
  • Hard (6, 10, 10): 3 < 6 → μ = 0.00
• Regulatory Relevance = 0.80 (0–1 scale):
  • Low (0.0, 0.0, 0.4): 0.80 > 0.4 → μ = 0.00
  • Medium (0.2, 0.5, 0.8): 0.80 = upper bound → μ = 0.00
  • High (0.6, 1.0, 1.0): On rising slope → μ = (0.80 − 0.6)/(1.0 − 0.6) = 0.20/0.40 = 0.50

Fuzzy inference rules were defined to represent the logical relationships between the input variables and the output variables. These rules form the core of the fuzzy reasoning process, guiding how linguistic inputs were combined to produce an output. The rules formulated for VoE1 in the QA context are presented below:

• R1: IF Regulatory IS High THEN QA_Priority IS High

  ○

  α₁ = μ_Regulatory_High = 0.50

• R2: IF AbsoluteImportance IS High THEN QA_Priority IS High

  ○

  α₂ = μ_AbsoluteImportance_High = 0.00 (does not fire)

• R3: IF AbsoluteImportance IS Medium AND Regulatory IS Medium THEN QA_Priority IS Medium

  ○

  α₃ = min (μ_AbsoluteImportance_Medium, μ_Regulatory_Medium) = min (0.21, 0.00) = 0.00 (does not fire)

• R4: IF AbsoluteImportance IS Low AND Regulatory IS Low THEN QA_Priority IS Low

  ○

  α₄ = min (μ_AbsoluteImportance_Low, μ_Regulatory_Low) = min (0.29, 0.00) = 0.00 (does not fire)

• R5: IF Difficulty IS Hard AND AbsoluteImportance IS NOT Low THEN QA_Priority IS High

  ○

  α₅ = min (μ_Difficulty_Hard, 1-μ_AbsoluteImportance_Low) = min (0.00, 1 − 0.29) = min(0.00, 0.71) = 0.00 (does not fire)

• R6: IF Difficulty IS Easy AND AbsoluteImportance IS Low THEN QA_Priority IS Low

  ○

  α₆ = min (μ_Difficulty_Easy, μ_AbsoluteImportance_Low) = min (0.67, 0.29) = 0.29

In defuzzification, the centroid method was applied to the aggregated output fuzzy set to obtain a crisp QA priority score. Using Mamdani implication (min operator) for rule consequents and maximum operator for aggregation, the output membership functions were combined as follows:

Input Values from the Previous Phase:

• Rule R1 firing strength: α = 0.50 (from: Regulatory IS High = 0.50)
• Rule R6 firing strength: α = 0.29 (from: Difficulty IS Easy = 0.67 AND Absolute Importance IS Low = 0.29)
• Output membership functions: Low = (0, 0, 4), High = (6, 10, 10)

The aggregated membership values shown in Table 11 were computed by applying the Mamdani min–max aggregation defined in Formula (2) to the output membership functions.

$${\mu }_{agg}\left(x\right)=max[\mathit{min}\left({\mu }_{Low}\left(x\right),0.29\right),min({\mu }_{High}\left(x\right),0.50\left)\right]$$

where:

$${\mu }_{Low}\left(x\right)={\displaystyle \frac{4-x}{4}}for x\in [0, 4]$$

$${\mu }_{High}\left(x\right)={\displaystyle \frac{x-6}{4}}for x\in [6, 10]$$

with step size Δx = 1. The calculation results are summarized in

Table 12. Defuzzification calculation for QA priority.

$\mathit{x}$	${\mathit{\mu }}_{\mathit{a}\mathit{a}\mathit{g}}\left(\mathit{x}\right)$	$\mathit{x}.{\mathit{\mu }}_{\mathit{a}\mathit{g}\mathit{g}}\left(\mathit{x}\right)$
0	0.29	0.00
1	0.29	0.29
2	0.29	0.58
3	0.25	0.75
4	0.00	0.00
5	0.00	0.00
6	0.00	0.00
7	0.25	1.75
8	0.50	4.00
9	0.50	4.50
10	0.50	5.00
Sum	2.87	16.87

.

Using the aggregated values from Table 12 in the Discretized summation (4), the crisp output was calculated as follows. $Output={\displaystyle \frac{{\sum }_{x=0}^{10}x.{\mu }_{agg}\left(x\right).∆x}{{\sum }_{x=0}^{10}{\mu }_{agg}\left(x\right).∆x}}$,

$$Crisp Output={\displaystyle \frac{16.87}{2.87}}=5.88$$

Note: The result was verified using finer discretization steps (Δx = 0.1 yielding 5.78, Δx = 0.01 yielding 5.77), confirming robustness within the same priority category.

The defuzzified QA priority score of 5.88 (on a 0–10 scale) falls into the Medium priority category according to the established thresholds:

• Low: 0–3.0
• Medium: 3.01–6.5
• High: 6.51–8.5
• Very High: >8.5

The aggregated output’s bimodal character showing activations in both Low and High parts led to a centroid value that was in the middle. This symbolizes the disagreements from the fuzzy rules: regulations pushing for a higher priority, while the low technical difficulty and moderate importance indicated a lower priority.

For VoE1 (“User-friendly UI/UX design”) with a priority score of 5.88 (Medium priority), the following QA entry was generated using the following structure, as we discuss in methodology:

[Action] [VoE feature] ([Defuzzified Priority Score]) to meet [Regulatory Requirements/Standards] ([Linked REGs]), ensuring [Technical Target/Acceptance Criteria] through [Implementation Method or Verification Approach].

Example text: Ensure User-friendly UI/UX design (5.88) to meet WCAG 2.1 accessibility standards (REG3) and mobile app store guidelines (REG4), ensuring usability score ≥85/100 through iterative user testing cycles.

The generated statement maintains full traceability to the original QFD data:

• Technical Feature: VoE1—User-friendly UI/UX design
• Linked Customer Needs: VoC1 (Easy-to-Use Interface), VoC10 (Social Sharing and Collaboration)
• Regulatory Requirements: Reg3 (Accessibility standards), Reg4 (Mobile app store policies)
• Priority Score: 5.88/10 (Medium priority from defuzzification)
• Technical Target: “≥85/100 usability score” (from Step 10 Technical Targets)

5.2.2. Key Needs and Prioritization (Scope Plan Element 4.1.1)

To demonstrate the fuzzy QFD process, this section presents the detailed calculation for VoE5 (“Route Optimization”) using three representative inputs from the complete set of six QFD sources in

Table 13. HoQ steps used for Key Needs and Prioritization and their purpose.

Input Variable/HoQ Step	Purpose in Key Needs and Prioritization
Voice of Customer/S1	Direct stakeholder Requirements
Importance Ratings/S3	Quantified customer needs significance
Voice of Engineer/S5	Technical features to be prioritized
Relationship matrix/S7	Strength of feature–customer relationships
Technical Targets/S10	Measurable performance criteria
Relative Importance/S12	Normalized priority weighting (0–100%)

employed for Key Needs and Prioritization.

The fuzzy sets were applied specifically to the scope-related attributes of the House of Quality, as presented in

Table 14. Fuzzy system parameters for requirement classification.

Variable	Range	Fuzzy Sets (a, b, c)
Customer Importance Ratings	0–10	Low: (1, 1, 4), Medium: (2, 5, 8) High: (6, 10, 10)
Relationship Strength	1, 3, 9	Weak: (0, 1, 3), Moderate: (1, 3, 9) Strong: (3, 9, 9)
Relative Importance	0–100%	Low: (0, 0, 33), Medium: (17, 50, 83) High: (67, 100, 100)
Output: Priority	1–10	Low: (0, 0, 4), Medium: (3, 5, 7) High: (6, 10, 10)

.

For VoE5 (“Route Optimization”), the following values were extracted from the HoQ:

• Relative Importance: 8% (from S12)
• Customer Importance Ratings: 7.5 (from S3—average of linked VoCs)
• Relationship Strength: 9 (from S7—strong link to VoC5, VoC6)

The fuzzification results for VoE5 (“Route Optimization”) are summarized in

Table 15. Summarized fuzzification results for VoE5 (“Route Optimization”).

Input Variable	Value	Low	Medium	High
Relative Importance	8%	0.76	0.00	0.00
Importance Ratings	7.5	0.00	0.17	0.38
Relationship Strength	9	0.00	0.00	1.00

:

As with the previous one, the summarized results for each input variable are shown in Table 15, and following are the calculations for that.

• Relative Importance = 8% (0–100% scale):

• Low (0, 0, 33): On descending slope → μ = (33 − 8)/(33 − 0) = 25/33 ≈ 0.76
• Medium (17, 50, 83): 8 < 17 → μ = 0.00
• High (67, 100, 100): 8 < 67 → μ = 0.00

• Importance Ratings = 7.5 (1–10 scale):

• Low (1, 1, 4): 7.5 > 4 → μ = 0.00
• Medium (2, 5, 8): 7.5 is between peak (5) and upper bound (8) → μ = (8 − 7.5)/(8 − 5) = 0.5/3 ≈ 0.17
• High (6, 10, 10): 7.5 is between lower bound (6) and peak (10) → μ = (7.5 − 6)/(10 − 6) = 1.5/4 = 0.38

• Relationship Strength = 9 (Discrete: 1, 3, 9):

• Weak (0, 1, 3): 9 > 3 → μ = 0.00
• Moderate (1, 3, 9): 9 = upper bound → μ = 0.00
• Strong (3, 9, 9): 9 ≥ peak → μ = 1.00

The rules formulated for VoE5 in the Key Needs and Prioritization context are presented below:

• R1: IF Relationship_Strength IS High (1.00) AND (Importance_Rating IS Medium (0.17) OR Importance_Rating IS High (0.38)) THEN Priority IS High → α = min (1.00, max (0.17, 0.38)) = min (1.00, 0.38) = 0.38
• R2: IF Importance_Rating IS High (0.38) OR Relative_Importance IS High (0.00) THEN Priority IS High → α = max (0.38, 0.00) = 0.38
• R3: IF Importance_Rating IS Medium (0.17) AND Relative_Importance IS Medium (0.00) THEN Priority IS Medium → α = min (0.17, 0.00) = 0.00
• R4: IF Relationship_Strength IS Medium (0.00) AND (Importance_Rating IS Medium (0.17) OR Importance_Rating IS Medium (0.17)) THEN Priority IS Medium → α = min (0.00, max (0.17, 0.17)) = min (0.00, 0.17) = 0.00
• R5: IF Importance_Rating IS Low (0.00) AND Relative_Importance IS Low (0.76) THEN Priority IS Low → α = min (0.00, 0.76) = 0.00
• R6: IF Relationship_Strength IS Weak (0.00) AND Importance_Rating IS Low (0.00) THEN Priority IS Low→ α = min (0.00, 0.00) = 0.00

In the defuzzification, the centroid method was applied to the aggregated output fuzzy set to obtain a crisp priority score. Using Mamdani implication (min operator) for rule consequents and maximum operator for aggregation, the output membership functions were combined as follows:

Input Values from the Previous Phase:

• Rule R1 firing strength: α = 0.38
• Rule R2 firing strength: α = 0.38
• Output membership functions: Low = (0, 0, 4), Medium = (3, 5, 7), High = (6, 10, 10).

The aggregated membership values shown in Table 15 were computed by applying the Mamdani min–max aggregation defined in Formula (2) to the output membership functions.

$${\mu }_{agg}\left(x\right)=\mathit{max}\left[\mathit{min}\left({\mu }_{High}\left(x\right),0.38\right),\mathit{min}\left({\mu }_{High}\left(x\right),0.38\right)\right]=min({\mu }_{High}\left(x\right),0.38)$$

where,

$${\mu }_{High}\left(x\right)={\displaystyle \frac{x-6}{4}} for x\in \left[\mathrm{6,10}\right]$$

with step size Δx = 1. The calculation results are summarized in

Table 16. Defuzzification calculation for priority.

$\mathit{x}$	${\mathit{\mu }}_{\mathit{a}\mathit{g}\mathit{g}}\left(\mathit{x}\right)$	$\mathit{x}.{\mathit{\mu }}_{\mathit{a}\mathit{g}\mathit{g}}\left(\mathit{x}\right)$
6	0.00	0.00
7	0.25	1.75
8	0.38	3.04
9	0.38	3.42
10	0.38	3.80
Sum	1.39	12.01

.

Using the aggregated values from Table 16 in the Discretized summation (4), the crisp output was calculated as follows. $Output={\displaystyle \frac{{\sum }_{x=0}^{10}x.{\mu }_{agg}\left(x\right).∆x}{{\sum }_{x=0}^{10}{\mu }_{agg}\left(x\right).∆x}}$

$$Crisp Output={\displaystyle \frac{12.01}{1.39}}=8.64$$

Note: The result was verified using finer discretization steps (Δx = 0.1 yielding 8.58, Δx = 0.01 yielding 8.55), confirming robustness within the same priority category.

The defuzzified scope priority score of 8.64 (on a 0–10 scale) falls into the High priority category according to the established thresholds:

• Low: 0–3.0
• Medium: 3.01–6.5
• High: 6.51–8.5
• Very High: >8.5

Although the computed value slightly exceeds the upper ‘High’ threshold (8.5), it remains within rounding tolerance and can be categorized as High in the scope prioritization context.

The high priority score reflects the strong influence of both relationship strength and importance ratings, with both rules (R1 and R2) activating the High output set. This indicates that Route Optimization represents a high-priority stakeholder requirement that warrants significant emphasis during requirement prioritization.

For VoE5 (“Route Optimization”) with a priority score of 8.64 (High priority), the following scope entry was generated using the template syntax defined in Section 4.2.5

Template for Key Needs and Prioritization/VoE5

Prioritize [VoE feature] ([Defuzzified Scope Priority Score]) for [Linked Customer Needs/VoCs] ([Linked VoCs]), ensuring [Technical Target/Performance Metric] to address [Justification/Importance].

Using the previous text template, the generated text is as below:

“Prioritize Route Optimization (8.64) for multi-destination trip planning (VoC5) and navigation integration (VoC6), ensuring optimal route generation within ≤3 s to address high customer importance and strong feature-VoC relationships.”

The generated statement maintains full traceability to the original QFD data:

• Technical Feature: VoE5—Route Optimization
• Linked Customer Needs: VoC5 (Multi-destination Trip Planning), VoC6 (Integration with Maps and Navigation)
• Relationship Strengths: Strong (9) with VoC5 and VoC6
• Priority Score: 8.64/10 (High priority from defuzzification)
• Technical Target: “Optimal route generation ≤3 s” (from Step 10 Technical Targets)
• Importance Basis: Importance Rating 7.5 (average of VoC5 = 7, VoC6 = 8), Relative Importance 8%

5.3. Final Generated PMP and Scope Plan Elements

In the final generation of the PMP and SP elements, the presented sequence primarily reflects the prioritization determined by the proposed fuzzy QFD methodology. All attributes’ defuzzified scores are provided to allow verification of the prioritization order. However, for demonstration and clarity, some lower-priority items have also been included, even though they are not strictly required for illustrative purposes, and it does not affect the validity of the methodology or its prioritization logic.

5.3.1. Quality Assurance

By using multiple text templates, a final complete PMP element, “Quality Assurance” 3.4.3 (Table 1), can be generated from the Travel Planning application’s HoQ (Figure 3 and Table 5), as shown below:

• Live API Integration (7.45) (VoE3) following third-party API terms of service (Reg8), ensuring response time ≤ 2 s (target3) for real-time travel updates.
• AI Recommendation Engine (7.12) (VoE2) aligned with Consumer protection laws (Reg9) compliance, targeting recommendation accuracy ≥ 80% (target2) with continuous algorithm tuning.
• Route Optimization (6.90) (VoE5) adhering to travel regulations (Reg5), geo-location consent (Reg6), and API terms (Reg8), ensuring optimal route generation ≤ 3 s (target5) for multi-destination trip planning.
• Multi-platform Support (6.75) (VoE9) adhering to mobile app store guidelines (Reg4), ensuring app load time ≤ 2 s (target9) across Multi-platforms.
• Performance Optimization (6.50) (VoE10) with achieving full compatibility and smooth performance across iOS (15+), Android (10+), and Web(target10).
• Secure Payment Gateway (6.25) (VoE6) compliant with GDPR (Reg1), PCI-DSS (Reg2), and electronic transaction laws (Reg7), guaranteeing 100% secure payment transactions.
• User-friendly UI/UX design (5.88) (VoE1) to meet WCAG 2.1 accessibility standards (Reg3) and mobile app store guidelines (Reg4), ensuring Avg. usability score ≥ 85/100 (Based on UX test) (target1).
• Cloud Storage (4.25) (VoE8) compliant with GDPR (Reg1), offering 99.9% uptime (target8) and reliable storage for offline travel data.
• Cost Estimation Algorithm (4.15) (VoE4) complying with travel industry regulations (Reg5), and maintaining price deviation ≤5% (compared to real time prices) (target4) for accurate budget planning.
• Data Synchronization for Offline Mode (4.00) (VoE7) following GDPR (Reg1) and geo-location consent (Reg6), ensuring data sync within ≤5 s (target7) for offline itinerary access.

5.3.2. Key Needs and Prioritization

By using multiple text templates, a complete SP element, “Key Needs and Prioritization” 4.1.1 (Table 2), can be generated from the Travel Planning application’s HoQ (Figure 3), as shown below:

• Route Optimization (8.64) (VoE5): Prioritize multi-destination trip planning (VoC5) and integration with navigation (VoC6), ensuring optimal route generation ≤ 3 s (target5). A high scope priority reflects critical customer need alignment.
• Live API Integration (7.40) (VoE3): Ensure real-time travel updates (VoC3), integration with maps/navigation (VoC6), Budget planning assistance (VoC4) and Flight & hotel booking features(VoC7) with response time ≤ 2 s (target3). Strong linkage to multiple customer needs makes this a high-priority requirement.
• AI Recommendation Engine (7.25) (VoE2): Focus on Easy to use Interface (VoC1) and budget planning assistance (VoC4), achieving recommendation accuracy ≥ 80% (target2). Strong customer-relationship links make this a high-priority feature.
• Multi-platform Support (6.75) (VoE9): Ensure Easy to use Interface (VoC1) and Social sharing and collaboration (VoC10) with app load time ≤ 2 s (target9). Strong relationships with customer needs make this a high-priority requirement.
• Performance Optimization (6.50) (VoE10): Enable Real-time travel updates (VoC3) and Easy to use Interface (VoC1) with full compatibility across iOS, Android, and Web (target10). High priority due to critical technical impact on user experience.
• Secure Payment Gateway (6.25) (VoE6): Focus on secure payment options (VoC8), guaranteeing 100% compliance with payment standards (target6). Strong customer and regulatory relevance indicate medium-high priority.
• User-friendly UI/UX design (5.88) (VoE1): Prioritize features addressing easy-to-use interfaces (VoC1) and social sharing/collaboration (VoC10), ensuring usability score ≥ 85/100 (target1). Strong relationship with key customer needs indicates this is a medium-to-high priority feature.
• Cloud Storage (4.25) (VoE8): Maintain data availability and save data Offline access to itineraries (VoC9) with a 99.9% uptime guarantee (target8). Moderate-priority scope element due to indirect customer influence.
• Cost Estimation Algorithm (4.10) (VoE4): Address budget planning assistance (VoC4), maintaining price deviation ≤ 5% (target4). Moderate relationship strength positions this as a medium-priority scope element.
• Data Synchronization for Offline Mode (4.00) (VoE7): Support offline itinerary access (VoC9) with sync time ≤ 5 s (target7). Moderate priority due to partial customer impact.

5.4. Expert Review and Validation

As an initial validation step, the generated PMP and Scope Plan elements were reviewed by an academic expert with extensive experience in IT project management. The review focused on assessing whether the prioritized elements, their relative ordering, and the generated textual descriptions were reasonable, coherent, and aligned with established project management practices. The expert feedback confirmed that the prioritization outcomes, particularly for high-impact requirements such as API integration and route optimization, were appropriate and consistent with professional expectations. This expert review provides qualitative validation of the proposed fuzzy QFD methodology, while broader empirical evaluation involving multiple experts or industrial projects is identified as future work.

6. Discussion

The study shows that a formalized fuzzy QFD approach can be applied to transform HoQ artifacts into more concrete PMP and SP elements. Working examples such as PMP–QA and SP–Key Needs and Prioritization demonstrate full traceability from the HoQ steps to standards-aligned text. These examples also validate the hypothesis that a significant portion of early-phase planning artifacts can be at least partially derived from QFD outputs. These results correspond with earlier work advocating model-based and requirement-driven approaches to enhance traceability and cut manual effort for project documentation while extending this body of literature with a reproducible rule-based method for synthesizing formal PMP and SP content.

6.1. Interpretation in the Context of the Literature

Traditionally, model transformation and Model-Driven Engineering (MDE) approaches looked primarily into downstream artifacts (design and code generation, for instance) and often analyzed early-phase artifacts (usually PMP and SP) as manual processes. The present results demonstrate from our standpoint that HoQ data combined with explicit mapping rules and the fuzzy decision layer can serve as a fairly dependable basis for many PMP/SP subsections. This line of work advances previous fuzzy QFD applications (which were concerned with prioritization and design optimization) to develop a way to directly convert fuzzy outputs into text-based planning documents that conform to accepted PMBOK [4], IEEE [5], and LVS67 conventions. Previous AI-assisted text generation, which has been criticized for producing generic outputs with little to no traceability, is something that our method preserves: from HoQ identifiers, through all rule firings, and into generated text-as-traceability-construct.

6.2. Implications and Broader Significance

The methodology offers several practical benefits for IT project management: (1) increased traceability between stakeholder inputs and plan elements, reducing the risk of omission; (2) improved consistency and repeatability of early-phase documents, lowering variability introduced by different authors; and (3) reduced manual effort and fewer subsequent plan revisions for elements that are well-represented in the HoQ (for example, work activities, quality assurance, and functional/non-functional specifications). For organizations that maintain rigorous requirement-capture processes, this approach can be integrated into Project Management Information Systems (PMIS) to accelerate plan drafting and review cycles.

6.3. Limitations

This study, in turn, uncovers some important limitations. First, not all PMP elements may be derived fully from the HoQ: items that call for hard quantitative inputs (detailed schedule, budget numbers) or highly contextual organizational knowledge (communication plans, staffing strategy) must still be provided manually or through other external data sources. Second, the results depend on the quality and completeness of the HoQ: output quality decreases with inconsistent stakeholder ratings, sparse technical mappings, or missing regulatory annotations. Third, the example rule base and membership functions given here are for illustration; domain-specific tuning and larger rule bases might be required across different types of projects. Finally, the fuzzy layer compensates for subjectivity but cannot substitute for expert validation—the drafted output should support human planners rather than replace them.

Finally, while the fuzzy membership functions and rule bases were calibrated using HoQ-derived data ranges and expert validation, a formal sensitivity analysis examining the impact of variations in fuzzy parameters on priority scores was beyond the scope of this study and is identified as an important direction for future work.

6.4. Future Work and Next Steps Application with UI

This research is a component of a broader project aimed at AI-assisted generation of PMP and SP that is graphically presented in Figure 6.

The immediate next step is to operationalize the fuzzy QFD methodology into a practical application with a user interface (UI). Key features and research priorities for that application include automated HoQ data ingestion, rule-based fuzzy inference execution, traceability visualization from HoQ elements to generated text, and configurable text templates for different PMP and SP sections. These aspects are identified as future development goals and are not implemented within the scope of the present study.

7. Conclusions

The introduction of a fuzzy QFD methodology by this study is a systematic conversion of the customer requirements into three forms of PMP and SP documentation, which proved to be a solution to the persistent problems in requirement traceability, prioritization, and stakeholder alignment. Moreover, the combination of QFD with fuzzy logic allows the proposed method to deal with the uncertainty and subjectivity that are characteristic of expert evaluations, coming up with a ranking that aligns with expert review outcomes, as demonstrated through the qualitative case study validation, when it comes to high-priority requirements like API integration for real-time updates.

The model gives a structured traceability chain from the “Voice of the Customer” (VoC) to the “Voice of the Engineer” (VoE) and finally to document-level elements, along with the quantification of technical and managerial parameters with absolute transparency. Practitioners are able to rely on directly defuzzified outputs like VoE scores over a 6.0 threshold—for decision-making—and are backed up by standardized templates that guarantee data quality and uniform reporting. Furthermore, some factors like Work Activities or Quality Assurance tasks can be assigned priority directly to facilitate planning and resource distribution. The combination of prioritization and the logical classification mechanism not only makes project governance stronger but also enhances the requirement-to-document linkage and informs managerial actions in IT project environments. The existing model, even though it demonstrates great potential, still has some drawbacks such as the manual tuning of fuzzy rules and the use of static membership functions, which restrict the model’s ability to adapt easily. Hence, the next step would be to create an adaptive system that will be trained and thereby able to switch the fuzzy logic or inference model dynamically according to the input’s nature and complexity. This type of adaptation will not only make the system more traceable and context-aware but will also allow it to automatically decide the best representation of the results in the document format, thus ensuring better accuracy, explain ability, and trust among stakeholders.

Furthermore, the fuzzy QFD engine extension to a wider spectrum of PMP and SP factors would raise its usability and enable the document generation of large-scale projects from a single QFD model. By introducing automated input validation and expert review processes, reliability could be raised even more since it would guarantee that the raw data, the linguistic labels, and the text content generated would always be cross-verified. Ultimately, this study is a point-of-departure for intelligent, self-improving project documentation systems that require less human intervention, are rigorous in their applied methods, and are flexible to changes in the project environment. This is a big step forward in the direction of AI-powered project management and document generation.