Systems Engineering and Requirements Management in Medical Device Product Development


Published on

Todd Hansell, Medical Devices QA Director Covidien

Published in: Technology, Business

Systems Engineering and Requirements Management in Medical Device Product Development

  1. 1. Systems Engineering and R i t M tRequirements Management in Medical Device Product Development Todd HansellTodd Hansell Director, Systems Design Quality Assurance Covidien February 16, 2012 todd hansell@covidien 303-530-6306 COVIDIEN, COVIDIEN with logo, Covidien logo, positive results for life and ™ marked brands are U.S. and internationally registered trademarks of Covidien AG. R0027846
  2. 2. Background Todd 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
  3. 3. 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 engineering Tools 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
  4. 4. 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 functionalityy g q y early 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
  5. 5. 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
  6. 6. 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]
  7. 7. 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
  8. 8. 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]
  9. 9. Why Use Systems Engineering? Develops, drives, implements, leads, standardizes, reuses, predicts, adapts, communicates, improves, analyzes… 1. Standardized deliverables 2. Decomposition process of customer requirements 3. System functionality that meets customer’s expectation 4. Commitment to faster time to market 5. Systems that can evolve with a minimum of redesign and cost 6. Designs for systems reuse 7. More predictable outcomes 8. Products with adaptable, resilient systems 9. Verified functionality with fewer defects 10 I d i ti10. Improved communications a. Across functions b. Programs c. 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 toy p g p j q management • See SEI (Software Engineering Institute for data on Systems Engineering process improvement) 9 | 16 February 2012
  10. 10. 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: 10 | 16 February 2012
  11. 11. Systems Engineering ProcessSystems Engineering Process Life Cycle Models 11 | 16 February 2012
  12. 12. A Typical “Waterfall” Life Cycle Model Concept Voice of the customer, concept development, business plan Feasibilityeas b ty Definition of customer and system requirements, project plan and schedule Development Develop/implement/document product design, develop V&V strategy Qualification Execute product V&V, validate manufacturing processes, prepare for volume production Commercialization Product launched, achieve stable production Sustaining support Ongoing product changes, enhancements, address complaints, reliability 12 | 16 February 2012
  13. 13. The Systems Engineering V Model User requirements Validation Tests Validation System Requirements System Tests Verification Requirements IntegrationArchitectural VerificationDefining the d t Integrating & verifying what has been b ilt g TestsDesign product been built Abstract, early, formative, creative, conducive Systems Engineering Component Engineering Component Development Component Tests to change Expensive, realistic, late, difficult to change Component Engineering 13 | 16 February 2012 Stevens, [6]
  14. 14. 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]
  15. 15. 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 •None 15 |
  16. 16. CMMI Solid Foundations… 5Org. Perf. Mgmt 4Quantitative Project Management Causal Analysis and Resolution Requirements Development Technical Solution Verification Organizational Training Validation 3 Organizational Process Performance R i t M t P j t M it i d C t l Product Integration Verification Organizational Process Definition + IPPD Organizational Process Focus Risk Management Integrated Project Management + IPPD Decision Analysis and Resolution 3 2Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management 2 16 | 16 February 2012
  17. 17. Example: Requirements Management Requirements Management (REQM) – Maturity Level 2 (Process Management) Purpose The 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 Goal SG 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 |
  18. 18. Example: Requirements Development Requirements Development (RD) An Engineering process area at Maturity Level 3. PurposePurpose The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements. Specific Practices by Goaly SG 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 Requirementsq 18 |
  19. 19. 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 ROI Organizations which have invested in CMMI-based process improvements have seen an ROI ranging from 2:1 to 13:1g g See SEI web site: 19 | 16 February 2012
  20. 20. CIMM – The Missing Levels (Humor) 0 : Negligent0 : Negligent The 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 : Obstructive Processes, 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 : Undermining Not 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
  21. 21. (Over) Simplified View of Product Development E ti D i Final Product Innovation Domain •Low uncertainty •Low risk Execution Domain •Safe and effective •Manufacturable •Reliable •Affordable •Few defects •Few assumptions •“Hard” (physical prototypes) •Iteration is very expensive Conceptual Design Model (one of many!) Mature Design Model •Quality System •Engineering ProcessesHigh uncertainty Processes •OperationsIdea •High uncertainty •High risk •Many assumptions •“Soft” (paper, electronic models) •Iteration is inexpensive Systems Engineering Process Covidien | | Confidential “Gain”
  22. 22. Systems Engineering and Quality:Systems Engineering and Quality: Verification 22 | 16 February 2012
  23. 23. 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
  24. 24. The Systems Engineering ToolboxThe Systems Engineering Toolbox 24 | 16 February 2012
  25. 25. Systems Engineering Tools INCOSE Tools Taxonomy http://www incose org/productspubs/products/setools/tooltax/se tools taxonomy html 25 | 16 February 2012
  26. 26. SE – Engineering Tools •System Design Tools •Structural and Behavioral modeling, UI prototyping •Requirements Engineering Tools Requirements capture traceability•Requirements capture, traceability •Design Validation Tools •Specialty Engineering Tools •Reliability Engineering, Failure Analysis, DFx 26 | 16 February 2012
  27. 27. Useful Tools – Some Examples Requirements 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 for more information • Executable models, systems analysis, software code generation 27 | 16 February 2012
  28. 28. Systems Engineering and the SafetySystems Engineering and the Safety Risk Management Process 28 | 16 February 2012
  29. 29. When Risks Go Unconsidered in Medical Devices… The Therac-25 Disaster Medical 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 Paper 29 | 16 February 2012
  30. 30. 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
  31. 31. 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 specifies I 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
  32. 32. 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
  33. 33. A Risk-Driven Process … An integrated risk management process is essential to successful medical device development. Risk analysis (fault tree) Product i t Risk-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
  34. 34. Creating Good RequirementsCreating Good Requirements 34 | 16 February 2012
  35. 35. 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
  36. 36. 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
  37. 37. Verification Verification is the process which makes sure that what was built matches the requirements. Was the system built the way the requirements and designq y y q g specified? Was the system built “right”?Was the system built right ? 37 | 16 February 2012
  38. 38. 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
  39. 39. 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 Requirements Derived from Top-level Requirements 39 | 16 February 2012
  40. 40. 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 Requirements Into Systems Requirements Sub system RequirementsSub-system Requirements Derived from Top-level RequirementsTechnical Development (Tech Dev) Sustainability 40 | 16 February 2012
  41. 41. 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 Requirementsa 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
  42. 42. 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
  43. 43. Requirements Analysis Phase • Derive safety requirements from risk management plan • Organize and Scrub requirements • !! Delete orphan requirements !! • Review & validate requirements 43 | 16 February 2012
  44. 44. 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
  45. 45. Requirements Analysis Process 45 | 16 February 2012
  46. 46. 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 known 4. Avoid constraining the designers 5. Free of Specific Design Content – NOT a specification, NOT a design solution / design outputdesign solution / design output 46 | 16 February 2012
  47. 47. 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]
  48. 48. 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 s acquire 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
  49. 49. 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
  50. 50. Negative (Anti-) Requirements Negative 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-recoverable error 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
  51. 51. Requirement Qualifiers Qualifiers 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 early switch 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
  52. 52. 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
  53. 53. Systems Engineering Resources 1. International Council on Systems Engineering: 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
  54. 54. Questions? 54 | 16 February 2012
  55. 55. THANKS!THANKS! For your attention and patience! 55 | 16 February 2012