Open minds. Open doors.TM School of Mechanical, Industrial, & Manufacturing Engineering MIME...

Open minds.Open doors.TM

School of Mechanical, Industrial, & Manufacturing Engineering

MIME Capstone Design

Project Initial Phase Systems

System Analysis Functional Decomposition

Design Research



Project Initial Phase

Develop Customer Requirements

Perform System Analysis / Functional Decomposition

Conduct Design Research

Customer Requirements

SA / FD

Existing Designs




Writing Good Requirements Requirements state something:

Necessary

Verifiable/Measurable – Note: Customer Requirements (CRs) need not be Engineering Requirements (ERs) must be

Attainable

and they state it clearly.

Common Problems Writing implementation (HOW) instead of requirements (WHAT)

Using incorrect terms

Using incorrect sentence structure or bad grammar

Over-specifying

Missing requirements



Writing implementation (HOW) instead of requirements (WHAT)

Example:– The workstation shall include an RDM

hydraulic lift, adjustable-height work table. (IMPLEMENTATION)

The requirement should state WHAT is needed not HOW it is to be provided.

Solution: Ask the question: WHY do you need the requirement?



Writing implementation (HOW) instead of requirements (WHAT)

Answers: Workers of various sizes will use the workstation.

A typical workpiece requires handwork about four inches above the surface supporting it.

By ergonomic guidelines, the workpiece should be slightly below elbow level.

This is real requirement: The workstation shall be adjustable so that the work

surface is 4 in below the elbow level of the worker.

It leaves lots of options open for implementation.



Using Incorrect Terms

Use of Terms:– Requirements use the word “shall”.– Statements of fact use “will”.– Goals use “should”.

Terms to avoid:– support– but not limited to– etc.– and/or



Using Incorrect Sentence Structure Or Bad Grammar

Requirements should be easy to read and understand. Format:

– The system shall provide means to …– The system shall be capable of …

– The system shall weigh …

– Subsystem 2.1 shall provide means to ...– Subsystem 2.2 shall interface with …

Note: the name of the system and subsystem appears in these locations, if the system name is complex, use acronyms.

Guidelines: – Each “shall” should be followed by a single predicate, not by a list.– Should not be complicated by explanation of operations, design or other

information.



Unverifiable Requirements

Avoid ambiguous terms:– Minimize– Maximize– Rapid– User-friendly– Easy– Sufficient– Adequate– Quick

Be specific. – How rapid? 10 per hour, 5 per hour.– What is sufficient? 10 units, 100 units.– What is “user-friendly”?

If you are not sure yet (e.g., in CR phase), – enclose the term in asterisks (e.g., *rapid*, *minimize*).



Over-specifying(Typically in the ER Phase)

Major cause of cost overruns and delivery time delays.

Ask the question why it is needed before writing it as a requirement.

Be aware of over stringent requirements– Allow for tolerances (i.e. if height of a table

is specified to be 1000 mm allow for variations, such as 1000 +/- 10mm)



Missing Requirements

Use models and other elaboration tools to make sure every aspect of the system is specified.

Requirements Drivers (i.e., things to think about):– Functional – Reliability– Performance – Maintainability– Environment – Safety, Integrity– Facility – Regulatory– Transportation – Security– Deployment – Privacy– Training – Complexity, Usability– Personnel – User Safety, Usability, Operability



SMART: Guidelines For Checking Requirements

S Specific? Well defined and clear to anyone involved in the product/process.

M Measurable? Have a way of quantifiable measurement to know when the requirement is reached, or at least the potential for that. Some flexibility in Customer Requirements.

A Agreed Upon? Agreement between both you and your customer.

R Realistic? Within the availability of resources and knowledge.

T Time Based? Enough time to produce the desired result.








SA / FD

Existing Designs




System (Engineered) A collection of entities that interact to perform

some useful function Can be analyzed / decomposed into

subsystems to facilitate understanding, design. Entities may be

physical components or processes.



System

System

Subsystem 1 Subsystem 2 Subsystem 3

Subsystem 2.1 Subsystem 2.1 Subsystem 2.1

System Analysis

Functional Decomposition



Function

An activity or process performed to achieve some desired end. e.g.,

provide power (ME) manufacture Widgets (IE / MfgE)

For our purposesfunction ≈ process



Perform System Analysis / Functional Decomposition (additional points)

To perform Functional Decomposition is to perform System Analysis (analyze a system) with consideration to what functions the subsystems perform, not just proximity of physical components.

For our purposes,

System Analysis ≈ Functional Decomposition

Note, “System Analysis” / “Functional Decomposition” can mean

the process of performing SA / FD

or the result of performing SA / FD.



System Analysis / Functional Decomposition Result Representation

DiagramSystem Analysis

orFunctional Decomposition

orSystem Hierarchy (Diagram)

System Analysisor

Functional Decomposition

Outline/Hierarchy System

Subsystem 1

Subsystem 2 Subsystem 2.1 Subsystem 2.2 Subsystem 2.3

Subsystem 3



System Analysis / Functional Decomposition Example 1(Based on a past Capstone Design Project)

Rainwater Use Demonstration System

Catchwater Subsystem

Water Transfer Subsystem

Water Use Subsystem

Holding-Pump Conduits Pump

Pump-Use Conduits

Objective: A system to demonstrate how rainwater can be collected and utilized using only natural or human power.

Collection Subsystem

Holding Subsystem

etc.

etc.Analysis/Decomposition proceeds to sufficient level of detail -- without making design decisions too early.



System Analysis / Functional Decomposition Example 1(Based on a past Capstone Design Project)


Catchwater Subsystem Collection Subsystem Holding Subsystem

Water Transfer Subsystem Holding-Pump Conduit Pump Pump-Use Conduits

Water Use Subsystem








SA / FD

Existing Designs



Conduct Design ResearchIncluding Benchmarking

Goal: to identify existing designs, methods, “best practices” or “state-of-the-art” as ideas for your project's

system subsystems equipment processes procedures

Prerequisites: System Analysis / Functional Decomposition sources of research / benchmarking sites



Systems/Subsystems To Research and/or Benchmark

Some examples (drawn from past and present system/process projects) manual recyclables/waste sorting systems safe furniture handling training materials safety audit processes compact hand tool storage systems applications processing systems optimal pickup/delivery schedule algorithms equipment test procedures & equipment processes & equipment to remove hardware from used/scrap lumber equipment to grind waste wood into salable material manufacturing cost modeling methods production scheduling algorithms, software barcode equipment and procedures process (vs. product) quality control methods food packaging equipment & processes



Sources For Design Research Textbooks Course Notes Catalogs Past Projects Baldrige and Presidential Quality Award Winners Federal Agencies Internet Experts Trade Journals Scientific Publications Navy Best Manufacturing Practices database College/University libraries Consultants Professional Associations Companies & other organizations for site visits Companies & other organizations for Formal BenchmarkingNOTE: These sources may not address systems exactly

like the one you are to design!



Design Research For Example 1


Catchwater Subsystem

Water Transfer Subsystem

Water Use Subsystem

Holding-Pump Conduits Pump

Pump-Use Conduits

Collection Subsystem

Holding Subsystem

etc.

etc.



System Analysis / Functional Decomposition Example 2Process-Oriented

Wood Waste Conversion System

Receiving ConversionStorage &

Sale

Waste Disposal

Grinding Pelletizing

Objective: A system to convert used wood (waste from building/remodeling) to a salable product.

Sorting Hardware Removal

etc.

etc.Analysis/Decomposition proceeds to sufficient level of detail -- without making design decisions too early.

etc.



System Analysis / Functional Decomposition Example 2Using Process Verb Phrase Convention

Convert Wood Waste

Receive Used Wood

Convert to Product

Store & Sell

Dispose of Waste

Grind Pelletize

Objective: A system to convert used wood (waste from building/remodeling) to a salable product.

Sort Remove Hardware

etc.

etc.

etc.



System Analysis / Functional Decomposition Example 3From a Class Example

Assemble Widgets

Restock Parts Get Widget Parts

Assemble Parts

Secure Parts To Base

Release Assembled

Widget

Inspect Widgets

Objective: Assemble parts into a finished Widget.

Hold Widget Base For Assembly

Position Parts In Place

Analysis/Decomposition proceeds to sufficient level of detail -- without making design decisions too early.



System Analysis / Functional Decomposition Example 3IDEF0 Representation



Formal Benchmarking Distinction: involves site visits to outside companies,

organizations, to identify

alternative approaches

“best practices”

etc.

Steps to formal benchmarking

Prepare to benchmark (decide what to benchmark, understand current process)

Conduct research (collect information, who’s best? who to ask?)

Select who to benchmark

Collect and share information

Analyze, adapt, improve

These Benchmarking slides were adapted from Dr. Toni Doolen's 2008-9 Capstone Design lecture, which was adapted, in turn, from Norma Jo Greenlee, U.S. Patent and Trademark Office, Office of Quality Management.



Benchmarking Guidelines

Be specific. Be willing to share. Make a win-win proposal. Know the site. Send questions. Don’t go alone. Document.



Benchmarking Guidelines

Respect privacy. Dress appropriately. You can call. Say thanks—often! Follow up.



Types of Formal Benchmarking

Internal Benchmarking Competitive Benchmarking Functional Benchmarking Generic Benchmarking



Internal Benchmarking

An approach to benchmarking where organizations learn from “sister” companies, divisions, or operating units.



Competitive Benchmarking

An approach to benchmarking that targets specific product designs, process capabilities, or administrative methods used by one’s direct competitors.



Functional Benchmarking

An approach to benchmarking that seeks information from the same functional area within a particular application or industry.



Generic Benchmarking

An approach to benchmarking that seeks process performance information from outside one’s own industry. Enablers are translated from one organization to another through the interpretation of their analogous relationship.

Open minds. Open doors.TM School of Mechanical, Industrial, & Manufacturing Engineering MIME...

Documents

Transcript of Open minds. Open doors.TM School of Mechanical, Industrial, & Manufacturing Engineering MIME...