v2.0 - SEP - Requirements

Added by Jeremy Wright about 9 years ago

I've pulled out the current structure related requirements for review below. After these are set we'll make another pass for the software requirements. Ideally, I'd like to have some discussion here so that we're well prepared to wrap these requirements up at the next Shepard focused Hangout.

Technical Requirements

  • STSR 1.1 The STS must accommodate low power, commercially available amateur rocket motors sized A through E.
  • STSR 1.2 The STS must be mobile enough to enable live demonstrations as part of educational and outreach activities.
    • STSR 1.2.1 The STS total weight shall be less than 25 pounds (11.3 Kg), or be able to break into components that weigh no more than 25 pounds (11.3 Kg) each (based on OSHA recommendations).
    • STSR 1.2.2 The STS must be transportable by 1 person.
  • STSR 4.1 The STS shall be easily set up and torn down for demonstration purposes.
    • STSR 4.1.1 Unpack and set up time should be less than 45 min.
    • STSR 4.1.2 Clean up and storage time should be less than 90 min.
  • STSR 4.2 The STS shall be easy to package for shipment to any event at which it will be used, meaning the whole test stand system shall fit in the backseat or trunk of a standard 4-door sedan.
    • STSR 4.5.1 IAW NAR testing manual requirements specified in Section 8.5.1, it must be possible to calibrate the load cell with a "NIST traceable weight standard such as an Instron". 1
    • STSR 4.5.3 The force sensor shall have a measurement range of no less than 33 Newtons.
  • STSR 4.6 Temperature sensor requirements
    • STSR 4.6.3 IAW (partial) NAR testing manual requirements specified in Section 8.6, a temperature sensor will be attached to the motor under test "where the propellant and nozzle meet" (the "throat" in Mach 30 parlance). 1 Full compliance with this requirement has been moved to the future requirements section below.

Project Requirements

  • STSR 2.1 The STS must be well documented so as to meet the needs of open source spaceflight designers who will design and build future test stands (at Mach 30 and elsewhere).
  • STSR 2.2 The STS documentation and procedures must be complete enough that Mach 30 operators, students and educators who want to bring rocket engineering into the classroom, and anyone else interested in how rockets are tested can learn how to use it.
  • STSR 2.3 The STS documentation must cover the engine testing procedure from test stand setup, to running tests, and ending with stowing the test stand.
  • STSR 3.3 The STS must be designed in a way that the structure can be slid down over a heavier object, such as a concrete block, to hold it in place. Whoever builds the test stand structure should not be required to permanently fasten it down to an object to keep it stationary.
  • STSR 3.4 The STS shall be operated IAW the safety procedures which are outlined in Section 8 of the NAR testing manual.
  • STSR 4.3 The STS shall provide a fixed base on which to test model rocket motors.
    • STSR 4.3.1 The test stand will remain stationary during motor firings.
    • STSR 4.3.2 The test stand components will not experience undo vibration during motor firings.
  • STSR 7.1 All STS design documentation must be open and complete enough so that ANYONE, without necessarily a technical education in rocketry, propulsion, or engineering, would be able to build and operate the test stand.
  • STSR 8.1 The design of the STS must enable the completion of at least one operational test stand.
  • STSR 8.2 Whenever and wherever possible, considerations should be made so that the design of this STS can be used as a kit in the future.
  • STSR 9.1 The cost of the first operational STS must not exceed $200 excluding "consumables" and tools.
  • STSR 10.1 If at all possible, the STS should be completed within 3 months of formal launch as an exercise in agile design.

Replies (6)

RE: v2.0 - SEP - Requirements - Added by J. Simmons about 9 years ago

Here are my thoughts (based on reviewing our revisions to the Initial Questions.

  • STSR 1.2 The STS must be mobile enough to enable live demonstrations as part of educational and outreach activities compact and light weight enough to accommodate shipping to conferences and other demonstration events or transporting up to ten copies in the same passenger car.
    • STSR 1.2.1 The STS total weight (structure and DAQ) shall be less than 25 5.0 pounds (11.3 2.7 Kg). , or be able to break into components that weigh no more than 25 pounds (11.3 Kg) each (based on OSHA recommendations). <- guessing at a revised weight, need to check Aaron's prototype weight to see if this is realistic
    • STSR 1.2.3 The STS structure shall be no larger than <insert reasonable dimensions to support low cost shipping here>
  • Strike STSR 4 or move the STSR 1.2.x requirements to STSR 4.x
  • STSR 4.6.4 The temperature sensor will have two mounting options: a) mounting for measurement of the case temperature as specified above, b) mounting for measuring the flame temperature
  • STSR 4.10 The motor mount must be able to survive catastrophic motor failure (eg motors exploding during a test)
    • STSR 4.10.1 The motor mount must not create metal or plastic shrapnel when exposed to an exploding motor during test
    • STSR 4.10.2 The motor mount must be repairable within 60 minutes after a motor explosion and repairs must cost less than $10 (US)
  • STSR 4.11 The STS structure will include space to display identifying marks (eg Mach 30 logo, STS logo, OSHW logo, etc) and safety information (eg warnings, safety instructions, etc)
  • STSR 8.1 The design of the STS must enable the completion of at least one operational test stand sale of dozens to hundreds of kits per year (and possibly more as demand warrants).
  • Strike STSR 8.2
  • STSR 9.1 The cost of the materials for the STS (not including consumables or user purchased computational equipment) must not exceed $80. <- the "computational equipment" is a backdoor to allow us to offload the price of the Arduino Uno from the kit price by making it a separate purchase like the PC.
  • STSR 10.1 The v2.0 prototype of the STS should be completed and undergo initial test firing no later than Dec 31, 2013.

OK, so I have not captured what it means to be "hackable" and I may have missed something else, but hopefully this gets the ball rolling.

RE: v2.0 - SEP - Requirements - Added by Jeremy Wright about 9 years ago

A couple things have come up as I've been working on this.

1. Our requirement statements usually only cover the "what", not the "why" or the "who". Should those aspects be included in the statements, or is that non-standard for a requirements document?
2. I think that J is touching on this in the comment to strike STSR 4 or move STSR 1.2.x, but I think that we've had some of our requirements placed under technical requirements that should be project requirements, and vice versa. Also, some requirements seem to be mapped to the wrong initial questions and our technical requirements don't always seem to have measurable (quantifiable) outcomes to them.

Below is an attempt I made on reorganization and the creation of templates to include the why, what, and who aspects. It only covers initial questions 1 through 3 and part of 4. Before I put any more time into it I want to see if I'm headed in the wrong direction.

As a reminder, technical requirements have measurable outcomes attached to them, and project requirements do not.

Q1. Why are we making this? (Project Requirements)

  • STSR 1.x The STS should [task/focus] so that [organization/individual] can [goal/accomplishment].

Example taken from the initial question:

  • STSR 1.1 The STS should focus on low power, commercially available amateur rocket motors so that Mach 30 and partner organizations can provide a safe first experience for both designers and operators.
  • STSR 1.2 The STS should provide a platform for performing live demonstrations so that Mach 30 and its educational partners can conduct educational and outreach activities.

Q2. Who is this for? (Project Requirements)

  • STSR 2.x The STS should provide a(n) [organization/individual] with [ability/activity] so that [goal/accomplishment].

Example taken from the initial question.

  • STSR 2.1 The STS should provide a middle school (6th through 8th grade in the U.S.) teacher who does not have the support of an IT department, and who does not have computer expertise beyond how to connect a USB cable and install software, with the ability to introduce their students to rocket science in a safe and hands-on way.
  • STSR 2.2 The STS should provide open source spaceflight designers with the ability to learn about measuring the performance of rocket motors in a low risk way so that they can progress to larger motors and engines safely.

Q3. How will this be used? (Project Requirements)

  • STSR 3.x The STS must allow [organization/individual] to [activity] so that [goal/accomplishment].
  • STSR 3.1 The STS must allow Mach 30 and its partner organizations to collect motor thrust and casing temperature data to be compared against the published Estes motor documentation so that test stand users know when their test has been run correctly.

Q4. What features does it need to have (now)? (Technical Requirements)

  • STSR 4.x The STS needs to [function] so that a user can [ability/activity].
  • STSR 4.1 The STS needs to provide a stable base on which to test rocket motors with a maximum of 35 Newtons of thrust so that a user I can reliably and safely measure motor thrust.
  • STSR 4.2 The STS nneds to accommodate Estes rocket motor sizes A through E with a peak thrust range of approximately 6 Newtons up to 33 Newtons so that a user can record measurements which can be compared against the published Estes documentation.

RE: v2.0 - SEP - Requirements - Added by J. Simmons about 9 years ago

Jeremy,

When I was working on my previous post, I started pondering some of the same questions you brought up. On reflection, I am starting to think the Initial Questions actually break down into three categories.

  • Project Background Questions - questions which help set the stage for the questions which turn into technical and project requirements. They are also good places to look for narrative which can be used in promotional material for the project. This would cover questions 1, 2, 3, & 7.
  • Technical Requirement Questions - questions which when answered lead to technical requirements (those that can be measured and deal with the performance of the hardware being developed). This covers questions 4, 5 (after a fashion, but I almost think this should become a question 4b with what we call question 4 being question 4a), & 6.
  • Project Requirement Questions - questions which when answered lead to project requirements (requirements are the remaining requirements which are not tied to specific performance values). This would cover questions 8, 9, 10, & 11.

Assuming something like this structure made sense to other people, I would want to discuss reorganizing the Initial Questions (including renumbering them) to look something like this:


<Project Name> Initial Questions vX.x

Project Background Questions

BQ1. Why are we making this?

BA1. ...

BQ2. Who is this for?

BA2. ...

BQ3. How will this be used?

BA3. ....

BQ4. Who's going to build this?

BA4. ...

Technical Requirement Questions

TQ1a. What features does it need to have (now)?

TA1a. The test stand needs to:

  • ....

TQ1b. What features does it need to have (later)?

TA1b. These features will not necessarily make it into any version of the project, but should be kept in mind for any of its larger sibling test stands later on.

  • ...

TQ2. What are the legacy requirements?

TA2. ...

Project Requirement Questions

PQ1. How many do we want to make?

PA1. ...

PQ2. What is the budget?

PA2. ...

PQ3. What is the timeline?

PA3. ...

PQ4. What waste products will be produced by the manufacture and/or operation of this?

PA4. ...


This would then naturally lead to a requirements document setup like this:


<Project Name> Requirements vX.x

Technical Requirements

  • TR 1.1 ....
  • TR 1.2 ....
  • TR 2.1 ....
  • TR 2.2 ....

Project Requirements

  • PR 1.1 ....
  • PR 1.2 ....
  • PR 2.1 ....
  • PR 2.2 ....
  • PR 3.1 ....
  • PR 3.2 ....
  • PR 4.1 ....
  • PR 4.2 ....

RE: v2.0 - SEP - Requirements - Added by Greg Moran about 9 years ago

Howdy all, This post was a conversation topic between J and I on the drive down to Las Cruces, NM. I'm really excited about this small (yet potentially impactful) tweak of the Initial Questions and the Requirements Document.

RE: v2.0 - SEP - Requirements - Added by Jeremy Wright about 9 years ago

I like where this is going. I think this structure addresses all of my concerns except whether or not to add the "who" and "why" to the existing wording of the requirements.

Do we want template sentences like I created above for people to reference when they're converting initial questions to requirements?

RE: v2.0 - SEP - Requirements - Added by J. Simmons about 9 years ago

Jeremy,

I am just now getting around to looking at your comment (attending conferences always makes it hard to keep up with communications). Requirements, as a rule of thumb, are inherently answer the whats of a project ("what must it do? what must it measure? what must it accept? what must it produce?). The who and why type questions are really about a different aspect of the project. And having captured the who and why in the initial questions, I don't think we need to capture them anywhere else.

As for why then do we have requirements to recapture the what type questions... We do this for requirements so we can add the next level of detail to the what type questions by including measurable performance specifications (preferably with both thresholds, minimum acceptable performance, and objectives, highly desired performance). Also, by capturing these measurable aspects of the hardware or management of the project in one place, we can more easily reference them when reviewing a project for completeness.

Hope that helps.

In terms of the template sentences, I think I missed your examples (this thread is getting pretty dense with all the formatting I threw in around the new layout of the questions and requirements docs). Can you comment on just that part below?

(1-6/6)