11

““Writing Good Engineering Writing Good Engineering Requirements…Communicating Input”Requirements…Communicating Input”

Part I of a III Part Series on REPart I of a III Part Series on RE

ByBy

Seth D. BurgettSeth D. Burgett

Systems ArchitectSystems Architect

MR 05-016MR 05-016

Stereotaxis, Inc.Stereotaxis, Inc.

September 26, 2005September 26, 2005

22

Example of Good Practices Example of Good Practices Catalyst for Self Study in Breadth and Catalyst for Self Study in Breadth and DepthDepth

Provide Sources for ReferenceProvide Sources for Reference Ignite Desire to Pursue Knowledge in REIgnite 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:Goal: Value to Attendee – Immediate and Long Value to Attendee – Immediate and Long TermTerm

Discussions on Discussions on Requirements Engineering (RE)Requirements Engineering (RE)

33

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 CommunicatingGOAL: Visualize RE as a Tool for Communicating

Part III: “Allocation of Sub-System Requirements” > DELIVERABLE: Communicate to Team

Discussions on Discussions on Requirements Engineering (RE)Requirements Engineering (RE)

44

Viewpoint: Capital Medical DevicesViewpoint: Capital Medical Devices

GOAL: Describe viewpoints for definitions and GOAL: Describe viewpoints for definitions and termsterms

55

Part I: “Writing Good Engineering Part I: “Writing Good Engineering Requirements…Communicating Requirements…Communicating

Input”Input”

Overview To Communication of InputOverview To Communication of Input 5 Principles to Good Engineering Requirements5 Principles to Good Engineering Requirements Specific Goals for Different RequirementsSpecific Goals for Different Requirements

CustomerCustomer System System Sub-SystemsSub-Systems

Avoid Common PitfallsAvoid Common Pitfalls Examples: Good, Bad and Good with Bad InputExamples: Good, Bad and Good with Bad Input

ContentContent

Next Session: Next Session: ““How do we know we are Specifying the Correct Input?”How do we know we are Specifying the Correct Input?” > Good Requirements, Bad Input….> Good Requirements, Bad Input….

66

Overview to Fundamental ProcessOverview to Fundamental Process

Goal:Goal: Build a Thought Process for What and Why? Build a Thought Process for What and Why?

““Writing Good Engineering Writing Good Engineering Requirements…Communicating Requirements…Communicating

Input”Input”

Customer Input

Marketing Captures “Need and Desire”

SE Interprets into Quantified Engineering

Terms

Sub-System Requirements Derived from Top Level System

77

5 Principles to Good 5 Principles to Good RequirementsRequirements

1. Communicate Input to Design1. 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 TeamClarity to Cross-Functional Team

2. Measurable & Testable2. Measurable & Testable Verification and Validation are PossibleVerification and Validation are Possible Subjective Requirements cannot be VerifiedSubjective Requirements cannot be Verified

3. Requirements are Focused 3. Requirements are Focused Audience for Requirement is knownAudience for Requirement is known

4. Provide Value to Development4. Provide Value to Development Based on Need: Answer WHY? Based on Need: Answer WHY?

5. Free of Specific Design Content5. Free of Specific Design Content

88

Specific Goals for Different Specific Goals for Different RequirementsRequirements

Goal:Goal: Communication of Customer’s Problem Statement Communication of Customer’s 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 RqmtsTranslate Customer Input to Engineering Rqmts Convert Subjective to ObjectiveConvert Subjective to Objective Conduit for Communication:Conduit for Communication:

Customer to Development TeamCustomer to Development Team Sub-System (Engineering)Sub-System (Engineering)

Higher ResolutionHigher Resolution Specific to a Functional DomainSpecific to a Functional Domain Often Communication Tool for Sub-ContractorOften Communication Tool for Sub-Contractor Direct Communication to Test TeamDirect Communication to Test Team

99

Good requirements with Subjective ContentGood 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.Action: Use Positive and Objective Terms.Example: “Example: “ShallShall move at 100 meters per second”. move at 100 meters per second”.

Conflicting RequirementsConflicting Requirements Multiple Objectives for a Single KeyMultiple Objectives for a Single Key

Action: Create Separate Keys for each ObjectiveAction: Create Separate Keys for each ObjectiveExample: Velocity Example: Velocity OROR Acceleration AccelerationExample: Size Example: Size OROR Weight Weight

Comparative RequirementsComparative RequirementsExample: “Shall be at least 20% Better than best Example: “Shall be at least 20% Better than best

available”available”

Goal:Goal: Avoid Common Pitfalls Avoid Common Pitfalls

Avoid the Following:Avoid the Following:

““Writing Good Engineering Writing Good Engineering Requirements…Communicating Requirements…Communicating

Inputs”Inputs”

1010

Typical ExamplesTypical 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 The software architecture needsneeds to be to be flexible and flexible and modularmodular”” “ “The GUI shall be The GUI shall be user friendlyuser 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 The User Interface shall produce a system response within 10 milliseconds of contact by user”within 10 milliseconds of contact by user”

The user may not be capable of noticing a difference The user may not be capable of noticing a difference between 10 mseconds and 200 mseconds. The example between 10 mseconds and 200 mseconds. The example is “gold plating” of requirements, overly constraining is “gold plating” of requirements, overly constraining the Development Team.the Development Team.

Example of a Good Requirement, Bad Input

Goal:Goal: Clear AND Correct Input Clear AND Correct Input

1111

Examples in Need of Examples in Need of RepairRepair

1212

Example 1: Steps to ImproveExample 1: Steps to Improve

1.1. Establish Purpose for Requirement: Core ValueEstablish Purpose for Requirement: Core Value

2.2. Delete Superfluous informationDelete Superfluous information

3.3. Divide and Redefine for Clarity Divide and Redefine for Clarity To be effective, the Developer should be able to quickly quickly

establish Purpose, Functionality and Exceptions.establish Purpose, Functionality and Exceptions.

1313

Example#2Example#2

1414

Systems Engineer needed to develop Systems Engineer needed to develop S/W Requirements for Graphical User S/W Requirements for Graphical User Interface. Interface.

Note: End Customers are luminary Note: End Customers are luminary Cardiologists who have strong Cardiologists who have strong opinions.opinions.

HELP NEEDEDHELP NEEDED

Goal:Goal: Solicit Attendee Participation Solicit Attendee Participation

1515

Goal:Goal: Better approach for GUI Requirements Better approach for GUI Requirements

Graphical User Interfaces Objective Requirements for a Subjective ArenaObjective Requirements for a Subjective Arena Describe the intended design to Software DevelopersDescribe 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 PracticesInput from Audience on Best Practices PLEASE HELP!PLEASE HELP!

Design Description vs. Design RequirementsDesign Description vs. Design Requirements

1616

Goal:Goal: Extract diverse viewpoints of audience Extract diverse viewpoints of audience

Point and CounterpointPoint and Counterpoint

CounterpointCounterpoint

PointPoint

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 Customer’s Desire.

1717

Goal:Goal: Extract diverse viewpoints of audience Extract diverse viewpoints of audience

Point and CounterpointPoint and Counterpoint

CounterpointCounterpoint

PointPoint

Verification requires a testable requirement, how do you test a “look and feel”.

Software currently in field needs improvement, why not use today’s version as a basis to graphically show the desired new look?

1818

Closing StatementsClosing Statements

Goal:Goal: Value to Attendee Value to Attendee

Communication Media: User Input to DesignCommunication Media: User Input to Design Attempt to understand viewpoint of audienceAttempt to understand viewpoint of audience Value to Development ProgramValue to Development Program

““Writing Good Engineering Writing Good Engineering Requirements…Communicating Input”Requirements…Communicating Input”

1919

ReferencesReferences::

Goal:Goal: Long Term Breadth and Depth Long Term Breadth and Depth

1.1. Bahill, A.T., Dean, F., (1997). Bahill, A.T., Dean, F., (1997). Discovering system requirements. Discovering system requirements.

Note: A paper similar to this has been published by: Bahill, A.T. and Dean, F., Discovering 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, 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.A.P. Sage and W.B. Rouse (Eds), John Wiley & Sons, 175-220, 1999.

2.2. Blanchard, Benjamin L. (1998). Blanchard, Benjamin L. (1998). System Engineering Management,System Engineering Management, 2 2ndnd edition: John Wiley & edition: John Wiley & Sons, Inc.Sons, Inc.

3.3. Nuseibeh, B., Easterbrook, S. (2000). Nuseibeh, B., Easterbrook, S. (2000). Requirements Engineering: A Roadmap, Requirements Engineering: A Roadmap, Proceedings of Proceedings of International Conference on Software Engineering,International Conference on Software Engineering, 4-11 June 2000, Limerick, Ireland. 4-11 June 2000, Limerick, Ireland.

4.4. Russo, A., Nuseibeh, B., and Kramer, J. (1999)Russo, A., Nuseibeh, B., and Kramer, J. (1999) Restructuring Requirements Specifications. Restructuring Requirements Specifications. Proceedings of IEEE: SoftwareProceedings of IEEE: Software, 146(1): 44-53, February 1999., 146(1): 44-53, February 1999.

““Writing Good Engineering Writing Good Engineering Requirements…Communicating Input”Requirements…Communicating Input”

2020

““Writing Good Engineering Writing Good Engineering Requirements…Communicating Requirements…Communicating

Inputs”Inputs”

Contact Information:Contact Information:

Seth D. BurgettSeth D. Burgett

Systems ArchitectSystems Architect

Stereotaxis, Inc.Stereotaxis, Inc.

4041 Forest Park Ave4041 Forest Park Ave

St. Louis, MO 63108St. Louis, MO 63108

sburgett@charter.netsburgett@charter.net