STAKEHOLDER REQUIREMENTS DOMAIN
The stakeholder requirements domain is characterized by expression of the needs of the customer. This domain thus describes the customer needs as the “CN” value of an axiomatic design study. Stakeholders may be interviewed or surveyed in order to determine the applicable needs that the system must meet .
The chief difficulty in ensuring a correctly configured stakeholder requirements domain is that stakeholder requirements may not be the same requirements that the designated design engineers have picked . As a result, it is necessary for the design team to translate customer needs into system requirements accurately.
These needs may be created accurately by following a process recommended by Buede [3,13]. First, the operational concept must be created for the product. This will include development of a system boundary. The objectives of the system must be placed in a hierarchy. The stakeholder requirements and system requirements must be created and included in this structure. The feasibility of the proposed structure must be evaluated. The system will be bench-marked to ensure that it meets the expected needs. Finally, everything will be documented accordingly. Documentation may be accomplished via SysML or another modeling system.
FUNCTIONAL ARCHITECTURE DOMAIN
Functions of a design are transformative actions carried out by portions of the design to act upon the system. Functions may transform a material, store energy, or exchange signals as well as many other tasks. Functions are grammatically transitive verbs which act upon an operand. Functions must be solution-neutral and may not presume a technology or solution .
The functional architecture domain is the home of the functional requirement. Functional requirements can best be considered to be a result of inputs from the shareholders regarding the needs of the product. Customer needs can therefore be said to drive functional requirements. All functions of the product must also be functional requirements. Similarly, all functional requirements must correspond to product functions. This ensures that the product does what it is desired to do. Functional requirements are thus mutually exclusive and collectively exhaustive .
In some cases, functional architecture exists prior to the design action. Not all engineering design actions are for new products. Many legacy systems are inherited by design engineers that must be modified to meet new customer requirements. Reverse engineering of an existing product’s functional architecture is an acceptable method of using axiomatic design on inherited products. One method of creating a functional architecture is using SysML to create a model. These models should incorporate activity-based diagrams that show the general purpose of the product. Additionally, models should be created that utilize state machines.
State machines indicate the sequence of responses to stimuli that a given system will produce throughout an input/output cycle. State machines should provide an output for every input with provisions for resetting back to an initial rest state at the conclusion of expected inputs . The final type of diagram that should be created for functional architecture is use case diagrams. These diagrams enumerate and express the interactions external to the product. By combining these tools together, design engineers can ensure that functional requirements are robust and authoritative .
PHYSICAL ARCHITECTURE DOMAIN
The physical architecture domain can be said to contain the design parameters used in axiomatic design. Design parameters are vital in understanding how well customer requirements are being met by the design in question. Design parameters are examined in terms of how well they accomplish the functional requirements determined through interviews with the stakeholders of the product as well as market surveys of the area in which the product will be deployed. The physical architecture domain contains the modules and components which are synthesized into block diagrams and parametrized diagrams . SysML contains tools to easily convert design parameter data into block diagrams for use in axiomatic design.
These block diagrams can describe both physical and nonphysical systems. As both types of systems benefit from axiomatic design, systems composed entirely of software can be modeled similarly to physical systems. An example of a block diagram formed using SysML can be found in Figure 2. This block diagram describes the software that drives a music purchasing website in terms of the design parameters required for operation .
This system allows for elements of the physical architecture to be enumerated without resolving required performance characteristics. This allows for performance characteristics to be defined without placing constraints on the value of said performance characteristics. As this set of characteristics does drive axiomatic design from a linear algebra perspective, physical architecture can be expressed as a weighted square matrix .
PROCESS ARCHITECTURE DOMAIN
Process architecture is the axiomatic design domain concerned with the manufacturing processes associated with a design. This domain deals exclusively with manufacturing processes and the relationship of these processes to the product. Process architecture converts manufacturing constraints to a format that can be treated similarly to customer requirements. This ensures that the product can be readily produced .
Domain mapping can be accomplished by the traditional Design Structure Matrix system. In order to cross between domains, a zig-zagging method is recommended. Functional requirements are mapped to design parameters by crossing from the applicable domain and then returning. This ensures that all design parameters are appropriately matched to functional requirements. An example of this zig-zagging system can be seen in Figure 3.
However, this method may be improved upon by utilizing a newer method known as the Engineering Systems Matrix. This allows for multiple domains to be simultaneously evaluated in context of all system drivers regardless of type. The engineering systems matrix operates as an improved system-level modeling framework. It can be most readily visualized as a multiple domain Design Structure Matrix that is adaptable to other design tools. This system incorporates a newly developed tool called Qualitative Knowledge Construction  to improve engineering design results. An example of an Engineering Systems Matrix can be seen in Figure 4.
In seeking to incorporate qualitative design information into an engineering framework, Bartolomei realized that engineers tend to focus on non-human components of a system. Bartolomei felt this was a major failing of modern design theory. As qualitative information is typically developed through interviews, observations, and surveying, Bartolomei created a method to parametrize this data. Bartolomei converted this information into a text form and coded it based on nodes, relationships, and attributes. This was incorporated into the engineering systems matrix he had developed. Using a database system, the data was loaded into appropriate cells in order to develop a matrix framework .
By converting observational and interview-based data into a quantitative system, it is possible to objectively analyze this data using quantifiable matrices. As information coding allows for social scientists to explain data, so too does it allow engineers to synthesize design results to ensure the requirements imposed by the data are met . In order to systematically code data, the Qualitative Knowledge Construction process should be followed.
The boundaries of the system(s) of interest must be defined. This ensures that the system type is clearly recognized and understood by the designer. Early attempts at modeling the system or understanding the existing model should be made. Data collection should with sufficient rigor as to clearly define the system .
Next, the objectives to be analyzed must be defined. This must be abstract enough to be readily viewed by the engineer while still maintaining enough detail to contain useful information. If necessary, iteration may occur to clearly define the objectives in particularly large systems such as major production lines or especially complex systems .
Once the objectives are known, complete data collection must occur. This data collection typically involves interviews with the stakeholders, market surveys, or the collection of engineering data. Existing CAD models, finite element models, and written documentation should be explored fully to ensure a total understanding of the system and the requirements is complete .
Once the data collection is complete, it can be coded accordingly. The Engineering Systems Matrix framework allows for six classes of coding to occur. Coding classes are defined for stakeholders, system drivers, activities, functions, objects, and objectives. Coding is accomplished by extracting data artifacts from the data collected previously. For example, an interview with a worker that identifies a client would result in the client being coded as a stakeholder. Each subsequent relationship that the client has would be coded as a related attribute for that stakeholder cell. When the objective of that client is discovered, the objective would be coded as a related objective cell to the stakeholder cell. Other relationships between the original stakeholder and original objective found with other stakeholders and other objectives would then be related accordingly .
After coding has been completed, the model should be audited for mistakes and omissions. Since all systems goals should have at least one corresponding element, omissions should be obvious. Similarly, cells which do not align to any requirement should be evaluated for relevancy to the system. Missing data should be resolved by further research or additional interviews . At this point, multiple domains have been mapped and the axiomatic design process may continue.
STAKEHOLDER REQUIREMENTS DOMAIN