design requirements training
TRANSCRIPT
1
Design Requirements & Analysis
2
Pre-requisites & Ground Rules
Pre-requisites: Design Control Training Bring draft of Requirement Documents Provide Sources of inputs to generate
Requirements Ground Rules:
Share work with other teams Team learning experience
3
Topic Time (min)
Takeaways
Introduction 10
Role of Requirements 30 Why have good requirements? Benefits of having good requirements
Sources & Tools for gathering requirements
20 Sources of requirements Tools for requirements gathering
Characteristics of a Quality Requirement Statement
30 Common Characteristics of a Good Quality Requirement Statement How to check for a good requirement Critic requirements examples
Design Control Architecture - PCD
60 Understanding the PCD - Characteristics & Examples Application through team exercise
Lunch & Breaks 60
Design Control Architecture - SRD
90 Understanding the SRD - Characteristics & Examples Application through team exercise
Design Control Architecture - SSRD
90 Understanding the SSRD - Characteristics & Examples Application through team exercise
Design Requirements & Analysis Training
4
Medical Device
Design Validation
Planning
Verification & Validation
Design Verification
Customer Requirements (PCD)
System & Subsystem
Requirements Design &
Development
Design Output
DI/DO/DTM as part of PDP
Design Trace Matrix
5
Design Requirements as part of PDP
Design & Development
Phase
• D&D Plan• DI Documents• RAMT• DTM
DI & Planning
Review
DevelopmentPhase
Proceed
Stopped
Revise
Planning Phase
Core TeamFormed
Team Training & Activities:•Planning•Design Input•Risk Management•Design Traceability
6
Design Requirements & Analysis
Role of Requirements
Sources & Tools of Requirements
Gathering
Characteristics of Quality Requirement Statement
Design Control Architecture:PCD, SRD & SSRD
7
Why Requirements Definition is important?
Compliance Automation Inc.
8
The Role of Requirements‘Who are those guys, anyways?’
A statement(s) of what user capabilities or services a system or product needs to deliver Operational need translated into
descriptions, physical and performance parameter
Objective, complete, clear, testable
9
The Role of RequirementsWhy do Specifications Matter?
Are they ‘just another deliverable’? What is influenced by requirements? What role do requirements play in
development efficiency? What is the regulatory impact with respect to
requirements?
10
The Role of RequirementsAdvantages of Developing Excellent Requirements
Customer - Understand customer needs, desired outcomes and product intended use
Team – On the same page, pulling in the same direction, common ownership
Planning - Defines the scope and complexity of an effort
Team members – know what is expected, sets up successful outcomes
Business – communicate, plan and deliver results
11
The Role of RequirementsConsequences of Poor Requirements
Lack of a cohesive team effort Inability to launch a product Late projects, sliding schedules Cancellation at phase gate review Unsuccessful or unacceptable products
or services
12
The Role of RequirementsCost Pyramid
Requirements
Architecture
Detailed Design
Manufacturing
Verification
Field Action
13
The Role of RequirementsA Case Study
Incomplete requirement set on diagnostic device regarding priority of error reporting 3 stated requirements
1. Requirement for reading > 500 reported as ‘high’ result2. Error trap requirement for insufficient blood (X < 0.006)3. Error trap requirement for blood on wrong side of strip (X > 0.09)
Missing requirement• Priority of combined errors (1 and requirement 2 or 3)
Design assumption made Incomplete or inaccurate requirement analysis
Verification successful Validation does not show issue (low occurrence)
14
The Role of RequirementsA Case Study (Cont)
Severe Action Taken• Field action required – recall• Agency investigations• Litigation• Probation and penalties
Potential danger to customers Lost opportunities Direct financial loss
15
The Role of Requirements
Understand the user need and intended use as the basis for design and development:
Without understanding the customer requirements (e.g. user needs, intended uses), what are the reasons for design and development?
Provide an accurate translation of customer need and intended use to minimize design redundancies:
Planning, design decisions and project execution can be done efficiently.
Reduces the probability that errors will be introduced through redesign or design omissions
16
Create the foundation for product design and development – Product requirements are the cornerstone in providing results Product Development Process:
Cycle time reduction Product quality fulfilling customer need and desired outcomes Reduce or eliminate recalls and field actions Increase NP revenues
Design (product and process) improvements: Quality product Process and performance stability
The Role of Requirements
17
Complete definition and management of labeling claims:
The Marketing Team will have the competitive advantage in providing the product features to the customers.
Availability of information to suppliers for product changes.
Better control of the product development process:
The development team will be able the manage the project through prioritization.
Focus on the essential requirements of the product that will delight the customer.
The Role of Requirements
18
The Role of Requirements
Improved quality and end-user satisfaction : Product benefits consistent with customer desires Consistent performance Improved, predictable reliability
Improves Team Communication: Minimizes guess work, interpretation and disconnects Brings team to the same level of understanding
19
The Role of Requirements
Easier compliance with regulations through objective evident: Documented Design Verification and Validation Activities Traceability
Reduces Rework/Redesign/Add Product Features: More efforts can be focus adding Product Features that will delight
the customers. Improving the reliability and the quality of the products
Gain Market Share: Speed to market Product cycle time reduction
20
What’s wrong with this picture?
Compliance Automation Inc.
21
Sources of Requirements
Input Sources to Marketing Requirement Document
Business Proposal
• Regulatory Requirements
• J&J Business Requirements
• Customer input
• Technology Assessment
Marketing Requirement
Document
22
• Operations
• Product Support Teams
• CAPA
Marketing Requirement
Document
PHA and Preliminary Human Factors
Analysis
Product Criteria Document
Customer - Input Sources for the PCD
Additional Input Sources: Regulatory & Statutory LifeScan Business Requirements Others
Sources of Requirements
23
System Requirements
Document
Sub-system Requirements
DocumentsProduct Criteria
Document
Additional Hazards and Human Factors
Analysis
Design FMEA and Fault Tree
Analysis
Product - Input Sources for the SRD & SSRD
Sources of Requirements (cont.)Sources of Requirements (cont.)
24
Product – Other Input Sources for the SRD & SSRD Marketing Competitive Benchmarking Legacy Requirements Internal Benchmarking Brainstorming Complaints Technical Services Group CAPA Other Sources
Sources of Requirements (cont.)
25
Tool for Gathering Requirements
Ishikawa Fishbone (cause-and-effect) Diagram
SMBG System
ElectronicsRequirements
Labeling Requirements
Mechanical Requirements
Software Requirements
Strip & ReagentRequirements
OtherRequirements
26
Tool for Gathering Requirements
Advantages of cause-and-effect diagram Identify sources of requirements Apply to all levels Focus on specific issue without resorting to complaints and
irrelevancy Easy to use
Disadvantages: Relationship not well define Interrelationships not defined
27
Tool for Gathering Requirements
Quality Function Deployment (QFD)
Relationship
Customer to System
Cus
tom
er (P
CD
)
System
PriorityIm
portance
System to Subsystems
Relationship
Subsystems
Importance
Priority
Syst
em
28
Tool for Gathering Requirements
Advantages of QFD Clear translation of customer requirements into design through logical
steps Robust and applicable to projects of varying size, scope, and
complexity Allows user to prioritize and focus on the elements that are critical to
quality (CTQ) Able to define complex inter-relationship Provides the platform for post launch design change control by
depicting trace through entire system Forces requirements to be analyzed for ambiguity and redundancy Analysis for V&V planning done with requirements definition
Disadvantages of QFD: Requires substantial up front investment Requires specialized training
29
What wrong with this picture?
Compliance Automation Inc.
30
Characteristics & How to Check for Goodness
Characteristics that Individual Requirement StatementShould Exhibit: Necessary Concise Implementation Free Attainable Complete Consistent Unambiguous Verifiable Correct Feasible Prioritized
31
Characteristics & How to Check for Goodness
Necessary - The stated requirement is an essential capability, physical characteristic, or quality factor of the product or process. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the product or process.
One good test of necessity is traceability
Traceable - You should be able to link each requirement to its source, which could be a higher-level system requirement, risk mitigation, a use case, or a voice-of-the-customer statement. Also link each requirement to the design elements, source code, and test cases that are constructed to implement and verify the requirement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs or bullet lists.
Concise (minimal, understandable) - The requirement statement includes only one requirement stating what must be done and only what must be done, stated simply and clearly. It is easy to read and understand.
32
Characteristics & How to Check for Goodness
Implementation free - The requirement states what is required, not how the requirement should be met. A requirement statement should not reflect a design or implementation nor should it describe an operation.
At the system level, requirements can be truly abstract or implementation free. An example of a requirement for a monitor system at the system level is: "The system shall be capable of detecting a power failure.” This sentence should be followed by expected performance data (a quantification of what "detecting" means) against specific power failures. When no specific implementation has been stated, the system designer is free to pursue alternative, competing system designs.
33
Characteristics & How to Check for Goodness
Attainable (achievable or feasible) - The stated requirement can be achieved by one or more developed system concepts at a definable cost. This implies that at least a high level conceptual design has been completed and cost tradeoff studies have been conducted.
Complete (standalone) - The stated requirement is complete and does not need further amplification. The stated requirement will provide sufficient capability.
Consistent - The stated requirement does not contradict other requirements. It is not a duplicate of another requirement. The same term is used for the same item in all requirements.
Unambiguous - Each requirement must have one and only one interpretation. Language used in the statement must not leave a doubt in the reader's mind as to the intended descriptive or numeric value.
34
Characteristics & How to Check for Goodness
Verifiable - The stated requirement is not vague or general but is quantified in a manner that can be verified by one of these 4 alternative methods: inspection, analysis, demonstration or test.
Determine how the requirement will be verified.
Alarm example:
Within a system, both visual and audible alarms are often required to warn the user about abnormal or unsafe conditions. Also, the same alarm is used for multiple conditions, such as system failure, strip insertion, test results and low batteries.
To verify that both the visual and audible alarms work together, all tests must include both. Therefore, the visual and audible parts should be combined into a single requirement. Further, if the conditions providing inputs to the alarm can be incorporated into the same test or demonstration, these should also be included in the same requirement.
An example of a requirement following this approach can be "The element shall provide a visual and audible alarm under all conditions listed in Table 3-10. The alarm shall be activated no longer than 1 second after the condition exists."
35
Characteristics & How to Check for Goodness
Correct - Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct (of course, the system specification could itself be incorrect).
Only user representatives can determine the correctness of user requirements, which is why it is essential to include them, or their close surrogates, in inspections of the requirements. Requirements inspections that do not involve users can lead to developers saying, "That doesn’t make sense. This is probably what they meant." This is also known as "guessing."
36
Characteristics & How to Check for Goodness
Feasible - It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process. This developer can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other tradeoffs.
37
Characteristics & How to Check for Goodness
Prioritized - Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release. Customers or their surrogates have the lion’s share of the responsibility for establishing priorities. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. Priority is a function of the value provided to the customer, the relative cost of implementation, and the relative technical risk associated with implementation.
Three levels of priority: High priority means the requirement must be incorporated in the next
product release. Medium priority means the requirement is necessary but it can be
deferred to a later release if necessary. Low priority means it would be nice to have, but we realize it might
have to be dropped if we have insufficient time or resources.
38
Characteristics of Quality Requirements
Other Characteristics of a good Requirement Unique – A requirement should have a unique label, a unique name and
unique contents. Documented and Accessible – A requirement must be documented
(e.g. writing, pictures, images, database, etc.) and the documentation must be accessible.
Identifies Applicable States – Some requirements only apply when the system is in a certain states or modes. If the requirement is only to be met sometimes, the requirement should reflect when.
For example: The vehicle shall: Be able to tow 2000-pound cargo trailer at high way speed (65 MPH) Accelerate from 0-60 MPH in less than 10 seconds
39
Requirement Fundamentals
Some words to avoid for the SRD and SSRD:Vague and general words be avoided. Avoid "flexible", "fault tolerant", "high fidelity", "adaptable", "rapid or fast", "adequate", "user friendly", "support", "maximize" and "minimize“.
For example: "The system design shall be flexible and fault tolerant".
Other words that should be avoided are "and/or", "etc." and "may".
40
Requirement Fundamentals
Here are some examples of problematic requirements:
Original: "The product shall switch between displaying and hiding nonprinting characters instantaneously."
Not feasible: Computers cannot do anything "instantaneously". Incomplete: Does not state under what conditions the switching
occurs. Does it happen automatically, or as a result of user input?
Ambiguous: What does "nonprinting characters" mean? Hidden text? Attribute tags? Control characters?
Rewritten: "The user shall be able to toggle between displaying and hiding all HTML markup tags in the document being edited with the activation of a specific triggering mechanism."
41
Requirement Fundamentals
Problematic Requirements (cont.):
Original: "The software shall be able to clear the monitor after a successful upload."
Incomplete: Under what conditions is the monitor cleared? All the time? Or is a specific action required?
Ambiguous: What does "clear the monitor" mean?
Rewritten: "After a successful upload from the monitor, the software shall query the user as to whether s/he wants to erase the uploaded test records from the monitor's database."
42
Requirement Fundamentals
Problematic Requirements (cont.):
Original: "The monitor shall be able to store up to 1500 test records." Ambiguous: Does this mean that if the monitor can store more
than 1500 records it is in violation of this requirement? Does it mean that if it can only store 1100 records that is okay ?
Rewritten: "The monitor shall be able to store at least 1500 test records."
43
Requirement Fundamentals
Before & After ExamplesOriginal: "The monitor’s push buttons may be used for optional
settings." Ambiguous: What does “may” mean?
Rewritten: "Optional settings shall be accessible through the monitor’s buttons.“
Original: "The monitor should store test results and errors. Test results include INR result, date, time, and system quality control results."
Ambiguous: Should? More than one requirements? Verifiable: How many test results?
Rewritten: "The Monitor shall provide storage for a minimum of 75 test results.““Stored test results shall include the date and time stamp, an INR result from 0.8 to 8.0 if testing passes, ‘HI INR’ for high results, ‘LO INR” for low results if a result is reported, or an error code if testing fails. Stored results also include Control 1 and Control 2 values.“
44
Requirement Fundamentals
Before & After Examples
Original: "Test strip can hold sufficient sample without overflowing." Attainable: How much is sufficient?
Rewritten: "The test strip shall accommodate a variety of sample sizes (20 to 40 micro liter) without the sample overflowing beyond the sample application area.“
Original: "The monitor retains test result memory and additional memory without batteries."
Ambiguous: What additional memory?
Rewritten: "The monitor shall store test results, calibration coefficients, algorithm coefficients, and test strip lot-specific calibration data (calibration codes) in non-volatile memory."
45
Requirement Fundamentals
Before & After Examples
Original: "At a rate of one (1) test per week, the monitor indicates a low battery condition with at least four (4) tests remaining."
Unclear: How does rate relate to indicator for low battery condition?
Rewritten: "The monitor shall indicate a low battery condition with enough remaining power for at least four tests.“
Original: "The test strip prevents direct contact between the operator and any of the test strip reagents."
Consistent Wording: Use “shall”. Operator is referred to as “user”.
Rewritten: "The test strip shall prevent direct contact between the user and any of the test strip reagents."
46
Design Control Architecture
PCD Product Criteria Document
SRDSystem Requirement
Document
SRS RRSMRS ERS
Subsystem Requirement Documents (SSRD)
LRSPRS
47
Design Control Architecture – PCD
Characteristics: User/Customer Needs
A review of the Customer’s needs based upon Market Research and Focus Groups.
Intended UseA review of the claims that will be included in the labeling defining how the device will be used and who the primary end users will be. This could also include hospital guidance and interface requirements with other devices.
48
Design Control Architecture – PCD
Characteristics: Regulatory and Statutory
The domestic and international requirements for the device based upon the intended market, including any regional standards, directives, laws, and regulations.
Business NeedsSpecific Requirements mandatory for product acceptability (e.g. COGS, Quality, Reliability, etc.).
OthersDesign for ManufacturabilityTestabilityCustomer Service
49
Design Control Architecture – PCD
User Needs monitor Criteria
Examples The monitor shall be easy to turn on an off.Button functions shall be easy to understand and use. The monitor shall automatically turn itself off after a period of inactivity to conserve battery power. monitor display shall be easy to read and visible in normal lighting conditions.The monitor surface shall be easy to clean and sanitize.
Test Strip CriteriaExamples The user shall be able to insert the test strip in the monitor easily.
The test strip handle area shall be clearly marked. The sample size from a single finger stick shall be sufficient to give an accurate test.The product shall provide accurate results over the stated life of the product if kept in its original packaging.
50
Design Control Architecture – PCD
Intended UsesExamples The product is intended for use by health care professionals at
the point of care.The product is intended for use by laypersons in the home for patient self-testing.The product shall be used for quantitative measurement of PT in fresh capillary blood as an aid in monitoring oral anticoagulation (Warfarin) therapy.The product shall be used for quantitative measurement of PT in venous whole blood as an aid in monitoring oral anticoagulation (Warfarin) therapy.
51
Design Control Architecture – PCD
Regulatory and Statutory Requirements Certification Criteria
Examples The product shall meet CAN/CSA C22.2 No. 601.1, Medical Electrical Equipment - Part 1: General Requirements for Safety (equivalent to IEC 601.1) including any applicable collateral standards.International Electro-technical Commission (IEC), IEC601-1-4, Safety Requirements for Programmable Electronic Medical Devices shall be followed.
Labeling and Packaging CriteriaExamples Product labeling, packaging, and documentation shall be
readable and understandable.Product packaging and labeling shall include general instructions for how the product shall be used.
52
Design Control Architecture – PCD
OthersExamples The Rubicon Monitor shall be marketed in conjunction with the
Rubicon Test Strip.The monitor shall be storable and transportable in an acceptable range of environmental conditions.There shall be no user-serviceable components, except for batteries.Removable parts (i.e., test strip holder and batteries) shall be field-replaceable.Replacement parts shall be compatible with all monitors.
53
Design Control Architecture – PCD
Team Exercise
54
Design Control Architecture – SRD
Characteristics:
FunctionalFunctional requirements specify what the design does. Focus is on the operational capabilities, the processing of inputs and the resulting outputs.
Physical & PerformancePhysical and Performance requirements specify how much or how well the design must perform, addressing such issues as speed, strength, size, weight, response times, accuracy and precision, limits of operation, etc.
InterfaceInterface requirements specify characteristics that are critical to compatibility with external systems (including user and/or patient interface, if applicable).
Others
55
Design Control Architecture – SRD
Functional QC Requirements
Example The monitor shall have the capability of detecting a power failure and shall not display or store result from a test that is in-progress.
System RequirementsExample The system shall produce a test temperature at the assay site of
39 +/- 1 C.⁰The system shall complete the test and display an INR result or an error message, with time and date stamp, within 2 minutes of sample application
Monitor RequirementsExample Batteries inserted incorrectly (wrong polarity) shall not damage
the monitor.The Monitor shall turn itself off to conserve battery power after at least 90 seconds of being idle while waiting for user action.
56
Design Control Architecture – SRD
Physical and Performance Requirements monitor Requirements
Example The monitor dimensions shall be no greater than 8.0” long x 3.4” wide x 2.2” high (20.3 cm long x 8.6 cm wide x 5.6 cm high).
Test Strip RequirementsExample The test strip dimensions shall allow easy insertion of the test
strip to be into the test strip holder. System Requirements
Example The system shall provide accurate results for a temperature range of 15 to 35° C.
57
Design Control Architecture – SRD
Interface Requirements Monitor Requirements
Examples The monitor shall prompt the user to confirm or reset the CalCode.The monitor shall alert the user if the test strip is inserted incorrectly.
Test Strip RequirementsExamples The test strip shall be clearly marked as to the orientation and
direction of insertion. The test strip shall prevent direct contact between the user and any of the test strip reagents.
Labeling RequirementsExamples Product labeling shall conform to 21CFR820 part 809.10.
Product labeling shall conform to CAN/CSA C22.2 No 601.1. Product labeling shall contain instructions for the user to properly and safely operate the system.
58
Design Control Architecture – SRD
Team Exercise
59
Design Control Architecture – SSRD
Functional Physical & Performance Interface General Design Goals & Constraints
SRS RRSMRS ERS
Subsystem Requirement Documents (SSRD)
LRSPRS
60
Design Control Architecture – SSRD
Characteristics:
FunctionalFunctional requirements specify what the design does. Focus is on the operational capabilities, the processing of inputs and the resulting outputs.
Physical & PerformancePhysical and Performance requirements specify how much or how well the design must perform, addressing such issues as speed, strength, size, weight, response times, accuracy and precision, limits of operation, etc.
InterfaceInterface requirements specify characteristics that are critical to compatibility with external systems (including other Subsystem and user and/or patient interface, if applicable).
General Design Goals & Constraints
61
Software Design Constraints
General Design Constraints Regulatory Policies Hardware Limitations (e.g. time requirements) Interfaces to Other Applications Parallel Operation Audit Functions Control Functions Higher-Order Language Requirements Handshake Protocols Critical Nature of Application Safety and Security Considerations
62
Software Design Constraints
General Design Constraints Hardware Software Serial Communication
63
Software
Functional RequirementsThe essential functions provided by the software product. These requirements detail the behavior of the software. They should be grouped according to the product functions specified in the Product Function Overview. Sections may include; General Functions, Power-On and Self-Test, Serial Command Processing, Configuration of monitor Options, Performing a Glucose Test, and Reviewing Stored Data. Each section should contain those requirements associated with that particular function.
64
Software
Functional Requirements General Functions Power-On and Self Test Serial Communications Serial Command Processing monitor Configuration Data Storage Test Mode Calibration Strip Mode Setup Mode Data Review Mode User Data Management Mode Mimic Mode Functional Tests
65
Software
User Interface RequirementsDescribe aspects of the part of the software that interfaces the user to the monitor or application. This might include response time for button presses, debouncing requirements, minimum font size restrictions, standard error message formats, standard objects that must appear on every screen, etc. Do not include screen images or other design information in this section unless they truly represent a required feature.
66
Software
External Interface RequirementsExternal interfaces can include interfaces to hardware components of the system (displays, buttons, sensors, valves, etc), software components of the system (databases, drivers, etc.), or external devices (via serial port or network connection).
67
Software
Performance Interface RequirementsDescribe the numerical requirements placed on the software or user interaction with the software. Only measurable performance parameter shall be specified (file size, response time, frequency, etc.). Performance requirements for a particular function should be specified in the appropriate “Functional Requirement” section.
68
Electronics
General Design Goals and Constraints Electronic Components Size Weight Yield Cost Testability
69
Electronics
Interface Requirements Mechanical Strip & Reagent Software
70
Electronics
Functional Requirements monitor Measurement Requirements CALCODE Setting and Input Power Supply Generation & Distribution System Architecture
• Test Result and Calibration Memory (e.g RAM)• Processors• ASIC
Buttons Audio Communication Interface Battery Requirements
• Life• Installation
Real Time Clock System Fault Requirements
• Detection• Reporting
71
Electronics
Functional Requirements Sample Application Detection Strip-In-Place Detection Assay Detection Reagent Temperature Control
• Heater Driver• Heater Sensor Amplifier
72
Electronics
Physical and Performance Requirements Electromagnetic Compatibility
• Electrostatic Discharge• Electromagnetic Immunity• Electromagnetic Emissions
Accuracy & Precision• Drift Voltage• Reference voltage• Frequency• System Timing Accuracy• Resolution of ADC
73
Electronics
Durability & Reliability Requirements MTTF & MTBF Operating Environmental Conditions
• Temperature• Humidity• Altitude
Non-Operating Environmental Conditions• Storage• Shock
74
Mechanical
General Design Goals and Constraints Mechanical Components Size Weight Yield Cost Testability
75
Mechanical
Interface Requirements Electrical Strip & Reagent
• Test Strip Insertion• Test Strip Support• Strip Holder
Software
76
Mechanical
Functional Requirements System Fault Requirements
• Detection• Reporting
Sample Application Sensor• Sample Detection
Assay Optics• Optical System
Strip in Place Detection• Test Strip Detection
Reagent Temperature Control• Test Strip Temperature• Blood Sample Temperature
Battery Requirements• Battery Type• Battery Life• Installation
77
Mechanical
Functional Requirements (cont.) Monitor Assembly
• Temperatures• Alternative Power Source• Cleaning• Display• Graphics• Ergonomic• Safety• Identifier
Buttons• Requirements• Interface
Communication Interface• Data/Serial Communications Port• Power Port• Data Port Recognition
78
Mechanical
Physical and Performance Requirements Sample Application Sensor
• Wavelength• Window Transmission Percentage
Heater• Temperature• Sensor
Monitor• Label Area• Shipping• Storage• Shock Hazard• Fire Hazard• Size• Weight
Electromagnetic Compatibility• ESD Emissions
79
Mechanical
Durability & Reliability Requirements MTTF & MTBF Operating Environmental Conditions
• Temperature• Humidity• Altitude• Light• Orientation
Non-Operating Environmental Conditions• Storage• Shock• Rigidity• Impact• Vibration• Fluid Intrusion• Cleaning & Chemical Resistance
80
Strip & Reagent
General Design Goals and Constraints Size Yield Cost Testability
81
Strip & Reagent
Functional Requirements QC Requirements CalCode Requirements PT Reagent
82
Physical and Performance Requirements Test Strip and Strip-in-Place Dimensions Cleanliness Thermal Characteristics Fluidic Characteristics (e.g Flow Channel) Physical Attributes (e.g. Clarity) Precision & Accuracy Stability Shipping
Strip & Reagent
83
Interface Requirements Mechanical Characteristics Electrical Characteristics Software Strip Handling
Strip & Reagent
84
Labeling
Labeling on the monitor User Needs
Example: All monitor labeling shall be clearly legible. Regulatory/Statutory
Example: The monitor label shall specify “For In Vitro Diagnostic Use”.
LifeScan Labeling RequirementsExample: The monitor label shall include a LifeScan copyright
symbol. Owner’s Booklet
User NeedsExample: The Owner’s Booklet shall contain instructions for the
user to properly and safely operate all components of the system. Regulatory/Statutory
Example: The Owner’s Booklet shall include all applicable equipment classifications from CAN/CSA 601.1-M90 Clause 5.
LifeScan Labeling RequirementsExample: The Owner’s Booklet shall include an artwork number.
85
Labeling
Logbook User Needs
Example: The logbook shall provide space to record the result of each test.
LifeScan Labeling RequirementsExample: The Owner’s Booklet Addendum shall include an artwork
number. monitor Kit Carton Labeling
User NeedsExample: The monitor carton label shall contain the LifeScan
Customer Support and Service number. Regulatory/Statutory
Example: The monitor carton label shall include all information appearing on the monitor label.
LifeScan Labeling RequirementsExample: The monitor carton label shall contain LifeScan copyright
notice. Labeling on the Test Strips
User NeedsExample: The test strips shall have graphics printed on the top
side to aid the user in inserting the strip with the right side up.
86
Labeling
POC and PST Test Strip Bottle Labels User Needs
Example: The POC and PST test strip bottle labels shall contain instructions for proper storage.
Regulatory/StatutoryExample: The PST test strip bottle label shall contain the
“Rx Only” designation. LifeScan Labeling Requirements
Example: The POC and PST test strip bottle labels shall contain relevant patent numbers.
POC and PST Test Strip Carton Labeling User Needs
Example: The POC and PST test strip carton labeling shall have the expiration date prominently displayed.
Regulatory/StatutoryExample: The POC and PST test strip carton labeling
shall include a Lot Number. LifeScan Labeling Requirements
Example: The POC and PST test strip carton labeling shall contain a product number and barcode.
87
Labeling
POC and PST Test Strip Package Inserts Intended Use
Example: The POC and PST test strip package insert shall state that the product is for use with the monitor.
User NeedsExample: The POC and PST test strip package inserts shall provide a quick reference
to the steps for performing a test using the monitor INR Monitoring System. Regulatory/Statutory
Example: The POC and PST test strip package inserts shall describe physical, biological, or chemical indications of instability or deterioration of the reagent.
LifeScan Labeling RequirementsExample: The POC and PST test strip package inserts shall include an artwork number.
monitor Kit Shipping Labeling User Needs
Example: The monitor shipper labeling shall specify the temperature and humidity ranges for transport and storage of the monitor.
LifeScan Labeling RequirementsExample: The monitor shipper labeling shall contain a product number and barcode.
88
Labeling
POC and PST Test Shipper Labeling User Needs
Example: The test strip shipper labeling shall indicate the number of cartons contained in the shipper.
LifeScan Labeling RequirementsExample: The test strip shipper labeling shall contain a
part number and barcode. Instructor’s Guide
Intended UseExample: An Instructor’s Guide shall be created for use
in training and certification of PST users. User Needs
Example: The Instructor’s Guide shall provide written and hands-on exercises to be performed by the trainees.
89
Design Control Architecture – SSRD
Team Exercise