Mach 30 #EngineerSpeak Hangout October 17, 2013
Discussion Topic: Changes to the SEP Initial Questions and Requirements Documents
Attending: Jeremy, J, Greg, Chris, Mike M., Juli, Aaron, Debi-Lee, Ethan
- It was a light-weight approach.
- We’ve been using it and adapting it.
- We distill requirements out of the initial questions document. This ensures that you address everything.
- We’ve noticed that there are some “hiccups”. Thus J has suggested some changes to the order and nomenclature of the questions to make it easier to map the questions to requirements.
- Three groups have emerged - Background Questions (BQ), Project Questions (PQ), and Technical Questions (TQ).
- The TQ and PQ map to TR and PR requirements. TQ1 ==> TR1.1, etc.
- This sets you up to create proper requirements, but also gives you narrative style content for things like marketing materials.
- Jeremy - The requirements are missing the who and the why. Is that normal?
- J- Yes thats intentional because the requirements are meant to measure quantitative things (with a threshold and objective value).
- J - The “where” might be important, the “how” is the answer to the engineering design, and the “who” and “why” are not parts of the requirements.
- Jeremy - So, can we create examples and templates for this?
- J- 2 things: a) the process that we are using is only one way to do this, but certainly not the only way. b) in terms of providing guidance on HOW to move from “initial questions” to “requirements” I don’t think we have enough experience to make that kind of recommendations yet.
- Greg- In systems engineering classes there’s a lot on the process to follow, but little on implementation. That’s for a reason. You really need to go through the entire process to make sure you don’t miss anything. Each project needs to be treated as a separate entry.
- J - It’s ok to set your expectations.
- Greg - If you’re not careful you can box yourself in. No one set of requirements will be the same as any others. Any template needs to allow for additional thinking beyond what’s been done before.
- J showed Greg the related forum post and Greg approved.
- Aaron - You do need to be able to change the requirements document. It has to be a living document because we can’t anticipate projects 5 years from now.
- J - Agreed. Things will get more rigorous when you’re dealing with much larger project.
- Aaron/J/Greg - Permit evolution and revolution with the SEP and engineering processes.
- Jeremy - Do we have the support to approve the new format for the questions and requirements that J came up with?
- Jeremy, Aaron, J, Greg, Juli, Chris, Ethan - Approve
- J - Needs to ask Aaron new questions about metrics.
- J - Was the limitation of Shepard to 5 lbs including the DAQ reasonable?
- Aaron - The current R&D frame weighs about ¼ pound.
- Greg - The 5 lbs is driven by decreased shipping costs.
- Jeremy - What about setting a required weight and a goal weight?
- J - We need to shoot for as close to 5 pounds to reduce shipping costs.
- Greg - Thinks a range would be acceptable.
- Chris - It should say “should weigh no more than a threshold of 7 and a objective of 5 pounds”.
- Aaron - The current structure with load cell and Arduino + Protoshield ~= 9 ounces.
- J - If that’s the case, we should bump the threshold and objectives down. Maybe “Including the structure, mounting hardware and DAQ, but not the block, the STS should weigh no more than a threshold of 5 and an objective of 3 pounds. This is due to a need to keep shipping costs low.”
- Greg - Make sure to be very specific about the system boundaries, and state what the weight includes and excludes.
- J - We need to specify the physical dimensions of the test stand.
- Aaron - The R&D structure fits on an 8.5x11 inch sheet of paper.
- Greg - “It should fit inside of a USPS first class flat rate box” or something like that.
- J - Aaron’s is unrealistically small at this point.
- J - One of the small flat 8-⅝ x 5-⅜ x 1-⅝ in.
- Greg/J - Ok with some disassembly as long as it doesn’t cause an overshoot of our setup time requirements.
- J - Objective = fit into USPS small flat rate box, threshold = fit into USPS medium flat rate box.
- Medium dimensions set #1: 13-5/8" x 11-7/8" x 3-3/8"
- Medium dimensions set #2: 11" x 8-1/2" x 5-1/2"
- Aaron/Chris - You could remove the load cell, but you’ll have to recalibrate.
- J - That’s ok because we’re planning to always calibrate anyway.
- J - It would be great to get down to the small sized box, but we can be pretty sure that one of the two medium sizes will work.
- Jeremy - That makes it easier for CCSSC to transport 10 or more at a time.
- J - Yes, that would get them to fit inside a normal sedan trunk.
- J - Took poll: Are people ok with an objective of the small box and a threshold of the medium box.
- Aaron - The prototype won’t currently make that objective without additional disassembly.
- J - Could rest on how much disassembly we can tolerate. At more than a 50% reduction in shipping costs it’s a worthy goal.
- Chris - Thinks we can get the structure in the small box.
- Has been able to fit things in the flat rate envelopes that wouldn’t fit in the flat rate box.
- Juli - Some Air freight companies will often give bulk/volume discounts - or at least we did at Airborne.
- Chris - Has been looking at worst case shipping.
- Approve - Aaron, Chris, J, Greg, Juli, Jeremy, Debi-Lee