Government regulation shapes many aspects of the design of a product. This paper addresses the effect of the complexity of a regulation on product architecture through the structure of the regulation itself. The structure of a regulation derives from dependencies among requirements and parameters in the regulation that are ipso facto design elements. Since design elements such as requirements and parameters have no formal definition in regulation, it is difficult to identify them accurately and consistently. We apply two approaches to defining and coding requirements and parameters in the context of washing machine regulation. The two coding approaches generate networks of design elements that are analyzed to measure the complexity of the regulation and by extension the product. We find significant differences in the complexity of the regulation when coded in different ways and note deficiencies and strengths of each approach. These findings will support future research to measure the impact of regulatory complexity on product architecture.

The problem at hand is that vast amount of data on industrial changes is captured and stored; yet the present challenge is to systematically retrieve and use them in a purposeful way. This paper presents an industrial case study where complex product development processes are modeled using the design structure matrix (DSM) to analyze engineering change requests sequences. Engineering change requests are documents used to initiate a change process to enhance a product. Due to the amount of changes made in different projects, engineers want to be able to analyze these change processes to identify patterns and propose the best practices. The previous work has not specifically explored modeling engineering change requests in a DSM to holistically analyze sequences. This case study analyzes engineering change request sequences from four recent industrial product development projects and compares patterns among them. In the end, this research can help to identify and guide process improvement work within projects.

This paper proposes a method to automatically generate a multi-domain matrix (MDM) from textual activity specifications. The format for specifying these activities is based on a structured grammar derived from natural language and consists of two types of activities: goal activities and transformation activities. A goal activity describes the purpose of an action performed by an actor for the benefit of another actor in the system. A transformation activity describes an activity from the viewpoint of a single actor, who receives, generates, and outputs information or artifacts. If one describes activities using these two types of activity specifications, dependencies can be automatically derived between actors, activities, and parameters of the system and visualized in an MDM. Thus the generated MDM presents an organization DSM (actors), a process DSM (activities), and a parameter DSM (flows of information or objects), as well as the mapping matrices coupling the different domains. An illustrative house construction example demonstrates the effectiveness of the proposed activity specification format. The method may provide an outcome in understanding and managing complex systems.

In many engineering design contexts models are indispensable. They offer decision support and help tackle complex and interconnected design projects, capturing the underlying structure of development processes or resulting products. Because managers and engineers base many decisions on models, it is crucial to understand their properties and how these might influence their behaviour. The level of detail, or granularity, of a model is a key attribute that results from how reality is abstracted in the modelling process. Despite the direct impact granularity has on the use of a model, the general topic has so far only received limited attention and is therefore not well understood or documented. This article provides background on model theory, explores relevant terminology from a range of fields and discusses the implications for engineering design. Based on this, a classification framework is synthesised, which outlines the main manifestations of model granularity. This research contributes to theory by scrutinising the nature of model granularity. It also illustrates how this may manifest in engineering design models, using Design Structure Matrices as an example, and discusses associated challenges to provide a resource for modellers navigating decisions regarding granularity.

The systems engineering V (SE-V) is an established process model to guide the development of complex engineering projects (INCOSE, 2011). The SE-V process involves decomposition and integration of system elements through a sequence of tasks that produce both a system design and its testing specifications, followed by successive levels of build, integration, and test activities. This paper presents a method to improve SE-V implementation by mapping multilevel data into design structure matrix (DSM) models. DSM is a representation methodology for identifying interactions between either components or tasks associated with a complex engineering project (Eppinger & Browning, 2012). Multilevel refers to SE-V data on complex interactions that are germane either at multiple levels of analysis (e.g., component versus subsystem) conducted either within a single phase or across multiple time phases (e.g., early or late in the SE-V process). This method extends conventional DSM representation schema by incorporating multilevel test coverage data as vectors into the off-diagonal cells. These vectors provide a richer description of potential interactions between product architecture and SE-V integration test tasks than conventional domain mapping matrices. We illustrate this method with data from a complex engineering project in the offshore oil industry. Data analysis identifies potential for unanticipated outcomes based on incomplete coverage of SE-V interactions during integration tests. In addition, assessment of multilevel features using maximum and minimum function queries isolates all the interfaces that are associated with either early or late revelations of integration risks based on the planned suite of SE-V integration tests.