Hello all, I have any concept doubt about Software Validation Life Cycle.
Briefly are corrects the follows definitions:
-A URS defines, clearly and precisely what the user wants the system to do
-A FS defines abstract what the system will do.
My question is, in what part I be able to define the “HOW” (or the way) the system will do???
thanks all.
The FS will functionality describe how the URS requirements will be handled by the system. Some companies use a FDS which is a functional design specification others separate them out into FS and DS (Design specifications) documents.
The FDS document should describe the “How”.
The IQ and OQ documents will then test the “How”
Regards
Graham
URS
A URS defines, clearly and precisely, what the user wants the system to do. It defines the functions to be carried out, the data on which the system will operate, and the operating environment. The URS defines also any non-functional requirements, constraints such as time and costs, and what deliverables are to be supplied. The emphasis should be on the required functions and not the method of implementing those functions.
The URS should refer to and interpret the relevant GxP regulations, to assist the project team and supplier to deliver a compliant system meeting GxP requirements.
FS
A Functional Specification defines what the system should do, and what functions and facilities are to be provided. It provides a list of design objectives for the system.
DS
There are two flavours of DS - a Hardware DS and Software DS. This is the detailed design.
Things like source code snippets and/or pseudo-code, HMI screen detailed design etc. would appear here. Instrument lists, I/O etc. etc.
You can also split off Software DSs into Software Module DSs for larger systems.
You can put the H-DS and S-DS into an appendix of the FS for a small system.
Requirements Traceability Matrix
Link it all up with an RTM.
IQ
The IQ basically verifies the installation and hardware according to the H-DS (and a little bit of the S-DS).
OQ
The OQ verifies much of the S-DS and the FS. Many pictures of the GAMP V-Model show the OQ only verifying the FS, but it verifies a lot of the DS too.
GAMP Categories
Only “Category 5” software requires the rigour of a full-blown S-DS.
Only “Category 2” hardware requires the rigour of a full-blown H-DS. Bear in mind that the Hardware Category and Software Category are not the same.
If you drop to “Category 4” software then you replace the S-DS with a simpler “CS” or Configuration Specification. The IQ and OQ perform similar roles but there is much less vigour associated with them compared to C5.
“Category 3” software dispenses with the FS too (just a URS and some sort of verification/qualification protocol that verifies the URS - no IQ, OQ).
Ranjan Acharya
New Zealand
[quote=acharyar]URS
A URS defines, clearly and precisely, what the user wants the system to do. It defines the functions to be carried out, the data on which the system will operate, and the operating environment. The URS defines also any non-functional requirements, constraints such as time and costs, and what deliverables are to be supplied. The emphasis should be on the required functions and not the method of implementing those functions.
The URS should refer to and interpret the relevant GxP regulations, to assist the project team and supplier to deliver a compliant system meeting GxP requirements.
FS
A Functional Specification defines what the system should do, and what functions and facilities are to be provided. It provides a list of design objectives for the system.
DS
There are two flavours of DS - a Hardware DS and Software DS. This is the detailed design.
Things like source code snippets and/or pseudo-code, HMI screen detailed design etc. would appear here. Instrument lists, I/O etc. etc.
You can also split off Software DSs into Software Module DSs for larger systems.
You can put the H-DS and S-DS into an appendix of the FS for a small system.
Requirements Traceability Matrix
Link it all up with an RTM.
IQ
The IQ basically verifies the installation and hardware according to the H-DS (and a little bit of the S-DS).
OQ
The OQ verifies much of the S-DS and the FS. Many pictures of the GAMP V-Model show the OQ only verifying the FS, but it verifies a lot of the DS too.
GAMP Categories
Only “Category 5” software requires the rigour of a full-blown S-DS.
Only “Category 2” hardware requires the rigour of a full-blown H-DS. Bear in mind that the Hardware Category and Software Category are not the same.
If you drop to “Category 4” software then you replace the S-DS with a simpler “CS” or Configuration Specification. The IQ and OQ perform similar roles but there is much less vigour associated with them compared to C5.
“Category 3” software dispenses with the FS too (just a URS and some sort of verification/qualification protocol that verifies the URS - no IQ, OQ).
Ranjan Acharya
New Zealand[/quote]
Hi Ranjan, thanks for your wide answers
I agree with you but, I still have other questions for you.
1-Which are all hardware categories?
2-I don´t understand very well the idea with de CS.
3-What is HMI?
Thanks very much!!!
Hi Ranjan, thanks for your wide answers
I agree with you but, I still have other questions for you.
1-Which are all hardware categories?
2-I don´t understand very well the idea with de CS.
3-What is HMI?
Thanks very much!!!
There are only two hardware categories for GAMP - (1) and (2). (1) is basically standard stuff and (2) is customised.
HMI is human machine interface or MMI or OIT etc.
CS is GAMP5 “Configuration Specification”. This replaces the DS in that all you need to list for off-the-shelf systems his how you configured the system. You don’t need to document basic design stuff as (a) you probably aren’t aware of it and (b) equipment is not customised, widely used etc.