Sei sulla pagina 1di 5

Procedural Model of Design Engineering 223

7. Other available methods and resources (e.g., computers) for rationalizing


the particular stage or step, and their relationship to the presented course of
design engineering.
8. Form of representation of the output.
9. Remarks about further efforts of organizational or other kind related to this
stage, which can be important for successfully handling the stage.

4.3 PHASE IELABORATING THE ASSIGNED


PROBLEM
Elaborating and clarifying the assigned task proceeds by accepting the assignment of a
design brief from management, and exploring it from the viewpoint of the engineering
designer, resulting in a list of requirements, a design specification, and a proposed
plan of action.

4.3.1 STAGE (P1): ESTABLISH A LIST OF REQUIREMENTS


Clarifying the task offers the possibility to discuss and argue with the problem situ-
ation, and to obtain information of the causes. In extreme cases, a solution can be
found here, abolishing or avoiding the causes, instead of fighting them.
During establishing the list of requirements, stage (P1) and step Op-H3.1 of the
basic operations, the engineering designers get to know and understand the situation
around the TP(s) and TS(s). They developconsciously or subconsciouslyan idea
about the possibilities for solutions, and whether there are any completely or partially
available TS that will meet parts or all of the requirements. Designers must perform an
analysis, to answer all questionswhat? how? who? when? where? why? and so forth
(see topika, Figure 8.7). Thereby a starting point develops for a possible procedural
strategy or technology for designing the required TP(s)/TS(s).
The quality of the requirements listed in the assigned task, the design brief given
by the organization management, is usually not sufficient for designing. Require-
ments, wishes, and constraints must be examined and clarified. The goal in this
stage is therefore a list of requirements with highest possible quality covering all
criteria, a design specification. The design specification should allow multiple solu-
tions at appropriate levels of abstraction. Yet the engineering designers should not be
allowed to wander too far for the design situation. This matter needs good judgment.
The list of requirements should [503]: (1) focus attention on key issues; (2) ensure
that all stakeholders (including clients or customers) agree on the nature of the
problem; (3) stimulate innovative thinking; (4) incur relatively low administrative
overhead; and (5) facilitate navigation and searching of information about require-
ments. A challenge to typical ways of solving the problem can lead to better, more
innovative solutions.
During design engineering, undetermined questions are discovered, even if
they are interpreted as organization-internal tasks, and must be successively and
formally incorporated into the specification. The design specification should be under

Eder: 47655_C004 2007/6/1 14:31 PAGE 223 #13


224 Design Engineering: A Manual for Enhanced Creativity

constant review, and should be updated at intervals, preferably in consultation with


the project sponsor.

(1a) Input: Assigned design briefduty booklet, contract for a TP(s)/TS(s) with
given constraints (e.g., delivery time), as defined by management, and agreed with a
customer.

(1b) Output: A full design specification (list of requirements) which has been agreed
with the customer or sponsor, with the most appropriate state of anticipated properties
in all features.

(1c) Theorem: The TP(s) and TS(s) should be capable of effectively transforming
the operand and delivering the TS-effects. The TS(s) should also be appropriate
for all anticipated life cycle situations, and should have suitable properties (see
Section 6.6), for example, for humans, for nonpolluting disposal at life ended
(see Section 6.11.9), and so forth.

(1d) Applied Models: The model of the TS life cycle (Figures I.13 and 6.14) rep-
resents individual phases and processes of origination, operation (TP[s], and TS[s]
as operator), and disposal is represented as a sequencing of transformation systems
(Figures I.6 and 5.1). The model shows only the main processes and phases, which
contain several subprocesses. For example, testing can be included in manufactur-
ing and assembling, or distribution can include packaging and transport. During
the TS-operational process, the TP(s), additional processes of cleaning, mainten-
ance, repair, and upgrading may be required. The concretization of the general life
cycle for a TS-sort should contain these particulars, and avoid unnecessary work,
iterations and failures for the engineering designer within a specialty (branch of
industry).

(1e) Partial Operations (Steps):


Op-P1.1 Establish rough factors for all life phases. Determine or assume the prop-
erties for the TP(s), that is, purpose, operand, technology, operators, and
TS-inputs and outputs of each life phase (see Figure I.18).
Op-P1.2 Analyze the TS-life phases, and establish requirements on the TP(s)
and TS(s).
Op-P1.3 Anticipate the environment of the TS-life processes, especially the
TS(s)-operational process (the TP) as far as they can be anticipated.
A detailed analysis can consider the model of the design situation
(Figures 3.1 and I.17), which shows aspects of the environment and the
burden on the design potential. This should include a study of technical,
financial and other feasibility, possibilities of realization, state of the art,
market situation, and other factors.
Op-P1.4 Examine the importance (relative priority level) of individual require-
ments from the viewpoint of the importance of TS(s)-life cycle processes,
and operators.

Eder: 47655_C004 2007/6/1 14:31 PAGE 224 #14


Procedural Model of Design Engineering 225

Op-P1.5 Quantify and state tolerances for the requirements where possible.
Op-P1.6 Allocate the requirements according to life phases, operators, and classes
of TS-properties.
Op-P1.7 Establish any anticipated requirements for a supply chain for manufacture,
and for environmental concerns.
Op-P1.8 Review the results of this stage, be constructively critical, evaluate and
decide (e.g., among alternatives), reflect and improve, and verify and
check (including checking for possible conflicts and contradictions).

Enter this information into a list of requirements. This ongoing task covers the
information generated in each operation, and reviews and keeps this design specific-
ation up to date. Goals and principles can guide the process of generating the list of
requirements, as the task definition for the TP(s) and TS(s) (compare Chapter 2), and
for each subproblem. As interpreted by engineering designers and team members,
after clarification of the task

1. The list of requirements should ideally be complete, organized, clear and


unambiguous, with reasonable progress to the state of the art, adequate
innovation, but controlling risksrequirements, including constraints,
should be as explicitly and completely formulated as possible for that design
situation.
2. The requirements should be correct: the manifestation or measure (quantity,
size, value) of all requirements should conform to the desires of the customer
and relate to the state of the art, both for the TS-branch and for related
regions.
3. The design task and the requirements should preferably be formulated with
process capabilities, and effects and capabilities of the TS(s)what the
TP(s) and TS(s) should be able to dobut usually not with meanswhat
the TS should befor example, a device for regulating flow of a fluid, in
preference to a valve.
4. Requirements should be classified and qualified into at least the two groups
of priorities, for example, fixed requirement, minimum requirement, desire,
wish, constraint, and so forth.
5. Requirements should be quantified, and permitted variations (limits of min-
imum or maximum values, or tolerances) of the values to be reached should
be indicated.
6. The list should be formalized, for example, according to the classes of
properties (see Figures I.8 and 6.86.10), and the Df X classes and life
cycle operators (see Figure 6.15). Appropriate forms of presentation can
use pro forma sheets (see Section 9.5).
7. Requirements should not be duplicated within the list. Many requirements
influence several factors, for example, classes of properties (see Figures I.8
and 6.86.10), and operators of the individual life cycle processes (see
Figures 6.14 and 6.15). For each requirement that could be classified under
several headings, one class should be regarded as primary, the other classes
should contain only cross-references to the primary class.

Eder: 47655_C004 2007/6/1 14:31 PAGE 225 #15


226 Design Engineering: A Manual for Enhanced Creativity

8. The state of the art should be clearly established within the design
specification.
9. The assigned problem statement and the list of requirements are sets of
information, therefore knowledge from the field of information processing
is applicable, for example, instructions about establishing the state of the art,
information storage and retrieval, and computer science. In this operation,
the majority of the technical (branch-related object) information concerning
the problem and solutions should be collected. Study stage is a frequently
applied term, but information is gathered through the whole design process.

Completeness and qualification of the requirements are (and continue to be) points
of contention; opinions and conceptions differ. A few hundred statements of require-
ments must be formulated at the start of the TP(s)/TS(s) life, before and during the
conceptual phases of designing. These goals and principles should be appropriate and
adapted to the needs of the design situation (see Chapter 3). The working methods
used by engineering designers should contribute to reaching a corresponding per-
fection and quality, both of the task definition and of the TP(s) and TS(s). Suitable
methods (see Chapter 8) are given as follows:

1. Analysis of classes of properties of TS: helps to attain clarity, new ideas,


quality, quantity.
2. Method of systematic field coverage: aims toward completeness.
3. Method of questioning: strives for perfection, elucidates quantity (see
topika).
4. Market analysis (market survey): helps to obtain quality of the require-
ments which correspond to the needs of the market. Users (customers)
may be [329]: primary users: operate the TP(s) and TS(s) for the intended
purpose; secondary users: operate the product or operate on the product,
but not for its primary purpose; side users: influenced (positively or
negatively) by the product, but do not use it; co-users: cooperate with
the other users, but do not directly use the product. These classes cover the
operators of TS-life cycle processes.
5. Method of methodical doubt (Descartes): encourages critical examination
of all statements, for validity, accuracy, coherence with known situations,
and so forth.
6. Quality function deployment (QFD) (see Chapter 8).

The possibility of realizing the TS(s), and its operational process, TP(s), should
be examined (a feasibility study), which should indicate whether a solution of the
given task is possible, and whether solving it is expedient. A feasibility study will
either indicate a possibility does not exist, or a possibility may existfeasibility
can never be proved. Areas to be explored are

1. Technical aspects: Are laws of nature respected? Do the requirements ask


for a perpetuum mobile (perpetual motion machine)? Are technical means
and experiences available?

Eder: 47655_C004 2007/6/1 14:31 PAGE 226 #16


Procedural Model of Design Engineering 227

2. Economic aspects: Are the anticipated TP(s), operation of the TS(s), and
its manufacture likely to be economical?
3. Timeline: Is the available time sufficient? Can and should the product be
first to be marketed?
4. Environmental and social factors: Are any hazards foreseeable?

An ideal can never be reached, a suitable level of meeting the stated requirements
should be satisfactory. The process of evaluation is intended to enable a comparison
with the requirements, and to point out deficiencies that must or should be corrected.
(1f ) Important Information Areas: Engineering designers must know the state of
the art about their TS-sort, the development of the branch with its conditions and
causes, the market situation and current competitive products (TP and TS) and patents.
Information about other areas of engineering, social and cultural aspects, at least at
the level of awareness, is also useful, and can help to avoid introducing failures in
ones own area for problems that have already been overcome in other areas [572].
Question about possibilities of realization needs well-founded information about (new
and existing) materials and manufacturing techniques. An excursion into the sphere of
economics, organizations, and management is necessary for designers. Engineering
designers are responsible for about 80% of the manufacturing and whole-life costs
(see Figure 10.4), they must have information about production, life cycle assessment
and engineering [62,160,186,237,244,582], costs and cost management, and so forth.
The designed TP(s) and TS(s) must also conform to all applicable laws, standards
and codes of practice. This is a further field of information with which designers must
become familiar.
(1g) Available Methods and Resources: Checklists are a resource for processing
the task definition that offer systems of questions and hints, and can deliver new
inspiration. An interdisciplinary team is usually an advantage (see Chapter 10). Full
records (minutes) of meetings should be kept, especially of any decisions reached.
Individual specialists (including engineering designers) will have their own duties to
perform between the meetings [247].
(1h) Form of Representation: The list of requirements (design specification) can
be formalized and unified for a specialty, and used as masters or pro forma (see
Section 9.5). Masters and other paradigmatic representations have proven useful
in practice, other developments are possible and likely. A graphical representa-
tion has been suggested [503], in which the individual requirements (subclassified
as product characteristics, functional requirements, constraints, and performance
metrics) are coded for importance, and linked into a hierarchical network, prefer-
ably in column-and-row format, to improve visualization and understanding of the
design problem. The area of quality assurance offers benchmarking, QFD, and other
methods for comparisons with competitive products and company procedures. The
feasibility study method is usable in this stage of designing.
(1i) Remarks: This stage demands cooperation with stakeholders, for example,
sales department, and manufacturing, so that the established data corresponds to
their ideas, or a consensus is reached.

Eder: 47655_C004 2007/6/1 14:31 PAGE 227 #17

Potrebbero piacerti anche