MIME Capstone Design

1
MIME Capstone Design

• Project Initial Phase
• Systems
• System Analysis
• Functional Decomposition
• Design Research

2
Project Initial Phase
Develop Customer Requirements
Customer Requirements
Perform System Analysis / Functional Decomposition
SA / FD
Conduct Design Research
Existing Designs
3
Develop Customer Requirements

• 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

4
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?

5
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.

6
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

7
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.

8
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).

9
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)

10
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

11
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.

12
Project Initial Phase
Develop Customer Requirements
Customer Requirements
Perform System Analysis / Functional Decomposition
SA / FD
Conduct Design Research
Existing Designs
13
Perform System Analysis / Functional Decomposition

• 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.

14
System
System
Subsystem 1
Subsystem 2
Subsystem 3
Subsystem 2.1
Subsystem 2.1
Subsystem 2.1
System Analysis
Functional Decomposition
15
Function

• An activity or process performed to achieve some
  desired end. e.g.,
• provide power (ME)
• manufacture Widgets (IE / MfgE)
• For our purposes
• function process

16
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.

17
System Analysis / Functional Decomposition Result
Representation

• Diagram

System Analysis or Functional Decomposition or Sys
tem Hierarchy (Diagram)

• Outline/Hierarchy
• System
• Subsystem 1
• Subsystem 2
• Subsystem 2.1
• Subsystem 2.2
• Subsystem 2.3
• Subsystem 3

System Analysis or Functional Decomposition
18
System Analysis / Functional Decomposition
Example 1(Based on a past Capstone Design
Project)
Objective A system to demonstrate how rainwater
can be collected and utilized using only natural
or human power.
Rainwater Use Demonstration System
Water Use Subsystem
Catchwater Subsystem
Water Transfer Subsystem
Collection Subsystem
Holding Subsystem
etc.
Holding-Pump Conduits
Pump-Use Conduits
Pump
etc.
Analysis/Decomposition proceeds to sufficient
level of detail -- without making design
decisions too early.
19
System Analysis / Functional Decomposition
Example 1(Based on a past Capstone Design
Project)

• Rainwater Use Demonstration System
• Catchwater Subsystem
• Collection Subsystem
• Holding Subsystem
• Water Transfer Subsystem
• Holding-Pump Conduit
• Pump
• Pump-Use Conduits
• Water Use Subsystem

20
Project Initial Phase
Develop Customer Requirements
Customer Requirements
Perform System Analysis / Functional Decomposition
SA / FD
Conduct Design Research
Existing Designs
21
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

22
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

23
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
  Benchmarking
• NOTE These sources may not address systems
  exactly like the one you are to design!

24
Design Research For Example 1
Rainwater Use Demonstration System
Water Use Subsystem
Catchwater Subsystem
Water Transfer Subsystem
Collection Subsystem
Holding Subsystem
etc.
Holding-Pump Conduits
Pump-Use Conduits
Pump
etc.
25
System Analysis / Functional Decomposition
Example 2Process-Oriented
Objective A system to convert used wood (waste
from building/remodeling) to a salable product.
Wood Waste Conversion System
Storage Sale
Receiving
Conversion
etc.
Sorting
Hardware Removal
Waste Disposal
Pelletizing
Grinding
etc.
etc.
Analysis/Decomposition proceeds to sufficient
level of detail -- without making design
decisions too early.
26
System Analysis / Functional Decomposition
Example 2Using Process Verb Phrase Convention
Objective A system to convert used wood (waste
from building/remodeling) to a salable product.
Convert Wood Waste
Store Sell
Receive Used Wood
Convert to Product
etc.
Sort
Remove Hardware
Dispose of Waste
Pelletize
Grind
etc.
etc.
27
System Analysis / Functional Decomposition
Example 3From a Class Example
Objective Assemble parts into a finished Widget.
Assemble Widgets
Assemble Parts
Inspect Widgets
Restock Parts
Get Widget Parts
Secure Parts To Base
Release Assembled Widget
Hold Widget Base For Assembly
Position Parts In Place
Analysis/Decomposition proceeds to sufficient
level of detail -- without making design
decisions too early.
28
System Analysis / Functional Decomposition
Example 3IDEF0 Representation
29
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, whos
  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.
30
Benchmarking Guidelines

• Be specific.
• Be willing to share.
• Make a win-win proposal.
• Know the site.
• Send questions.
• Dont go alone.
• Document.

31
Benchmarking Guidelines

• Respect privacy.
• Dress appropriately.
• You can call.
• Say thanksoften!
• Follow up.

32
Types of Formal Benchmarking

• Internal Benchmarking
• Competitive Benchmarking
• Functional Benchmarking
• Generic Benchmarking

33
Internal Benchmarking

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

34
Competitive Benchmarking

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

35
Functional Benchmarking

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

36
Generic Benchmarking

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