The system shall provide a user-friendly interface.
Not testable: "User-friendly" is subjective. What criteria define
"user-friendly"?
Rewritten:
The system interface shall:
- Allow navigation using a maximum of 3 mouse clicks between any two screens.
- Provide context-sensitive help accessible from any screen with a single click.
- Use terminology consistent with common user expectations.
- Present information in a format that minimizes eye and cursor movements.
These criteria make "user-friendly" objective and testable.
General deficiencies found during inspection of gates and remedy with case st...IEI GSC
This presentation on General deficiencies found during inspection of gates for dams, canals etc and remedy with case studies was done by Shri D.K.Mehta at All India Seminar on Safety Inspection and O & M of gates conducted by Gujarat State Center of The Institution of Engineers (India) on July 3rd 2015 at Ahmedabad.
Construction quality process, inspection, quality control and quality assurance,cost of quality, ISO standards. Introduction to concept of Total Quality Management.
Introduction to concepts of HSE as applicable to Construction. Importanceof safety in construction , Safety measures to be taken during Excavation ,Explosives , drilling and blasting , hot bituminous works , scaffolds / platforms /ladder , form work and equipment operation. Storage of materials. Safety through legislation, safety campaign. Insurances.
Quality awareness of concrete cube casting and testing must be done to achieve the desired strength of that particular grade of concrete and for the stability of the structure.
What is strategic visualization and how does it work? Get introduced to this new, convincing method that is transforming the way we understand business issues.
Make your business challenges and strategic initiatives transparent, understandable and accessible for all your key stakeholders.
General deficiencies found during inspection of gates and remedy with case st...IEI GSC
This presentation on General deficiencies found during inspection of gates for dams, canals etc and remedy with case studies was done by Shri D.K.Mehta at All India Seminar on Safety Inspection and O & M of gates conducted by Gujarat State Center of The Institution of Engineers (India) on July 3rd 2015 at Ahmedabad.
Construction quality process, inspection, quality control and quality assurance,cost of quality, ISO standards. Introduction to concept of Total Quality Management.
Introduction to concepts of HSE as applicable to Construction. Importanceof safety in construction , Safety measures to be taken during Excavation ,Explosives , drilling and blasting , hot bituminous works , scaffolds / platforms /ladder , form work and equipment operation. Storage of materials. Safety through legislation, safety campaign. Insurances.
Quality awareness of concrete cube casting and testing must be done to achieve the desired strength of that particular grade of concrete and for the stability of the structure.
What is strategic visualization and how does it work? Get introduced to this new, convincing method that is transforming the way we understand business issues.
Make your business challenges and strategic initiatives transparent, understandable and accessible for all your key stakeholders.
Creation and refinement of the product backlog can be achived in different ways.
Roman Pichler, in is post originally written in Jul, 16 2012 - http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas , has proposed a really interesting approach: use canvas to create and share product vision and product backlog creation and refinement.
I used this approach for a while with cool results.
These slides are a step-by-step introduction of the tool.
Please send me feedbacks to correct and improve it!
You can use these slides under Creative Commons Attribution-ShareAlike 3.0 Unported License.
This tutorial teaches you how to employ the Product Canvas, an agile UX tool that helps you create a product with a great user experience and the right features. Download the Product Canvas at: http://www.romanpichler.com/tools/product-canvas/
The 150 Most Powerful Marketing & Sales ToolsBrian Downard
Does your marketing and sales need a boost? ELIV8 created this huge list to show you the best online marketing and sales tools available today.
In the list you’ll find a variety of tools with a wide range of applications. For example; content marketing, analytic tools and customer relationship management.
Using Doors® And Taug2® To Support A Simplifiedcbb010
In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.
PRODUCT BRIEF DEVELOPMENT TOOLS Quality Function Dep.docxbriancrawford30935
PRODUCT BRIEF
DEVELOPMENT
TOOLS
Quality Function Deployment
In a few words: The voice of the customer translated into the voice of the engineer.
To design a product well, a design teams needs to know what it is
they are designing, and what the end-users will expect from it.
Quality Function Deployment is a systematic approach to design
based on a close awareness of customer desires, coupled with the
integration of corporate functional groups. It consists in
translating customer desires (for example, the ease of writing for
a pen) into design characteristics (pen ink viscosity, pressure on
ball-point) for each stage of the product development (Rosenthal,
1992).
Ultimately the goal of QFD is to translate
often subjective quality criteria into objective
ones that can be quantified and measured and
which can then be used to design and
manufacture the product. It is a complimentary
method for determining how and where
priorities are to be assigned in product
development. The intent is to employ
objective procedures in increasing detail
throughout the development of the product.
(Reilly, 1999)
Quality Function Deployment was developed
by Yoji Akao in Japan in 1966. By 1972 the
power of the approach had been well
demonstrated at the Mitsubishi Heavy
Industries Kobe Shipyard (Sullivan, 1986) and
in 1978 the first book on the subject was
published in Japanese and then later translated
into English in 1994 (Mizuno and Akao,
1994).
In Akao’s words, QFD "is a method for developing a design quality aimed at satisfying the
consumer and then translating the consumer's demand into design targets and major quality
assurance points to be used throughout the production phase. ... [QFD] is a way to assure the
design quality while the product is still in the design stage." As a very important side benefit he
points out that, when appropriately applied, QFD has demonstrated the reduction of development
time by one-half to one-third. (Akao, 1990)
The 3 main goals in implementing QFD are:
1. Prioritize spoken and unspoken customer wants and needs.
2. Translate these needs into technical characteristics and specifications.
3. Build and deliver a quality product or service by focusing everybody toward customer
satisfaction.
Technique useful for:
Derivative First of a kind
Me too with
a twist Next generation
Familiar New
E
st
ab
lis
he
d
N
ew
M
ar
ke
t
Product Concept
Since its introduction, Quality Function Deployment has helped to transform the way many
companies:
• Plan new products
• Design product requirements
• Determine process characteristics
• Control the manufacturing process
• Document already existing product specifications
QFD uses some principles from Concurrent Engineering in that cross-functional teams are
involved in all phases of product development. Each of the four phases in a QFD process uses a
matrix to translate customer requirements from initial plann.
During the Agile Austria Conference 2017, Graz, Austria
Speaker: Fariz Saracevic
This session will examine how requirements management can bring significant value to agile development teams.
Optimizing Product Realization Costs Across the Value ChainCognizant
Across a range of industries, realization of cost optimization requires a holistic approach throughout the product lifecycle - requirements, design, manufacture and post-launch - in order to weed out cost overruns and ensure the highest quality process and products.
International Journal of Engineering Research and Development (IJERD)IJERD Editor
call for paper 2012, hard copy of journal, research paper publishing, where to publish research paper,
journal publishing, how to publish research paper, Call For research paper, international journal, publishing a paper, IJERD, journal of science and technology, how to get a research paper published, publishing a paper, publishing of journal, publishing of research paper, reserach and review articles, IJERD Journal, How to publish your research paper, publish research paper, open access engineering journal, Engineering journal, Mathemetics journal, Physics journal, Chemistry journal, Computer Engineering, Computer Science journal, how to submit your paper, peer reviw journal, indexed journal, reserach and review articles, engineering journal, www.ijerd.com, research journals,
yahoo journals, bing journals, International Journal of Engineering Research and Development, google journals, hard copy of journal
International Journal of Engineering Research and Development (IJERD)IJERD Editor
journal publishing, how to publish research paper, Call For research paper, international journal, publishing a paper, IJERD, journal of science and technology, how to get a research paper published, publishing a paper, publishing of journal, publishing of research paper, reserach and review articles, IJERD Journal, How to publish your research paper, publish research paper, open access engineering journal, Engineering journal, Mathemetics journal, Physics journal, Chemistry journal, Computer Engineering, Computer Science journal, how to submit your paper, peer reviw journal, indexed journal, reserach and review articles, engineering journal, www.ijerd.com, research journals,
yahoo journals, bing journals, International Journal of Engineering Research and Development, google journals, hard copy of journal
2. 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. 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
5. 5
Design Requirements as part of PDP
Design &
Development
Phase
• D&D Plan
• DI Documents
• RAMT
• DTM
DI & Planning
Review
Development
Phase
Proceed
Stopped
Revise
Planning Phase
Core Team
Formed
Team Training & Activities:
•Planning
•Design Input
•Risk Management
•Design Traceability
6. 6
Design Requirements & Analysis
Role of
Requirements
Sources & Tools
of Requirements
Gathering
Characteristics of Quality
Requirement Statement
Design Control Architecture:
PCD, SRD & SSRD
8. 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. 9
The Role of Requirements
Why 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. 10
The Role of Requirements
Advantages 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. 11
The Role of Requirements
Consequences 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. 12
The Role of Requirements
Cost Pyramid
Requirements
Architecture
Detailed Design
Manufacturing
Verification
Field Action
13. 13
The Role of Requirements
A Case Study
Incomplete requirement set on diagnostic device
regarding priority of error reporting
3 stated requirements
1. Requirement for reading > 500 reported as ‘high’ result
2. 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. 14
The Role of Requirements
A 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
Potential danger to customers
Lost opportunities
Direct financial loss
15. 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. 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. 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. 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. 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
24. 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. 25
Tool for Gathering Requirements
Ishikawa Fishbone (cause-and-effect) Diagram
SMBG System
Electronics
Requirements
Labeling
Requirements
Mechanical
Requirements
Software
Requirements
Strip & Reagent
Requirements
Other
Requirements
26. 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. 27
Tool for Gathering Requirements
Quality Function Deployment (QFD)
Relationship
Customer to System
Customer(PCD)
System
Priority
Importance
System to Subsystems
Relationship
Subsystems
Importance
Priority
System
28. 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
30. 30
Characteristics & How to Check for Goodness
Characteristics that Individual Requirement Statement
Should Exhibit:
Necessary
Concise
Implementation Free
Attainable
Complete
Consistent
Unambiguous
Verifiable
Correct
Feasible
Prioritized
31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 43
Requirement Fundamentals
Before & After Examples
Original: "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. 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. 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. 46
Design Control Architecture
PCD Product Criteria
Document
SRD
System Requirement
Document
SRS RRSMRS ERS
Subsystem Requirement Documents (SSRD)
LRSPRS
47. 47
Design Control Architecture – PCD
Characteristics:
User/Customer Needs
A review of the Customer’s needs based upon Market Research and
Focus Groups.
Intended Use
A 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. 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 Needs
Specific Requirements mandatory for product acceptability (e.g. COGS,
Quality, Reliability, etc.).
Others
Design for Manufacturability
Testability
Customer Service
49. 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 Criteria
Examples 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. 50
Design Control Architecture – PCD
Intended Uses
Examples 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. 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 Criteria
Examples 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. 52
Design Control Architecture – PCD
Others
Examples 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.
54. 54
Design Control Architecture – SRD
Characteristics:
Functional
Functional requirements specify what the design does. Focus is on the
operational capabilities, the processing of inputs and the resulting outputs.
Physical & Performance
Physical 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.
Interface
Interface requirements specify characteristics that are critical to compatibility
with external systems (including user and/or patient interface, if applicable).
Others
55. 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 Requirements
Example 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 Requirements
Example 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. 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 Requirements
Example 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. 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 Requirements
Examples 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 Requirements
Examples 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.
59. 59
Design Control Architecture – SSRD
Functional
Physical & Performance
Interface
General Design Goals & Constraints
SRS RRSMRS ERS
Subsystem Requirement Documents (SSRD)
LRSPRS
60. 60
Design Control Architecture – SSRD
Characteristics:
Functional
Functional requirements specify what the design does. Focus is on the
operational capabilities, the processing of inputs and the resulting outputs.
Physical & Performance
Physical 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.
Interface
Interface 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. 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
63. 63
Software
Functional Requirements
The 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. 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. 65
Software
User Interface Requirements
Describe 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. 66
Software
External Interface Requirements
External 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. 67
Software
Performance Interface Requirements
Describe 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.
70. 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
76. 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. 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
84. 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 Requirements
Example: The monitor label shall include a LifeScan copyright symbol.
Owner’s Booklet
User Needs
Example: 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 Requirements
Example: The Owner’s Booklet shall include an artwork number.
85. 85
Labeling
Logbook
User Needs
Example: The logbook shall provide space to record the result of each test.
LifeScan Labeling Requirements
Example: The Owner’s Booklet Addendum shall include an artwork number.
monitor Kit Carton Labeling
User Needs
Example: 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 Requirements
Example: The monitor carton label shall contain LifeScan copyright notice.
Labeling on the Test Strips
User Needs
Example: 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. 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/Statutory
Example: 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/Statutory
Example: 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. 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 Needs
Example: 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 Requirements
Example: 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 Requirements
Example: The monitor shipper labeling shall contain a product number and barcode.
88. 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 Requirements
Example: The test strip shipper labeling shall contain a part number and
barcode.
Instructor’s Guide
Intended Use
Example: 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.
The physical and performance requirements specify how much or how well the design must perform. The requirement statements address such issues as speed, strength, size, weight, response times, accuracy and precision, limits of operation, etc.
Interface statements specify characteristics that are critical to compatibility with external systems, including user and/or patient interfaces. This section also addresses issues that are relevant to the human factors component.