Engineering Design Notes II Problem Formulation. EE 498/499 Capstone Design Classes Klipsch School of Electrical & Computer Engineering

Transcription

1 Engineering Design Notes II Problem Formulation EE 498/499 Capstone Design Classes Klipsch School of Electrical & Computer Engineering

2 Topics Overview Specifications Customer Requirements Over-specification Acceptance Criteria Real-life Constraints Data Items Spring 2007 Design Notes II - Formulation 2

3 Overview Problem formulation is the first part of the design problem. The objective of problem formulation is to identify Customer/user needs Relevant regulatory, safety, economic, etc. constraints What the final acceptance criteria will be. The problem formulation step will result in the problem Specifications. Redesign iteration Specification Generate Alternatives Analyze Alternatives Evaluate Alternatives Establish functional requirements Determine design constraints Determine acceptance criteria Create alternative solutions to realize Specifications Feasible Alternatives How well do the alternative designs meet the Specifications Perform numeric comparison of the alternatives and the quality of their meeting Specifications Fabrication specification for the best alternative Spring 2007 Design Notes II - Formulation 3

4 Specifications Specifications are factual statements of functional performance that the design is to meet. Specifications must be testable via a measurement or analysis to be valid. Specifications should not realize design element unless required by regulations. There should be only as many specifications as required to encapsulate all of the required functions. Spring 2007 Design Notes II - Formulation 4

5 Customer Requirements The Requirements Specification is key to the design. It drives not only the design but the testing and acceptance criteria for the design. Where do they come from: Customer needs survey Known deficiencies in existing designs Reactions to changes brought on by regulatory or cost drivers Spring 2007 Design Notes II - Formulation 5

6 Customer Requirements What are requirements: A set of short (one or two sentences), testable statements that embody the functional and performance specifications that the design is to meet. Usually, the requirements are grouped, to the extent possible, into subsets that cover like areas of design. For example, user interface requirements would not be placed next to power requirements. Spring 2007 Design Notes II - Formulation 6

7 Customer Requirements The requirements specification process is iterative and produces two outputs A specific problem statement The Requirements Specification document Spring 2007 Design Notes II - Formulation 7

8 Customer Requirements The Problem Statement is statement that is Non-technical (free of jargon or buzz-words) Not using quantifiable descriptions (save those for the requirements specification) Complete covering all of the aspects of the design Specifiable or able to be taken to the detail of the requirements specifications document This forms the basis for deriving the Requirements Specification Document Spring 2007 Design Notes II - Formulation 8

9 Customer Requirements The requirements specification is intended to specify the design requirements and not the final product embodiment. The requirements should be traceable to the design problem statement and necessary safety, regulatory, or marketing constraints The next slide contains a typical Requirements Document for industry. Spring 2007 Design Notes II - Formulation 9

10 Customer Requirements Introduction Problem Description Intended/unintended uses Special Features Operational Concept Design Requirements Functional Performance Operating Environment Safety Economic Form Factor Limitations Maintenance & Repair Retirement Reliability Robustness Pollution Ease of Use Human Factors Appearance Acceptance Test Plan Spring 2007 Design Notes II - Formulation 10

11 Over-specification There are several types of over specification: Taking customer wants as needs Being overly conservative in design constraints Adding too much detail to functional requirements. The down side to these over-specifications is Increased cost Increased complexity Potential schedule, manpower, and budget slippage Spring 2007 Design Notes II - Formulation 11

12 Over-specification Needs vs. Wants Try to separate between those functions that must be done versus those functions that would be nice to have. This is often difficult to do and may take several iterations with the customer to distinguish true needs from wants in the requirements. Needs are absolute, can t-live-without functions. Wants are features that would be nice to have if possible. Spring 2007 Design Notes II - Formulation 12

13 Over-specification Overly-conservative design occurs when the requirements go beyond what is required for health, safety, or regulatory constraints. For example, if a safety margin of 25% is required in the design by safety requirements, then do not make the safety margin 50%. Spring 2007 Design Notes II - Formulation 13

14 Over-specification Adding too many details to the functional requirements results in a design that is harder to realize and verify. The goal is to capture the basic functional details without going into more detail than necessary. In particular, do not specify design options as requirements unless there is an explicit reason. Spring 2007 Design Notes II - Formulation 14

15 Real-life Constraints Each design will ultimately have constraints. Some will be explicit constraints: These are customer-expressed statements of what comprises an acceptable design. For example, they may involve materials, cost, weight, etc. They must still be expressed in terms of a testable requirements statement Spring 2007 Design Notes II - Formulation 15

16 Real-life Constraints Some constraints will be implicit constraints (not officially stated by the customer). Implicit constraints include: They may involve the laws of physics (no perpetual motion machines). Health, safety, or other regulatory requirements. When all constraints are met, the design is feasible. Spring 2007 Design Notes II - Formulation 16

17 Acceptance Criteria The customer will always have a set of specifications that will be used to buy off on the design. These criteria will form the basis for the final acceptance of the design. Frequently, the customer will specify these final acceptance criteria as a subset of the total design requirements. The acceptance criteria will be used as drivers for subsystem and unit testing. Spring 2007 Design Notes II - Formulation 17

18 Data Items After the Formulation step, the following data items are the products of this design phase: Requirements Document a listing of the requirements for this item based on the requirements development process Requirements Verification Matrix a matrix version of the requirements to track assignment of design elements to the requirements These are not static but updated and refined as the design process continues. Spring 2007 Design Notes II - Formulation 18