Project Management Template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1 IDENTIFICATION 1
1.1 Document overview
1.2 Abbreviations and Glossary
1.2.1 Abbreviations
1.2.2 Glossary
1.3 References
1.3.1 Project References
1.3.2 Standard and regulatory References
1.4 Conventions
2 Project Management
2.1 Team, responsibilities
2.2 Work breakdown structure, tasks, planning
2.2.1 Task n
2.3 Resource identification
2.4 Relationships with project stakeholders
2.4.1 Customer or end-user involvement
2.4.2 Subcontractor management
2.4.3 Relationships with other teams
2.5 Communication
2.5.1 Meetings
2.5.2 Reviews
2.6 Training
3 System requirements and project input data
4 Configuration management
4.1 Software configuration management
4.2 Documentation configuration management
5 Software development management
5.1 Software development process
5.2 Software development tools
5.2.1 Tools
5.2.2 Obsolescence management
5.3 Software development rules and standards
6 Tests phases management
6.1 Integration tests
6.2 Verification tests
6.2.1 Phase 1
6.2.2 Phase 2
7 Problems resolution
1 IDENTIFICATION
1.1 Document overview
This document contains the project management plan of software XXX.
1.2 Abbreviations and Glossary
1.2.1 Abbreviations
Add here abbreviations
1.2.2 Glossary
Add here words definitions
1.3 References
1.3.1 Project References
# Document Identifier Document Title [R1]IDdd your documents references.
One line per document
1.3.2 Standard and regulatory References
# Document Identifier Document Title
[STD1] ISO 13485:2003 Medical devices - Quality management systems
- Requirements for regulatory purposes
[STD2] ISO 14971:2007 Medical devices - Application of risk management ...
[STD3] IEC/TR 80002-1:2009 Medical device software ...
[STD4] ISO 62304:2006 Medical Devices - Software life cycle processes
1.4 Conventions
- Typographical convention.
- Any other convention.
2 Project Management
[the section describes the organizational structure of the XXX
project, the corresponding responsibilities and the flows of internal
information.]
2.1 Team, responsibilities
The organizational structure is: Describe the team, if necessary
Title Name Responsibilities
Project Manager John Smith Manages costs, quality, schedule of the project,
manages relationship with end users.
...
2.2 Work breakdown structure, tasks, planning
The tasks of the project are described in the table below.
Insert a table or list or diagram describing the tasks.
The Working Breakdown Structure (WBS) of the XXX project identifies all the tasks to the development of XXX product. If necessary, add a WBS codification.
The planning below contains all tasks of the project and the links between tasks.
Insert a table or list or diagram describing the planning.
Remark: for small projects, a gantt diagram is enough for this section!
Important, list the deliverables and reviews of each phase of the project
2.2.1 Task n (Example)
Optional, add a sub-section for each task with:
- Inputs of the task
- Content of the task
- Outputs of the task
- Task reviews (in, if necessary, and out).
Verification tasks are described more precisely in "verification tests" section.
If you instantiate the "software development plan" document, you may add a
reference to that doc and remove these sub-sections.
2.3 Resource identification
If specific resources are need for the project such as a
calibrated measurement tool or a simulator, they shall be identified,
referenced and managed in configuration.
2.4 Relationships with project stakeholders
2.4.1 Customer or end-user involvement
Describe how the customer or end-user is involved in the software
development: meetings, reviews, and presentations of intermediate
versions
2.4.2 Subcontractor management
Describe how subcontractors are managed: statement of work,
reviews, validation, verification
2.4.3 Relationships with other teams (Optionnal)
Describe relationships with other teams of your company, like the
team in charge of the system design.
2.5 Communication
2.5.1 Meetings
Describe what kinds of meetings are organized during the project
and what happens in these meeting. This may be described in your
quality management system. In this case, this section is not
necessary.
2.5.2 Reviews
Describe what kinds of reviews are organized during the project:
launch review, design reviews, tests reviews and what happens in
these reviews. This may be described in your quality management
system. In this case, this section is not necessary.
2.6 Training
Describe training of people involved in the project, if necessary.
3 System requirements and project input data
Reference here the input data from your project , non limited list :
- Intended use
- End user requirements (they may be very unstructured ! like meeting reports)
- Statement of work of your customer
- System requirements
- Risk analysis
- Legacy system documentation
- Any other input data
And how you manage their possible modification.
4 Configuration management
If you instantiate the software configuration management plan
document, you may add a reference to that doc and leave this section
and subsections blank.
4.1 Software configuration management
The management of the software configuration may be included in this
section: what kind of SCM tool is used, when branches are made etc...
How is the scm database saved or archived, when and where
How a version is extracted and delivered, for verification phases,
for final delivery, for patches and service packs
It may be also described either in your quality management system
procedures or in a software configuration management plan.
4.2 Documentation configuration management
This section present the documentation management rules for all
documents sent or received during the XXX project. It may be also
described in your quality management system procedures. In this case,
this section is not useful.
5 Software development management
If you instantiate the "software development plan" document, you may
add a reference to that doc and leave this section and subsections
blank.
5.1 Software development process
The software development process chosen for the project is the
waterfall/SCRUM/Extreme programming model (choose yours). The
waterfall/SCRUM/Extreme programming model was chosen for the reasons
below: add justification.
5.2 Software development tools
5.2.1 Tools
Describe the IDE, the SCM tools, any tool used to write and manage
requirements, code and configuration. Dont forget their versions.
SCM tools are described more precisely in « configuration management »
Examples
- Eclipse + list of plugins or VS2010 + list of plugins
- Purify, boundschecker,
- Git, redmine, Hudson,
- Clearcase,
- Rational Rose, Together J,
- Doors (erk !),
- Bugzilla,
- Any Open source product
- Willy Waller 2006
- And so on
5.2.2 Obsolescence management
Describe how you manage the obsolescence of software development tools :
- Either you update them when a new version comes up
- Or you stick to a version during the developpement and maintenance.
Explain you choice.
5.3 Software development rules and standards
Describe here the standards and rules used for software
development, like modelling (UML), data modelling, coding rules,
6 Tests phases management
If you instantiate the software development plan document and
describe phases in that doc, you may add a reference to that doc and
leave this section and subsections blank.
6.1 Integration tests (Optional)
Describe how integration is managed Phases, reviews, documentation
Even if this may be described in your quality management system, I
recommend you to describe what is forecasted.
6.2 Verification tests
Describe how verification tests are managed. Phases, reviews,
documentation
Even if this may be described in your quality
management system, I recommend you to describe what is forecasted.
Tests is often the weak link of soft development. Thinking about
tests at the beginning of the project is worth the effort.
Example:
Tests are split in four phases:
* Alpha 1 tests: in this phase, V0.1 of software will be tested.
Testers will be the software development team. Each member tests a
portion of software developed by another member. Software will be
directly tested on the development platform
* Alpha 2 tests: in this phase, V0.5 of software will be tested.
Tester will be the software integrator. Software will be installed on
the integration and test platform.
* Beta 1 tests: in this phase, V0.8 of software will be tested.
Tester will be the software integrator and selected end-users.
Software will be installed on the integration and test platform.
* Beta 2 tests: in this phase, V0.9 of software will be tested.
Testers will be selected end-users. Software will be installed on the
pilot platform in.
Tests phases are described in the software tests plan OR below:
6.2.1 Phase 1
Describe the verification phase:
- In: what is verified (version Vx.y.z)
- Tasks: how it is verified (tests are done according to software test description doc XXX)
- Out: the test report
- Acceptation criteria: how the tests are passed or failed.
Example of acceptation criteria, with bugs levels ratios (dummy but very effective):
- Alpha tests: all blocking bugs are fixed
- Beta tests: all major bugs found in alpha tests are fixed and less than 20% of remaining bugs are major
- Final version: all major bugs are fixed and 90% of minor bugs are fixed.
Example of acceptation criteria, with rationale about requirements:
- Alpha tests: tests about critical requirements (like those from
risk analysis) are passed and requirements about system-software
interfaces are passed
- Beta tests: tests on previous requirements and tests on
requirements about main use cases are passed
- Final version: all tests are passed
6.2.2 Phase 2
Repeat the pattern for each phase
Describe the verification phase:
- In: what is verified (version Vx.y.z)
- Task: how it is verified (tests are done according to software
test description doc XXX)
- Out: the test report
- Acceptation criteria: how the tests are passed or failed.
7 Problems resolution
Describe here how bugs, requests, questions anything coming from
anyone outside the software development team. Especially for bugs,
how they are recorded, tracked, fixed.
It may be also described in your quality management system
procedures. In this case, this section is not useful.
Remark: there is no risk management section in this document. This
is voluntary, the risk management plan is an important document and
cannot be a section of project management.
Risk Management Plan template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1 Introduction 2
1.1 Document overview 2
1.2 References 2
1.2.1 Project References 2
1.2.2 Standard and regulatory References 3
2 Risk management during software development 3
2.1 Organization and Responsibilities 3
2.2 Qualification of personnel 3
2.3 Objective of risk management activities 3
2.4 Tasks, Planning 4
2.4.1 Task n 4
2.4.2 Risk analysis initialization 4
2.4.3 Risk analysis update 5
2.5 Criteria for Acceptability of Risk 5
2.6 Verification and Risk traceability matrix 5
2.7 Approvals 5
2.8 Location of Risk Management File 5
3 Risk management after software development 5
3.1 Organization and Responsibilities 5
3.2 Qualification of personnel 6
3.3 Production and maintenance information 6
3.4 Annual Audit 6
4 Ranking System for Risk Analysis 6
4.1 Probability of Occurrence 6
4.2 Consequences of Hazard 7
4.3 Add your other criteria 7
4.4 Determination of risk priority number 7
4.5 Criteria for acceptability 8
1 Introduction
1.1 Document overview
This document covers the risk management plan of XXX device, designed in XXX software development project.
It contains:
- The risk management organization and process during the software
development project,
- The risk management organization and process during maintenance,
after final delivery of the software development project.
Note: most of times, risk management organization is very different
before and after design. You may split the risk management plan in
two documents, the first one before end of design, the second one
after the end of design.
1.2 References
1.2.1 Project References
Document Identifier Document Title
[R1] ID Add your documents references.
One line per document
1.2.2 Standard and regulatory References
# Document Identifier Document Title
[STD1] Add your documents references.
One line per document
Add the standard references to the table above.
2 Risk management during software development
This chapter covers the risk management process and organization
during the software development.
2.1 Organization and Responsibilities
Describe the organization of the team responsible for risk
management during design. You may add an organization chart or add a
reference to your project management plan, where the organization of
the project should be already described.
Person Responsibility
Project Manager * Overall management process responsibility
* Risk Management Plan development
* Creation and update of Risk Analysis Table
* Creation and update of Risk traceability matrix
* Creation and update Risk Analysis Report
Quality Manager * Independent review of Risk Management File
2.2 Qualification of personnel
Describe the qualification of personnel responsible for the risk
management and risk analysis activities. Example:
The personnel who participates to the risk analysis is composed of:
- Experienced staff who was involved in the design process of similar products
- The expert praticians who participate to the design process
2.3 Objective of risk management activities
The objective of risk management activities is to deliver a risk
analysis report, which contains:
- The device characteristics that could impact on safety (ISO 14971),
- The software safety classification (IEC 62304),
- The risk analysis table,
- The risk traceability matrix with design requirements,
- The overall assessment of residual risk.
The risk analysis table and risk traceability matrix will be created
and updated as necessary during software development, according to
tasks described in §2.4.
Data on the risk analysis table includes:
- List the columns, according to your risk analysis table in your risk analysis report,
Data on the risk analysis table includes:
- List the columns, according to your risk traceability matrix in
your risk analysis report,
See the risk analysis report template for columns samples.
Note: The Risk analysis may be performed with the help of the table
B.1 in IEC/TR 80002-1.
The risk analysis report will summarize whether identified and
mitigated risks meet the acceptable values defined in this plan. It
will also include a statement indicating whether all known hazards
have been identified.
The Risk Management File gathers this document and all documents quoted above.
2.4 Tasks, Planning
Describe how the risk management activities are planned during the project.
The planning of risk activities shall be coherent with the planning
of the project found in §2.2 of the project management plan.
Insert a table or list or diagram describing the planning.
Important, list the deliverables and reviews of each phase of the project
2.4.1 Task n
Optional, add a sub-section for each task with:
- Inputs of the task
- Content of the task
- Outputs of the task
- Task reviews (in, if necessary, and out)
- Relationship with development planning.
Note: The tasks may group sets of activities found in §4 to §7 of ISO14971.
Examples of tasks below:
2.4.2 Risk analysis initialization
During this phase, the following activities are performed:
identification of intended use, identification of characteristics
affecting the safety, assignation of safety class (see §2.5.1)
identification of hazards, evaluation of hazards, and identification
of foreseeable mitigation actions.
- Inputs: publications, clinical data, any information prior to design phase
- Two meetings with clinicians involved in the design process
- Outputs: intended use, safety characteristics and hazards,
creation of risk analysis
- Relationship with development planning: Output data of this task
is input data for specification
- End of Task review: review of risk analysis in draft version.
2.4.3 Risk analysis update
During this phase, the following activities are performed:
identification of mitigation actions, evaluation of hazards after
mitigation and analysis of risk/patient outcome ratio.
- Inputs: publications, clinical data, any information prior to design phase
- Two meetings with clinicians involved in the design process and system architect
- Outputs: Update of risk analysis
- Relationship with development planning: this task is performed during specifications
- End of Task review: review of risk analysis in first revision.
2.5 Criteria for Acceptability of Risk
Warning: I recommend you to read carefully §3.4 of IEC 80002-1 to
understand how probability of occurrence is determined for software
failure.
Risks will be evaluated in accordance with Risk Management Procedures for:
- Probability of occurrence
- Consequence of hazard
- Any other criteria of your choice, like probability of detection
Based on the risk priority number, for each hazard analyzed for
XXXX , the Residual Risk will be considered Acceptable if the risk
priority number value is less than .
Based on the risk priority numbers, the Overall Residual Risk for a
device will be considered acceptable if the following conditions are
satisfied:
1. None of the identified hazards leads to an unacceptable risk
(i.e., no risk priority number above is
identified); and
2. Another quantitative criterion of your choice
3. Another one
Any risk priority numbers above these values need to have actions
taken to reduce the risk.
2.6 Verification and Risk traceability matrix
Verification testing activities will be cross-referenced in the
risk traceability matrix, as applicable.
2.7 Approvals
The Risk Management Plan must be reviewed and approved by XXXX prior
to the start of the risk assessment process.
The Risk Analysis Report will be reviewed and approved by XXXX to
ensure completeness and conformance to this Risk Management Plan.
2.8 Location of Risk Management File
The Risk Management File is located in XXX (for example a document
management tool defined in the software development plan or project
management plan). This file contains all the documents related to the
management of risk for the device and is kept for the life of the
product.
3 Risk management after software development
3.1 Organization and Responsibilities
Describe the organization of the team responsible for risk
management after software development. You may add an organization
chart.
Discard if unchanged and during and after software development
Maintenance Manager * Overall management process responsibility
* Annual Risk Management File Review
* Update of Risk Analysis Table
* Update of Risk traceability matrix
* Update Risk Analysis Report
* Independent review of Risk Management File
3.2 Qualification of personnel
Describe the qualification of personnel responsible for the risk
management and risk analysis activities.
Discard if unchanged and during and after software development.
3.3 Production and maintenance information
The Risk Management File is systematically reviewed and updated in
the maintenance of the device, especially when:
* The product is modified (software patch, minor updates),
* Analysis of data of post marketing surveillance triggers a
reevaluation (internal defects, customer requests, maintenance,
vigilance bulletins, of field information from any source),
3.4 Annual Audit
Reviews and updates to the Risk Management File will be done
annually (choose your periodicity)
Reviews and updates to any risk related document will be
documented, approved, and included within the Risk Management File.
4 Ranking System for Risk Analysis
This section describes how the risk priority number is deduced from
the characteristics of the risk:
* List the criteria defined in §2.2.
Describe in sub sections how you quantify your criteria, like these:
4.1 Probability of Occurrence
Use quantitative criteria. Here is an example.
Ranking Definition Frequency (F)
----------------------------------------------------------------------
5 Every month Frequent (very high probability)
----------------------------------------------------------------------
4 Once every year Probable (high probability)
----------------------------------------------------------------------
3 Once in last 5 years Occasional (moderate probability)
----------------------------------------------------------------------
2 Once in last 10 years Unlikely (low probability)
----------------------------------------------------------------------
1 Zero occurrence in the Very Unlikely (very low probability)
past 10 years with
similar products
----------------------------------------------------------------------
4.2 Consequences of Hazard
Use criteria based on damages on patient and/or user
Ranking Definition Clinical and Process End Effects
5 Catastrophic Serious injury (irreversible) or death of the patient or user
4 Critical Serious injury (reversible) to the patient or user.
New treatment required.
3 Moderate Moderate injury to the patient or user. Longer treatment
time or new minor treatment required.
2 Minor Minor injury to the patient. Longer treatment time
1 Negligible/ No injury to the patient or user.
Cosmetic
4.3 Add your other criteria
Your definition
4.4 Determination of risk priority number
A rule of your choice, like.
Risk priority number = criterion 1
x criterion 2
...
x criterion n
Example of cross-table of RPN with two criteria:
CROSS TABLE OF RISK PRIORITY NUMBER
Frequent 5 10 15 20 25
5
Probable 4 8 12 16 20
4
Occasional 3 6 9 12 15
3
Unlikely 2 4 6 8 10
2
Very Unlik. 1 2 3 4 5
1
Negligible Minor Important Critical Catastrophic
1 2 3 4 5
4.5 Criteria for acceptability
Acceptability per risk priority number is: (choose your own)
* If the risk priority number is 1 to xx the risk is acceptable -
No recommended actions are required.
* If the risk priority number is xx to yy the risk is tolerable -
Some actions may be used, where possible, to lower the level.
* If risk priority number is above yy the risk is unacceptable.
Mitigation action must be implemented to lower the level.
Soft. Requirement Specs template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1 INTRODUCTION 3
1.1 Document overview 3
1.2 Abbreviations and Glossary 3
1.2.1 Abbreviations 3
1.2.2 Glossary 3
1.3 References 3
1.3.1 Project References 3
1.3.2 Standard and regulatory References 3
1.4 Conventions 3
2 REQUIREMENTS 5
2.1 States 5
2.2 Functionalities and Performance 5
2.3 Safety, security, and privacy protection 6
2.4 User maintenance 6
2.5 Usability and human-factors engineering 6
2.5.1 Man machine interface layout 6
2.5.2 Help 7
2.6 Regulatory requirements 7
2.7 System environment 7
2.8 External interfaces 7
2.8.1 Hardware interfaces 8
2.8.2 Network interfaces 8
2.8.3 Data exchange 8
2.9 Resources 8
2.9.1 Hardware resources 8
2.9.2 Software resources 8
2.10 Internal data 8
2.11 Adaptation 8
2.12 Verification 8
2.13 Personnel and training 9
2.14 Packaging and installation 9
3 VERIFICATION METHODS 10
4 REQUIREMENTS TRACEABILITY 12
5 CRITICAL REQUIREMENTS 13
1 INTRODUCTION
1.1 Document overview
This document presents the software requirements
specifications of XXX software development project.
It describes:
* Requirements of functionalities, performances, interfaces, environment ...
* Tests principles and definitions of validation methods of requirements,
* The compliance of requirements to customer needs,
* The relative importance and precedence of requirements
1.2 Abbreviations and Glossary
1.2.1 Abbreviations
Add here abbreviations
1.2.2 Glossary
Add here words definitions
1.3 References
1.3.1 Project References
# Document Identifier Document Title
[R1] ID Add your documents references.
One line per document
For example a statement of work,
a user interface mock-up ...
1.3.2 Standard and regulatory References
# Document Identifier Document Title
[STD1] Add your documents references.
One line per document
For example: ISO 13485, ...
1.4 Conventions
Requirements listed in this document are constructed according to
the following structure:
Requirement ID SRS-XXX-000
Title Title of XXX-000 requirement
Description Description of XXX-000 requirement
Version Version of XXX-000 requirement
Example:
Requirement ID SRS-GUI-010
Title Main Window Background Color
Description The background color of the main window is grey RGB(192,192,192)
Version V1.0
2 REQUIREMENTS
Note : have a look at http://en.wikipedia.org/wiki/Requirement,
article in wikipedia. It's well written and the links at the bottom
are useful.
2.1 States
FOO software works in three states:
* Starting: the software loads its components;
* In use: all the functionalities of the software are available to the users;
* Stopping: the software is being stopped.
* Maintenance: the software is in maintenance mode
* And so on ...
Add a diagram with states and transitions if necessary
2.2 Functionalities and Performance
This is the core of your SRS. It contains the purpose of your
software expressed in technical requirements
You may organize this part in sub-sections like:
* Module 1
o Function 1.1
o Sub-Function 1.1
o Sub-Function 1.2
o ...
o Function 1.2
o Sub-Function 1.1
o Sub-Function 1.2
o ...
o ...
* Module 2
o ...
...
Choose your own structure which best fits your needs.
Requirements shall not be vague. They shall be understandable and testable.
Ask yourself "How am I going to test this?" when you write a requirement
Examples of requirement:
Requirement ID SRS-XXX-010 SAMPLE
Title Sample requirement about a function
Description FOO software shall compute the zzz parameters with the
a, , c and d input parameter, with the use of the XXX algorithm.
Version V1.0
Requirement ID SRS-XXX-020 SAMPLE
...
2.3 Safety, security, and privacy protection
This section is about software features like confidentiality, integrity control, reliability, and availability. You can add subsections on:
· Confidentiality, security, integrity,
· Virus, malware protection
· Operational security
See CyberSecurity requirements of FDA
See also 2016/679 GPDR in Europe if necessary of data privacy
Requirement ID SRS-XXX-030 SAMPLE
Title Patient data
Description XXX stores patient data with a checksum to ensure their integrity.
Version V1.0
Requirement ID SRS-XXX-030 SAMPLE
Title Password protected functions
Description The following functions are protected by password:
* Configuration
* Firmware update
Version V1.0
2.4 Personal Data
This section is about management of personal data to be compliant with regulations.
See HIPAA requirements, See also 2016/679 GPDR in Europe, especially articles 15 to 22
Requirement ID SRS-XXX-130 SAMPLE
Title Right to forget
Description XXX software has a function to delete all patient data.
The deletion is permanent and not reversible
Version V1.0
2.5 User maintenance
Maintenance functions accessible by users or by administrators. Do sub-sections if there are different types of users.
Requirement ID SRS-XXX-040 SAMPLE
Title Application logs
Description XXX generates a log file containing:
* The state of the application and the steps performed to reach
that state,
* The possible error logs, if any.
Version V1.0
2.6 Usability and human-factors engineering
The requirements here may have traceability with the results of 62366 standard
implementation
2.6.1 Man machine interface layout
The layout of XXX is ....
Instead of a dozen of text requirements, a mock-up of the software
GUI is very appreciated
Add only requirements for which a description of layout/behaviour is necessary and/or
requested by a user.
Requirement ID SRS-XXX-050 SAMPLE
Title Menu items and other widgets
Description XXX software has the following items:
* Menu file ...
* Widgets in the main window (slider, button, radiobutton, textfield).
* ...
Version V1.0
2.6.2 Help
The user guide is always very important for medical devices. It
may be online, in this case add requirements here about the online
help ....
Requirement ID SRS-XXX-060 SAMPLE
Title Online user guide
Description XXX contains an online user guide
Version V1.0
2.7 Regulatory requirements
Regulations can have an impact on software design. For example,
this is the case with the future Unique Device Identification of FDA.
An about window is a good way to identify software version and provide a UDI....
Requirement ID SRS-XXX-070 SAMPLE
Title About XXX
Description XXX shall display an "About..." window. This window displays the current
version of the application.
Version V1.0
...
2.8 System environment
If software is integrated in a specific system, describe briefly
the system and add specific requirements for the integration of your
software in this system
Warning : for PEMS/Electro-medical Devices with a big system architecture, a system
architecture document is necessary to describe the system/software architecture.
2.9 External interfaces
This section describes hardware and software interfaces of the software in the system
2.9.1 Hardware interfaces
For PEMS/Electro-medical Devices, add requirements about
integration of software and hardware.
2.9.2 Network interfaces
Also add here communication and networks stuff, like IP, wireless, Bluetooth ...
2.9.3 Data exchange
If XXX software is in interface with other software, describe here
the requirements on data exchanges.
2.10 Resources
2.10.1 Hardware resources
Requirement ID SRS-XXX-080 SAMPLE
Title Hardware configuration
Description XXX shall run with the expected response times on a PC with the
following minimal configuration:
* 2 Go RAM
* ...
Version V1.0
2.10.2 Software resources
Requirement ID SRS-XXX-090 SAMPLE
Title Software configuration
Description XXX runs in the following software environment:
* (describe OS version),
Version V1.0
2.11 Internal data
If specific requirements for internal data, like databases, binary files, xml ...
It can be necessary to specify internal data if their design mitigates a risk
2.12 Configuration or Adaptation
If specific requirements adaptability or configuration of software
2.13 Verification
Special functions to test the software, if necessary. For example
a hidden function to activate a log file during beta tests. But not a
backdoor or a security hole!!!
2.14 Personnel and training
Requirements about the capabilities/knowledge of users, the
training they shall have before using software
Requirement ID SRS-XXX-USR-010 SAMPLE
Title E-learning
Description XXX is delivered with e-learning module.
Version V1.0
2.15 Packaging and installation
Requirement ID SRS-XXX-PAK-010 SAMPLE
Title Packaging
Description XXX shall be delivered on zzz media.
Version V1.0
Requirement ID SRS-XXX-PAK-010 SAMPLE
Title Install-shield
Description XXX shall be installed with the use of an install shield.
Version V1.0
3 VERIFICATION METHODS
Discard this section if you don't want to have verification
methods attached to your requirements.
The verification methods of the requirements are defined below:
• Inspection (I): control or visual verification
o Control of the physical implementation or the installation of
a component. The control verifies that the implementation or the
installation of a component is compliant with the requirements of
diagrams.
o Control of the documentation describing a component. The control verifies that
the documentation is compliant with the requirements.
• Analysis (A): verification based upon analytical evidences
o Verification of a functionality, performance or technical solution of a component
by analyzing the data collected by tests in real conditions, by simulation of real
conditions or by a analysis report.
o Analysis of test data or of design data is used as appropriate to verify
requirements.
o The verification is based upon analytical evidences obtained by calculations, like
modeling, simulation and forecasting.
o Analysis is used when an acceptable level of confidence cannot be established by
other methods or if analysis is the most cost-effective solution.
• Demonstration (D): verification of operational characteristics, without quantitative
measurement
o Verifying a requirement by demonstration implies that the
required functionality specified by a requirement is complete.
o Demonstration is used when quantitative measurement is not required for
verification of the requirements
o Demonstration includes the control of the technical solutions specified by the
non-functional requirements.
• Test (T): verification of quantitative characteristics with quantitative measurement
o Verifying a functionality, performance or technical solution of a component by
executing testing scenarios in predefined, controlled and traceable testing
conditions.
o Tests require the use of special equipment, instrumentation, simulation
techniques, or the application of established principles and procedures,
o Data produced during tests is used to evaluate quantitative results and compare
them with requirements.
For each requirement of the SRS, a verification method is defined.
Method is abbreviated I, A, D or T.
Requirement ID Requirement Title Method
REQ-001 Verify that the speed is displayed in rpm D
REQ-001 Verify background color is blue I
Note: do not mistake the two meanings of the word "test" in this document:
• The method of verification, named Test and abbreviated (T), as defined above.
• A test, or test case, is a sequence of actions to verify a
requirement. Tests are defined in the software test plan.
Examples of tests methods:
Inspection:
• Verify that the color of background is blue,
• Verify that the user manual has the CE mark on its cover
• Verify that the PC has 4Gb memory
• Verify that firmware version on electronic card is 1.0.1
Demonstration
• Verify that when the user closes the window, a confirmation message appears
• Verify that the file is saved in the output directory
• Verify that the result is shown
• Verify that if a value is out of range, a warning is displayed
Analysis:
• Verify that the statistical distribution of results of xxx
algorithm is a Gaussian with mean=x and stdev=y, when input
data are blah blah
• Verify that the linear regression of results of xxx algorithm
is a line which value is 1 on the y-axis, at zero on the x-axis,
Test:
• Verify that a file of 1Gb is processed in less than 3s
• Verify that the response time of the server is 15ms with 20 simultaneous requests
Rule of thumb for software, 80% of requirements are verified by
demonstration, 15% by inspection and 5% by analysis or test methods.
4 REQUIREMENTS TRACEABILITY
Add a table with traceability of software requirements of this
document with user or system requirements.
Example
SRS Req. Req Title Functional Req. Req. Title
SRS-REQ-001 Reading ECG values FUN-REQ-00A ECG post treatment
SRS-REQ-002 Writing results FUN-REQ-00A ECG post treatment
5 CRITICAL REQUIREMENTS
If necessary, add a list of critical requirements, or a list of reference to requirements in previous sections.
This list may be the result of risk analysis (ISO 14971).
Examples
Requirement ID Requirement Title Origin
REQ-001 Alarm when value out of range Risk Analysis
REQ-002 Do not open file if no patient Risk Analysis
name
REQ-003 Display negative values in red Human factor engineering
color
System Architecture Template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1 Introduction 2
1.1 Document overview 2
1.2 Abbreviations and Glossary 2
1.2.1 Abbreviations 2
1.2.2 Glossary 2
1.3 References 2
1.3.1 Project References 2
1.3.2 Standard and regulatory References 2
1.4 Conventions 2
2 Architecture 3
2.1 Architecture overview 3
2.2 Logical architecture overview 3
2.2.1 Software Component 1 description 3
2.2.2 Software Component 2 description 3
2.2.3 Software Component 3 description 3
2.3 Physical architecture overview 3
2.3.1 Hardware Component 1 description 3
2.3.2 Hardware Component 2 description 4
2.3.3 Hardware Component 3 description 4
2.4 Software COTS 4
3 Dynamic behaviour of architecture 5
3.1 Workflow / Sequence 1 5
3.2 Workflow / Sequence 2 5
4 Justification of architecture 6
4.1 System architecture capabilities 6
4.2 Network architecture capabilities 6
4.3 Risk analysis outputs 6
4.4 Human factors engineering outputs 6
5 Requirements traceability 7
1 Introduction
1.1 Document overview
This document describes the architecture of XXX system.
It describes:
* A general description of the system
* The logical architecture of software, the layers and top-level components
* The physical architecture of the hardware on which runs the software
* The justification of technical choices made
* The traceability between the architecture and the system requirements.
1.2 Abbreviations and Glossary
1.2.1 Abbreviations
Add here abbreviations
COTS: Components Off the Shelf (software industry acronym)
OTSS: Off The Shelf Software (FDA acronym)
SOUP: Software Of Unknown Provenance (IEC 62304 acronym)
1.2.2 Glossary
Add here words definitions
1.3 References
1.3.1 Project References
# Document Identifier Document Title
[R1] ID Add your documents references.
One line per document
1.3.2 Standard and regulatory References
# Document Identifier Document Title
[STD1] ID Add your documents references.
One line per document
1.4 Conventions
Add here conventions
For example for diagrams.
COTS, OTSS and SOUP refer to the same concept, i.e. software delivered by 3rd party that wasn't
developed with a regulatory and/or normative compliant development process.
We deliberately use the term "SOUP", to focus on IEC 62304 compliance.
2 Architecture
2.1 Architecture overview
Give a general description of the system, from the point of view of the user:
• In what environment it works (home, near patient bed, operating room ...)
• Who the users are
• What it is for,
• The main functions,
• The main interfaces, inputs and outputs.
If your software is integrated in a larger system, you may reference a document that describes
this system.
2.2 Physical architecture overview
Describe the hardware components on which software runs and their interactions/relationships
Use components diagrams, deployment diagrams, network diagrams, interface diagrams...
2.2.1 Hardware Component 1 description
Describe the content of each hardware component in the architecture
Optional, you may not do it if your software is not class C according to IEC 62304
The description shall contain:
• Its identification
• The purpose of the component
• The software component it receives
• Its technical characteristics: type of machine, CPU, RAM, disk and so on.
• Its network hardware interfaces
2.2.2 Hardware Component 2 description
Repeat the pattern for each top-level component.
2.2.3 Hardware Component 3 description
Repeat the pattern for each top-level component.
2.3 Logical architecture overview
Describe the top level software components and their interactions/relationships.
Use UML package diagrams and/or layer diagrams and/or interface diagrams.
Describe also the operating systems on which the software runs.
2.3.1 Software Component 1 description
Describe the content of each top-level software component in the architecture
Optional, you may not do it for 2 rationales:
1. Either your software is not class C according to IEC 62304
2. Or you describe each top level component in a SDD.
The description should contain:
• Its identification
• The purpose of the component,
• Its interfaces with other components,
• Its network interfaces,
• The hardware resources it uses, for example: average RAM usage, peak RAM usage and
peak frequency and duration, disk space for permanent data, disk space for cache data,
average CPU usage, peak CPU usage and peak frequency and duration ...
2.3.2 Software Component 2 description
Repeat the pattern for each top-level component.
2.3.3 Software Component 3 description
Repeat the pattern for each top-level component.
2.4 Software SOUP
If you use SOUP (Software Of Unknown Provenance), list them here.
For each SOUP, describe:
• Its identification and version
• Its purpose
• Where it comes from: manufacturer, vendor, university ...
• Wether it is maintained by a third party or not
• If this is an executable,
o What are the hardware / sotfware resources it uses
o Wether it is insulated in the architecture and why
• Its interfaces and data flows
• Which SOUP functions the software uses
• How the SOUP is integrated in the software
• What hardware/software resources it requires for proper use
Note: have a look at FDA Guidance " Off-The-Shelf Software Use in Medical Devices " to
determine if you need specific or special documentation for your COTS.
If there is a list of known bugs on your COTS, you may add here this list with a review of their
consequences in terms of software failure and patient safety. If there are concerns about known
bugs, they should be treated by the risk analysis process.
3 Dynamic behavior of architecture
The architecture was designed to answer to functional requirements.
For each main function of the system, add a description of the sequences / data flow that occur.
Use sequence diagrams, collaboration diagrams
3.1 Workflow / Sequence 1
Describe here the workflow / sequence of a main function
For example, the user queries data, what happens, from his terminal to the database.
3.2 Workflow / Sequence 2
Repeat the patern for each main function of the system
4 Justification of architecture
4.1 System architecture capabilities
Describe here the rationale of the hardware / software architecture in terms of capabilities:
• Performances (for example response time, user mobility, data storage, or any functional
performance which has an impact on architecture)
• User / patient safety (see §4.3 and §4.4)
• Protection against misuse (see 4.4)
• Maintenance (cold maintenance or hot maintenance),
• Adaptability, flexibility
• Scalability, availability
• Backup and restore
• Hardware and Software security : fault tolerance, redondancy, emergency stop, recovery
after crash ...
• Administration,
• Monitoring, audit
• Internationalization
4.2 Network architecture capabilities
If the medical device uses/has a network, describe here the rationale of the hardware / network
architecture:
• Bandwidth
• Network failures
• Loss of data
• Inconsistent data
• Inconsistent timing of data
• Cyber security (see FDA Guidance on Cyber Security of networked medical devices)
4.3 Risk analysis outputs
If the results of risk analysis have an impact on the architecture, describe here for each risk
analysis output what has been done to mitigate the risk in the architecture.
Use diagrams if necessary, like architecture before risk mitigation and architecture after risk
mitigation, to explain the choices.
4.4 Human factors engineering outputs
If (by any chance) the results of human factors analysis have an impact on the architecture,
describe here for each risk output what has been done to mitigate the risk in the architecture.
4.5 Regulation on personal data
If HIPAA or EU Regulation 2016/679 (GDPR) are applicable, describe here how the architecture
is compliant to these regulations. For GDPR, see articles 25 and 32.
4.6 SOUP integration
If the software architecture has a particular structure dedicated to SOUP integration, it can be
described here. For example a wrapper of the SOUP, or an external process + a socket
communication, ...
5 Requirements traceability
Add a table with traceability of components of this document with functional requirements.
Requirement Component Comment
REQ-001 The device shall do foo COMPO-001: foo maker
COMP-001 does foo.
COMP-002 also does
verification of foo result.
This may be a difficult job. A high level function is usually handled by many components. In this
case, quote only the component(s) which has(have) the major role.
Soft.Detailed Design template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1 Introduction 2
1.1 Document overview 2
1.2 References 2
1.2.1 Project References 2
1.2.2 Standard and regulatory References 2
2 Software Architecture overview 3
3 Software design description 3
3.1 Component 1 3
3.1.1 Component interfaces 3
3.1.2 Component design description 3
3.1.3 Workflows and algorithms 4
3.1.4 Software requirements mapping 4
3.2 Component 2 4
3.3 Component 3 4
4 SOUP identification 4
5 Critical Requirements 4
1 Introduction
You may have all the description of the design of your software:
* Either in a single instance of this document
* Or have the design of each component/package/element in many instances of this document.
This is your choice, which depends on the size of your software.
1.1 Document overview
This document describes the design of XXX
component/package/element of XXX device, part of XXX software
development project.
1.2 References
1.2.1 Project References
# Document Identifier Document Title
[R1] ID Add your documents references.
One line per document
1.2.2 Standard and regulatory References
# Document Identifier Document Title
[STD1] ID Add your documents references.
One line per document
Add your documents references.
One line per document
Add the standard references to the table above. It may include ISO/IEC...
Software Architecture overview
Describe here the top-level software components and their interactions/relationships.
Use UML package diagrams and/or layer diagrams and/or interface diagrams.
Describe also the operating systems on which the software runs.
You may reference the system architecture document, if you have
one in your project, which already explains the software architecture.
3 Software design description
If you have a single design document, describe each top-level
package/component of your software, and if necessary
sub-components/sub packages.
* Single instance of design document
o Top-level-component #1 --> described in section 3.1
- Sub-component #1 --> described in section 3.1.1
- Sub-component #2 --> described in section 3.1.2
- And so on...
o Top-level-component #2 --> described in section 3.2
- ...
o Top-level-component #1 --> described in section 3.3
- ...
If you decide to have one design document for each top-level
package/component, describe the content (sub components, sub
packages) of each top-level package/component.
The top-level components shall then be described in the system architecture document
* Top-level-component #1 --> described in instance #1 of SDD document
o Sub-component #1 --> described in section 3.1
o Sub-component #2 --> described in section 3.2
o And so on...
* Top-level-component #2 --> described in instance #2 of SDD document
o ...
* Top-level-component #3 --> described in instance #3 of SDD document
o ...
Use Class diagrams, Collaboration / sequence diagrams, Deployment
diagrams to illustrate your description.
3.1 Component 1
Describe the component with the structuration relevant to the technology you use.
Below are examples of sub-sections to describe components.
If you're in class C, have a look at 5.5.4 of IEC 62304.
3.1.1 Component interfaces
Describe the interfaces of the component and input output data
3.1.2 Component design description
Describe the design of the component, Use package diagrams
and/or class diagrams to show the links between
sub-components/sub-packages and or classes inside the component.
3.1.3 Workflows and algorithms
Use collaboration diagrams and/or sequence diagrams to show the
workflows of components/packages/classes inside the component.
Describe algorithms, if possible. An algorithm may be described
outside this document, in this case, add the reference to that
document.
3.1.4 Software requirements mapping
Class C software only, list the SRS requirements handled by this component
3.2 Component 2
Repeat the pattern for each component.
3.3 Component 3
Repeat the pattern for each component.
4 SOUP identification
Add the list of SOUP used in software. Example:
SOUP libraries used in XXX are the following:
* foo.jar/foo.so/foo.dll, version id, download URL, License
type, requirements traceability
* bar.jar/bar.so/bar.dll, version id, download URL, License type,
requirements traceability
Caution: if SRS requirements are handled by SOUP, then
traceability between SOUP and SRS requirements shall be described
here.
5 Critical Requirements
If requirement were tagged as critical in the SRS, add here the
traceability between these requirements and the components described
in this document. Critical requirements may be those added after risk
analysis.
Requirement ID Requirement title Component Comment
REQ-001 Software shall have Main window Widget added in the
an abort button window layout
-----------
Main window Controller aborts the
controller operation
Meeting report Template
- Date
- Title
- Atendees:
- Atendee 1
- Atendee 2
- ...
- Discusion Points:
- Topic 1.
- Topic 2.
- ...
- Agreed Actions:
- Action 1: ... Deadline: YYYY/mm/dd
- Action 2: ... First Review: YYYY/mm/dd
- ...
Peer to peer Review template
┌─────────────────────────────────────────────────────────────────────
│ Introduction:
│
│ Peer Review process for its internal quality assurance for
│ deliverables to assure consistency and high standard for documented
│ project results.
│
│ - Instructions:
│ The Peer Review is processed individually by selected reviewers.
│ The allocated time for the review is about two weeks. The author of
│ the document has the final responsibility to collect the comments and
│ suggestions from the Peer Reviewers and decide what changes to the
│ document and actions are to be undertaken.
│ Reviewers:
│
│ - [Mr./Ms. NAME] – [ORGANISATION]
│
│
│ - Overall Peer Review Result:
│ - Deliverable is:
│ o Fully accepted
│ o Accepted with reservation
│ o Rejected unless modified as suggested
│ o Fully rejected
│
│ - Please give an overall rating of this deliverable in a scale from
│ (1: very poor to 5: very good) : _______
│
│ - Suggested actions:
│ 1. The following changes should be implemented ...
│ 2. Specify missing chapters / subjects ...
│ 3. Required changes on deliverable essence and contents ...
│ 4. Further relevant required improvements ...
│ ===========================================================
│ - Comments of Mr/Ms X
│ - GENERAL COMMENT
│ These refer to:
│ • Deliverable contents thoroughness
│ • Innovation level
│ • Correspondence to project and programme objectives
│
│ (...comments...)
│ - SPECIFIC COMMENTS
│
│ - Topic A: Relevance
│ - Reviewer comment
│ ...
│ - Author response
│ ...
│ - Topic B: Relevance
│ - Reviewer comment
│ ...
│ - Author response
│ ...
│ - Topic C: Methodological framework soundness
│ - Reviewer comment
│ ...
│ - Author response
│ ...
│ - Topic D: Quality of achievements
│ - Reviewer comment
│ ...
│ - Author response
│ ...
│ - Topic E: Quality of presentation of achievements
│ - Reviewer comment
│ ...
│ - Author response
│ ...
│ - Topic F: Deliverable Layout / Spelling / Format
│ - Reviewer comment
│ ...
│ - Author response
│ ...
└─────────────────────────────────────────────────────────────────────
Risk Management Plan template
It's an important to adhere to ISO 14971.
Soft.Dev. Validation Plan template
- (optional) contains elements to help validating software development tools.
Software Tests Plan template
(Sofware Component Spec Template)
Category : front-end | back-end | Middleware | Service | ...
Description: List of Main responsibilies (features) of this component
Constrains : The list of consraints applying to this component:
Composition: This component reuses/integrates the following building
blocks / products:
- Commercial Product Name, including version
- Open Source project name, including version
Licensing : "Enumerate licensing options for building blocks/ libs:
- Commercial/Open-source; Needed to assess if any OOSS
license prohibtis commercialization of final product
Inputs : - Raw data files (e,g CSV, DBF,...)
- Online data streams (e.g, Twitter API)
- Structured data (JSON, XML, protobuff,...)
- ...
Outputs : - Structured data (e.g, JSON, XML,...)
- Unstructured data (Doc, image, pdf,...)
- ...
Interactions: [Enumerate expected interactions with other components]
Ex:
- Receive stream of events from Kafka hub
- Store "XXX" data in DDBB
Sofware : Ex: this components requires the following base-software
Requirements to operate:
- GNU/Linux AMD64 ....
- Docker/Swarn (min.version)
Hardware : - Recomented: 16 Gb RAM, ...
Requirements
- Minimal: 2 GB RAM ,...
Meeting Output template:
Meeting title: Status and progress meeting
Meeting date: ....
Meeting type: INternal.
Meeting location: Videoconference.
Meeting coordinator: Dnaiel Arosa,
Issue Date: ...
Attendee Name Initials Organisation/Email
...
Meeting Agenda:
1.- ...
2.- Project progress..
3,. Next stesps
Meeting Output Summary:
- Project report:
- Task 1:
- Task 2:
- Task 3:
...
Risk and changes:
- ....
Next steps:
-...
Actions table:
ID Creation date Description Status Target Resolution Owner
... ... .... ... ... ...
Soft.Development Estimation Template
│ estimated │
│ Hours/Days │ Risks(Rº*1 WARN, WARN, WARN:º)
│────────────│ ─────────────
Functional Analysis ·············· │ │
└ User Stores / Sequence Diagrams· │ │
└ GUI definition ················· │ │
└ Privacy/Security Definition ···· │ │
│ │
Module 1: Middleware API │ │
└ API Swagger Definition ········· │ │
└ Implementation │ │
└ Core REST API Server ········· │ │
└ Logic ······················ │ │
└ Error Control, filters ····· │ │
└ Documentation ·················· │ │
│ │
Module 2: Front-End: │ │
└ Control cli Shell ·············· │ │
└ Async notification system ······ │ │
└ Documentation ·················· │ │
│ │
Module 3: BackEnd │ │
└ Development │ │
└ Functional Analysis ·········· │ │
└ Functional Tests ·········· │ │
└ Java Development ············· │ │
└ Documentation ·················· │ │
│ │
Infrastructure: │ │
└ CI Environment ················· │ │
└ Git ·························· │ │
└ Build Pipelines ·············· │ │
└ Backups ······················ │ │
└ Basic Monitoring ············· │ │
└ Cloud Environment ·············· │ │
└ Admin tasks ·················· │ │
└ Deployment Module 1 ·········· │ │
└ Deployment Module 2 ·········· │ │
... │ │
└ Documentation ·················· │ │
Rº*1 WARN, WARN, WARN:º
NOTE that the Risk column can weight more than the Estimation column
in context with high uncertainty as we switch from industrialized
(automated repetitive tasks) to development of new Software Solutions
with non-scoped definition about Use-stories, technology stack,...
Since software is easy to industrialize, many projects fall under the
second alternative and so Risks must be taken as reference over
estimations.
94 Google Docs templates
Source: @[https://www.xataka.com/basics/plantillas-google-docs-para-organizarlo-todo]
- Board Member Accountability Form by The Management Center.
- Business Plan, por Smartsheets. to planify a business model,
describing the company to be created, and anything related.
- Business Plan, by Google. based on text (vs squares). Very
detailed.
- Business Plan with Social Impact Statement.
- Certificate of appreciation, by GooDocs.
- Communication Plan, by ProjectManater.
- Community meeting minutes.
- Company Invoice, by GooDocs.
- Press release:
- Formal Meeting Agenda.
- Invoice professional
- Meeting agenda:
- Receipt template
- Red Blocks Business (Visit) Card.