Technology & Engineering
Design Specification
A design specification is a detailed description of the requirements and characteristics of a product, system, or component. It outlines the parameters, features, and performance criteria that the design must meet. This document serves as a guide for engineers and designers to ensure that the final product aligns with the intended functionality and quality standards.
Written by Perlego with AI-assistance
Related key terms
1 of 5
10 Key excerpts on "Design Specification"
eBook - PDF- H. Sales(Author)
- 2006(Publication Date)
- Palgrave Macmillan(Publisher)
Engineering Specifications and Requirements 97 In order to properly devolve the requirements for, and specify the Company's products, a hierarchy of specifications has been developed. This hierarchy ensures that the requirements are captured, devolved and recorded in a controlled and logical fashion such that demonstration of compliance and repeatable delivery of consistent product is possible. This statement reflects the company's concern to manage the writing of specifications, and to ensure some kind of control of the activity. Reading the document further, each type of specification is defined under the subheading 'Hierarchy and Rules', with the design specifica- tions ranging from system specifications at the top to software specific- ations at the bottom, as follows: • System Specifications • Product Specifications • Design Proving Specifications • Design Requirement Specifications • Software Specifications. An examination of the definitions for the first two shows them to be concerned with procedural matters, in that they provide information about contexts for use, rather than their purpose, function, or language form: System Specifications - Mandatory unless substituted by a Product Specification or Design Requirement Specification. Product Specifications- Used in place of a System Specification or Design Requirement Specification on simpler and proprietary products. Product Specifications can be used in the selling of products into the open market place where the Company wishes to protect its designs by not disclosing the level of detail normally contained in a Systems or Design Requirement Specification. During develop- ment, the product Specification acts as the requirement for all other specifications during which it is at its 'Draft' or 'Preliminary' issue. Once development is complete the product Specification becomes the technical description of the final product and is therefore subser- vient to the DRS.
eBook - ePub- Peter Childs, Peter R. N. Childs(Authors)
- 2013(Publication Date)
- Butterworth-Heinemann(Publisher)
Design usually starts with a need or requirement which, when satisfied, will allow a product or process to be offered to an existing market or new market. The market need may be to meet competition, a response to social changes, opportunities to reduce hazards, inconvenience or costs, or exploitation of a new market opportunity. This is the “front end” of design. People with front-end skills, such as market researchers and information scientists, are fundamental to the design process. The starting point for the majority of design activities in industry is the establishment of the market need situation. Common practice is to produce a document or statement of need, called “the brief” or “market brief,” at this initial stage. The brief varies from a simple statement of the requirements to a comprehensive document that describes the true needs of the user.Specification is usually critical to effective design. Thorough specification provides limits defining the attributes and functions that are requisites of a design. Common practice is to develop a product Design Specification (PDS) where each attribute and function required of the product or system is described and quantified. An alternative is the use of quality function deployment (QFD), where matrices are used to capture the attributes, functions, and features associated with a product or system with a particular focus on ensuring that the voice of the customer (VOC) is captured in the specification—geared toward ensuring that the product development cycle results in an outcome that matches the customer requirement.There are many variants and forms of specification. Specification can represent a significant undertaking. The specification documentation associated with a new turbofan engine for an aviation application, for example, may occupy over 500 pages. The precise form used will likely depend on precedence within a particular organization. The automotive industry, for example, has tended to use QFD over the last few decades, and such approaches may demand more resources than available and simpler pro formas may enable a more timely and accessible approach to specification.Specification is usually incorporated as a fundamental part of new product development project management. It is not always possible to produce a complete specification at the outset of a project. It may be necessary to take an iterative approach to the specification with elaboration of details as a result of initial phases of design activity and concept ideas with these providing insights to what attributes and functions for a product or system are possible and desirable. In essence, the early concepts and designs serve to inform the specification. Such an approach fits well with stage gated project management processes, perhaps with phases of system design review, performance design review, and technical design review, with each referring back to an original specification and enabling the development of an agreed technically feasible specification that provides a design that is fit for purpose. A common occurrence in industry is the use of an agreed specification to provide the basis for contractual negotiation, enabling the associated parties to be able to define the completion of tasks. Any variation on the specification should be addressed by a change management process, where changes to the specification need to be agreed upon by all associated parties. When agreement cannot readily be obtained, these changes must be managed by an arbitration process.
eBook - PDF- Roderick A. Macleod, Jim Corlett, Roderick A. Macleod, Jim Corlett(Authors)
- 2012(Publication Date)
- De Gruyter Saur(Publisher)
-4414 ENGINEERING DESIGN requirements and the constraints on the design, and describing these in a product Design Specification. Figure 19.1 also shows the elements that should be considered in such a specification. • The concept design phase, which involves establishment of the functions to be included in the design, and identification and development of suitable solutions. • The detail design phase, in which the dimensions, tolerances, materials and form of individual components of the design are specified in detail for subsequent manufacture. • The manufacture phase, in which the production system and tooling are designed and acquired, and the product is then manufactured. • The sales phase, in which the product is sold in the market. Many variations on the models of the design process may be identified. Models used by specific companies or industries may be very much more detailed - in the aerospace industry, for example, as many as fourteen phases are identified in the 'Product Introduction Process', with specific conditions that have to be achieved before a project may pass through a 'gateway' from one phase to the next. In practice, the main phases of real processes are not always clearly defined, and there is invariably feedback to previous phases and often iteration between phases. Increasingly, also, DESIGN CORE BOUNDED BY PRODUCT SPECIFICATION Information Technique Fig. 19.1: The SEED Design Activity Model (Kimber et α/., 1985) INFORMATION SOURCES IN ENGINEERING 4 1 5 ^ the pressures on the design process to effect reductions in time to market have led to compression and parallelisation of the phases of the design process. This has occurred not just because of the requirement to reduce programme timescales, although this has been one of the major benefits, but because of the complexity and dynamism of today's product tech-nologies, with the resulting imperative to share product and technical knowledge.
eBook - PDFProduct Development
An Engineer's Guide to Business Considerations, Real-World Product Testing, and Launch
- David V. Tennant(Author)
- 2022(Publication Date)
- Wiley(Publisher)
Specifications are generally technical and very detailed. There are several types of technical specifications that can be devel-oped. These include: ● Design Specifications ● Performance Specifications ● Functional Specifications. Design Specifications are developed by the buyer and will describe the physical attrib-utes of the deliverable. A description of its operating environment may also be included. As an example, suppose you have a chemical testing lab and need a specialized pump that will operate in a hazardous location. Your firm’s engineering depart-ment has developed a pump design and has tasked a local pump manufacturer with building the pump. Your design team has specified the operating condi-tions, the size and material of the pump casing, size of pump inlet and outlet, the size and material of the impeller, motor size, hazardous electrical circuit box, wiring diagram and connections. Upon installation, it is apparent that the pump is not working. Whose fault is this? First, if the pump manufacturer built the pump to your firm’s design speci-fications, the fault will lie with your firm (buyer). Be aware that this type of specification scenario puts the risk on the buyer (you). Performance Specifications are developed by you (the buyer) but the manufacturer (the supplier) is given the freedom and responsibility for designing, building, and delivering the product. Let’s return the previous pump example. However, instead of developing a Design Specification, we will provide the supplier with a performance specification. In this case, the buyer will leave all design and material decisions to the supplier. The Role of Supply Chain in Product Development 179 For this example, the supplier will simply provide the operating characteristics: Table 8.7 Sample Functional Specification No.
eBook - PDFEngineering Design
A Project-Based Introduction
- Clive L. Dym(Author)
- 2013(Publication Date)
- Wiley(Publisher)
Design Specifications are presented in three forms that represent different ways of formalizing a design’s functional performance and its features and behaviors for engineering analysis and design: Prescriptive specifications specify values for attributes of design. Thus, for our children’s juice container we might say, “A juice container must be made of at least 50% recyclable plastic.” For a ladder design we might say that “A ladder step shall be made from Grade A fir, have a thickness of at least 0.75 in., have a length that does not exceed 80 in., and be attached to the side rails through a full-width groove at each end.” Procedural specifications specify procedures for calculating attributes. So we would say: “The juice container must be disposable as stipulated by EPA standards.” In a ladder design we might specify: “The maximum bending stress s max in a ladder step shall be calculated from s max ¼ Mc=I and shall not exceed the allowable stress s allow .” Performance specifications specify performance levels that a function must demon- strate to be successful. Then we would say: “A juice container must contain 75 ml.” And for the ladder project we’d say: “A ladder step shall support an 800 lb gorilla.” In addition, if a system or device has to work with other systems or devices, then we must specify how those systems interact. We call these particular requirements interface performance specifications. 6.3.1 Attaching Numbers to Design Specifications It is normally the designer’s job to express functions in engineering terms so that engineering principles can be appropriately applied to the design problem at hand. As designers, we have to cast functions into terms that enable us to measure how well a design 6.3 Design SpecificationS: SPECIFYING FUNCTIONS, FEATURES, AND BEHAVIOR 81
eBook - PDFCompetitive Engineering
A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage
- Tom Gilb(Author)
- 2005(Publication Date)
- Butterworth-Heinemann(Publisher)
The two design idea specifications are local to the two different target specifications. They are not design constraints. They are clearly suggestions that need to be evaluated like any other suggestion . Allowing systems engineers to note design ideas at an early stage is useful in several ways: . it keeps track of potentially valuable design ideas which otherwise might get forgotten . it helps make the distinction between the requirements and the design technology clearer (‘clear ends–means separation’) . it lends credibility to the proposed goal levels (there exists some credible technology for the goal level suggested) 190 Competitive Engineering . it avoids the ‘frustration’ that some systems engineers feel when they are not allowed to be specific about the technology they have in mind . it allows us to send a message that we have noted a systems engineer’s suggestion or ‘pet idea’ and credited them with it – without yet officially approving it. Some of the early design ideas may be politically wise to consider, due to the fact that influential stakeholders have suggested them. There is no risk of any unfairness in considering these design ideas, because they will have to compete with the later design ideas. All design ideas must win their place for implementation by being the best, in terms of numeric satisfaction of the requirements. Design Constraints These are design ideas within the requirement specification, which have to be implemented at some stage. They can either specify or veto the use of specific designs. Usually, specific qualifying conditions apply. E XAMPLE Project Interface [Product Line ¼ New Generation, European Market]: Type: Design Constraint. Description: The full Project Interface shall be implemented using the most < current version > available. It shall be updated whenever < newer versions > are available.
eBook - ePub- Benjamin S. Blanchard, John E. Blyler(Authors)
- 2016(Publication Date)
- Wiley(Publisher)
management requirements necessary to fulfill program objectives. The combination of specifications and plans is considered the basis for all future program engineering and management decisions.The scope and depth of such documentation depend on the nature, size, and complexity of the system. In addition, the extent to which new design is feasible (where extra guidance and controls are desired), versus the selection of a standard off-the-shelf capability, will dictate the amount of documentation necessary. For small and relatively simple items, the technical specification and program planning requirements may be included in a single document. By contrast, for large-scale systems there may be a significant assemblage of documentation.3 In either case, the amount of documentation must be tailored to the need as dictated by the degree of technical and management controls necessary to accomplish program objectives.In dealing with large systems, there are numerous elements that must be covered by specifications. Some components of the system may require an extensive amount of research-and-development effort, whereas other components are procured directly from existing supplier inventories. In regard to new items, some are developed by the major producer of the system and others are developed by suppliers remotely located in various parts of the world. In manufacturing, certain components may be produced in multiple quantities using conventional methods, whereas a special process may be required to produce other items. There may be a variety of specifications necessary to provide the guidance and controls associated with the development of the system and its components.In preparing and applying specifications, there may be different classifications, depending on the type and nature of the item being designed or purchased off the shelf, as noted and illustrated in Figure 3.2 .4Hierarchy of technical specifications.Figure 3.2- System specification (Type A). Includes the technical, performance, operational and support characteristic for the system as an entity. It includes the allocation of requirements to functional areas, and it defines the various functional area interfaces. The major interfaces with other systems within the same SOS structure are also defined. The information derived from the feasibility analysis, operational requirements maintenance concept, and functional analysis is covered (refer to Sections 2.3
eBook - PDFA Philosophy of Technology
From Technical Artefacts to Sociotechnical Systems
- Peter Vermaas, Peter Kroes, Ibo van de Poel, Maarten Franssen, Wybo Houkes(Authors)
- 2022(Publication Date)
- Springer(Publisher)
2.1. CHARACTERISING TECHNICAL DESIGNING 23 further extend to, for instance, the necessary manufacturing facilities, including the technological infrastructure required for maintenance and repair. Methodologically, and in terms of timeframes, the core activity of designing is not, moreover, isolated but rather intertwined through all kinds of feedback loops with the preceding and ensuing phases. If the description D S of an artefact with function F is impossible or too complex, the designing engineer can return to the customer and ask if he or she can adapt his or her goals. But also after the description D S of an artefact has been laid down or after it has been proved that the prototype works, it is still possible for the engineer to go back to the customer and modify the goals. The artefact can be difficult to manufacture, or it can turn out that the fabrication costs are too high. In some cases, it is only once an aeroplane has been manufactured or has even entered into service that a clear view of the production costs emerges; one need only think in this context of the new problems that continuously surface during Space Shuttle flights. Designing is therefore an iterative activity or, in other words, an activity in which, step by step, engineers translate the goals of customers into functions F , convert those functions into descriptions D S of artefacts, construct those same artefacts, test them and ultimately produce them, while at every new stage being able to return to previous steps. In the engineering literature, technical designing is sometimes placed in an even broader context, which brings us to the second feature of designing mentioned at the beginning of this chapter.
eBook - PDF- Mike Tooley, Lloyd Dingle(Authors)
- 2010(Publication Date)
- Routledge(Publisher)
641 BTEC National Engineering. DOI: Copyright © 2010 Mike Tooley and Lloyd Dingle. Published by Elsevier Ltd. All rights reserved. 10.1016/B978-0-12-382202-4.00008-8 Engineering Design D esign is the process of converting an idea or market need into the detailed information necessary to manufacture a product or deliver a service. Successful design involves combining a number of skills together with the use of available technologies, materials and processes and then being able to deliver the product or service at a cost that will make it competitive with other products and services. Being able to design something is a fundamental engineering skill but simply being able to design something is not the end of the story. Equally important are the skills that you will need in order to be able to communicate your design to other people; even the most basic design will be hopelessly flawed if you cannot explain to people what it is about and how to make it! As an engineer, you might be involved with the design of an engineered product that varies from something as basic as a screwdriver to something as complex and sophisticated as a military aircraft. This unit will help you understand the design process and provide you with a variety of skills that will help you communicate your ideas to other people. Unit 8 Engineering Design 642 UNIT 8 The Design Process The design process is the name given to the various stages that we go through when we design something. Each stage in the process follows the one that goes before it and each stage is associated with a particular phase in a design project. You also need to be aware that design is not always about creating a brand-new product or service. Instead, it is often about improving or modifying an existing product.
eBook - PDF- Mike Tooley(Author)
- 2009(Publication Date)
- Butterworth-Heinemann(Publisher)
The effects of even a single design idea are too complex to understand without ‘experience analysis’ from past use of the idea, and especially without actual use on our new system. So it must normally be expected that the ‘final’ and ‘correct’ Design Specification can only be evolved toward (never perfectly or ideally reached) as a result of multiple feedback-and-change cycles. Refinement of design can be done in parallel with actual use (by at least some early stakeholders) of a version of the product. The practical feedback from this early delivery can be used to improve the design; prob-ably faster and more correctly than by staying in the ‘design phase’ longer. A further complication is that as time goes on, both the ‘design requirements’ and ‘potential and selected design technology’ will ‘expectedly’ change, thus re-quiring yet another set of cycles of learning how to satisfy these new, changed requirements. Never perfect, con-tinuously better, is the watchword. In terms of ‘Competitive Engineering’ you can always refine the design to be more competitive. However, there is a point where the cost and time of refining the design exceeds any competitive benefit, and it is time to stop designing and to get the product out of the door, this time around. Design Policy Design ideas are only really finally validated when they display satisfactory attributes in a real system (that is, after successful delivery in an evolutionary step). Don’t kid yourself that they are ‘final’ before that. A suggested mental attitude toward Design Specifications. Don’t believe any estimates of performance and cost, only reality as measured! 75 Solving the requirements problem C H A P T E R 2 . 3 This page is intentionally left blank 2.4 Chapter 2.4 Design Specification Tom Gilb 2.4.1 Introduction: specification quality control Specification quality control (SQC) is the name I shall use to refer to this method in this text. Within the software community, the term ‘inspection’ is used.
Index pages curate the most relevant extracts from our library of academic textbooks. They’ve been created using an in-house natural language model (NLM), each adding context and meaning to key research topics.
