“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
1
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?
2
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
3
Viewpoint: Capital Medical Devices
GOAL: Describe viewpoints for definitions and terms
4
Part I: “Writing Good Engineering
Requirements…Communicating Input”
Content
 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….
5
“Writing Good Engineering
Requirements…Communicating Input”
Overview to Fundamental Process
Customer Input
Marketing Captures
“Need and Desire”
SE Interprets into
Quantified Engineering
Terms
Sub-System Requirements
Derived from Top Level System
Goal: Build a Thought Process for What and Why?
6
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
7
Specific Goals for Different
Requirements
 Customer (Marketing)
 Needs: “Must Have”
 Desires: “Nice to Have”
 What are we trying to Solve?
 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
8
“Writing Good Engineering
Requirements…Communicating Inputs”
Avoid the Following:
 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
9
Typical Examples
Examples of Good Engineering Requirements
 “The System shall fit a 95th percentile US Male Patient”
 “The Theta Axis shall be capable of 2.10 radians/sec”
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?
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
10
Examples in Need of Repair
11
Example 1: Steps to Improve
1.
2.
3.
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.
12
Example#2
13
HELP NEEDED
Systems Engineer needed to develop S/W
Requirements for Graphical User Interface.
Note: End Customers are luminary
Cardiologists who have strong opinions.
Goal: Solicit Attendee Participation
14
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
15
Point and Counterpoint
Point
 User Has Strong Desire for Appearance of GUI Icons.
We should specify the Customer’s Desire.
Counterpoint
 Subjective requirements are too difficult to quantify in a
specification. The requirements become a design
description.
Goal: Extract diverse viewpoints of audience
16
Point and Counterpoint
Point
 Software currently in field needs improvement,
why not use today’s version as a basis to
graphically show the desired new look?
Counterpoint
 Verification requires a testable requirement, how do you
test a “look and feel”.
Goal: Extract diverse viewpoints of audience
17
“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
18
“Writing Good Engineering
Requirements…Communicating Input”
References:
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, 2nd 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.
Goal: Long Term Breadth and Depth
19
“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
20