Biomedical Engineering Reference
In-Depth Information
It is likely that any increased risk probability and decreased risk
detectability will increase the resulting risk priority, requiring additional
scope and rigour with respect to verifi cation activities (design reviews,
testing, etc.). For each of these risks appropriate controls need to be
identifi ed, understanding that it may not be possible to leverage any
supplier activities and that the regulated company will be responsible for
any risk control activities.
Additional risk controls for open source software may include:
■
more rigorous testing of standard software functions, where no formal
supplier testing can be leveraged;
■
development of additional documentation, including user manuals,
functional and technical specifi cations;
■
development of rigorous change control and confi guration management
processes including detailed software release processes;
■
more frequent periodic reviews and revalidation.
The effectiveness of these risk controls should be monitored and reviewed
to ensure that any risks are mitigated.
21.6 Key validation activities
Whatever the nature (categorisation) of the software, it is important
that the regulated user defi nes and most probably documents
clear requirements. Where there is little or no ability to change
the functionality, it is acceptable for regulated company users to
assess the package and confi rm that it meets their requirements (Eudralex
Volume 4 Annex 11). Even this will require a clear understanding
of the business requirements, even if these are not documented in
extensive user requirement specifi cations. It is recommended that the
business process and data fl ows are documented as a minimum, against
which the package can be assessed and this can be done at the package
assessment stage.
For open source systems that are highly confi gurable, it is recommended
that formal user requirements are documented and key areas are
highlighted in Figure 21.4. It will be important to maintain these
requirements in an up-to-date state as the use of the software changes
over time. These may record user requirements in a variety of applicable
formats including business process fl ows, use-cases, business rules and
traditional singly stated user requirements ('The system shall . . .'). It is
Search WWH ::
Custom Search