Systems engineering is an interdisciplinary approach that focuses on defining customer needs, documenting requirements, and enabling the realization of successful systems. It considers both business and technical needs across the entire life cycle from concept to disposal. Requirements management is the foundation of systems engineering. Organizations can improve processes and reduce risks through structured approaches like the Systems Engineering V-Model and maturity models like CMMI that provide standard processes and best practices. Verification and validation are used to ensure a system meets its requirements through methods like testing, analysis and demonstration.

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 comtodd.hansell@covidien.com
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. 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. 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. 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. 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. 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. 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. 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. 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. 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

11. Systems Engineering ProcessSystems Engineering Process
Life Cycle Models
11 | 16 February 2012

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. 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. 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. 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. 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. 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. 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. 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:
http://www.sei.cmu.edu/publications/documents/03.reports/03sr009.html
19 | 16 February 2012

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. (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. Systems Engineering and Quality:Systems Engineering and Quality:
Verification
22 | 16 February 2012

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. The Systems Engineering ToolboxThe Systems Engineering Toolbox
24 | 16 February 2012

25. 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

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. 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 http://www.omgsysml.org for more information
• Executable models, systems analysis, software code generation
27 | 16 February 2012

28. Systems Engineering and the SafetySystems Engineering and the Safety
Risk Management Process
28 | 16 February 2012

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
www.cs.washington.edu/research/projects/safety/www/therac-25.html
29 | 16 February 2012

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. 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. 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. 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. Creating Good RequirementsCreating Good Requirements
34 | 16 February 2012

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Requirements Analysis Process
45 | 16 February 2012

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. 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. 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. 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. 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. 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. 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. 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

54. Questions?
54 | 16 February 2012

55. THANKS!THANKS!
For your attention and patience!
55 | 16 February 2012