Our department is responsible for transforming the System Integration (SI) business within the NEC Group and promoting the improvement of quality and productivity of products and services. We are involved in planning and promoting measures related to software and systems engineering, such as development methodologies. Additionally, we advance the cross-organizational technical coordination and dissemination of expertise related to the overall production of software and systems. In the context of increasing complexity and diversification of quality requirements for IT systems, there is a need for a framework that allows logical and objective explanations of quality. The ISO/IEC 25000 (SQuaRE) series, an international standard, has proven to be an effective approach to understanding quality. It is crucial to reach an agreement with customers on quality requirements from the proposal and project planning phases, and to utilize these requirements as a basis for project quality throughout the execution and completion of the project. This is seen as a "quality strategy" for SI projects. In this report, we will discuss the activities and innovations related to applying this strategy to various internal standard processes, as well as the challenges encountered when applying them to projects.
In today's unpredictable VUCA era (Volatility, Uncertainty, Complexity, Ambiguity), we cannot know whether the anticipated digitalization will align with user demands without actually trying it out. Additionally, there is a need to respond to changes in the market and user needs with overwhelming speed.
Under such circumstances, achieving high customer value and addressing the diversification of customer requirements in the SI business becomes crucial. Both require firstly understanding customer's quality concerns. Customer's quality concerns encompass not only the presence or absence of bugs but also effectiveness for customer operations, ease of use of the system, reliability, and more. SQuaRE is effective in understanding customer’s quality concerns in situations where quality tends to be handled centering on the presence or absence of bugs, as stated in the paper [1].
In SI projects, cost control and lead time reduction are often prioritized, sometimes leading to technical considerations taking precedence over customer requirements. Particularly with the waterfall development method, there is a project risk of declining quality as cost and delivery time become priorities in the later phases of the project. In the agile method, although customer understanding has been advancing, there are aspects where providing the required value becomes difficult in situations where cost control and lead time reduction are also demanded. Additionally, it must be assumed that the level of required quality will continually change. In this way, the issues differ between the waterfall development method and the agile method, and factors other than quality also come into effect. However, it should be noted that understanding customer’s quality concerns, agreeing on how to achieve it and its prioritization, are essential from the proposal and project planning phases.
We believed that in the VUCA era, SI projects require a methodology that strategically focuses on quality to quickly respond to customer demands, control costs, and shorten lead times in IT system development. The situation we are in is as follows.
concerns: It was confirmed that SQuaRE's quality model/quality characteristics can be used to understand customer’s quality concerns.
Standardized SI Methodology: The methodology for building IT systems has been standardized over many years. This includes both domestic and international knowledge, as well as internal and external expertise. [2]
Considering these circumstances, we are developing a strategic quality management methodology for SI in the VUCA era. We call this methodology the "Strategic Quality Management Method for IT System Development" (hereafter referred to as Strategic Quality Management Method).
The Strategic Quality Management Method focuses on quality in a strategic manner. Ideas were derived from Quality Function Deployment (QFD) [3]. Initially, QFD was a methodology for developing competitive products. However, it is also used as a quality assurance mechanism. It clarifies the quality required at the upstream phase and ensures that it is conveyed and reflected in the downstream processes.
QFD has various deployments. Below, we organize the perspective as an SI project.
Quality Deployment: Deployment from customer requirements to realized functions/components. Mainly handled in business design to functional design.
Engineering Deployment: From customer requirements to the design of implementation methods and frameworks of adopted technologies. This is managed within the standardization of a project.
Cost deployment: Quality targets for functions/parts are clarified from customer requirements and developed into highprecision cost estimates. It is used in rough estimates and final estimates.
Reliability Deployment: Deployment from customer requirements to non-functional requirements. It is handled in the software development domain and platform construction domain as non-functional requirements.
Job Function Deployment: Upon receiving customer requirements, define and implement processes for quality deployment, engineering deployment, cost deployment, and reliability deployment. This corresponds to the methodology of SI. • • • • • • • • •
By linking quality deployment with job function deployment, it ensures the "traceability of technical information," showing how the requirements will be realized through certain characteristics, technologies, and functions.
These effects ensure the traceability regarding customer’s quality concerns, allowing for an accurate understanding of how additional/changed requirements impact the original customer requirements. The QFD methodology influences the improvement of QCD (Quality, Cost, Delivery), profit improvement, and the overall optimization of quality management in SI projects. These are indeed the themes to be addressed in SI projects in the VUCA era, aiming to realize these effects through the Strategic Quality Management Method.
In the NEC Group, there is a method called Software Quality Accounting [4]. This method statistically predicts the presence of bugs from the perspective of process quality, which corresponds to maturity, one of the quality characteristics in SQuaRE. Software Quality Accounting uses quality metrics such as the number of bugs and the amount of review time, and it does not directly contribute to the improvement of the quality of project deliverables. On the other hand, the Strategic Quality Management Method primarily addresses product quality. This method, covering all quality characteristics of SQuaRE, directly contributes to the improvement of project deliverables.
By considering quality characteristics in requirement definition and basic design, it is possible to perform project tasks with the necessary quality perspective. As a result, project members can document these outcomes in project deliverables. Therefore, it was determined that incorporating this method into various internal standard processes would help penetrate the SI project site. There are optimal ways to integrate this into different activities such as proposal, project planning, software development, and platform construction. Hence, only the points of contact were clarified first. In Figure 1, the overall picture of utilizing the characteristics of SQuaRE in SI projects was constructed. And the timing of using each division of SQuaRE and the The effects of QFD that are focused on strategic quality management in SI projects are summarized below. The followings have been long-standing challenges in SI projects.
incorporate customer requirements for quality. It ensures that quality elements included in the upstream phases are reliably transmitted to the downstream processes (process perspective). handling scope of the quality strategy formulation process were clarified.
In the strategic quality management process, the proposal, project planning, requirements definition, and basic design are considered the core of quality strategy formulation. The quality strategy is positioned to be completed after the basic design of the IT system. This is because by the basic design phase, the QCD requirements and estimates for the target system construction are finalized, marking a significant milestone in mutual agreement between the customer and the SIer.
Of course, quality requirements will arise during functional design, internal design, and coding. These are addressed in the quality strategy formulation as scope confirmation after the final estimate (post-functional design) and internal quality from the developer’s perspective (internal design to coding).
Next, in Figure 2, the quality strategy formulation process is detailed, aiming to integrate the quality strategy process with various internal methodologies. Our internal process standards include the customer agreement guidelines for the customer agreement process, project management process standards for the project planning process, software development process standards, and platform construction process standards for IT system construction. We clarified the linkage points with these processes and organized the types of information and objectives at each linkage point. The process of formulating a quality strategy is defined by three major steps. These steps are explained using the 5W1H framework.
In the proposal phase (strategy planning phase), it is important to understand customer’s quality concerns (What, Why). By using SQuaRE quality characteristics guideline for SI [1], we aim to accurately understand customer requirements in the SI project from the proposal phase. We will proceed with obtaining customer agreement according to our internal customer agreement guidelines.
In the project planning phase, it will be decided how to handle the identified quality aspects. This corresponds to the formulation of a quality strategy (When, Who, How). In decision-making, we utilize the positive and negative effects and derivations [1] among quality characteristics to maximize ROI, avoid risks, and prevent over- or under-engineering. We will carry out job function deployment and cost deployment in quality function deployment.
In the requirements definition and basic design phases, quality strategies and quality objectives are cascaded down as business functions and system functions materialize for system implementation. Based on quality strategies, quality objectives are divided by function (Where). In Quality Function Deployment, quality deployment, technical deployment, reliability deployment, and cost deployment are conducted.
Through the three steps of quality strategy formulation, it becomes possible to achieve the effects of Quality Function Deployment (QFD). These effects include "ensuring customer requirements are integrated into quality", "conveying quality elements integrated in the upstream phases to the downstream phases", and "communicating quality elements for the entire system to each element of the system".
During the quality strategy formulation process, a quality table is created at each phase of QFD (Table 1). These quality tables are templated and standardized, with some providing references based on internal process standards, making them usable along with the process. We have developed a more than 200-page quality strategy formulation process definition. This guide clarifies the timing of these series of steps and how to utilize quality tables based on various internal process standards. Engineering deployment uses the results of quality deployment (various quality tables) in standardized activities within the project. Cost deployment uses quality tables (system function-quality characteristics, common components-quality characteristics) deployed after basic design as a project management process. Reliability deployment uses nonfunctional requirement definitions during the requirements definition phase (affecting both software development and platform construction) utilizing tools like the non-functional requirement grade table [4]. For non-functional requirements, in current SI project fields, SQuaRE's quality characteristics are often treated, allowing quality management without creating quality tables. Therefore, the policy is to document them in individual project deliverables.
The application of the strategic quality management method in the Proof of Concept has started. However, it is necessary to accompany the SI project period, and it will take considerable time. Therefore, we plan to report separately after some results become visible. Here, we introduce a case where the PoC was partially implemented during the quality strategy formulation process. This case involves considering the introduction of strategic quality management into an SI project that uses the waterfall development method, utilizing business package software on SaaS. of requirements in the strategy planning phase are not concrete is a significant finding.
We hypothesized and acted on presenting quality trend analysis reports [1] to strategy planning phase projects. This helped understand the effectiveness of understanding customer’s quality concerns using SQuaRE quality characteristics. It also aimed to support decision-making for the introduction of strategic quality management.
the strategy planning materials. We analyzed the presence and quantity of mentions for each quality characteristics. We checked for any implicit requirements and presented the findings as a quality trend analysis report. By specifically indicating the aspects of customer’s quality concerns, we aim to demonstrate the effectiveness of understanding quality through the quality characteristics. This gives the project manager a sense that strategic quality management can be implemented.
We propose for initiating quality management from the strategy planning phase, prioritizing tasks, and reflecting them in the project plan. Personnel well-versed in SQuaRE quality characteristics and strategic quality management methods will support the project closely.
In the quality trend analysis report, the rationale for linking requirements and quality characteristics is specified. However, due to the busy schedules of project members, there was a lack of understanding of quality characteristics, making it difficult for them to learn. Strategic quality management, such as understanding the quality characteristics of SQuaRE, is necessary. But prior learning was challenging in the hectic SI project environment.
Since the requirements are in the strategy planning phase, some have not yet been turned into specific requirements. This led to many doubts among project members about the basis for classifying quality characteristics. It was recognized that concretizing quality requirements is not feasible at this phase, and that proper deployment of Quality Function Deployment (QFD) before classifying quality characteristics is crucial. However, identifying that part
We conducted an analysis of the Proof of Concepts results from two perspectives.
It is advisable to advance the learning of SQuaRE quality characteristics as much as possible in SI project sites. However, project sites seek tools that can deliver concrete results in the execution of SI. For example, in the current business package software SaaS implementation SI, a checklist was required during the planning phase to determine the requirements for the business package software. Although it is okay for the checklist to be organized based on SQuaRE quality characteristics, the actual situation in the project site is that the checklist items are directly desired as requirements items for the business package software on SaaS.
For members who are responsible for developing organizational or project standards, it is appropriate for them to learn SQuaRE quality characteristics. Members involved in standard development are likely to be motivated to learn about quality characteristics as part of their mission. On the other hand, the extent to which all project members should learn SQuaRE quality characteristics depends on the type of organizational or project standardization being pursued. Forcing all project members to learn might not be necessary. Instead, it might be a good idea to structure project standardization in a way that directly contributes to project deliverables, as in the example of the business package software implementation checklist.
Since we are leveraging business package software as SaaS rather than developing from scratch, the selected software product already exists. In the planning phase, addressing the quality in use model, product quality model, and data quality model simultaneously may have hindered project members' understanding. The quality promotion department, which supports the project, also expressed a desire to address quality in use as first.
In the strategic quality management method, it assumes development from scratch and constructs the process assuming customer requirements will intermingle various quality characteristics of quality models (without conscious awareness of the quality models). The method is designed to handle customer requirements corresponding to three quality models comprehensively. However, when software products already exist like in business package SaaS, it is smoother and clearer to address quality in use first and then check external and internal quality, as explained in Annex C (C.5) of ISO/IEC 25010.
In Figure 3, considering the quality life cycle is crucial in the VUCA era to continuously achieve high customer value and respond to diverse customer requirements. This case is a PoC assuming a single SI project, but the quality concept is essential, especially in continuous improvement activities like DevOps and Agile practices.
In NEC's Software Quality Accounting, SI projects are categorized into several patterns for data analysis. The current strategic quality management method is based on a process definition assuming development from scratch, to organize the basic approach for application. However, considering processes for different SI patterns seems necessary.
Regarding the quality strategy formulation process, inspired by Quality Function Deployment (QFD), several quality tables and process definitions were developed. However, the abundance of quality-controlled information is a concern as it might burden SI project teams. Although we limited the necessary items to a minimum, we still need to create several quality tables. When considering a matrix of requirements and quality characteristics, defining and judging at least thousands of quality characteristics are needed. During the PoC evaluation, there were also concerns that this would burden SI project teams.
In actual SI project scenarios, understanding quality models and characteristics is difficult. Consequently, they fail to function as a common language or measurement standard. Even the quality promotion department, which supports SI project teams, has found it challenging to grasp these concepts fully. Although there is a vague understanding of quality characteristic types, dedicating valuable resources to accurately understanding these perspectives has hindered the classification and project tasks. We have already prepared a Quality Model SI Application Guide and provided it to SI teams, but there's a need to further enhance it with tools such as quick reference tables for SI-specific quality characteristic classifications.
Efficient handling of extensive quality management information and stable quality characteristic classification judgments require IT systems, such as using Generative AI, to become more practical. The existence of SQuaRE as a quality standard undoubtedly promotes the use of Generative AI.
Once these challenges are addressed, combined with statistical methods like Software Quality Accounting— which predicts bugs based on maturity—we are confident that achieving a quality lifecycle will enhance transparency in SI quality during the VUCA era. This will support customer operations and businesses more effectively.
NEC Corporation, Japan, “Application of ISO/IEC25000