“Writing Good Engineering Requirements…Communicating Input” Part I of a III Part Series on RE

1. “Writing Good Engineering Requirements…Communicating Input”Part I of a III Part Series on RE By Seth D. Burgett Systems Architect MR 05-016 Stereotaxis, Inc. September 26, 2005

2. Discussions on Requirements Engineering (RE) Goal: Value to Attendee – Immediate and Long Term Example of Good Practices Catalyst for Self Study in Breadth and Depth Provide Sources for Reference Ignite Desire to Pursue Knowledge in RE Tool for Evaluation: Why is this function important? What is being solved? What is Value?

3. Discussions on Requirements Engineering (RE) Part I: “Writing Good Engineering Requirements…”> DELIVERABLE: Clear Input Part II: “Extracting Customer Needs and Desires”> DELIVERABLE: Correct Input Part III: “Allocation of Sub-System Requirements”> DELIVERABLE: Communicate to Team GOAL: Visualize RE as a Tool for Communicating

4. Viewpoint: Capital Medical Devices GOAL: Describe viewpoints for definitions and terms

5. Content Part I: “Writing Good Engineering Requirements…Communicating Input” Overview To Communication of Input 5 Principles to Good Engineering Requirements Specific Goals for Different Requirements Customer System Sub-Systems Avoid Common Pitfalls Examples: Good, Bad and Good with Bad Input Next Session: “How do we know we are Specifying the Correct Input?” > Good Requirements, Bad Input….

6. “Writing Good Engineering Requirements…Communicating Input” SE Interprets into Quantified Engineering Terms Customer Input Marketing Captures “Need and Desire” Overview to Fundamental Process Sub-System Requirements Derived from Top Level System Goal: Build a Thought Process for What and Why?

7. 5 Principles to Good Requirements 1. Communicate Input to Design What are we solving? Why is this function important? Clarity to Cross-Functional Team 2. Measurable & Testable Verification and Validation are Possible Subjective Requirements cannot be Verified 3. Requirements are Focused Audience for Requirement is known 4. Provide Value to Development Based on Need: Answer WHY? 5. Free of Specific Design Content

8. Customer (Marketing) • Needs: “Must Have” • Desires: “Nice to Have” • What are we trying to Solve? Specific Goals for Different Requirements • System (Top Level Engineering) • Translate Customer Input to Engineering Rqmts • Convert Subjective to Objective • Conduit for Communication: • Customer to Development Team • Sub-System (Engineering) • Higher Resolution • Specific to a Functional Domain • Often Communication Tool for Sub-Contractor • Direct Communication to Test Team Goal: Communication of Customer’s Problem Statement

9. Avoid the Following: “Writing Good Engineering Requirements…Communicating Inputs” Good requirements with Subjective Content Use of “should, might, higher, faster….” all are vague and subjective. Action: Use Positive and Objective Terms. Example: “Shall move at 100 meters per second”. Conflicting Requirements Multiple Objectives for a Single Key Action: Create Separate Keys for each Objective Example: Velocity OR Acceleration Example: Size OR Weight Comparative Requirements Example: “Shall be at least 20% Better than best available” Goal: Avoid Common Pitfalls

10. Examples of Good Engineering Requirements Typical Examples Examples of Poor Engineering Requirements • “The software architecture needs to be flexible and modular” • “The GUI shall be user friendly” • Clear, however, subjective. • Engineering or Customer Requirements? • Keep or Discard? “The System shall fit a 95th percentile US Male Patient” “The Theta Axis shall be capable of 2.10 radians/sec” Example of a Good Requirement, Bad Input • “The User Interface shall produce a system response within 10 milliseconds of contact by user” • The user may not be capable of noticing a difference between 10 mseconds and 200 mseconds. The example is “gold plating” of requirements, overly constraining the Development Team. Goal: Clear AND Correct Input

11. Examples in Need of Repair

12. Example 1: Steps to Improve • Establish Purpose for Requirement: Core Value • Delete Superfluous information • Divide and Redefine for Clarity • To be effective, the Developer should be able to quickly establish Purpose, Functionality and Exceptions.

13. Example#2

14. Systems Engineer needed to develop S/W Requirements for Graphical User Interface. Note: End Customers are luminary Cardiologists who have strong opinions. HELP NEEDED Goal: Solicit Attendee Participation

15. Design Description vs. Design Requirements • Graphical User Interfaces • Objective Requirements for a Subjective Arena • Describe the intended design to Software Developers • Define the needed functions with a “look and feel” • Dissect an Example Case • Input from Audience on Best Practices • PLEASE HELP! Goal: Better approach for GUI Requirements

16. Point • User Has Strong Desire for Appearance of GUI Icons. • We should specify the Customer’s Desire. • Counterpoint Point and Counterpoint • Subjective requirements are too difficult to quantify in a specification. The requirements become a design description. Goal: Extract diverse viewpoints of audience

17. Point • Software currently in field needs improvement, why not use today’s version as a basis to graphically show the desired new look? • Counterpoint Point and Counterpoint • Verification requires a testable requirement, how do you test a “look and feel”. Goal: Extract diverse viewpoints of audience

18. “Writing Good Engineering Requirements…Communicating Input” Closing Statements • Communication Media: User Input to Design • Attempt to understand viewpoint of audience • Value to Development Program Goal: Value to Attendee

19. “Writing Good Engineering Requirements…Communicating Input” References: Bahill, A.T., Dean, F., (1997). Discovering system requirements. Note: A paper similar to this has been published by: Bahill, A.T. and Dean, F., Discovering system requirements, Chapter 4 in the Handbook of Systems Engineering and Management, A.P. Sage and W.B. Rouse (Eds), John Wiley & Sons, 175-220, 1999. Blanchard, Benjamin L. (1998). System Engineering Management, 2nd edition: John Wiley & Sons, Inc. Nuseibeh, B., Easterbrook, S. (2000). Requirements Engineering: A Roadmap, Proceedings of International Conference on Software Engineering,4-11 June 2000, Limerick, Ireland. Russo, A., Nuseibeh, B., and Kramer, J. (1999) Restructuring Requirements Specifications. Proceedings of IEEE: Software, 146(1): 44-53, February 1999. Goal: Long Term Breadth and Depth

20. “Writing Good Engineering Requirements…Communicating Inputs” Contact Information: Seth D. Burgett Systems Architect Stereotaxis, Inc. 4041 Forest Park Ave St. Louis, MO 63108 sburgett@charter.net