Systems Engineering and Requirements Management in Medical Device Product Development

Systems Engineering and R i t M tRequirements Management in Medical Device Product Development

Todd HansellTodd HansellDirector, Systems Design Quality AssuranceCovidienFebruary 16, 2012todd hansell@covidien [email protected]

COVIDIEN, COVIDIEN with logo, Covidien logo, positive results for life and ™ marked brands are U.S. and internationally registered trademarks of Covidien AG. R0027846

BackgroundTodd Hansell, Speaker• Director of Design Quality Assurance & Reliability Engineering

– Electrical and mechanical hardware– Software Quality and Design Assurance

A t t d t t t d l t– Automated test system development• Joined Covidien (formerly Valleylab) in 2003• Education:

– BSEE Purdue University, 1989– SW Engineering Masters Certificate, University of Colorado at

Boulder, 2004• Twenty-three years of experience in the automotive, industrial and

medical industries • Software engineering, software quality assurance, systems engineering,

technical management organizational process improvement risktechnical management, organizational process improvement, risk management

Covidien, Surgical Solutions Group• Market leader in radiofrequency (RF) electrosurgical generators and

instruments, vessel/tissue sealing technologies (RF and mechanical stapling)

• Soft tissue ablation technology (RF, microwave)• Boulder, Colorado, and North Haven, Connecticut

2 | 16 February 2012

What’s Been Advertised…

An overview of systems engineering and requirements management in medical device product development.

• What is systems engineering?• Systems engineering and the FDA• The role of the systems engineer in new product developmente o e o e sys e s e g ee e p oduc de e op e• Systems engineering maturity models and best practices• Requirements engineering and requirements management – the

foundation of systems engineeringTools and methods for systems engineering• Tools and methods for systems engineering

• Systems engineering and product quality• Systems verification and validation• Accelerating new product development with systems engineeringg p p y g g

3 | 16 February 2012

What is Systems Engineering?

What is a System?A combination of interacting elements organized to achieve one or more stated purposes (INCOSE) [1](INCOSE).[1]

What is Systems Engineering?Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies in a near optimal manner the full range ofoperation of a real world system that satisfies, in a near optimal manner, the full range of requirements for the system. (Eisner)

Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality y g q yearly in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule performance, training and support, test, manufacturing, and disposal. SE considers both the business and technical needs of all customers with the

l f idi li d h h d (INCOSE)goal of providing a quality product that meets the user needs.(INCOSE)

Differs from other specialist disciplines of engineering, focus on technical coordinationDiffers from other specialist disciplines of engineering, focus on technical coordination

4 | 16 February 2012

What Do Systems Engineers Do?

• Identification and quantification of system goals & requirements• Creation of alternative system design conceptsy g p• Performance of design trades• Selection and implementation of the best design

(balanced and robust)• Verification that the design is actually built and properly integrated in

accordance with specifications• Assessment of how well the system meets the goals

Best career in America (Money magazine 2009)Best career in America (Money magazine, 2009)•High median salary compared to other engineering disciplines•Predicted 45% growth over 1st half of this decade

5 | 16 February 2012

Why Do We Need Systems Engineering?Competitive pressures from the rapid advancement of integrated technologies• Increased product complexity• Reduction of product development cycle time

I d f t d l t i t• Increased safety and regulatory requirements• Globalization of the marketplace and workforce• Software as a dominant force of change in new products • Worldwide deployment of new technology on ever-shorter time scales

S t t t d f i ti t i t ll t l t• Systems constructed from pre-existing components or intellectual property• Re-use of components, information, and knowledge across projects• Transition from paper-based control to electronically managed information• The rise of intellectual capital as the primary asset of many modern organizations

6 | 16 February 2012

INCOSE Handbook, [2]

A Brief History of Systems Engineering

• Water Distribution Systems in Mesopotamia 4000 BC • Irrigation Systems in Egypt 3300 BC• Urban Systems such as Athens, Greece 400 BCy ,• Roman Highway Systems 300 BC• Water Transportation Systems like Erie Canal 1800s• Telephone Systems 1877• Electrical Power Distribution Systems 1880y• Systems engineering concepts at Bell Labs and in the military (World War II) 1900s • Term conceived at Bell Telephone Laboratories 1940• DOD applied systems engineering to missiles and missile defense 1940s• RAND Corporation (US Air Force) developed systems analysis 1946• ATLAS ICBM Program Managed by Ramo-Wooldridge Corp 1954-1964• Defense Systems Management College (DMSC) 1971• National Council on Systems Engineering 1990• International Council on Systems Engineering (INCOSE) 1995• 75 US 141 international universities offer systems engineering programs 2006• 75 US, 141 international universities offer systems engineering programs 2006

7 | 16 February 2012

Systems Thinking

Definition: The process of understanding how things influence one another within a wholewithin a whole

Foundation in the field of system dynamics by Jay Forester in 1956 at MIT• Applying engineering principles to social systems• Study interactions vs decomposition and constituent analysis

Basic Tenets• Interdependence of objects and their attributes - independent elements can never constitute a system • Holism - emergent properties not possible to detect by analysis should be possible to define by a holistic

approach G f• Goal seeking - systemic interaction must result in some goal or final state

• Inputs and Outputs - in a closed system inputs are determined once and constant; in an open system additional inputs are admitted from the environment

• Transformation of inputs into outputs - this is the process by which the goals are obtained • Entropy - the amount of disorder or randomness present in any system• Entropy - the amount of disorder or randomness present in any system • Regulation - a method of feedback is necessary for the system to operate predictably • Hierarchy - complex wholes are made up of smaller subsystems • Differentiation - specialized units perform specialized functions • Equifinality - alternative ways of attaining the same objectives (convergence) q y y g j ( g )• Multifinality - attaining alternative objectives from the same inputs (divergence)

8 | 16 February 2012

Weinberg, [4]

Why Use Systems Engineering?Develops, drives, implements, leads, standardizes, reuses, predicts, adapts, communicates, improves, analyzes…

1. Standardized deliverables2. Decomposition process of customer requirements3. System functionality that meets customer’s expectation4. Commitment to faster time to market5. Systems that can evolve with a minimum of redesign and cost6. Designs for systems reuse7. More predictable outcomes8. Products with adaptable, resilient systems9. Verified functionality with fewer defects10 I d i ti10. Improved communications

a. Across functionsb. Programsc. Teams

11 Managed complexity11. Managed complexity

Industry Data• Cost and schedule overruns minimized with >10% SE effort• Survey: Of the top eight reasons for project failures: five related to requirements, three to y p g p j q

management• See SEI (Software Engineering Institute for data on Systems Engineering process improvement)

9 | 16 February 2012

Systems Engineering and the FDA“Electronic, software, and systems engineering concerns lie at the heart of the problems encountered with most of the sophisticated new medical devices regulated by the Agency. A critical core of expertise has been developed in each of these areas to address Center needsneeds.

Historically, many device problems arise at the intersections of hardware and software, the user, the manufacturing process and the use environment. A broad range of analytical tools are available to systems engineering specialists to help them identify such problems and take reasonable steps to prevent or limit the problems and/or mitigate the consequences.

…The term system effectiveness has been used in industry to describe the range of concerns addressed by these analytical techniques, including the following:reliabilityreliability dependability maintainability manufacturability testability ser iceabilitserviceability capability safety engineering and risk management metrology “

See FDA web site: http://www.fda.gov/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/ucm126804.htm

10 | 16 February 2012

Systems Engineering ProcessSystems Engineering Process Life Cycle Models

11 | 16 February 2012

A Typical “Waterfall” Life Cycle Model

ConceptVoice of the customer, concept development, business plan

Feasibilityeas b tyDefinition of customer and system requirements, project plan and schedule

DevelopmentDevelop/implement/document product design, develop V&V strategy

QualificationExecute product V&V, validate manufacturing processes, prepare for volume production

CommercializationProduct launched, achieve stable production

Sustaining supportOngoing product changes, enhancements, address complaints, reliability

12 | 16 February 2012

The Systems Engineering V Model

User requirements

Validation Tests

Validation

System Requirements System Tests

Verification

Requirements

Integration Architectural VerificationDefining the d t

Integrating & verifying what has been b iltg

TestsDesignproduct been built

Abstract, early, formative,creative, conducive

Systems Engineering

Component Engineering

Component Development

Component Tests

to changeExpensive, realistic, late, difficult to change

Component Engineering

13 | 16 February 2012

Stevens, [6]

ISO /IEC 15288: 2008 Systems and Software E i i S t Lif C l PEngineering – Systems Life Cycle Processes

14 | 16 February 2012

INCOSE Handbook, [2]

Capability Maturity Model Integration (CMMI) (Version 1.3)Level Focus Process Area

5 Optimizing Continuous Process Improvement •Organizational Performance Management

•Causal Analysis and Resolution

4 Quantitatively Managed

Management by Metrics •Organizational Process Performance

•Quantitative Project Management

3 Defined Process Standardization •Requirements Development

•Technical Solution

•Product Integration

•Verification

•Validation

•Organizational Process Focus

•Organizational Process Definition + IPPD

•Organizational Training

•Integrated Project Management + IPPD

•Risk Management

•Decision Analysis and Resolution

2 Managed Basic Project Management •Requirements Management

•Project Planning

•Project Monitoring and Control

•Supplier Agreement Management

•Measurement and Analysis

•Process and Product Quality Assurance

•Configuration Management

1 Initial Individual Heroism •None15 |

CMMI Solid Foundations…

5Org. Perf. Mgmt

4Quantitative Project Management

Causal Analysis and Resolution

Requirements DevelopmentTechnical SolutionVerification

Organizational TrainingValidation

3

Organizational Process Performance

R i t M t P j t M it i d C t l

Product IntegrationVerification

Organizational Process Definition + IPPDOrganizational Process Focus

Risk Management

Integrated Project Management + IPPDDecision Analysis and Resolution

3

2Requirements Management

Project Planning

Project Monitoring and ControlSupplier Agreement ManagementMeasurement and Analysis

Process and Product Quality Assurance

Configuration Management 2

16 | 16 February 2012

Example: Requirements ManagementRequirements Management (REQM) – Maturity Level 2 (Process Management)

PurposeThe purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans andensure alignment between those requirements and the project s plans and work products.

Specific Practices by GoalSG 1 M R i tSG 1 Manage Requirements

– SP 1.1 Understand Requirements – SP 1.2 Obtain Commitment to Requirements – SP 1.3 Manage Requirements Changes

SP 1 4 M i t i Bidi ti l T bilit f R i t– SP 1.4 Maintain Bidirectional Traceability of Requirements – SP 1.5 Ensure Alignment Between Project Work and Requirements

17 |

Example: Requirements DevelopmentRequirements Development (RD)An Engineering process area at Maturity Level 3.

PurposePurposeThe purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

Specific Practices by GoalySG 1 Develop Customer Requirements

– SP 1.1 Elicit Needs – SP 1.2 Transform Stakeholder Needs into Customer Requirements

SG 2 Develop Product Requirements SP 2 1 E t bli h P d t d P d t C t R i t– SP 2.1 Establish Product and Product Component Requirements

– SP 2.2 Allocate Product Component Requirements – SP 2.3 Identify Interface Requirements

SG 3 Analyze and Validate Requirements – SP 3 1 Establish Operational Concepts and Scenarios– SP 3.1 Establish Operational Concepts and Scenarios – SP 3.2 Establish a Definition of Required Functionality and Quality Attributes – SP 3.3 Analyze Requirements – SP 3.4 Analyze Requirements to Achieve Balance – SP 3.5 Validate Requirements q

18 |

Benefits of Structured Process Improvement

Improvements• Cost• Schedule• Productivity• Quality• Customer Satisfaction

Risk ReductionRisk Reduction• Reduce risk of regulatory non-compliance

Reduce Frustration!• Lower turnover of key talentLower turnover of key talent

ROIOrganizations which have invested in CMMI-based process improvements have seen an ROI ranging from 2:1 to 13:1g g

See SEI web site: http://www.sei.cmu.edu/publications/documents/03.reports/03sr009.html

19 | 16 February 2012

CIMM – The Missing Levels (Humor)0 : Negligent0 : NegligentThe organization pays lip service, often with excessive fanfare, to implementing software engineering processes, but lacks the will to carry through the necessary effort. Whereas CMM level 1 assumes eventual success in producing software, CIMM level 0 organizations generally fail to produce any product, or do so by abandoning regular procedures in favor of crash programs.product, or do so by abandoning regular procedures in favor of crash programs.-1 : ObstructiveProcesses, however inappropriate and ineffective, are implemented with rigor and tend to obstruct work. Adherence to process is the measure of success in a Level -1 organization. Any actual creation of viable product is incidental. The quality of any product is not assessed, presumably on the assumption that if the proper process was followed, high quality is guaranteed.Paradoxically, Level -1 organizations believe fervently in following defined procedures, but lacking the will to measure the effectiveness of the procedures they rarely succeed at their basic task of creating software.2 C t t-2 : Contemptuous

While processes exist, they are routinely ignored by engineering staff and those charged with overseeing the processes are regarded with hostility. Measurements are fudged to make the organization look good. This is not a good environment to work in or be associated with.-3 : Undermining-3 : UnderminingNot content with faking their own performance, undermining organizations routinely work to downplay and sabotage the efforts of rival organizations, especially those successfully implementing processes common to CMM level 2 and higher. This is worst where company policy causes departments to compete for scarce resources, which are allocated to the loudest advocates.p ,

Schorsch, [7]

20 | 16 February 2012

(Over) Simplified View of Product DevelopmentE ti D i

Final ProductInnovation Domain

•Low uncertainty•Low risk

Execution Domain

•Safe and effective•Manufacturable•Reliable•Affordable

•Few defects•Few assumptions•“Hard” (physical prototypes)•Iteration is very expensive

ConceptualDesignModel (one of many!)

Mature Design Model •Quality System

•EngineeringProcessesHigh uncertainty Processes

•OperationsIdea•High uncertainty•High risk•Many assumptions•“Soft” (paper, electronic models)•Iteration is inexpensive

Systems Engineering

Process

Covidien | | Confidential

“Gain”

Systems Engineering and Quality:Systems Engineering and Quality: Verification

22 | 16 February 2012

Approaches to Systems Verification

A Quality Strategy must be integrated into entire life cycle• Systems Verification and Validation Plan

T bilit i t i d th h t• Traceability maintained throughout

Approaches to Verification• Inspectionspec o• Analysis• Demonstration• Test

Certification• Certification

Test Categories• Development Testp• Qualification Test• Acceptance Test• Operational Test

23 | 16 February 2012

The Systems Engineering ToolboxThe Systems Engineering Toolbox

24 | 16 February 2012

Systems Engineering Tools

INCOSE Tools Taxonomy

http://www incose org/productspubs/products/setools/tooltax/se tools taxonomy htmlhttp://www.incose.org/productspubs/products/setools/tooltax/se_tools_taxonomy.html

25 | 16 February 2012

SE – Engineering Tools

•System Design Tools•Structural and Behavioral modeling, UI prototyping

•Requirements Engineering ToolsRequirements capture traceability•Requirements capture, traceability

•Design Validation Tools•Specialty Engineering Tools

•Reliability Engineering, Failure Analysis, DFx

26 | 16 February 2012

Useful Tools – Some ExamplesRequirements Management Tools

• Examples: IBM DOORS™, ReqPro™, etc. • Features:

• Requirements Database (usually object-oriented)q ( y j )• Requirements can have attributes and links• Supports document generation, automates traceability management• Enables information-centric vs document-centric view of project information

System Modeling ToolsSystem Modeling Tools• Examples: Enterprise Architect™, IBM Rhapsody™, Altova UModel™, etc. • Features:

• Implement UML or SysML(Systems Modeling Language)•SysML – tailored for systems engineeringy y g g•See http://www.omgsysml.org for more information

• Executable models, systems analysis, software code generation

27 | 16 February 2012

Systems Engineering and the SafetySystems Engineering and the Safety Risk Management Process

28 | 16 February 2012

When Risks Go Unconsidered in Medical Devices…

The Therac-25 DisasterMedical linear accelerator for tumor treatment• Based upon previously successful hardware-based design• Based upon previously successful, hardware-based design• Software controlled safety system (cost savings)• Low- and high-power modes• Timing problems with command response caused patient to be treated with

125 times intended radiation dosageg• Six deaths• Causes:

– Poor, incomplete testing and quality strategy– Failure to properly assess old software when applied to new equipment

Poorly designed error and warning messages– Poorly designed error and warning messages– Did not fix or understand recurring problems– Hardware backups for safety system– LACK OF SOUND SYSTEMS ENGINEERING!

• For more details, see the landmark paper by Nancy Leveson, Therac-25 , p p y y ,Accidents: An Updated Version of the Original Accident Investigation Paperwww.cs.washington.edu/research/projects/safety/www/therac-25.html

29 | 16 February 2012

ISO 14971:2007 – Harmonized Standard for Ri k M tRisk Management

“… provides manufacturers with a framework within which experience, insightframework within which experience, insight and judgment are applied systematically to manage risks associated with the use of medical devices.”

“… a self-improving process through which the manufacturer must use knowledge gained post-production to improve and refine the safety of the device ”refine the safety of the device.”

Compliance with this standard is rapidly becoming a general requirement of regulatory bodies worldwide.regulatory bodies worldwide.

30 | 16 February 2012

IEC 60601-1:2005 (3rd Edition)A New Standards ParadigmA New Standards Paradigm

A Risk-Based Approach to Medical Device Safety • Requirements can be tailored to the realities of a particular device and its intended use based

upon assessed riskupon assessed risk. – Some requirements may be waived altogether (with justification)– In cases of high safety risk, device must meet requirements beyond what the standard

specifiesI t t t t b d t i d b d f t i k– In many cases, test parameters must be determined based upon safety risk (vs. prescribed test parameters)

• Requires an intimate understanding of the design and functionality of the device being assessed

• Requires a risk management process compliant with ISO14971:2007.– Risk management file becomes a central repository for critical verification information

and decision-making• More than 100 references where the application of a clause modification of a test protocol orMore than 100 references where the application of a clause, modification of a test protocol or

provision of a safety feature are dependent upon a documented risk analysis. The Result: A flexible standard that is much easier to adapt to changing technology, with a higher (but appropriate!) burden of responsibility on the device manufacturer to demonstrate the

f t f it d isafety of its device.The Impact: Compliance required for international certifications June, 2012 (FDA June, 2013)

31 | 16 February 2012

Other Risk-Based Standards for Medical Devices

ISO 13485:2003 Quality Management Systems

• “The organization shall establish documented requirements for risk management throughout

product realization. Records arising from risk management shall be maintained.”

ISO 62304:2006 Medical Device Software

• Explicitly requires a formal risk management process (14971-compliant) to be applied at

many stages in the software development lifecycle

• Standard recently recognized by the FDA

GAMP 5 (ISPE 2008): Risk Based Approach to Compliant GxP Computerized SystemsGAMP 5 (ISPE – 2008): Risk-Based Approach to Compliant GxP Computerized Systems

Stay tuned. More are on the way!

Bottom line – Adopting a risk-based approach to product development and verification is really the only option!

32 | 16 February 2012

A Risk-Driven Process …An integrated risk management process is essential to successful medical device development.

Risk analysis (fault tree) Product

i tRisk-based

Risk-based Methods

Design FMEA

Process FMEA

requirementsstandards

(e.g., 14971, 60601-1,

62304 etc )

Safety requirements(incl. 60601-1 & particular stds.)

Product design

specifications

Application FMEA

62304, etc.)Functional

requirements

Product verification tests

33 | 16 February 2012

Creating Good RequirementsCreating Good Requirements

34 | 16 February 2012

Why requirements?

Provide a means to formally verify and validate that our devices are safeProvide a means to formally verify and validate that our devices are safe, effective, and reliable.

Communicate voice of customer to the design team.

35 | 16 February 2012

Definition of Requirement

In engineering, a requirement is a singular documented need of what a particular product or service should be or perform. p p p

A derived or technical requirement is a distinct testable verifiable characteristic or attribute of a system, system element, or system structural componentcomponent.

A requirement is captured in a single complete sentence.A requirement sentence is written as a SHALL statement.A derived requirement is verifiable.

– A met need or met intended use is validated.

36 | 16 February 2012

Verification

Verification is the process which makes sure that what was built matches the requirements. Was the system built the way the requirements and design q y y q gspecified?

Was the system built “right”?Was the system built right ?

37 | 16 February 2012

Validation

Validation determines if the system being developed will meet the intendedValidation determines if the system being developed will meet the intended needs of the system’s owner and stakeholders when completed. Does the system solve the problem or issue that it was intended to solve? Does it solve it to the expected extent?

Validation answers the question…

Was the “right” system built?

38 | 16 February 2012

Communicating - Decomposition

Customer Requirements

Marketing ‘Needs & Desires’RequirementsRequirements

Systems Engineering Decomposes Customer/Marketing ReqtsCustomer/Marketing Reqts.Into Top-level Systems Requirements

Sub system RequirementsSub-system RequirementsDerived from Top-levelRequirements

39 | 16 February 2012

Communicating

Customer Requirements

Usability

Cus o e equ e e s

Marketing ‘Needs & Desires’R i t

Prototype/Mock-up

Requirements

Systems Engineering Decomposes Customer/Marketing RequirementsInto Systems Requirements

Sub system RequirementsSub-system RequirementsDerived from Top-levelRequirementsTechnical

Development (Tech Dev) Sustainability

40 | 16 February 2012

Requirement Goal - Traceability

Customer/Marketing – Define Stakeholders• Needs: “Must Have”

D i “Ni t H ” “D li ht ”• Desires: “Nice to Have”, “Delighters”

System• Translate Customer Requirements to Engineering Requirements a s a e Cus o e equ e e s o g ee g equ e e s• Convert Subjective to Objective• Communication Tool – Customer to Development Team,

Verification Method (Test) Team Validation Team

Sub-System• Higher Resolution• Specific to Function/Sub-systemp y• Communication Tool – Sub-Contractor, Verification Method (Test) Team

41 | 16 February 2012

Requirements Gathering Phase

• Decompose requirements (derived requirements)

B i t / di i t• Brainstorm / discover requirements

• Capture Standards Requirements

• Ensure all regulatory, project-specific physical requirements are captured

42 | 16 February 2012

Requirements Analysis Phase

• Derive safety requirements from risk management plan

• Organize and Scrub requirements

• !! Delete orphan requirements !!

• Review & validate requirements

43 | 16 February 2012

Requirements Analysis Phase

• Iterate and maintain requirements

• Baseline requirements (sets)

• Release requirements

• Iterate throughout the product development life cycle• Iterate throughout the product development life cycle

• Apply change control to requirements – CCB!

44 | 16 February 2012

Requirements Analysis Process

45 | 16 February 2012

5 Principles for Good Requirements

1. Communicate Input to Design– WHAT are we solving? Not why… not how…g y– Does the cross-functional team understand requirement?

2. Verifiable– Verification is possible by a Verification Method(s);

TEST similarity analysis inspection demonstration observationTEST, similarity, analysis, inspection, demonstration, observation– Safety and criticality should determine a requirement’s

verification method.– Is a statement a requirement if it cannot be verified?

3. Requirements are Focused – audience is known4. Avoid constraining the designers5. Free of Specific Design Content – NOT a specification, NOT a

design solution / design outputdesign solution / design output

46 | 16 February 2012

Questions to ask…

• Is the requirement correct?

• Is the requirement verifiable?• Is the requirement verifiable?

• Is the requirement clear?

• Is the requirement consistent?

• Is the requirement feasible?

47 | 16 February 2012

Telelogic DOORS, [8]

Writing Good Requirements

• Avoid and/or conjunctions (one at a time)

The system shall operate at a power level of...

The software shall • Avoid exceptions (but, unless, except)

• Define verifiable criteria or expected result

s f sacquire data from…

The structure shall withstand loads of…

• Organize related requirements

• Group together related derived requirements

G t th i t i t i t d l ( id th 800

s s f

• Group together requirements into appropriate modules (avoid the 800-page document!)

• Avoid kitchen sink syndrome

• Requirements define “what” – not “how”, not “why”

48 | 16 February 2012

Examples – Good/Bad/Ugly

Good• The Theta Axis shall be capable of 2.10 radians/sec.

Bad• The software (SW) architecture needs to be flexible and modular.

Ugly• The User Interface (UI) shall produce a system response within 10

milliseconds (msec) of contact by user.– Good intention bad input; what is a response?Good intention, bad input; what is a response?– The user may not be capable of noticing a difference between 10

msec and 200 msec. The requirement may overly constrain the design team.

Document “why” the constraint

49 | 16 February 2012

Negative (Anti-) RequirementsNegative requirements should not be written as a general rule.

Examples:

The device software shall not fail.

The device software shall not activate energy when a non-recoverableerror is present.

Better:

The device software shall allow for 96 hours of continuous operation.

The device software shall inhibit energy delivery after occurrence of a non-recoverable error.

• Why? Burden of proof is greater for a negative requirement Proving aWhy? Burden of proof is greater for a negative requirement. Proving a negative requirement may be altogether impossible.

50 | 16 February 2012

Requirement QualifiersQualifiers follow an ‘if then construct’

Example of one too many qualifiers:

During energy activation, if the user releases the activation switch before sealing has been determined to be successfully completed, the generator software shall deactivate energy via the reactivate alarm.

Better:Better:If the user releases the activation switch before end of seal, the generator software shall deactivate energy.

Best:The device software shall deactivate RF within the 80 millisecond period after a switch release.

The device software shall issue a reactivate alarm within the 500 millisecond period after an earlyswitch release.

• Minimize number of qualifiers by deriving / separating requirements if possible.

• Simplify the qualifier as much as possible, requirement does not serve as a detailed design specification.

51 | 16 February 2012

Steps to Improve Requirements Writing

•Establish Purpose for Requirement

•Delete Superfluous Information•Delete Superfluous Information

•Divide and Redefine for Clarity

•Scrub with a small team early & often before formal review

The Theta Axis shall be capable of 2.10 radians/sec.

52 | 16 February 2012

Systems Engineering Resources

1. International Council on Systems Engineering: www.incose.org

2 INCOSE Systems Engineering Handbook v3 2 1 INCOSE 20112. INCOSE Systems Engineering Handbook v3.2.1, INCOSE, 2011.

3. Blanchard BS., Fabrycky WJ. Systems Engineering and Analysis, 5th edition. Prentice

Hall, 2010.

4. Weinberg, G. An Introduction to General Systems Thinking. Dorset House, 2001.

5. ISO/IEC 15288:2008: Systems and Software Engineering – System Life Cycle

Processes.

6. Stevens R., Brook P., Jackson K., Arnold S. Systems Engineering: Coping with

Complexity. Prentice Hall, 1998.

7 Schorsch T The Capability Im Maturity Model (CIMM) U S Air Force CrossTalk7. Schorsch T. The Capability Im-Maturity Model (CIMM), U.S. Air Force. CrossTalk

Magazine, 1996.

8. Telelogic DOORS Get It Right The First Time: Writing Better Requirements. IBM,

2008.

53 | 16 February 2012

Questions?

54 | 16 February 2012

THANKS!THANKS!For your attention and patience!

55 | 16 February 2012