These are working notes, toward a general strawman design process.
Product: the item being designed; e.g. “product characteristics” are characteristics of the actual product.
Design: the collection of information describing the product; e.g. “design characteristics” are characteristics of the design, not of the product.
There are many attempts to describe product development processes in strange, nearly vacuous ways. Examples include Quality For Business.
The strawman should be better than this.
SDS covers all stages of product life-cycle (LC):
SDS covers all phases of the product development process (PDP):
SDS takes into consideration other aspects of the engineering endeavor that affect or are affected by design:
SDS uses grammatical parsing & analysis to extract meaningful information from natural language statements. For example,
SDS takes advantage of principles of systems engineering.
SDS distinguishes kinds of information according to the following criteria:
SDS is based on pattern languages.
SDS evolves in time.
Concept Evaluation: When evaluating a concept with respect to a criterion, the good and bad characteristics of the concept are conflated. Try to devise a way of rating the good and bad characteristics separately. The analogy is to doing a cost/benefit analysis of each concept with respect to each criterion – rate the cost and benefit separately in the table, then combine them in some algebraic way. Cf [MZ96].
Problems are defined in situations/contexts. Problem analysis happens with respect to the situation. Need to capture situational analysis/understanding/awareness as a part of problem analysis, or something that even happens before problem analysis.
Add the attribute types of Kano models (cf Daryl Caswell's unit on Kano Models for his CDEN module) to my product characteristics work.
What do other authors have to say about the phases? Can other phase categorizations be unified?
[CTT94] consider a multimodeling approach to be appropriate because they see reasoning about systems as a cooperative activity. This meshes with the idea of multiple agents in ADPM. Check the paper, verify, and try to incorporate their results in some way.
[CJ96] stress that function descriptions must not make commitments (must not refer to) product structure. How does does this relate to levels of granularity, and Dym's objectives/functions?
[Hym98], the phrase “client's dissatisfaction with a current situation” is used to describe the as-is world into which a new product is introduced. Can this be fit into ALX3d?
Is a FR a constraint on functionality, whereas a plain constraint is a constraint on non-functional aspects of products? This may help distinguish between constraints, FRs, etc.
If synthesis is a mapping from function to form, then is analysis the inverse mapping, or is it the mapping from form to performance? (Where performance is not equal to function.)
What does it mean for a function to have a property? What kinds of properties do functions have that structures do not?
parametric design is intimately tied to an object-oriented perspective.
Sources to check:
A product characteristic is an essential quality of a product typically represented in adjectival form.
A product constraint, per [DL00], is a limit on the product that identifies what is not acceptable, whereas a product characteristic defines the minimum acceptable value of a design parameter and an indication of the direction in which better values are found.
To facilitate this distinction, constraints are written as negative statements about the product. E.g. “the product's weight cannot exceed 10kg” is a constraint, whereas “the product must be as light as possible” is an objective.
Two alternative methods:
Method 2 is preferred, because it clearly distinguishes between the creative/synthetic cognitive tasks and the reductive/analytic cognitive tasks. This provides a more intuitive framework - designers know “This is the time for innovative thinking”.
Is there some sort of experiment that can be done to check this? For example, have 2 small teams working on the same problem, each using a different method; then have the teams exchange their final design specs and comment on them. Does each team admire the other's work? Do both teams think one result is better than the other?
The method has the following basic stages:
Stages 1 and 3 are those where innovative ideas and free thinking are encouraged; stages 2 and 4 are those where analytic thinking is encouraged. However, each stage may contain a little of both kinds of thinking.
The example is drawn from [DL00] (p 55): Design a new ladder for electricians or other maintenance and construction workers for use on conventional job sites.
Every kind of design has certain common features, activities, and attributes. What exactly are they?
An interesting notion regarding validation: [ACC00] reads “This approach to product design has been validated on more than 100 real industrial cases.” The method described there is, however, surprisingly generic: set requirements, conceptualize, architect a system. If it's really generic, then can any similar approach recycle the same “proof”? Does the validation they performed also apply (at least generally) to any similar process model?
Many facilitators use process models to promote “creativity” that are essentially design processes. Here's one example.
Step | In Facilitation | In Design |
---|---|---|
1 | Focus - ask a question, don't pose an issue | Requirements elicitation and engineering |
2 | Divergent thinking | Concept design |
3 | Convergent thinking | Concept evaluation and systems design |
4 | Keep it fresh | Coevolution and detail design |
HCI has been a discipline that has adopted a strong design orientation. There is probably alot to be learned from HCI in working towards any reasonable “universal” design.
Some HCI links of interest include:
Danish HCI Research Symposia: