HUMAN-CENTERED PRODUCT PLANNING AND DESIGN:ENGINEERING PHASE

By -

1. ENGINEERING PHASE

The purpose of the engineering phase is developing a final design of the product or system. Much of the effort in this phase involves using various design methods and tools in the process of evolving a conceptual design to a final design. In addition to synthesis of a final design, planning and execution of measurements associated with evaluation, demonstration, verification, and testing are pursued.

Four-Step Process

In this section, a four-step process for directing the activities of the engineering phase and docu- menting the results of these activities is discussed. The essence of this process is a structured approach to producing a series of design documents. These documents need not be formal documents. They might, for example, only be a set of presentation materials.

Beyond the value of this approach for creating a human-centered design, documentation produced in this manner can be particularly valuable for tracing design decisions back to the requirements and objectives that motivated the decisions. For example, suggested design changes are much easier to evaluate and integrate into an existing design when one can efficiently determine why the existing design is as it is.

It is important to note that the results of the naturalist and marketing phases should provide a strong head start on this documentation process. In particular, much of the objectives document can be based on the results of these phases. Further, and equally important, the naturalist and marketing phases will have identified the stakeholders in the design effort, and are likely to have initiated relationships with many of them.

Objectives Document

The first step in the process is developing the objectives document. This document contains three attributes of the product or system to be designed: goals, functions, and objectives.

Goals are characteristics of the product or system that designers, users, and customers would like the product or system to have. Goals are often philosophical choices, frequently very qualitative in nature. There are usually multiple ways of achieving goals. Goals are particularly useful for providing guidance for later choices.

Functions define what the product or system should do, but not how it should be done. Conse- quently, there are usually multiple ways to provide each function. The definition of functions sub- sequently leads to analysis of objectives.

Objectives define the activities that must be accomplished by the product or system in order to provide functions. Each function has at least 1, and often 5 to 10, objectives associated with it. Objectives are typically phrased as imperative sentences beginning with a verb.

There are two purposes for writing a formal document listing goals, functions, and objectives. First, as noted earlier, written documents provide an audit trail from initial analyses to the ‘‘as-built’’ product or system. The objectives document provides the foundation for all subsequent documents in the audit trail for the engineering phase. The second purpose of the objectives document is that it provides the framework—in fact, the outline—for the requirements document.

All stakeholders should be involved in the development of the objectives document. This includes at least one representative from each type of stakeholder group. This is important because this doc- ument defines what the eventual product or system will and will not do. All subsequent development

assumes that the functions and objectives in the objectives document form a necessary and complete set.

The contents of the objectives document can be based on interviews with subject-matter experts, including operators, maintainers, managers, and trainers. Baseline and analogous systems can also be valuable, particularly for determining objectives that have proven to be necessary for providing specific functions.

Much of the needed information will have emerged from the marketing phase. At the very least, one should have learned from the marketing phase what questions to ask and who to ask. All the stakeholders in the process should have been identified and their views and preferences assessed.

The level of detail in the objectives document should be such that generality is emphasized and specifics are avoided. The activities and resulting document should concentrate on what is desirable. Discussion of constraints should be delayed; budgets, schedules, people, and technology can be considered later.

Requirements Document

Once all the stakeholders agree that the objectives document accurately describes the desired functions and objectives for the product or system, the next step is to develop the requirements document. The purpose of this document is to identify all information and control requirements associated with each objective in the objectives document.

For evolutionary designs, baseline and analogous systems can be studied to determine require- ments. However, if the product or system being designed has no antecedent, subject-matter expertise can be very difficult to find. In this case, answers to the above questions have to come from engi- neering analysis and, if necessary, validated empirically.

The requirements document should be reviewed and approved by all stakeholders in the design effort. This approval should occur prior to beginning development of the conceptual design. This document can also be very useful for determining the functional significance of future design changes. In fact, the requirements document is often used to answer downstream questions that arise concerning why particular system features exist at all.

Conceptual Design Document

The conceptual design of a product or system should accommodate all information and control requirements as parsimoniously as feasible within the state of the art. The conceptual design, as embodied in the conceptual design document, is the first step in defining how the final system will meet the requirements of the requirements document. The conceptual design document should de- scribe a complete, workable system that meets all design objectives.

Realistically, one should expect considerable disagreement as the conceptual design evolves. How- ever, the conceptual design document should not reflect these disagreements. Instead, this document should be iteratively revised until a consensus is reached. At that point, all stakeholders should agree that the resulting conceptual design is a desirable and appropriate product or system.

Detailed Design Document

The fourth and final step in the design process involves synthesizing a detailed design. Associated with the detailed design is the detailed design document. This document describes the production version of the product or system, including block diagrams, engineering drawings, parts lists, and manufacturing processes.

The detailed design document links elements of the detailed design to the functionality within the conceptual design document, which are in turn linked to the information and control requirements in the requirements document, which are in turn linked to the objectives within the objectives doc- ument. These linkages provide powerful means for efficiently revising the design when, as is quite often the case, one or more stakeholders in the design process do not like the implications of their earlier choices. With the audit trail provided by the four-step design process, evaluating and inte- grating changes is much more straightforward. As a result, good changes are readily and appropriately incorporated and bad changes are expeditiously rejected.

Summary

In this section, the engineering phase has been described in terms of a documentation process, including the relationships among documents. As noted earlier, this documentation need not be overly formal. For instance, documents may be simply sets of presentation materials. The key is to make intentions, assumptions, and so on explicit and to ensure that key stakeholders, or their representatives, understand, agree with, and will support the emerging design solution.

Obviously, much of the engineering phase concerns creating the contents of the documents de- scribed here. Many of the other chapters in this Handbook provide detailed guidance on these en-

gineering activities. Human-centered design is primarily concerned with ensuring that the plethora of engineering methods and tools discussed in this Handbook are focused on creating viable, ac- ceptable, and valid design solutions.

Comments

Post a Comment

Popular posts from this blog

DUALITY THEORY:THE ESSENCE OF DUALITY THEORY

By -
Image
THE ESSENCE OF DUALITY THEORY Given our standard form for the primal problem at the left (perhaps after conversion from another form), its dual problem has the form shown to the right. Thus, with the primal problem in maximizatio n form, the dual problem is in minimization form instead. Furthermore, the dual problem uses exactly the same pa r amete r s as the primal problem, but in different locations, as summarized below. 1. The coefficients in the objective function of the primal problem are the right-hand sides of the functional constraints in the dual problem. 2. The right-hand sides of the functional constraints in the primal problem are the coef- ficients in the objective function of the dual problem. 3. The coefficients of a variable in the functional constraints of the primal problem are the coefficients in a functional constraint of the dual problem. To highlight the comparison, now look at these same two problems in matrix notation (as introduced at the beginn...
Read more

NETWORK OPTIMIZATION MODELS:THE MINIMUM SPANNING TREE PROBLEM

By -
Image
THE MINIMUM SPANNING TREE PROBLEM The minimum spanning tree problem bears some similarities to the main version of the shortest-path problem presented in the preceding section. In both cases, an undi r ecte d and connected network is being considered, where the given information includes some mea- sure of the positive length (distance, cost, time, etc.) associated with each link. Both problems also involve choosing a set of links that have the shortest total length among all sets of links that satisfy a certain property. For the shortest-path problem, this property is that the chosen links must provide a path between the origin and the destination. For the minimum spanning tree problem, the required property is that the chosen links must provide a path between ea c h pair of nodes. The minimum spanning tree problem can be summarized as follows: 1. You are given the nodes of a network but not the links. Instead, you are given the po- tential links and the positive length for each ...
Read more

INTEGER PROGRAMMING:THE BRANCH-AND-CUT APPROACH TO SOLVING BIP PROBLEMS

By -
TH E BRANCH-AND-CUT APPROACH TO SOLVING BIP PROBLEMS Integer programming has been an especially exciting area of OR since the mid-1980s be- cause of the dramatic progress being made in its solution methodology. Background To place this progress into perspective, consider the historical background. One big break- through had come in the 1960s and early 1970s with the development and refinement of the branch-and-bound approach. But then the state of the art seemed to hit a plateau. Rel- atively small problems (well under 100 variables) could be solved very efficiently, but even a modest increase in problem size might cause an explosion in computation time be- yond feasible limits. Little progress was being made in overcoming this exponential growth in computation time as the problem size was increased. Many important problems arising in practice could not be solved. Then came the next breakthrough in the mid-1980s, with the introduction of the b r an c h- and-cu t approach to sol...
Read more