1. Introduction
In high-performance engineering, meeting compliance requirements is a necessity and a challenge in design. For vehicle design, regulatory conditions must be integrated with functional and performance objectives, making the design process complex, requiring structured methodologies to systematically link high-level requirements to specific engineering outputs (Reference Abdoli and KaraAbdoli & Kara, 2017). Systems engineering (SE) is a known approach to assist in the design of complex systems (INCOSE, 2023). The evolving terrain of current products with more features forces adaptation of SE field to manage largescale data in modern products (Reference Schluse, Priggemeyer, Atorf and RossmannSchluse et al., 2018), otherwise designers from different disciplines may end up designing different aspects of the products in silos, which may lead to inconsistencies between different disciplines and design failures (Reference AbdoliAbdoli, 2023).
Sunswift Racing, the University of New South Wales’ solar car team, operates at the cutting edge of innovation and compliance. As a team design practice, Sunswift not only tackles the engineering challenges of building solar-powered cars but has evolved to also ensure adherence to strict road legality requirements, competing with industry standards at a university level. This balance between creativity and compliance forms the backbone of the team’s approach to design for their new endeavors.
In this study, the Quality Function Deployment (QFD) method is explored for managing compliance and traceability within the design process of SE and its application is showcased in Sunswift Racing’s design process. In the proposed approach by developing a multi-layered QFD matrix, it would be possible to translate regulatory mandates or CRs and design requirements into specific design parameters, cascading them through subsystems and into actionable directives for engineering teams. The proposed approach also facilitates the verification and validation (V&V) phase following the known V-model of SE. Through the case study, the research demonstrates the ability of QFD to enhance collaboration across disciplines while ensuring compliance is embedded in the iterative design cycles.
This paper not only highlights how Sunswift has applied QFD but also offers insights into how the methodology can be extended to other high-performance design practices happening in teams and facing similar challenges. The study provides a replicable model for linking regulatory conditions to detailed engineering design, paving the way for improved compliance, consistency, and innovation.
1.1. Scope and objectives
This study investigates how QFD can be used to embed compliance into the design lifecycle of high-performance vehicles. This study uses Sunswift Racing, UNSW’s solar car team, as a case study to demonstrate how QFD can manage the complexity of translating regulatory and performance requirements into practical engineering outcomes.
The scope of the research includes:
1. Framework Development: Creating a multi-layered QFD matrix to translate high-level compliance requirements into specific subsystem design parameters and engineering directives and ensure clear traceability of requirements through all stages of the design process.
2. Design Lifecycle: Highlighting how QFD can support V&V to meet road legality requirements through the iterative design process.
3. Implementation
a) General Application: Developing a QFD framework that can be adapted and applied to other complex or high-performance product design teams or projects with compliance and design requirement challenges.
b) Case Study: Using Sunswift Racing’s projects as a testbed to demonstrate how the proposed innovative QFD approach can be implemented in practice.
This research focuses on technical aspects of QFD and its application to compliance and design processes. It doesn’t dive into areas like organizational management or cost optimization unless they are relevant to design requirements. The goal is to show how the approach streamlines compliance and improve collaboration in complex engineering contexts, especially those with large engineering teams.
2. Technical concepts and background
Verification and Validation (V&V) is a key part of the design process in systems engineering as it is used to ensure the final product is as close to the intended process as possible. Their importance cannot be overstated as “they directly influence production performance and ultimately define product functionality and customer perception.” (Reference Maropoulos and CeglarekMaropoulos, P & Ceglarek, D, 2010), representing a key part in the completion of any design process. There is a key difference between verification and validation as outlined by NASA (2023). Verification testing relates to the functional requirements that need to be met in a controlled environment to ensure the compliance of one or more systems. Validation, however, is a gauge of whether the product works as expected under realistic conditions. Both are needed to confirm a system technically meets regulations and is functional in real world applications.
The QFD method, introduced by Akao Reference Akao(1990), has been widely used in the SE approach to align customer requirements (CRs) with engineering characteristics (ECs) through one of its most famous matrices known as the House of Quality (HOQ) matrix. It helps prioritize design decisions and manage trade-offs (Reference CohenCohen, 1995). Puritan-Bennett demonstrated the benefits of the HoQ as a method of communication to understand the customer perspective and a framework for making consistent decisions, making their product a success with significant reductions in design time and costs by 40% and 60% respectively (Hauser, J. R., & Clausing, D., 1988).
Another study (Reference Park and KimPark, T., & Kim, K. J., 1998) explained how a House of Quality Model could be modified to incorporate Analytical Hierarchal Process (AHP) principles to prioritize design requirements & recommendations for improving air quality in non-industrial buildings. By introducing quantitative weighting techniques to assign numerical values for requirement importance, in addition to a mathematical model and sensitivity analysis that considered cost and feasibility constraints, a systematic method of deciding which design choices to implement presented an advancement from a typical HoQ or QFD application. Further development of a Three-Dimensional House of Quality (Reference Temponi, Yen and TiaoTemponi, C., Yen, J., & Tiao, W. A., 1999), combined a customer’s HoQ with an employee’s HoQ to extract optimal technical requirements from multiple perspectives.
Despite these advancements and benefits in studies which demonstrate the QFD’s success across various industries (Reference Chan and WuChan & Wu, 2002), HoQs and QFDs still have implementation challenges (Reference JaiswalJaiswal, E. S., 2012). Challenges such as high data collection efforts and subjective weighting (Reference Bosch-Rekveldt, Jongkind, Mooi, Bakker and VerbraeckBosch-Rekveldt et al., 2011) as uncovered in simulations of different scaling methods by Olewnik, A., & Lewis, K. Reference Olewnik and Lewis(2008), mean that decisions derived solely from HoQ, QFD and similar methods cannot be reliably replicated.
3. Methodology
In this paper, we look at a novel approach of applying a QFD in a regulatory compliance setting or general design requirements. With respect to the case study, the particular focus is on the Australian Design Rules (ADR) that oversee the compliance of automobiles in Australia. We develop an innovative approach to set up a QFD matrix to track and verify compliance requirements, incorporating V&V techniques with QFD in the SE process. In the context of the case study, this enabled us to understand the use case for development of Sunswift 8, a solar-electric-hydrogen vehicle being developed in the Sunswift Racing project at the University of New South Wales, Sydney, Australia.
The QFD approach includes the development of a House of Quality containing the attributes:
1. Stakeholder requirements
2. Importance rating for each stakeholder requirement
3. Features / functional requirements
4. Relationship scores between stakeholder requirements & features
Required outputs from using a QFD include a weighted score for stakeholder requirement and a technical importance score for each feature (Reference Revelle, Moran and CoxRevelle et al.,1998). As the example given in Figure 1 on doors of the Sunswift, safety was determined to be a crucial stakeholder requirement followed by durability and ease of use with a smooth mechanism, stable hinges and opening assist found to be valuable features for answering customer’s needs for a door.
Quality Function Deployment
3.1. Innovative application of QFD concepts to compliance requirements
This proposed approach of a traditional QFD was adjusted to accommodate for the differences in use cases when it comes to compliance requirements (CRs). These CRs serve a different purpose to stakeholder requirements as they must be met to obtain compliance certification. Therefore, all CR would be scored a 5/5 for the importance rating using the scale above, rendering the rating redundant. Instead, each project or subsystem design in a specific design discipline stands as a requirement for the creation of a complete product while each set of compliance requirements pertaining to a subsystem or project (ADR in the demonstration case) act as a feature, enabling the formation of a product that meets all the compliance requirements. As a result, the approach of defining relationship scores in the HoQ is modified. In the proposed approach, instead of being assigned a value based on the strength of the relationship between a requirement and a feature, this score would represent the number of requirements that relate a project to an CR. Thus, the weighted score of each stakeholder requirement simply becomes the number of requirements that pertain to a project/discipline while the technical importance score becomes the number of requirements that pertain to a CR. Given that each CR must be complied with, there is no priority ranking in the sense of eliminating less important features. However, each CR can be given a priority ranking to determine how much attention that CR needs based on the number of requirements, enabling more time for aspects such as requirement validation and testing to be conducted. The Verification Process involves the following ordered steps:
1. Identifying any relevant CR requirements (in the case study ADRs are equivalent to CRs)
2. Color-coding CRs based on whether it would be categorized as key information to note, key requirements to test or inapplicable requirements
3. Extracting relevant specific requirements from testing or evaluation reports to put them into individual CR checklists
4. Assigning relevant projects and departments to each specific requirement
5. Design engineers declare whether CRs are correctly assigned to their project/subsystem design
6. If not, another project/subsystem design is listed, and step 5 is repeated
7. Updates are reflected in a project assignment check, with the end goal of having all requirements assigned to the right project
8. An updated overview sheet displays which CRs are left for each project to verify
9. V&V are integrated into an overall timeline sheet, enabling requirements to be completed at different design phases and times
10. Systems engineers verify requirements from the design engineers are satisfied
11. Updates are reflected in the CR-QFD Tracking Matrix, with the goal of no requirements left to verify, signaling compliance with all CRs.
Given the scope of the proposed QFD in this methodology, the QFD is applied in both the project validation matrix and requirements tracking matrix, acting as a digital shadow. The former relates requirements to projects while the latter tracks the progress of requirement completion.
4. Case study application
4.1. Sunswift Racing and projects
Sunswift Racing is a team of students from the University of New South Wales that holds the Guinness World Record for the fastest Electric Vehicle over 1000km on a single charge and won the 2023 Bridgestone World Solar Challenge. It consists of 80-100 members from 9 different academic disciplines ranging from Computer Science to Chemical Engineering who are also organized into technical departments with interdisciplinary relationships within each department. This allows for stronger communication and a range of different skillsets within a department.
In Sunswift Racing, projects refer to the higher-level assemblies and installations that need to be completed to complete the design and manufacture of a new Sunswift Racing vehicle. They are allocated to a primary department with the potential to include secondary departments to cover all the technical requirements needed for a complete project.
4.2. Australian design rules
In Sunswift Racing’s goal to build the world’s first ‘TriBrid’ road-legal car, combining solar, battery and hydrogen fuel cell technology, the Australian Design Rules (ADRs) are the national standards for vehicle safety, anti-theft and emissions that the new Sunswift vehicle must comply with to be considered road legal in Australia. They encompass a wide range of requirements that impact different departments within the team, ranging from a vehicle’s exterior surfaces and ride height to the safe implementation of newer technologies such as battery or hydrogen systems.
ADRs are inconsistent in the way that different requirements are presented differently. Some requirements are provided with specific testing procedures and explicit values to test against, whereas others are more qualitative design guidelines on how certain components need to look or act. The differences between requirements as well as the sheer number of them makes forming a general procedure for the compliance process that applies to all requirements difficult. If design engineers are not aware that a requirement is directed at their project or a requirement is assigned to an incorrect project, this may necessitate the modification of existing designs for a project which may affect another project, which may affect another and so on. If designs need to be significantly altered, months of work may now be redundant, delaying the car build process and drastically increasing costs associated with building a student-built road-legal vehicle. Needing to do this becomes extremely problematic after detailed designs ready for manufacturing are already finalized or manufacturing has already occurred.
4.3. Requirement identification and categorization
To effectively incorporate ADRs into the Sunswift vehicle design process, a thorough scoping, analysis and categorization of each requirement was conducted. The first stage involved an in-depth review of each ADR document by multiple team members, initially assessing which requirements may relate to the passenger vehicle category that Sunswift Racing vehicles fall under. In the second stage, a system was developed to further analyze each document, ensuring that all relevant information was assigned to specific Sunswift projects and organized in a report format for compliance purposes.
An efficient color-coding system shown in Figure 2 was developed to streamline the process of requirement identification & categorization. Requirements that could be tested were highlighted in green, important design information in yellow, and requirements for optional features not included in the new Sunswift Racing Vehicle’s plans were left unhighlighted. Strikethrough was used to indicate inapplicable clauses, such as those specific to collision testing or trailers. Also, notes were recorded for requirements that do not currently apply but may be relevant for future Sunswift vehicles.
Color-coding system
This system was applied to a PDF version of each ADR, which included all current legislative regulations, ensuring every requirement was addressed and categorized. The method was designed for quick implementation, enabling team members to easily locate and apply ADR requirements to project designs, ensuring all necessary clauses were accounted for in a systematic manner.
4.4. Testing reports for validation phase
Building on the initial categorization and scoping, the next phase involved transforming the highlighted ADR documents into structured testing reports which would serve as a dynamic tool to address regulatory guidelines with Sunswift’s design features and ensure that each clause is thoroughly addressed. Each highlighted ADR document was reviewed to identify actionable steps for compliance, align requirements with Sunswift projects, and outline relevant testing procedures for verification.
As vehicle design progresses through more advanced development stages (conceptual, preliminary, detailed design), these reports evolve into a comprehensive record of supporting certification. This highlights the importance of testing reports in validating that each requirement is met through detailed evidence by ongoing testing, while also serving as clear and accessible references for project leads and stakeholders. By linking each ADR requirement to the relevant project(s), the reports help team members clearly understand which vehicle components are associated with each clause. In this way, the testing reports not only offer evidence of compliance but also act as dynamic tools for the ongoing V&V of ADR requirements. This documentation process is ongoing and will continue until the entire vehicle is completed, allowing compliance verification to occur alongside development. The testing reports provide a detailed, replicable framework to validate and organize every aspect of vehicle design, aiming to present complete reports to compliance authorities to confirm ADR compliance.
4.5. Creating the verification plan
The verification plan for Sunswift uses a structured testing approach to ensure that all components meet required ADR standards. This plan follows verification and validation (V&V) practices and tailors them to the specific needs of vehicle design. Since different components of the Sunswift vehicle are sourced, manufactured, or developed by various partners, the verification plan needs to adapt accordingly, with appropriate testing methods for each type of component. This flexibility ensures that each part of the vehicle is checked in a way that is relevant to its role in the system.
At the conceptual and preliminary stages of design, ADR requirements are incorporated, allowing early identification of potential interfacing and compliance issues. The verification of ADR requirements is organized following the testing report process, with the implementation of excel-based checklists that compile each requirement and testing procedure from each ADR.
4.6. Data repository structuring approach
Excel-based checklists were developed to keep track of all ADR requirements, acting as the foundation for a QFD matrix, as shown in Figure 3. Each regulatory clause was added as an individual line item, ensuring that no requirement was missed and that all requirements were assigned to a specific project in the car, thereby, helping to systematically map ADR requirements to specific design features. Clause numbers, self-assigned requirement names were added to ensure that design engineers could still resort to extra information provided in the testing reports. Progressing further into the testing phase, testing procedures for each requirement will be formed and displayed on each checklist, optimizing the amount of information that needs to be displayed.
Data repository structuring
4.7. Project validation matrix
Given the complexity of ADR compliance, with over 60 ADRs and 1000 independent requirements, ensuring each design engineer is aware of and is designing their project to adhere to each requirement is crucial. The project assignment check matrix, shown in Figure 4 a, is a visual tool to accomplish this. By developing the explained data repository, each requirement was assigned to a project by a systems engineer with a ‘pending’ project assignment check shown in Figure 3. If the right project is assigned, the design engineer would change the ‘pending’ status to ‘yes’, thereby agreeing this requirement is their responsibility. As more design engineers perform this action, this becomes reflected in the Project Assignment Check Matrix, where the intersection of an ADR and a project represents the number of unassigned requirements. If a design engineer deems that their project is incorrectly assigned to that requirement, they would simply change ‘pending’ to ‘no’ and list which project it should be, which would automatically update the Project Assignment Check Matrix. By the end of the process, the matrix should be blank, signifying that each ADR requirement has been assigned to the correct project. Thus, the Project Assignment Matrix is an intuitive visual tool that displays the assignment of relevant requirements to the correct projects for not just systems engineers but design engineers as well.
a) Project validation matrix b) QFD tracking matrix
4.8. Application of QFD-tracking matrix on ADRs
The proposed approach for developing QFD Tracking Matrix was applied to manage the complex ADR verification process. Using the parameters attributed to each requirement in data repository, a requirements tracking matrix adapting QFD principles was created, shown in Figure 4b. Each row represents a new project while each column represents a new ADR. At the intersection of a project and ADR, the number of remaining requirements to verify a project inside of a given ADR is displayed. Thus, the information pertaining to the requirements for each project and ADR is displayed:
1. The Total Number of Requirements to Verify
2. How Many Requirements Have Been Completed
3. The Percentage of ADR Requirements Completed
4. How Many Requirements Are Left to Verify
By observing the 4 values above for each ADR, various insights into verification process of ADRs are established. At initial stages of the V&V process, the QFD Tracking matrix highlights which ADRs initially contain more requirements, thus allowing bigger ADRs to be prioritized and testing for these ADRs to start earlier to mitigate delays.
As a requirement is verified, this is updated in the individual requirement sheet outlined in the data repository structuring section. This change is reflected in this QFD Tracking Matrix of ADRs. As the numbers in the matrix decrease, this signifies there are less requirements left to verify. Thus, the progress of verification for each ADR can be tracked in real-time, with the matrix acting as a digital shadow of the verification process. And so, a major benefit of this matrix is that if certain ADRs are displayed to have lower completion rates or an abundance of unverified requirements compared to what was expected, this is easily identifiable and can instigate the investigation of the cause, potentially due to a delay with the testing facility or a project itself. Through analyzing the progress of V&V for each ADR through this QFD Tracking Matrix, testing timelines can be easily modified to accommodate for changes to a broader timeline.
When individual ADR checklists are updated, the number of requirements for a project to comply with also decreases. So, it is a similar process for individual projects. Projects with more requirements will need more time to complete and so the verification phase (and preceding design phases) will start earlier to account for this. As car development progresses, the QFD Tracking Matrix displays which projects still have a significant number of unverified requirements and thus assigns more priority to these projects.
The QFD Tracking Matrix enables efficient tracking of ADR requirements, necessary for completing the testing reports explained in Section 4.5. Additionally, by revealing the number of requirements left to verify for every project in a Sunswift Racing Vehicle, the matrix facilitates progress tracking and timeline management not just for the build of the current Sunswift Vehicle, but all future versions of Sunswift Vehicles that are aiming to be road legal as well.
4.9. Single source of truth
Even though all the features to assist ADR compliance described above are useful, a high-level overview that can be easily understood and enacted upon through the data structure shown in Figure 5 accurately displays which ADRs are relevant to each project. Each row of this master sheet represents a project in Sunswift. Through the digital shadow properties of the ADR QFD Tracking Matrix explained in 3.8, the ADRs are listed in order of most requirements to least (excluding zero requirements) and are updated as requirements become verified. Accordingly, a design engineer will be able to see which ADRs they need to comply with throughout the V&V process. More parameters such as the type of testing required (physical, simulations, inspection) and timeline stages (pre-build component testing, post-build assembly, installation and whole car testing) may be developed into the master sheet, allowing for a comprehensive overview and timeline of all aspects of the V&V process.
Single source of truth
4.10. Verification process of ADRs
The ADR Verification Process is separated into the following steps:
1. Highlighting the PDF
2. Testing reports (with comments about relevant projects/information)
3. Extract relevant requirements from testing reports to put into individual ADR checklists
4. Assign a preliminary relevant project to each requirement
5. Initial version of master sheet displays which ADRs are relevant to each project
6. Design engineers declare whether the requirement is correctly assigned to their project
7. If not, the relevant project is listed, and step 5 is repeated
8. Updates are reflected in the project assignment check, with the end goal of having a null matrix (which means all requirements have been assigned to the right project)
9. The updated master sheet correctly displays which ADRs are left for each project to verify
10. Integration to an overall timeline sheet shows at which phase a requirement should be verified
11. Systems engineers verify requirements from the design engineers
12. Updates are reflected in the ADR Requirements Tracking Matrix, with the goal of a null matrix signifying there are no requirements left to verify
Incorporation of the proposed artifacts in this approach with the V-Model present in Systems Engineering is shown in Figure 6.
Sunswift validation and verification diagram
5. Conclusion
The complexity of complying with over 60 ADRs totaling more than 1000 requirements necessitates a method that not only identifies the requirements but also follows through to the validation and verification of these requirements to ensure compliance. Since Sunswift Racing had not implemented a comprehensive approach for managing design requirements for any of its previous vehicles, it was imperative that one systematic solution could be established so that any future Sunswift Vehicles wouldn’t have the recurring issues regarding the ADR compliance process. A major challenge was the difficulty in proper identification and tracking relevant requirements. This challenge arose from design engineers simply being unaware of certain requirements that were directed at their project either because they simply were not found or the previous project lead for a project may have been aware but not communicated it to new project lead as personnel changes very frequently in Sunswift. Moreover, there was a potential risk in which a requirement to be assigned to an incorrect project, potentially to be corrected after designs were finalized or manufacturing had already occurred resulted in delays or errors. This study proposed an innovative Quality Function Deployment approach that aimed to systematically manage design requirements and overcome the challenges identified. The initial stages of this approach focus on ensuring that the system engineers can recognize the existence of a relevant requirement and visually display them as different categories early in the design process. This is done through the master sheet that clearly categories ADRs and assign them to specific relevant projects, this ensures that the design engineers are concerned to requirements that affect their projects, not all the more than 60 ADRs they would have had to without this system in the described Sunswift case. This feature dramatically reduces the complexity of tracking all ADRs and streamlines the process (addressing the framework development objective of the paper). The core of this approach lies in the modified application of the QFD framework, where valuable insights can be derived from the project validation matrix and requirements tracking matrix. For the project validation matrix, the progress of assigning requirements to projects is tracked and updated in real-time. Similarly, the progress of verification for each ADR can be tracked in real-time, with the requirements tracking matrix acting as a digital shadow of the verification process. In both these cases, even if just one out of more than 100 projects in each Sunswift Vehicle has not completed the project validation or requirements verification stage, it is easily detectable, facilitating the initialization of solutions to any issues for a specific project. Furthermore, the requirements tracking matrix provides clear visibility of ADR completion rates, helping to identify requirements that are lagging behind and ensuring swift investigation and corrective action. ADRs with lower completion rates are easily identifiable from the matrix itself drastically reducing any uncertainty and concerns around the progress of ADR verification task. It also has the added benefits of eliminating the need to decide which ADR requirements should be prioritized if an ADR’s completion rate has halted or is significantly below where it is expected to be at since an investigation can uncover why this has occurred, potentially due to a delay with the testing facility or the project itself, and subsequently present a solution much quicker than previously possible (addressing the design lifecycle scope of the research). However, while the QFD approach offers improvements in managing compliance requirements, several limitations must be considered. The system’s dependence on real-time data tracking relies heavily on consistent and accurate data entry from all team members, which can be challenging to maintain, especially in large, dynamic teams like Sunswift Racing. In some cases, if a project lead overlooks or misinterprets the requirements, this could introduce errors into the system that may go unnoticed until later stages. Furthermore, the system may require substantial upfront training and a cultural shift within the team to ensure that all engineers fully embrace and consistently use the QFD tools. Additionally, while the approach is highly effective in handling regulatory compliance, its implementation may be more difficult to adapt to other contexts or product types that don’t share similar complexities or regulatory requirements. The need for ongoing updates and refinements to the matrices may also introduce overhead, particularly as project scopes evolve over time.
The latter stages of approach ensure that when submitting the ADR reports to compliance authorities, data repository displays every ADR requirement where combination of the right project being assigned to it and its testing procedure in the data repository covers all aspects of V&V.
Despite these challenges, the implementation of the QFD approach for Sunswift Racing provides an effective, scalable, and reusable solution for managing the design requirements of road-legal vehicles, ensuring that all compliance aspects are thoroughly validated and verified in an efficient manner. This methodology can be adapted for use in similar high-performance and regulatory-intensive design contexts (addressing the implementation objective of the paper), though careful attention must be paid to the limitations and potential challenges outlined above.
6. Discussion
The task of managing regulatory compliance in complex design projects, such as the explained Sunswift Racing, faces various difficulties—ranging from the sheer volume of requirements to frequent team turnover and the complexities of tracking multiple design iterations across various stages. The proposed QFD-based approach in this paper streamlines the compliance process, the ADRs in this case. However, while the approach has demonstrated notable improvements in Sunswift Racing’s ability to manage and track regulatory requirements, there are several reflections, challenges, and opportunities for further development, particularly in the context of Industry 4.0 technologies. By clearly assigning specific ADRs to relevant projects early in the design process and providing real-time tracking of requirements verification, the approach ensures that no requirement is overlooked or assigned incorrectly. Project Validation Matrix and QFD Tracking Matrix facilitated real-time updates and visibility into the verification process, enabling proactive management and quicker issue resolution. By repurposing the QFD methodology to be a digital shadow of the requirement validation progress of all requirements, this innovative approach make a valuable contribution to design science by improving the compliance verification process for any car manufacturer in Australia. Additionally, this approach can be adopted not just for ADRs but extended to a range of applications such as other vehicle standards, medical device approvals, construction and more, impacting the broader design science field.
However, the success of this approach relies on consistent and accurate data entry. The reliance on human input—especially in a high-turnover environment causes some vulnerability. Also, the issue of knowledge transfer can cause errors if there is insufficient communication between team members. This might pose challenges to the scalability of this manual tracking approach. Therefore, this research suggests investigating automation and streamlining data entry. Moreover, human errors in data entry can accumulate over time, which can lead to some discrepancies in the proposed matrix that may not be discovered until the later stages of design or even manufacturing. This again emphasizes the importance of having some automation. The proposed approach helps address compliance-related challenges in design and verification stages, it requires continuous monitoring and refinement. For example, in case of regulatory changes flexibility of system might be tested, requiring real-time adaptation that could introduce unexpected challenges. It is also worth mentioning that, in non-regulated industries, the necessity for such a detailed tracking system may lead to developing over-engineered solutions with no benefit and prolonging the early design stage and wasting resources.
In addition to QFD, other requirements management methods and tools could also be appropriate for ensuring compliance and design traceability in complex engineering projects. For example, SysML diagrams, such as requirement diagrams and block definition diagrams facilitate clearer communication between interdisciplinary teams and help prevent inconsistencies in requirement interpretation. Unlike a QFD, which focuses on translating requirements into specific design parameters through a structured matrix, SysML provides a model-based framework that visually links requirements with design and verification activities. When combined with QFD, SysML can enhance the ability to manage complex compliance structures, reducing ambiguity and improving collaboration in large-scale engineering projects like Sunswift Racing’s vehicle development.
The scope of this study is highly relevant to the industry 4.0 and digital engineering paradigm, particularly to the digitalization of the design and testing processes. The Project Validation Matrix and QFD Tracking Matrix can be uplifted with more sophisticated Industry 4.0 tools that integrate big data analytics, AI, and machine learning. For example, the proposed QFD can be equipped with AI module to automatically detect discrepancies in the tracking matrices. Additionally, machine learning algorithms could analyze the progress of ADR verification and suggest optimized testing schedules or flag potential delays before they become critical. Application of AI and ML can be investigated to automate or semi-automate the process of assigning requirements to specific projects based on historical design data. Another future research for this research can be the application of blockchain technology to allow secure and transparent tracking of requirements and verification statuses. Blockchain could provide an immutable record of all updates and changes made to the project and verification matrices, ensuring data integrity and providing a transparent audit trail for compliance purposes. This can be crucial to those environments that need to with multiple external stakeholders or regulatory entities.
Open access
