90 likes | 245 Views
Specifications. Specifications communicate the original design goals to various audiences All design goals must be supported by one or more specifications Functional Spec Describes what the product should do User Interface Describes how the user interacts with the product
E N D
Specifications • Specifications communicate the original design goals to various audiences • All design goals must be supported by one or more specifications • Functional Spec • Describes what the product should do • User Interface • Describes how the user interacts with the product • Technical Interfaces • Describes how other devices interact with the project
Design team This is their job description Management Informs them of what exactly their engineers are doing Marketing/Sales Used to prepare marketing material and sales pitches. FS compared with market needs QA Form a test plan and test your product to match specs. Can’t test what you don’t spec. Documentation Writes the user documentation based on FS. Potential Customers Selected customers will preview the spec to verify it meets their needs Who Reads a Specification?
Specs are Specific • Specifications are concise descriptions of exactly what the product must do • Shall and Will are commonly used • Avoid: Sort-of Might Should Could Hope • Good Specs • The RT-2200 shall have a button that starts the process of downloading data via the USB port. • The SnorkTop shall sample data at a minimum rate of 100 samples per second. • Bad Specs • We hope that the iron-nator can detect iron really well. • We were thinking that it would be really awesome of the AT-BST could interact with a digital camera or something like that.
Goals and Specifications • For all of the design goals/criteria from your design matrix plus others needed: • Describe how your product will meet the design goal (probably multiple ways) • Be specific – use numbers • Each must be measurable - testable • These form your product requirements • Requirements • Specifications you and your customer agree on • Contractual agreement • Options and Add-ons • Non-contractual goals
Goals/Specs Example • Spec 3: Range. The Hg detector shall report Hg vapor levels in the range 0.100 ug/m3 to 100ug/m3. • Goal (for Hg meter): The measurements provided by the Hg detector will be useful for public health and scientific professionals. • Spec 1: Accuracy. The Hg detector shall consistently report Hg levels within +/- 0.25% of known reference values throughout its range of operation. (Note: Accuracy tests compare reported value to reference values.) • Spec 2: Precision. The Hg detector shall report three significant digits throughout its range. (Note: Precision tests look at sensitivity. If the Hg level is changed by one count in the third most significant digit, the meter’s third most significant digit will also change by one count.)
Tricky Goals • Some of the goals from your design matrix may be difficult to write in specific form • Goal: The product has a great “wow” factor. • Goal: We don’t want to work too hard. • Best solution - Write a series of specs that achieve your goal • Specify certain user interface/mechanical interface features that produce a great “wow” factor • Next best solution – Designate certain goals as relevant only to the initial design decision • Identify any “ignored” goals and obtain permission of management/instructor
Changes to Specifications • Sometimes the spec has to change • Impossible requirements • Schedule slippage • New features • Design tradeoffs • Changes must follow a process • Formal change request (written document) • Approved by all interested parties • Communicated to all of the many audiences
Wait!! I’m Just Getting Started • The First Specification is a “draft” specification • Specifications may be looser (but try your best) • Specs may be changed relatively easy, with the instructors’ permission • Final Spec is due later in the quarter • Need to be complete and precise • Permission to change the final spec will be difficult to attain