P20095: Motorized Stage for Whole Slide Imaging
/public/

Problem Definition

Table of Contents

Your website should document your journey through MSD, so include work-in-progress as well as latest results. Use snapshots for display whenever possible so that information is easily viewable without the need to download files and open applications. Any time you post a snapshot of a document for a phase review, you should also provide a link to the live document (Your EDGE file repository should still contain original editable files).

You should use the Problem Definition Documents directory to store this information. Some templates are available there for your use.

All template text must be removed from this page prior to your Week 3 Problem Definition Review

Team Vision for Problem Definition Phase

Summarize:

Project Summary

A pathologist uses an inefficient and time consuming process of manually analyzing specimens by hand under a microscope to identify areas of interest within the specimen. A digital microscopy accessory with X, Y, Z coordinate tracking can improve the efficiency and accuracy of the process, helping pathologists to quickly identify and record the precise locations of key pathologic features of a tumor. The goal of the proposed project is to develop an optical microscope attachment utilizing a motorized stage which can precisely track and move to any given X, Y, Z coordinate on the specimen slide. The device is to be inexpensive, easy to use and install, save the pathologist time within their workflow, and be able to fit on any microscope on the market.

Use Cases

Your team will identify the different scenarios in which your project will be used. This will help inform your requirements and set bounds on specifications.

Project Goals and Key Deliverables

Expected end result of the project, what the customer can expect to receive at the end of the project.

Customer Requirements (Needs)

Questions for initial customer interview are found below.

1. What is so time consuming about the manual, by hand identification of areas of interest? 2. How is tracking the path of the slide and how efficiently the pathologist found the area of interest useful? 3. Why is the ability for the stage to be moved using only mouse input so important? 4. Is it more of a priority to be able to accurately track the X, Y, and Z coordinates than have a fully motorized stage? 5. Can pathologists quickly locate areas of interest if they know where the coordinates are? If so, is most of the time savings going to be from knowing the coordinate location rather than having an automated stage? 6. What was the particular event or catalyst that sparked the idea for this project? When did this happen? 7. Is the time it takes to locate the tumor or the tumor location more important or valuable to you? Are they equally significant? 8. What is the definition of a fully automated process in terms of this project? Is human interaction a significant part of the process? 9. Can we use a different method of moving the stage, such as a custom “controller” with a joystick or something else of nature? 10. Budget, the packet says low budget and 3d printed parts? 11. How many photos would typically be saved from one slide sample? 12. What will the manufactured enclosure be made out of? Aluminum? 13. Which desired attributes are the most important? Are there any that are purely “bonus” features? 14. What are key deliverables that you would like to see in the final device? 15. Who are key customers/stakeholders in your opinion? 16. Do you see us integrating with WSI companies? 17. What is the current method of extracting coordinate data from the external camera (Question for Eli and Dany...those are the developers)? 18. How fine does the movement of the stage need to be? a. Ratio of the mouse/joystick movement to the stage movement 19. What are the overall dimensions of each slide and are they consistent? a. Full range of motion for the slide in all directions 20. What is the depth (z) needed to obtain a clear image of the specimen? a. How many images would need to overlayed 21. Does the image need to be decomposed/stored using MATLAB or another software tool?

Purpose

Decompose the Problem Statement into functions of elements needed to satisfy the customer.

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. Include this document in all project reviews during MSD1.
  4. Have you sought input from all the relevant stakeholders? How will you confirm this?
  5. Have you converted customer-generated solutions into needs statements?
  6. Describe why each requirement has been requested.
  7. Have you confirmed this list with your customer?
  8. Customer requirements often evolve over the first several weeks of the MSD. Understanding the customer’s overall objective (Problem Statement) and the levels of each requirement needed to achieve that objective will help you get to a final requirements document more quickly.
  9. Functional requirements (e.g. capabilities, performance, robustness, etc.) typically denote the purpose of the project. Constraints (e.g. cost , safety, size & weight , etc.) typically denote conditions for acceptance of the solution.

http://edge.rit.edu/edge/P15001/public/MSDI/Problem%20Definition%20Documents/Edge_Pictures/P15001_Customer_Requirements.png

  1. In addition to a snapshot, include a link to the live document here
  2. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. PRP.
  2. Problem Statement.
  3. Customer Interviews. (Interview guidelines and expected outcomes are available for your reference)
  4. Customer's customer if possible.
  5. Standards, regulations, or other industry guidelines (e.g., ADA, EPA, OSHA, IEEE, ASME; IRB approval; etc.) that your customer or your customer's organization is required to address. The RIT library maintains an infoguide with links to standards databases
  6. Template and Example.
  7. Guide & other stakeholders.

Outputs and Destination

A completed form matching the supplied template to be used as input to define the Engineering Requirements.

Engineering Requirements (Metrics & Specifications)

Purpose

Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. Include this document in all project reviews during MSD.
  4. The Engineering Requirements (often called Specs.) must; cover all of the Customer Requirements, be as unambiguous as possible, and be confirmed by the customer, with signature if possible.
  5. System-level and function-level engineering requirements define the intended capabilities and performance of your system. Are your engineering requirements measurable and testable? Can they all be traced back to customer requirements?
  6. Constraints are factors, usually system-level, that limit your design space (e.g., cost, total weight, total footprint, total power available). Are your constraints measurable and testable, and can they be traced back to customer requirements? Have you considered economic, environmental, social, political, ethical, health and safety, manufacturability, and sustainability constraints, for example?
Engineering Requirements Template

Engineering Requirements Template

  1. References:

https://edge.rit.edu/edge/PTemplate/public/Establish%20Engineering%20Requirements

  1. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Customer Requirements
  2. Customer
  3. Phase I benchmarking
  4. Standards, regulations, or other industry guidelines (e.g., ADA, EPA, OSHA, IEEE, ASME, etc.) The RIT library maintains an infoguide with links to standards databases.
  5. Selected concept list
  6. System Design
  7. Template and Example
  8. Guide & other stakeholders

Outputs and Destination

  1. Function Decomposition.
  2. Concept Generation & Development.
  3. HoQ.
  4. System & Detail Design.
  5. Test Plans.
  6. Poster & Final Report.

Constraints

Factors, usually system-level, that limit your design space (e.g., cost, total weight, total footprint, total power available). Are your constraints measurable and testable, and can they be traced back to customer requirements? Have you considered economic, environmental, social, political, ethical, health and safety, manufacturability, and sustainability constraints and engineering standards, for example?

House of Quality

Purpose

  1. Confirm that satisfaction of the Engineering Requirements implies that all of the Customer Requirements are met.
  2. Facilitate design trade off decisions

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. This document will be inspected at all project reviews during MSD1.
  4. Array customer requirements in the first column and the Engineering Requirements across the top row.
  5. Evaluate the correlations between Customer and Engineering Requirements to ensure all of the Customer Requirements will be satisfied if the Engineering Requirements are satisfied.
  6. Evaluate the potential conflicts between the Engineering Requirements.
  7. Evaluate targets set for Engineering Requirements verses best benchmarking results.
  8. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Template and Example.
  2. Customer Requirements.
  3. Engineering Requirements.
  4. Benchmarking Data.

Outputs and Destination

Provide input to the risk management process.

Design Review Materials

Include links to:

It is appropriate for you to send your customer and guide a link to this page in preparation for the review. This will ensure that they know what you will be presenting and how to view all of your work. Any EDGE link should start with http://edge.rit.edu/edge/P1xxxx..... Using "http" instead of "https" will ensure that non-RIT stakeholders can view the content without being prompted for a DCE login and password.

Plans for next phase


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation