Editorial Feature

A Customer-Driven Approach to Product Engineering of Micro and Nano Devices - Requirement Analysis

Product engineering of micro and nano technology (MNT) devices differs substantially from product engineering in more traditional industries. The general approach is mostly bottom up, as it centres around the available fabrication techniques. The strong emphasis on manufacturing technology leads to a large number of application specific fabrication processes. For a comprehensive product engineering (PE) approach, the customer (as purchaser of the desired devices) has to have control over the specification and design flow. The customer is the only party capable of driving the product engineering process. He/she defines the technical requirements and economical constraints according to his/her interest in a successful product.

Within the EU FP7 project CORONA a comprehensive PE methodology in combination with a supporting software tool framework is currently under development. To determine the requirements for both methodology and tool framework, a detailed analysis of currently existing models and methodologies employed in the MNT-industry has been performed.

This paper presents the results of the requirement analysis for the product engineering approach.


In recent years, the demand for MNT (micro and nano technology) products has grown rapidly and is expanding quickly into new market segments1. Today development is performed in globally distributed organizations. In combination with tighter budgets and shorter time to market, this demands a more efficient product engineering approach. Different application areas, the variety of manufacturing technologies and the considerable number of small and medium sized companies makes a cooperative, globally distributed development approach common in the MNT industry.

The development of the geometric device design and the corresponding manufacturing steps are highly interdependent in MNT products (i.e. manufacturing processes are generally application specific). While in electronics the electrical material and device properties are paramount, in MNT devices the mechanical and electrical material properties determine the device performance and are therefore very important. Additionally, vertical layer properties require tighter control and therefore the interdependence of the device design and the exact manufacturing recipe is high in MNT.

Due to these higher degrees of freedom and the higher interdependencies between the different disciplines in MNT design, a comprehensive product engineering (PE) approach has to involve the customer and his requirements on a very detailed level. This can be achieved best if the customer is in control of the complete development process because only he know the exact specifications and the intended device application. Therefore the customer interactions with the development organizations and the development method itself need to be interwoven into the product engineering process. This integration of the customer in the MNT business is depicted in Figure 1.

Hierarchical model of the MNT business
Figure 1. Hierarchical model of the MNT business

The CORONA project financed under the 7th Research Framework by the European Union (contract number CP-FP 213969-2) has the goal to develop a comprehensive PE methodology in combination with a supporting software tool framework. The project partners represent different roles within the product engineering chain, presented in Figure 2, (e.g. integrated device manufacturer, pure foundry, fabless design house, research and development institute) and cover the currently prevalent business models3 encountered in the MNT industry.

Supply chain and Business models in MNT
Figure 2. Supply chain and Business models in MNT

The requirement analysis for the methodology follows a double tracked approach. The first track is a top-down analysis of currently existing models and methodologies. This includes general project management methods and product development model methods in literature4, and the often very specific methods currently employed in the MNT industry. The second track is a bottom up analysis of the typical business cases in the MNT industry. For this reason the business cases and processes of the partners involved in the CORONA project have been reviewed. This has been achieved by performing detailed interviews within these companies.

The combined results of both tracks lead to a set of concrete requirements for MNT product engineering. These requirements are described in the remainder of this paper. First, the general boundary constraints and the motivation for introducing a formal product engineering methodology are highlighted. This is followed by more detailed requirements for product development and project management.

Product Engineering

To define and extract the requirements for the methodology development, it is useful to look at the motivation to introduce and to use a methodology in the first place. Answering the questions: "What is product engineering (PE) all about?" and "What distinguishes PE from research?" offers some insight. The answers to these questions can be summarized in the following points:

  • Predefined time and budget limitations
  • Activities focused on actual "product"
  • Focus on reproducibility and quality
  • Predictability of the development progress and process
  • Focus on deliverables and the business case

Taking these requirements for development into account, it becomes clear that a thorough and flexible methodology needs to be established. The processes of such a methodology need to be rather flexible. They must provide a framework for execution that can be amended and merged with the processes already established within an adopting organization. The baseline for the framework should be a combination of a product development and a project management methodology. The product development method provides guidelines for target deliverables and the general steps as to how to progress the product development (the strategic goals and procedures). The project management method supplements this with the tactical procedures needed. Enriched with quality aspects and tools, a comprehensive, yet flexible methodology framework can be derived.


Boundary Requirements

As mentioned above, the customer is most likely the only entity in a development process that has a clear understanding of all functional, technological and financial constraints of the intended product. Putting the customer in control of the product engineering process can therefore lead to more streamlined product development as market and quality requirements are checked early.

The interview results show that the current involvement of the customer in the analyzed business cases is limited to the product specification phase. From then on the customer is only passively involved and updated with regular status reports. If a customer wishes to be more involved in the process obstacles and difficulties arise, because the current PE methodologies do not support such an extended involvement, and strict IP protection regulations prevent access to necessary design and manufacturing data.

To enable customer involvement in more phases of product development, the currently applied methodologies have to be augmented by new procedures. The most important requirement for these procedures is that they must not disrupt successful and well established work flows.

Equally important is to ensure that quality aspects of the project are covered. These largely depend on the products' application area, therefore, a flexible approach to integrating customer specific quality requirements is necessary.

General Requirements

The results of the interviews which were conducted recommend establishing a link between standardized methods like Stage-Gate, IPPD, PRINCE2 and PMBOK, and the methods specific to the project partner's environments. This link is especially important as the new methodology should not overthrow existing approaches but rather complement them with best practices. Another requirement of the methodology is that it must provide guidelines to organizations that have no or very limited experience in MNT product engineering, as the typical customer is most likely to belong to this group.

Minimum interference is one of the most important requirements for the further development of the methodology (framework). A possible solution is to offer a set of lean business processes (resp. modules), instead of one monolithic methodology. These processes will not be very detailed but they must provide a framework for individual adoption and amendment. All newly proposed or amended processes should therefore be as lightweight and flexible as possible. This also impacts on the requirements of the software framework that has to provide small and flexible services to support these processes.

Requirements for Product Development

The interview results assert the initial assumption that the product development approach in the MNT industry is almost completely process based. All approaches employed by the interviewees have in common that they start with a product idea that is refined through several consecutive development steps until the final product is ready for market launch. The following requirements have been identified as essential:

  • Quality of Execution
  • Product Development Quality
  • Resource Prioritization
  • Inclusion of Marketing Tasks
  • Early and Stable Product Specification
  • Parallel Processing
  • Cross-Functional Teams

Quality of Execution

Product development in the MNT industry depends on a very high level of quality in every development step. An appropriate product development methodology therefore requires distinguished quality-control checkpoints with clear and consistent metrics. Such intermediate checkpoints are based on best practices or direct customer requirements. Due to the variety of MNT product areas, these checkpoints need to be defined individually for each product during product specification. The checkpoints comprise of concrete deliverables, along with action standards and corresponding resource allocation methods.

In this context the methodology has to ensure that no deliverables are skipped, or quality criteria are ignored. In classic product development methodologies, these checkpoints are usually referred to as gates5. These gates are placed between the development phases and become quality-control checkpoints. According to Ref #5 these points are a key success factor for reduced cycle time and successful product developments.

Product Development Quality

According to the "Quality of execution" requirement above, it is necessary to define procedures that guide through the flexible adaption of the fabrication process and to manage it in a collaborative way. To be able to change fabrication processes "on demand", an additional toolset is necessary.

Resource Prioritization

The resources for product development are usually limited (e.g. budget, personnel, equipment). Therefore, methods to prioritize development efforts have to be part of the product engineering methodology. The prioritization of development efforts requires close customer interaction. This is especially true if prioritization means abandoning a certain development effort altogether. For such a case, processes should enable the customer to replace development partners if necessary.

Inclusion of Marketing Tasks

Marketing is an essential part of each product engineering process and includes tasks like preliminary market assessments, competitive analysis, concept testing, and of course very close customer interaction. If the customer is directly involved in (or as proposed, driving) the PE- process there must be a clear distinction between marketing efforts to keep the customer satisfied and preparations to make the product successful. For the marketable product, broad customer tests and field trials, test marketing and test launches etc. are required. Even the use of focus groups, customer panels etc. might be advisable to develop a product that really fits market needs. These activities need to start during product definition and have to continue during the whole PE process.

Early and Stable Product Specification

The product and requirements definition must be stable in the early product development phases as it provides the technological and legal baseline for all further development steps. A stable definition contains a mutual agreement between all involved parties (e.g. vendor, customer, R&D) regarding the requirements, features etc. This implies that the development target has been clearly defined. It does not mean though, that the results of the R&D process will exactly match the initial specification because usually there will be certain adaptations. Therefore a controlled change management process is required that coordinates necessary changes and keeps all stakeholders, and especially the customer, informed.

The early specification is one of the central steps in product engineering for customer interaction and therefore central to any customer driven developments. The product specification should cover aspects like target market, development and product concept, benefits and positioning strategy, requirements (functional and non-functional), and product features. Finally, the estimated production costs must be controlled during the whole process. At every gate (see quality of execution), the business plan / business case needs to be reviewed. The option of reducing production and/or development costs by (slight) modifications of the specification must always be monitored.

Parallel Processing

A MNT product usually consists of several physical components (e.g. the package, the fabrication process, the electrical- and non-electrical elements). A huge speedup of the development process can be achieved if these components are developed in parallel. In fact it is not acceptable to develop the different parts of a MEMS product one after another because of the interrelationship between the different components, sequential development would cause unacceptably long development periods. These interrelationships are also the main challenge for parallel development of the components, e.g. the development of the non-electrical part depends on the development of the fabrication process and vice versa. Therefore, flexible definition of control points for the exchange of intermediate results between development teams is essential. The methodology should foster this.

Cross-Functional Teams

Developing MNT products requires expertise in many different fields. The required expertise may also change during the development process. Layout expertise, for example, may only be required in late development phases. Therefore fluid teams, with new members added or dropped as work demands are required. As indicated above, the cross-functional nature of a development team is not only necessary within the technical teams; it must contain all functions essential for the product development. This includes, marketing, financial, sales, production, purchasing etc.

Requirements for Project Management

Before defining the requirements for project management, it should be made clear how the term "project" is defined in the current scope. A project is defined as a temporary and unique endeavour that is conducted in progressive elaboration using several steps or increments. Temporary in this context means that it has a defined beginning and end and can have a short or a long duration. A project has a lasting outcome addressing a business need with a well defined business case.

In addition, the results have a potentially limited market opportunity window and a project team which is disbanded at the end of the endeavour. It is unique in the sense that another project of the same entity will not have the same products, services or results. In this context it is important to distinguish between projects and operations. Operations are ongoing and repetitive and have the purpose of sustaining business.

All projects depend on critical success factors like executive support, user/customer involvement, experience of the project manager, clear business objectives, minimized scope, well defined requirements, formal methodology to follow, reliable estimates, etc. Projects are executed within the triple constraints depicted in Figure 37. The advantages of formal project management can be summarized as:

  • Better control of financial, physical, and human resources.
  • Improved customer relations.
  • Shorter development times.
  • Lower costs.
  • Higher quality and increased reliability.
  • Higher profit margins.
  • Improved productivity.
  • Better internal coordination.
  • Higher working morale (less stress).
Triple project constraints
Figure 3. Triple project constraints

To achieve the above goals and advantages, incorporated project management principles should comply with the following requirements. As indicated in the motivation, the project management principles are only a subcomponent of the overall product development method. It provides "only" guidelines and streamlines the execution. Therefore the project management principles that are adopted must comply with the requirements described for the product development method and must be supplemented with execution advice.

They need to comply with the following list of requirements:

  • Process Based Approach
  • Deliverable Oriented Process and Planning
  • Minimum Management Overhead and Interference
  • Transparency

Process Based Approach

The overall development efforts need to be driven by a defined, flexible business process offering advice for all potential development situations. Therefore, a utility box in terms of processes and tools needs to be provided, driving the development from the idea / customer request to a final product (which could be tangible or intangible as highlighted in the introduction).

Deliverable Oriented Process and Planning

To focus on the targets and the intermediate steps in between, a deliverable oriented development process and planning approach is desired. The completeness and the quality of the deliverables provide measures for intermediate assessment points during the development. They provide criteria for the possible prioritization of different projects (as stated in the description of the requirement for the product development process). Additionally a quality driven approach is enabled by making the project progress assessable.

Minimum Management Overhead and Interference

To allow for an efficient process, the induced overheads for the management of the projects should be minimized. Additionally the interaction with the stakeholders of the project should be optimized but kept as minimal as possible. Heavy reporting burdens and further necessities for management interaction should be prevented.


The project management principle and process needs to foster transparency concerning the status of the project, to all stakeholders. Therefore, it should provide means to effectively communicate the status, open issues, risks etc. and provide transparent assessment criteria during the development. This provides for easy auditing and quality assurance as well.

Conclusions and Future Work

This paper gives an overview of the requirements for a comprehensive approach to product engineering in the area of MEMS and similar nano or micro devices. It documents the first steps towards the support of a globally distributed, information-based product development method controlled by the customer and tailored to the MEMS/MST industry. The requirements indicate the use of a combination of methods from the product development realm defining the overall process, which is supplemented by the processes of a project management method. The documented requirements will be integrated into a comprehensive PE method based on Stage-Gate5 and PRINCE26 and further steps will automate many of the defined processes. In these efforts software components like XperiDesk® and tools from Coventor will be integrated into a framework fostering customer oriented, faster and more cost-effective MNT development.

The authors would like to acknowledge the financial contribution of the European Union financing the CORONA project under the 7th Research Framework (contract number CP-FP 213969-2). Additional thanks go to all project partners providing valuable knowledge from the domain and the software point of view.


1. NEXUS! Task Force: NEXUS Market Analysis for MEMS and Microsystems III, 2006
3. Yole Developpement: MEMS Foundries 2009 market report, 2009
4. D. Ortloff, "Product engineering for silicon based MEMS IP," PhD thesis, Universität Siegen, 2006.
5. Robert G. Cooper, "Product leadership - Creating and Launching Superior New Products," 1st edition, Basic Books, 1998.
6. Great Britain Office of Government Commerce, "Managing Successful Projects with PRINCE2," 5th edition, OGC, 2005.
7. From: "Information Technology Project Management" Fourth Edition


Disclaimer: The views expressed here are those of the author expressed in their private capacity and do not necessarily represent the views of AZoM.com Limited T/A AZoNetwork the owner and operator of this website. This disclaimer forms part of the Terms and conditions of use of this website.


Please use one of the following formats to cite this article in your essay, paper or report:

  • APA

    MANCEF. (2022, November 02). A Customer-Driven Approach to Product Engineering of Micro and Nano Devices - Requirement Analysis. AZoNano. Retrieved on March 05, 2024 from https://www.azonano.com/article.aspx?ArticleID=2612.

  • MLA

    MANCEF. "A Customer-Driven Approach to Product Engineering of Micro and Nano Devices - Requirement Analysis". AZoNano. 05 March 2024. <https://www.azonano.com/article.aspx?ArticleID=2612>.

  • Chicago

    MANCEF. "A Customer-Driven Approach to Product Engineering of Micro and Nano Devices - Requirement Analysis". AZoNano. https://www.azonano.com/article.aspx?ArticleID=2612. (accessed March 05, 2024).

  • Harvard

    MANCEF. 2022. A Customer-Driven Approach to Product Engineering of Micro and Nano Devices - Requirement Analysis. AZoNano, viewed 05 March 2024, https://www.azonano.com/article.aspx?ArticleID=2612.

Tell Us What You Think

Do you have a review, update or anything you would like to add to this article?

Leave your feedback
Your comment type
Azthena logo

AZoM.com powered by Azthena AI

Your AI Assistant finding answers from trusted AZoM content

Your AI Powered Scientific Assistant

Hi, I'm Azthena, you can trust me to find commercial scientific answers from AZoNetwork.com.

A few things you need to know before we start. Please read and accept to continue.

  • Use of “Azthena” is subject to the terms and conditions of use as set out by OpenAI.
  • Content provided on any AZoNetwork sites are subject to the site Terms & Conditions and Privacy Policy.
  • Large Language Models can make mistakes. Consider checking important information.

Great. Ask your question.

While we only use edited and approved content for Azthena answers, it may on occasions provide incorrect responses. Please confirm any data provided with the related suppliers or authors. We do not provide medical advice, if you search for medical information you must always consult a medical professional before acting on any information provided.

Your questions, but not your email details will be shared with OpenAI and retained for 30 days in accordance with their privacy principles.

Please do not ask questions that use sensitive or confidential information.

Read the full Terms & Conditions.