APDL Process Overview

The APDL model proposes a V-shaped process to develop the detail design with a top-down approach and complete the PVs, CTCs, and FTCs and produce and test the product with a bottom-up approach as shown in Figure 3.2.

The first step of the product development lifecycle is to elicit and clarify the customer needs. The objective of this step is to gather as much information as possible to correctly and completely identify all the stakeholders of the product, all the customer needs and problems relating the product to be developed as well as any constraints imposed by the customer, operational environment, rules and regulations, existing and available resources and technology on the development and selection of acceptable design solutions.

Once the CNs are available, they should be analyzed to derive initial FRs (FRis) and any product related constraints, called input constraints (ICs). The mapping from CNs to FRis and ICs is a simple mapping process. This mapping is performed once before the design decomposition starts and whenever there is a change in the customer needs.

Once the FRis and the ICs are derived, they should be analyzed to develop the system FR, DP, and SC triplet that states the system objective, the proposed system design, and the proposed system. Developing the system FR/DP/SC triplet helps ensure that a true top-down approach is used to analyze the requirements and develop the design. This triplet also serves as a mean to establish the scope for the system and the project.

Customer Need (CN) Identification Map CNs to FRi and IC

Develop System FR/DP/SC Start decomposition and zigzagging process from System FR/DP/SC

Develop children FRs Develop children DPs for the children FRs Evaluate the design

Acceptable Design (Uncoupled or

Decoupled)?

Develop SCs for DPs Develop draft PVs for

SCs Develop draft CTCs

for SCs

Are verifiable/ attainable FRs obtained

for all branches? Baseline FRs Is detail design complete? Complete PVs Complete CTCs Develop FTCs for baseline FRs Produce components by executing PVs Assemble subsystem by executing PVs Test components by executing CTCs Test subsystems by executing CTCs

Test the system by executing FTCs T o p -D o_w n D e_c o_m p_o s itio_n a n_d Z ig_z a_g g in_g Yes No No No Allocate ICs to DPs Yes Yes Bo tto m-U p C om ple tio n - Pro du ctio n - Te stin g No Yes

Figure 3.2 – APDL Process

Once the system FR/DP/SC triplet is developed, the design decomposition and zigzagging process starts. Since the initial FRis can be at different levels of detail, they should be mapped to the FR/DP hierarchy during the decomposition process where appropriate. The ICs that are derived from the CNs are first allocated to the top level DP, and then during the decomposition, the ICs are decomposed, if necessary and allocated to the lower level DPs.

During the decomposition, given the parent FR and DP as well as the allocated ICs to the parent DP, the functions that the DP has to perform in order to achieve the parent FR and satisfy the allocated ICs are determined and they are listed as the children FRs. The decomposition and zigzagging continues by finding or developing DPs for the newly established FRs and checking the design to make sure that an acceptable design (uncoupled or decoupled design) is obtained that satisfies the allocated FRs and ICs. When the DPs are developed, the ICs are analyzed again to determine if the proposed solution satisfy the ICs and also to allocate them to the new DPs.

Once a DP is determined, a corresponding SC that provides the solution stated in the DP is identified and then a draft PV that defines the process to produce the SC is developed, and finally, a draft CTC is developed to test the SC.

The top-level FRs should be solution-neutral as much as possible in order not to set mind-barriers and to encourage creativity. In addition, the FRs should be both verifiable and attainable. However, at very high levels, the FRs may be very vague, and therefore, not verifiable. Also, one cannot claim that the FRs are attainable without proposing a possible solution. Even if a solution (DP) is proposed for a FR, the proposed DP will most probably be very generic at this level and it would be very difficult to determine if the DP is doable without further decomposition. Therefore, before committing a lot of resources, a minimum set of verifiable and attainable FRs that completely characterizes the functional needs of the design solution should be established. To achieve this, the design decomposition and zigzagging process should have two phases: requirement analysis and design phases. The requirement analysis phase ends when a set of verifiable and attainable FRs is developed and the design phase ends when the leaf-level DPs are developed.

The FRs and DPs at the end of requirement analysis phase are called the baseline FRs and DPs. At this point, the FRs are documented in the requirement specification (RS) document. This RS document should be reviewed by the stakeholders and sponsors’ approval for the requirements should be obtained.

Sponsors’ approval of this FR set indicates the end of the “requirement analysis phase” and the start of the “design phase” of the development project. Up to this point, only conceptual design is developed to map all the FRis into the FR hierarchy and to completely define the functional needs. Some detailed design can also be developed, such as proof of concept prototypes or virtual models, to make sure that the FRs are attainable. However, the only design related information contained in the RS document should be the input constraints and the conceptual design that is used to develop the baseline FRs.

When the baseline FRs/DPs are obtained, they are placed under change control and any changes to them should go through a change management process to analyze the impact of the change on the design and rest of the development lifecycle and determine if the proposed change should be accepted.

The decomposition and zigzagging process proceeds to the leaf level where the DPs are specified well enough to be either implement (produced/manufactured/coded/ etc.) or to be procured whether the DPs are subsystems or components.

Once the leaf level is reached, the design decomposition and zigzagging ends and a bottom-up process starts to re-evaluate and complete the descriptions of the SCs, PVs, and CTCs.

The FTCs are developed for the baseline FRs that are documented in the RS document when the detail design is completed.

The next step in the product development lifecycle is to use the PVs to produce the components and then integrate them to produce the system. Whenever an SC, be it a component or subsystem, is produced, the CTC for that SC is used to test it before it is integrated/assembled further into the system.

When the system is produced, the final acceptance test is conducted by executing the FTCs to validate the system. The final acceptance test, i.e., the acceptance of the system, first article, or the prototype, marks the end of the product development lifecycle.

By manipulating the mapping matrices as well as the characteristic vectors relationships between any entities from different domains as well as entities in the same domain can be easily identified. Therefore, it is easy to find out if all CNs and FRs are

satisfied by the DPs or SCs. It is also possible to find out if each and every FR and SC are tested at the system, subsystem, and component level.

The detail descriptions of the domain entities should be provided in a format most suitable for the discipline and the unique identifiers should be used to relate the documents to the mapping matrices. This will provide full integration of documentation as well as traceability throughout the development lifecycle.

It is important to define standards and templates for the domain entities, if possible, so that they are not misused or misunderstood. The description of customer needs, functional requirements, component test cases and functional test cases do not depend very much on the discipline of the product being developed whereas the description of design parameters, system components, and process variables very much depend on the terms and nature of the discipline of the product being developed.

Templates can and should be developed for CNs, FRs, CTCs, and FTCs in order to make sure that all required information related to these domain entities are properly captured and their descriptions are complete. Even if all the required information is not complete, at least the missing information can be determined and necessary actions can be taken such as making an assumption, identifying a risk and developing a risk plan, or allocate enough resources to find the missing information.

In the following sections, the APDL process is further explained; the domain entities are described in detail, and the templates for documenting the domain entities and the mapping matrices are presented.