5 Design Steps PDF

helaly 1 helaly 2  Step 1. Identify a need. Needs (also called the problem you are solving or the engineering goal) are frequently identified by customers--the users of the product. The customer cou...

helaly 1 helaly 2  Step 1. Identify a need. Needs (also called the problem you are solving or the engineering goal) are frequently identified by customers--the users of the product. The customer could be a retail consumer or the next team in a product development. helaly 3  Step 2. Establish design criteria and constraints. Design criteria are requirements you specify that will be used to make decisions about how to build and evaluate the product. Criteria are derived from needs expressed by customers. Criteria define the product physical and functional characteristics. Some examples of criteria are shape, size, weight, speed, ruggedness, and ease of helaly manufacture. 4  Step 3. Evaluate alternative designs. Your research into possible solutions will reveal what has been done to satisfy similar needs. You’ll discover where knowledge and science limit your solutions, how previous solutions may be improved, and what different approaches may meet design objectives. You should to consider at least two-to-three alternative designs and consider using available technology, modifying current designs, or inventing new solutions. helaly 5  Development of Alternative Designs ❑ involves creativity and eng. tools ❑ CADD & computer modeling ❑ stress analysis ❑ material science ❑ manufacturing processes ❑ constraints must be identified & met ❑ availability of parts & materials ❑ personnel ❑ facilities helaly 6  Step 4. Build prototype of best design. Use your alternatives analyses to choose the design that best meets criteria considering the constraints, then build a prototype. A prototype is the “first full scale and usually functional form of a new type or design” (Webster’s Dictionary). Expense may limit full-scale; often prototype components Prototype 1. An original model upon which something is patterned (Webster) 2. A standard or typical example. 3. A first full scale and usually functional form of a new type or design helaly 7  Step 5. Test and evaluate the prototype (against important design criteria) to show how well the product meets the need. You should develop a test plan describing what you will test, how you will test, and how you’ll perform analyses. You must test your prototype under actual or simulated operating conditions. Customers are usually involved in product testing so be sure you have an approval. helaly 8  Step 6. Analyze test results, make design changes and retest. Testing will disclose some deficiencies in your design. Sometimes the testing fails completely and sends the designer “back to the drawing board.” Make corrections and retest OR prepare an analysis of what went wrong and how you will fix it. As always, document your analyses, fixes, and retests in you project book. helaly 9  Step 6. Analyze test results, make design changes and retest. Testing will disclose some deficiencies in your design. Sometimes the testing fails completely and sends the designer “back to the drawing board.” Make corrections and retest OR prepare an analysis of what went wrong and how you will fix it. As always, document your analyses, fixes, and retests in you project book. helaly 10  Engineering Design Process helaly 11  “The base of the design process is creating a satisfactory solution to a need.” The need may be to improve an existing situation or to eliminate a problem. Or, the need may be to develop a use for a new discovery or concept. helaly 12 Engineering is all about—using knowledge and know- how to achieve a desired outcome. Designing is problem solving. It is creative problem solving. “Engineers are applications specialists”. They apply the principles, discoveries, experiences, techniques, and methods derived from ages of research, experimentation, trial and error, and invention helaly 13  Design Requirements Requirements are the necessary attributes defined for a system before and during design. The customer's need is the ultimate system requirement from which all other requirements flow. In addition, requirements are statements that identify the essential needs of a system in order for it to have value and utility. Requirements may be derived or based upon interpretation of other stated requirements to assist in providing a common understanding of the desired characteristics of a system. Finally, requirements should state what the system is to do, but they should not specify how the system is to do it. There are two types of system requirements: helaly mandatory and14preference.  Mandatory requirements: ❑(1) specify the necessary and sufficient conditions that a minimal system must have in order to be acceptable and are usually expressed with shall and must, ❑(2) are passed or failed (must not use scoring functions), and ❑(3) must not be susceptible to trade-offs between requirements. ❑After mandatory requirements have been identified, Systems Engineers propose alternative candidate designs, all of which satisfy the mandatory requirements. ❑Preference requirements are then evaluated to determine the "best" designs. helaly 15  Preference requirements: 1) state conditions that would make the customer happier and are often expressed with should and want, 2) should use scoring functions to produce figures of merit and 3) should be evaluated with a multicriteria decision technique because none of the feasible alternatives is likely to optimize all the criteria, and there will be trade-offs among these requirements. helaly 16  Defining the Customer The term customer includes anyone who has a right to impose requirements on the system. This includes end users, operators, bill payers, owners, regulatory agencies, victims, sponsors, etc. Because Systems Engineering delivers both a product and a process for manufacturing it, we must also consider the customer of the process. helaly 17  Stating the Problem Stating the problem is one of the Systems Engineer's most important tasks. The problem must be stated in a clear, unambiguous manner. State the problem in terms of what the world would be like if the problem did not exist, and not in terms of preconceived solutions However, it is better to state the problem in terms of the deficiency that must be ameliorated. This stimulates consideration of more alternative designs. helaly 18  Sources of Requirements In this section we list two dozen sources of requirements. However, Wymore (1993) says that only the first six sources are necessary: Input-Output, Technology, Performance, Cost, Trade-off, and System Test. He says all of the other sources can be put into one of these six. Grady (1993) says we should have only five sources: Functional, Performance, Constraints, Verification, and Programmatic. He thinks that most of our sources are constraints. The EIA/ANSI-632 Standard on Systems Engineering says there are only three: Functional, Performance, and Constraints (Martin personal communication). helaly 19  1-Input-Output 2-Technology Perhaps the most The technology requirement common requirements specifies the set of components -- relate the inputs of the hardware, software, and bioware -- system to its outputs. that is available to build the system. For example, an input- The technology requirement is output requirement for usually defined in terms of types of an electronic amplifier components that cannot be used, that must be used, or both 3-Performance Performance requirements include quantity (how many, how much), quality (how well), coverage (how much area, how far), timeliness (how responsive, how frequent), and readiness (ability, MTBF). helaly 20  4-Cost There are many types of cost, such as manpower, resources, and monetary cost. An example cost requirement would be that the purchase price cannot be more than $10,000, and the total life cycle cost cannot exceed $18,000. 5-Trade-off Trade-off between performance and cost is defined as the different relative value assigned to each factor. For example, the performance figures of merit may have a weight of 0.6, and the cost figures of merit may be given a weight of 0.4. 6-System Test The purpose of the system test is to verify that the design and the system satisfy the requirements. For example, in an electronic amplifier, a 3-mV, 10-kHz sinusoid will be applied to the input, and the ratio of output to input will be calculated. helaly 21  7-Company Policy Company policy is another way of stating requirements. For example, Learjet Inc. has stated, "We will make the airframe, but we will buy the jet engines and the electronic control systems." 8-Business Practices Corporate business policies might require Work Breakdown Structures, PERT Charts, Quality Manuals, Environmental Safety and Health Plans, or a certain return on investment. 9-Systems Engineering Systems or Software Engineering might require that every portable disk (e.g., floppy or Bernoulli) have a Readme file that describes the author, date, contents, software program, and version (e.g., Word 6.0 or Excel 4.0). helaly 22  10-Project Management Access to source code for all software might be a project management requirement. It takes time and money to install new software. This investment would be squandered if the supplier went bankrupt and the customer could no longer update and maintain the system. Therefore, most customers would like to have the source code. However, few software houses are willing to provide source code, because it might decrease their profits and complicate customer support 11-Marketing The marketing department wants features that will delight the customer. Kano calls them exciters. They are features that customers did not know they wanted. In the 1970's, IBM queried customers to discover their needs. No one mentioned portability, so IBM did not make it a requirement helaly 23  12-Manufacturing Processes Sometimes we might require a certain manufacturing process or environment. We might require our semiconductor manufacturer to have a Class 10 clean room. Someone might specify that Quality Function Deployment (QFD) be used to help elicit customer desires (although this would be in bad form because it states how not what). Recently, minimization of the waste stream has become a common requirement. 13-Design Engineers Design engineers impose requirements on the system. These are the "build to," "code to," and "buy to" requirements for products and "how to execute" requirements for processes. 14- Reliability Reliability could be a performance requirement, or it could be broken out separately. helaly 24 15- Safety Some requirements may come from safety considerations. These may state how the item should behave under both normal and abnormal conditions. 16 The Environment Concern for the environment will produce requirements, such as forbidding the use of chlorofluorocarbons (CFCs) or tetraethylchloride (TEC). 17- Ethics Ethics could require physicians to obtain informed consent before experimenting on human subjects. 18- Intangibles Sometimes the desires of the customer will be hard to quantify, such as for intangible items such as aesthetics, national or company prestige (e.g., putting a man on the moon in the Apollo project), or ulterior motives such as trying to get a foot in the door using a new technology (e.g., the stealth helaly 25 airplanes), or starting business in a new country (e.g., China).  19- Common Sense Many requirements will not be stated because they are believed to be common sense. For example, characteristics of the end user are seldom stated. If we are designing a computer terminal, it would not be stated that the end user would be a human with two hands and ten fingers. Common sense also dictates that computers not be damaged if they are stored at temperatures as high as 140°F. Furthermore, we do not write that there can be no exposed high voltage conductors on a personal computer, but it certainly is a requirement. Many of these requirements can be found in de facto standards. 20- Laws or Standards Requirements could specify compliance with certain laws or standards, such as the National Electrical Code, City/County Building codes, ISO-9000, or the IEEE 1220 Standard for Systems Engineering. helaly 26 21- The Customer Some requirements are said to have come from the customer, such as statements of fact and assumptions that define the expectations of the system in terms of mission or objectives, environment, constraints, and measures of effectiveness. These requirements are defined from a validated needs statement (Customer's Mission Statement), from acquisition and program decision documentation, and from mission analyses. 22- Legacy Requirements Sometimes the customer has definite requirements that are not stated. For example, "Your last system was robust enough to survive a long trip on a dirt road, so we expect your new system to do the same." helaly 27  23- Data Collection Activities If an existing system is similar to the proposed new system, then existing data collection activities can be used to help discover system requirements, because each piece of data that is collected should be traceable to a specific system requirement. Often it is difficult to make a measurement to verify a requirement. It might be impossible to meet the stated accuracy. Trying to make a measurement to verify a requirement might reveal more system requirements. 24- Other Sources There are many other sources of system requirements, such as: human factors, the environment (e.g., temperature, humidity, shock, vibration, etc.), the end user, the operator, potential victims, management, company vision, future expansion, schedule, logistics, politics, public opinion, business partners, past failures, competitive intelligence, liability, religion, culture, government agencies (e.g., DoE, DoD, OSHA, helaly 28  Testing and Evaluation Step 5. Test and evaluate the prototype against important design criteria to show how well the product meets the need. You should develop a test plan describing what you will test, how you will test, and how you’ll perform analyses. You must test your prototype under actual or simulated operating conditions. Evaluation of designs/Selection of optimal design One or more of the designs must be fabricated Thorough testing must be done to ensure the product meets performance specifications Based on the results of the testing, the design is finalized helaly 29  This is where the rubber meets the road! Remember those specifications you developed back at the beginning of the project? It's time to pull those out again and test your product to make sure it meets every single spec! Make sure you test it thoroughly before you release it to the customer. Four things can happen at this point: 1.The product doesn't meet the spec 2.The product meets the spec but the spec was wrong 3.The customer changed his/her mind 4.The product meets the spec and the customer is happy helaly 30  A critical element of the requirements development process is describing the tests, analysis or data that will be used to prove compliance of the final system with its requirements. Each test must explicitly link to a specific requirement; this will help expose untestable requirements. Describing the system tests informs the producers how the system will be tested, so that they know how they will be "graded." helaly 31  This process frequently uncovers overlooked requirements. At this time it may be useful to examine the following definitions. Validating a System: Building the right system; making sure that the system does what it is supposed to do. It determines the correctness of an end product, compliance of the system with the customer's needs, and completeness of the system. helaly 32  Validating Requirements: Ensuring that the set of requirements is consistent, that a real-world solution can be built that satisfies the requirements, and that it can be proven that such a system satisfies its requirements. If Systems Engineering discovers that the customer has requested a perpetual-motion machine, the project should be stopped. helaly 33 Verifying a System: Building the system right; ensuring that the system complies with its requirements. Verifying a system determines the conformance of the system to its design requirements. It also guarantees the consistency of the product at the end of each phase, with itself and with the previous prototypes. In other words, it guarantees the honest and smooth transition from model to prototype to preproduction unit. to production unit. helaly 34  Verifying Requirements: Examination, analysis, test, or demonstration that proves whether a requirement has been satisfied. This process is iterative. The requirements should be verified with respect to the model, the prototype, the preproduction unit, and the production unit. For Systems Engineers, to validate requirements is to prove that it is possible to satisfy them. System verification, on the other hand, is a process of proving that a system meets its requirements. To add further confusion, ISO-9000 tells you to verify that a design meets the requirements and validate that the product meets requirements. helaly 35  Prototyping A good design isn't worth anything unless you can actually make something. The goal of prototyping is to follow the recipe that you developed during detailed design and actually build a product. If you did a good job and accurately documented the design, prototyping is simply a matter of following the directions. If you find yourself continuing to work out the details of the solution, then you need to go back to detailed design and make corrections. helaly 36  Prototypes can serve three different purposes. One purpose is that of function, the ability of a proposed design to operate in a desired way. In the mechanical world, this is often known as a working prototype, and demonstrates that the essential functionality of a design operates as intended. A look-and-feel prototype is used to understand what the form and appearance of a design should be. An example is a non-functional industrial design model made of foam or rendered in 3-D. Finally, role prototypes give a sense of the usability of a design. Storyboards are often used to illustrate how and under what contexts a product might be employed by an end user. helaly 37