There is a multitude of different ways and practices to describe specifications. Please consider the lecture on this portion for more details. To summarize there are three major types of terminologies which needs consideration
System Specification / Target Specification / Functional-Specifications / Product Specification (Deutsch: "Pflichtenheft")
The system specifications are usually defined by the customer. They are the most relevant basis for a design and need to be fullfilled by the development. Any deviation from this system-specification needs clarification. In a business-context, any deviation will become cost-relevant.
The system specifications usually go along with certain features of the product. Especially when it comes to complex software functionality, the number of features may be thousands of each feature will be tracked as an indicidual specification
Requirement-Specifications / Performance-Specifications or just Specifications (Deutsch: "Lastenheft")
The requirements-specification describe the internal development target for a product. They are usually much more detailed and updated frequently during the development. When the development is progressing the device is going to be splitted in functions. With each function the requirements specifications continue to grow and will get independent subsections for the functions.
Company Standards and Norms (ISO/DIN)
Comparable to product-specifications they can be considered a source for requirements. Usually the product-specification requires some ISO/DIN norms to be used (e.g. norms on product development) and this then triggers some internals standards/processes to be considered. So company-standards usually do not stand for themselves, as they are otherwise not really adding value to the product development. At least they take influence on cost of development/production/overhead of the task, so a n internal company-standard should help to minimize across all products the cost-structure of the company.
Examples
Product Specification Version 1.0
(make sure to keep versioning when you do those lists)
| Index | Titel | Value | Unit | Importance* | Source | Links to Req. Specification | Comment |
|---|---|---|---|---|---|---|---|
| AA | Weight | <1 | kg | R | Customer Mechanics | 1 | |
| AB | Power consumption | <1 | W | R | Customer Electrical | ||
| AB | Power consumption | <0.5 | W | O | Customer Electrical | ||
| AC | Costs | <100 | EUR | R | Customer Purchasing | 2,3 | |
| ... |
* there are hundreds of ways how to handle the "importance". The most basic information is to define Required values (R) and optional values (O). But you can also give an analogue rating like a number from 0 to 5 with 0 means "optional" and 5 means "super important".
Requirement Specification Version 1.0
(make sure to keep versioning when you do those lists)
| Index | Titel | Value | Unit | Importance* | Source | Links to Source | Influence by product function | Comment |
|---|---|---|---|---|---|---|---|---|
| 1 | Total Weight | <1 | kg | R | Product Specification | AA | (this column can be filled only after functional decomposition) | |
| 2 | Bill of Material Costs | <20 | EUR | R | Product Specification | AC | Break-Down by target-costing team | |
| 3 | Assembly Costs | <5 | EUR | R | Product Specifications | AC | Break-Down by target-costing team | |
| ... |
Areas requirements may come from
Within literature on design there are always checklists which should help to tailor the requirements and to prevent missing a specific topic or area while creating the lists. I personally like the lists of "Pahl Beitz", although they may need to be extended beyond the technical features a bit.
Areas to consider | |
|---|---|
| Geometry | How large should it be, are there any limitations or boundaries. How does the geometry change when operating. Anything to consider compared to storage and non-operational states. |
| Kinematics | How does the mechanical interface look like. How is it fixated, should the output translate/rotate, ... |
| Forces | What are the in-/ and output forces or torques generated by the device but also applied to the device |
| Energy | Power sources available, output power, radiation relevant, other "exotic" forms of energy existing (accelerations) |
| Material | Any exposure to materials (chemical, biological,...). Any limitations on material choices |
| In- and Output Signals | What kind of control signals does the device receive, what kind of output signals should it generate? |
| Safety | Passive or active safety of the device relevant? |
| Ergonomics | Even if not required, considering the ergonomics of usage will greatly improve the perception of quality of your work! |
| Manufacturability | Can all parts be manufactured or are available of-shelves? Ask for help if you are unsure! |
| Assembly | Can it be assembled and how is the assembly-sequence? |
| Control | Any need for open- or closed-loop control? Reaction timings, dynamics of this? |
| Mounting | if part of a larger assembly |
| Transport | Does it has to be moved, if so, mounting points, size to fit through a door, weight |
| Noise | Rattle/squeek/mechanical play/operational noises of relevance? |
| Repair | Does it need to be repaired, in which areas, and how to access later |
| Costs | Prototype costs, series costs |
| Timing | Major milestones for the development and the delivery |
| Quantity | What quantity of the device needs to be built in which time - will greatly influence the emphasis and balance between manufacturability/assembly vs. all other features |
0 Comments