Presentation is loading. Please wait.

Presentation is loading. Please wait.

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,

Similar presentations


Presentation on theme: "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,"— Presentation transcript:

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

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

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

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

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

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

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

9 9 Good requirements with Subjective Content Good requirements with Subjective Content Use of should, might, higher, faster…. all are vague and subjective. 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 Conflicting Requirements Multiple Objectives for a Single Key Multiple Objectives for a Single Key Action: Create Separate Keys for each Objective Example: Velocity OR Acceleration Example: Size OR Weight Comparative Requirements Comparative Requirements Example: Shall be at least 20% Better than best available Goal: Avoid Common Pitfalls Goal: Avoid Common Pitfalls Avoid the Following: Writing Good Engineering Requirements…Communicating Inputs

10 10 Typical Examples The System shall fit a 95th percentile US Male Patient The System shall fit a 95th percentile US Male Patient The Theta Axis shall be capable of 2.10 radians/sec The Theta Axis shall be capable of 2.10 radians/sec Examples of Good Engineering Requirements The software architecture needs to be flexible and modular The software architecture needs to be flexible and modular The GUI shall be user friendly The GUI shall be user friendly Clear, however, subjective. Clear, however, subjective. Engineering or Customer Requirements? Engineering or Customer Requirements? Keep or Discard? Keep or Discard? Examples of Poor Engineering Requirements 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. 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. Example of a Good Requirement, Bad Input Goal: Clear AND Correct Input Goal: Clear AND Correct Input

11 11 Examples in Need of Repair

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

13 13 Example#2

14 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 Goal: Solicit Attendee Participation

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

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

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

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

19 19 References: Goal: Long Term Breadth and Depth Goal: Long Term Breadth and Depth 1.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. 2.Blanchard, Benjamin L. (1998). System Engineering Management, 2 nd edition: John Wiley & Sons, Inc. 3.Nuseibeh, B., Easterbrook, S. (2000). Requirements Engineering: A Roadmap, Proceedings of International Conference on Software Engineering, 4-11 June 2000, Limerick, Ireland. 4.Russo, A., Nuseibeh, B., and Kramer, J. (1999) Restructuring Requirements Specifications. Proceedings of IEEE: Software, 146(1): 44-53, February 1999. Writing Good Engineering Requirements…Communicating Input

20 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


Download ppt "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,"

Similar presentations


Ads by Google