Design Validation vs. Verification: 6 vinkkiä lääkinnällisten laitteiden kehittämiseen

Jos kehität tuotteita — erityisesti lääkinnällisiä laitteita — niin olet kuullut termit design validation ja design verification (kutsutaan myös nimellä V&V). Tässä kerromme, mitä kaksi toimintaa ovat, ero niiden välillä, plus jakaa vinkkejä saada irti ponnisteluistasi.

Huomautus: Vahvistaaksemme, että tämä sisältö olisi hyödyllinen sinulle, otimme yhteyttä Megan Martiniin, lääketieteelliseen laitteeseen v&V konsulttiin, jolla on yli 30 vuoden kokemus lääkinnällisistä laitteista v&V, lääkinnällisten laitteiden ohjelmistoihin, tuotteiden ja ohjelmistojen laatuun sekä Yhdysvaltain ja kansainvälisten laitesääntelyaineistoihin. Löydät hänen oivalluksia ja esimerkkejä kaikkialla!

seuraa perässä tai siirry osioon:

• suunnittelun validointi vs. suunnittelun todentaminen
• mitä suunnittelun validointi tarkalleen ottaen on?
• mikä on FDA: n Suunnittelutarkastus?
• Validation vs. Verification Summary
• suunnittelun validointiprosessin perusteet
• suunnittelun varmennusprosessin perusteet
• 6 vinkkiä parempaan validointiin & verifiointi
• Video: Simplify v & V
• v&V: termien sanasto

design validation vs. design verification: what ’ s the difference?

Mitä eroa on validoinnilla ja todentamisella? Yksinkertaisesti sanottuna, suunnittelun validointi määrittää, Jos olet rakentaa oikea tuote. Toimiiko laite loppukäyttäjille tarkoitetulla tavalla? Suunnittelun varmennus määrittää, onko tuote rakennettu oikein. Ovatko design tuotokset vastaavat suunnittelu tuloa?

se on yksinkertainen ero, kuten alla olevassa graafissa on selvästi esitetty.

Design validation: Are you building the right product? Suunnittelun varmennus: rakennatko tuotteen oikein?

mutta haluatte tietysti lisätietoja ja esimerkkejä. Aloitamme vahvistuksella.

mitä suunnittelun validointi tarkalleen ottaen on?

suunnittelun validointi on testausprosessi, jossa todistetaan (”validoidaan”), että rakentamasi laite toimii loppukäyttäjälle tarkoitetulla tavalla.

FDA: n virallinen sana (21 CFR 820.3) toteaa, että suunnittelun validointi ”osoittaa objektiivisin todistein, että laitteen eritelmät ovat käyttäjien tarpeiden ja käyttötarkoituksen mukaisia.”

suunnittelun Validointiesimerkki

kuvitellaan, että rakennamme hengityskonetta, joka pitää potilaan hengittämässä ja että käyttäjä haluaa sen toimivan potilaskuljetuksen aikana.

ensin on määriteltävä käyttäjän tarpeet. Käyttäjä haluaa siirtää potilaita, kun he ovat hengityskoneessa. Mutta mitä he oikeastaan yrittävät tehdä? ”Kuljetukseen” voisi kuulua potilaan siirtäminen sairaalan sisällä. Tai saattaa sisältää kuljetuksen ambulanssilla tai ilmateitse. Käyttäjätarve voi esimerkiksi näyttää seuraavanlaiselta.

käyttäjän tarve

UsNe-0001

hengityskone soveltuu käytettäväksi potilaiden sairaalahoidossa.

Tämä käyttäjän tarve jaetaan tuotevaatimuksiin ja suunnitteluvaatimuksiin tuotteen suunnittelua ja rakentamista varten. (Tarkastelemme niitä hetken kuluttua suunnittelun tarkastuksessa.)

sitä ennen tarkastellaan käyttäjän tarpeita ja katsotaan, mitä suunnittelun validointitapauksia voitaisiin tarvita. Käyttäjätarpeemme validointitestaus voi näyttää tältä.

User Need		Validation Test
UsNe-0001	hengityskone soveltuu käytettäväksi potilaiden sairaalahoidossa.	TCase-0001	Validation Test Suite: Test that the ventilator can be rolled easily by 15 members of hospital transport staff.
		TCase-0002	Validointitestisarja: Testaa, että tuuletin toimii sen eritelmien mukaisesti, kun sitä rullataan käytävillä, oviruuvien yli ja hissikynnysten yli.
		TCase-0003	Validation Test Suite: testaa, että tuuletin toimii sen vaatimusten mukaisesti vaihtovirran ja akun välillä.

Validointitestaus sisältäisi testitapauksia, testisarjoja tai jopa kliinisiä tutkimuksia, joiden tarkoituksena on osoittaa, että tuote sellaisenaan toimii käyttäjän odotusten mukaisesti niissä olosuhteissa, joissa hän aikoo sitä käyttää. Koska nämä testit on tehtävä tuotantoa tai tuotantoa vastaavilla yksiköillä, suunnittelun validointitestit ovat usein viimeisiä testejä.

periaatteessa suunnittelun validoinnissa on osoitettava, että tuote vastaa käyttäjän tarpeita.

muuten yllä olevasta taulukosta käy ilmi myös jäljitettävyys käyttäjien tarpeiden ja testitapausten välillä. Tämä jäljitysmatriisi antaa osan V&V todistusaineistoa, jota FDA vaatii.

mikä on suunnittelun varmennus FDA: lle?

suunnittelun varmennus on se, jossa testataan (”tarkistetaan”), että suunnittelutulokset vastaavat suunnittelutuloja.

jälleen FDA: n mukaan suunnittelun varmennus on ”vahvistusta tutkimalla ja toimittamalla objektiivista näyttöä siitä, että tietyt vaatimukset on täytetty.”

muista, että vaikka siihen liittyy testausta, on muitakin hyväksyttäviä todentamistoimia.

ne voivat sisältää testejä, tarkastuksia ja analyysejä (lisätietoja tästä, tutustu FDA Design Control Guidance).

suunnittelun Varmennusesimerkki

palataan Tuulettimen esimerkkiin. Olemme tunnistaneet käyttäjän tarpeet; nyt selvitetään, mitä laitteen on tehtävä ja miten sen on tehtävä se.

tämän saavuttamiseksi meidän on määriteltävä erityiset tuotevaatimukset. Esimerkiksi:

• mikä on potilaan maksimikuormitus? (Kuinka paljon ilmaa hengityskoneen täytyy liikkua?)
• kuinka kauan akun pitää kestää? (Kuinka kauan kuljetus kestää?)
• millaisiin olosuhteisiin he joutuvat kuljetuksen aikana? (Ovi jumittaa? Hissit?)
• onko olemassa sääntelystandardeja, jotka on täytettävä? (Turvallisuusnormit?)

”selkeät, täydelliset, yksiselitteiset, testattavat vaatimukset ovat avainasemassa onnistuneessa kehityshankkeessa. Riittämättömät vaatimukset johtavat ajanhukkaan, suunnitteluvirheisiin, laajoihin uudistuksiin ja hauraisiin tai virhealttiisiin tuotteisiin.”- Megan Martin, V&V Consultant

Tämä on ”mikä” osa laitteen ominaisuuksien määrittelyä. Mitä laite tarvitsee tehdä? Tuotteen vaatimukset (usein sisältyy tuotteen vaatimukset asiakirja) meidän käyttäjän tarve voi näyttää alla.

tuotevaatimukset

PrRq-0001	tuulettimessa saa olla enintään 2 litran tilavuusohjattu hengitys 20 hengenvedolla minuutissa.
PrRq-0002	tuuletinta on käytettävä paristoteholla enimmäisasetuksilla vähintään 90 minuuttia.
PrRq-0003	tuuletin on voitava asentaa vierivälle tukijalalle.
PrRq-0004	Tuulettimen ja jalustan on pystyttävä kulkemaan tyypillisten sairaalan oven ja hissin kynnysten läpi.

lopulta tarvitaan suunnittelumääritelmä. ”Olemme jo määritelleet, mitä aiomme saavuttaa, ja nyt meidän on määriteltävä, miten aiomme saavuttaa sen”, Megan sanoo. Tämä voidaan toteuttaa eri tavoin, mukaan lukien kirjalliset eritelmät, sähköiset tai Mekaaniset piirustukset, komponenttien osto eritelmät, tai muita menetelmiä.

esimerkiksi suunnitteluerittelyissä ja piirustuksissa saattaa näkyä seuraavaa.

suunnittelutiedot

turbiini, joka voi tuottaa jopa 40 litraa ilmaa minuutissa.

DSC-0001
DSC-0002	litiumioniakkupaketti, joka on mitoitettu vähintään 100 ampeerin tunniksi.
DSC-0003	valssitelineen kiinnityksessä käytetään 22 paunan teräskiinnikettä.
DSC-0004	jalustan pohja on 22″ leveä ja siinä on 5 pyörää.
DSC-0005	seisontapyörien halkaisija on 4″.

suunnittelun todentaminen antaa näyttöä (testitulokset) siitä, että suunnittelun tuotokset (varsinainen tuote) vastaavat suunnittelutuloksia (tuotevaatimukset ja suunnitteluvaatimukset). Riippuen kohde todennettava, testi tapaus tai testisarja olisi käynnissä, tai tarkastus tai analyysi tehdään antaa vaaditut todisteet.

alla olevat taulukot kuvaavat, miltä se voisi näyttää. Ne osoittavat myös FDA: n odottaman jäljitettävyyden.

Product Requirement		Verification Test
PrRq-0001	Tuulettimen enimmäisasetus on 2-litran tilavuusohjatut hengitykset 20 hengityksellä minuutissa.	TCase-0004	testitapaus: Tarkista enimmäishengitysasetukset tai hengitysasetusten yhdistelmät.
PrRq-0002	Tuulettimen on toimittava akun virralla maksimiasetuksilla vähintään 90 minuuttia.	TCase-0005	testisarja: Tarkista ajoaika maksimiasetuksilla täysin ladatulla uudella akulla.
		TCase-0006	Test suite: Tarkista ajoaika maksimiasetuksilla akulla, joka on käynyt läpi 50 lataussykliä.
PrRq-0003	tuuletin on voitava asentaa vierivälle tukijalalle.	TCase-0007	Demonstrointitesti: osoitettava, että tuuletin voidaan kiinnittää ja irrottaa vierintätelineestä.
PrRq-0004	Tuulettimen ja jalustan on pystyttävä kulkemaan tyypillisten sairaalan oven ja hissin kynnysten läpi.	TCase-0008	ulkoinen testi: testauspalvelun suorittama testi ventilaattorin ja telineen varmentamiseksi voidaan vierittää kynnyksen yli ilman kaatumista IEC 60601-1 lääketieteellisen Sähköstandardin mukaisesti.

tuotteen vaatimusten tarkistaminen, Kuten edellä on todettu, osoittaa, että tuote tekee sen, mitä sanoimme sen tekevän.

seuraavaksi esiteltävien suunnittelueritelmien tarkistaminen osoittaa, että tuote tekee sen niin kuin sanoimme sen tekevän.

Suunnittelumääritelmä
DSC-0001	turbiini, joka voi tuottaa 40 litraa ilmaa minuutissa.	TCase-0009	Test Suite: Tarkista ilman tuottaminen turbiinilla 40 lpm: n teholla joko verkko-tai akkuteholla.
DSC-0002	litiumioniakkupaketti, joka on mitoitettu 100 ampeerin tunnille.	TCase-0010	Tarkastustesti: Tarkista paristojen osto-ohjelma osoittaa tyypin olevan litiumioni.
		TCase-0011	Analyysitesti: kerää testitietoja ja tee data-analyysi, jolla osoitetaan akun suorituskyky akun käyttöiän aikana täyttää tai ylittää 100 ampeeria.
DSC-0003	valssitelineessä käytetään 22 paunalle mitoitettua teräskiinnikettä.	TCase-0012	Tarkastustesti: Tarkista osan spesifikaatio on teräksiselle vipu-Action-puristimelle, joka on mitoitettu vähintään 22 paunalle.
DSC-0004	telinealusta on 22″ leveä ja siinä on 5 pyörää.	TCase-0013	testitapaus: mittaa pohjan halkaisija; laske Pyörät; mittaa pyörän halkaisija
DSC-0005	seisontapyörien halkaisija on 4″.

pohjimmiltaan suunnittelun varmennuksessa on osoitettava, että rakentamamme tuote on se tuote, jonka sanoimme rakentavamme.

kun ne kootaan yhteen V&V-raporttiin, todentamis-ja validointitestitulosten yhdistelmä sekä jäljitettävyys takaisin käyttäjien tarpeisiin, tuotevaatimuksiin ja suunnitteluvaatimuksiin tarjoaa osan todisteista, joita FDA tarvitsee toimittaessaan lääkinnällisen laitteen puhdistettavaksi.

Validation vs. Verification Summary

tässä lyhyt, joskin hieman yliyksinkertaistettu yhteenveto keskeisistä eroista.

Design Verification	Design Validation
Design output is as expected.	Final design meets user’s needs.
System, subsystem and unit testing.	System testing.
During development.	After development.
Test individual module or completed system under any conditions.	Test conditions per user needs.
Sisältää järjestelmätarkastukset, analyysit ja testaukset.	Sisältää tuotantoyksikköjen testauksen todellisissa käyttöolosuhteissa.
Sisältää raportit tehdyistä testeistä, testituloksista ja jäljitettävyydestä. Raportit tarkistetaan, hyväksytään ja allekirjoitetaan.	Sisältää loppuraportin, jossa on testitulokset ja jäljitettävyys, valmiina viranomaisarviointia varten. Raportit tarkistetaan, hyväksytään ja allekirjoitetaan.

suunnittelun validointiprosessin perusteet

suunnittelun validointiprosessi koostuu suurelta osin laitteen testaamisesta. Voit tehdä tämän muutamalla tavalla, olosuhteista riippuen. Toimintaan voi kuulua:

• vertaamalla samanlaisiin laitteisiin, jotka suorittavat samankaltaisia tarkoituksia varten.
• simuloi toiminnallisuutta matemaattisen mallinnuksen avulla.
• testaa lopullista rakennetta todistaaksesi, että järjestelmä toimii käyttäjän tarpeiden mukaisesti.

testaussuunnitelma, testitapaukset, testien suoritustiedot ja testitulokset tulee dokumentoida ja ylläpitää osana suunnittelutietokantaa. Validointi ei kokonaisuudessaan ole yhden toimen tulos, vaan kaikkien validointitoimien tulosten kerääminen.

suunnittelun varmennusprosessin perusteet

todentaminen voidaan pelkistää yksinkertaiseksi viisivaiheiseksi prosessiksi.

tunnistus ja valmistelu

yksilöi paras tapa suorittaa todentaminen. Määrittele, mitä mittaat ja miten mittaat sen. Sinun kannattaa myös harkita tarvittavat resurssit, työvoimaa, ja työkalut onnistuneen todentamisen.

suunnittelu

todentamisen suunnittelu tapahtuu koko hankkeen elinkaaren ajan. Kehität testisuunnitelman, joka tallentaa kriittiset virstanpylväät. Suunnitelma on päivitettävä aina, kun suunnittelupanoksiin tehdään muutoksia.

kehittäminen

tuotekehitys alkaa! Se suoritetaan menetelmällä valinta(Scrum, vesiputous, Hybridi, jne.). Tämä osa prosessia sisältää myös kirjallisesti, koeajo, ja hyväksymällä testitapaukset, joita käytetään todentamiseen.

suoritetaan

testimenettelyt suoritetaan suunnitellusti. Virheelliset tulokset dokumentoidaan ja tarkistetaan, ja ne joko hyväksytään tai kirjataan vioiksi. Tuotteen viat ratkaistaan ja vapautetaan, ja regressiotestaus suoritetaan. Luodaan jäljitettävyysmatriisi sen todentamiseksi, että todentamistestisuunnitelmassa yksilöidyt suunnittelutiedot on testattu ja hyväksytty.

raportointi

raportointi suoritetaan kunkin todentamisvaiheen lopussa. Yksityiskohtaiset raportit sisältävät konfiguraation hallinta-ja julkaisuraportit, testaustyypin tai tuoteversion mukaiset testitulokset sekä todentamistoimen aikana havaitut ongelmat. Suunnittelun varmennuksen jäljitettävyysraportissa esitetään testitulokset ja vaatimusten kattavuus. Lopuksi katselmukset saatetaan päätökseen ja hyväksytään jokaisen suunnittelun todentamistoimen jälkeen.

6 vinkkiä parempaan validointiin & verifiointi

tässä vinkkejä, joilla varmistat, että saat kaiken irti validoinnistasi & todentamistoimet.

Plan Ahead (And Test Early)

Have a solid plan upfront and loop everyone in. Sisällytä testausinsinöörit kehitystyön varhaisessa vaiheessa varmistaaksesi, että vaatimukset ja suunnittelu ovat selkeitä, täydellisiä ja testattavissa. Megan sanoo: ”testimenetelmien varhainen kehittäminen voi valottaa teknologiakysymyksiä ennen kuin niistä tulee suuria esteitä.”Varhainen testikehitys voi tarjota myös testityökaluja. Näitä voidaan sitten käyttää nopeuttamaan tuotekehitysprosessia sekä antamaan testinäyttöä muodollisen testauksen aikana.

käytä jaettua nimikkeistöä

tiimin saaminen samalle sivulle on ratkaisevaa onnistuneen suunnittelun validoinnin kannalta & todentaminen. Osa samalle sivulle pääsemisestä tarkoittaa yhteisen terminologian käyttöä. Käyttämällä samoja termejä poistaa sekaannusta joukkueen jäsenille (ei vain uusia jäseniä — veteraanit, liian). Katso alla oleva sanasto termeistä ja yleisistä lyhenteistä, jotka auttavat kehittämään terminologian perustaa.

Käytä työkaluja, joilla on päästä päähän-jäljitettävyys

yksinkertaisimmillaan jäljitettävyys voidaan saavuttaa word-dokumenteilla ja taulukoilla, mutta ne tuottavat niin paljon manuaalista työtä (ja ovat niin virheherkkiä), että toivot aloittavasi erikoistyökalulla.

”tarkka jäljitysmatriisi on korvaamaton, kun tehdään regressioanalyysiä sen määrittämiseksi, mitä pitäisi testata uudelleen tuotteen vaihdon tai vian korjauksen jälkeen.”- Megan Martin, v&V Consultant

käyttämällä työkalua, jolla on vahva requirements-to-test-to-results trace capability, voit tunnistaa peittoaukot ja antaa ennakkovaroituksia herkistä tai testaamattomista alueista tuotteessa.

Get end-to-end traceability now

Build Your Trace Matrix As You Go

”it can be tempting to put it off, but don’ t wait to build your trace matrix!”sanoo Megan. Jäljitettävyyden rakentaminen matkan varrella estää reikien kehittymisen huomaamatta. Harvat asiat ovat vaikeampi toipua kuin löytää olet jäänyt kriittisiä vaatimuksia, riskejä lieventäviä ominaisuuksia, tai olennaisia testejä juuri silloin, kun luulet kehitystyösi on valmis.

jäljitettävyyden ylläpitäminen vaatimusten, mallien ja testien kehittyessä vaatii paljon vähemmän huoltotyötä kuin kriittisten reikien paikkaaminen suunnittelussa ja kehityksessä 11.hetkellä. Tämä vaivaa voi myös auttaa sinua tunnistamaan, kuinka paljon työtä on jäljellä, jos saatat joutua lisäämään kehitys-tai testihenkilöstöä, tai kun sinun pitäisi arvioida uudelleen toimitusaikataulut.

Avoid 11th-hour emergencies! Tässä statusta seurataan vaatimusten & Helix ALM: ssä suoritetut testit.

Integrated Requirements Traceability & Testing With Anomaly Tracking

se, että anomalioita pystytään yhdistämään suoraan vaatimukseen, parantaa viestintää testaajien ja kehittäjien välillä. Se on erittäin hyödyllistä. Poikkeamien luominen suoraan testiprotokollan vikaantumisesta tarkoittaa, että asiasta saadaan lisätietoja. Tämän seurauksena ongelmat voidaan helpommin dokumentoida, jäljentää, korjata ja testata uudelleen.

valitse työkalut, joita voit muokata menetelmääsi

”minkä tahansa kehittämismallin olet valinnut — ketterän, iteratiivisen, muokatun vesiputouksen — haluat valita v&V työkalut, jotka palvelevat sinua mukautumalla prosessiisi sen sijaan, että pakottaisit sinut mukauttamaan prosessisi työkalun palvelemiseen”, Megan neuvoo.

valitsemiesi lääketieteellisten laitteiden kehitystyökalujen tulisi lisätä tiimisi työn tarkkuutta ja tehokkuutta, eikä lisätä tarpeettomia yleiskustannuksia päivittäisiin tehtäviinsä. Hyvä työkalu tarjoaa suojakaiteet varmistaa, että tärkeät asiat tehdään aina. Se antaa tiimillesi joustavuutta tuottaa ad hoc-näkymiä ja raportteja, jotta voit paremmin käyttää (ja tutkia) kaappaamiasi tietoja. Se tarjoaa V&V kohdennettua tietojen keruuta ja raportointia, jotta raporttien tuottaminen olisi yksinkertaista ja toistettavaa.

varaa aikaa määritellä, miten haluat työkalut tiimisi tueksi ennen valintaa. Sitten saat työkalut konfiguroitu tiimisi tarpeisiin.

kaiken yhdistäminen

suunnittelun validointi ja todentaminen ovat olennaisia osia onnistuneessa laitekehityksessä. Jaetulla yhteisymmärryksellä tiimin kesken, sekä oikeat työkalut, sinulla on vankka kehys saada laitteen markkinoille.
Katso koko DEMO nyt >>

Simplify v&V Helix ALM

katso, miten helix Alm voi nopeuttaa lääkinnällisten laitteiden kehitystä.

tutki Helix ALM

*taas, kiitos V & V asiantuntija Megan Martin, joka antoi korvaamattoman oivalluksen tähän blogiin!

V&V: Glossary of Terms

Actual Result – What a system actually does when an action is performed.

anomalia – kun systeemi ei toimi odotetulla tavalla. Esimerkiksi vika, virhe tai testivirhe.

Deliverable – projektin toteuttamisen tuloksena syntynyt pakollinen esine, yleensä validointityössä olevat asiakirjat.

poikkeama – kun prosessia tai menettelyä ei voida toteuttaa määritellyllä tavalla ja käytetään vaihtoehtoista menetelmää tai materiaalia.

odotettu tulos – mitä järjestelmän pitäisi tehdä, kun toiminto suoritetaan.

Integrointitesti – testaus, joka suoritetaan käyttämällä kahta tai useampaa osajärjestelmää osajärjestelmien vuorovaikutuksen ja keskinäisten riippuvuuksien todentamiseksi.

Protocol – kokoelma testitapauksia, joita käytetään järjestelmätestauksen dokumentointiin.

Qualification – testausprotokolla, jonka mukaan järjestelmä täyttää tietyn vaatimuskokoelman.

Quality Assurance – tiimin jäsenet, joiden tehtävänä on varmistaa tuotteen laatu tai prosessin eheys.

vaatimus – jotain, mitä järjestelmän on kyettävä tekemään.

retrospektiivinen validointi – jo olemassa olevan järjestelmän validointi.

erittely – asiakirja, jossa esitetään järjestelmää tai osaa koskevat vaatimukset.

osajärjestelmän testaus – merkittävälle osajärjestelmälle tai komponenttiryhmälle suoritettu testaus.

järjestelmä-asia, jota validoidaan.

järjestelmän omistaja – yksilö, joka on viime kädessä vastuussa järjestelmästä.

System Test – testaus, jossa käytetään koko järjestelmää.

Test Case – dokumentoitu menettely, jota käytetään testaamaan, että järjestelmä täyttää vaatimuksen tai vaatimusten kokoelman.

Testisuunnitelma – testausmenetelmä, joka on laadittu sen varmistamiseksi, että järjestelmä täyttää vaatimukset.

testivaihe – testitapauksen Yksittäinen rivi. Sen tulisi sisältää ohjeet, odotettu tulos ja todellinen tulos.

jäljitettävyys – kyky varmistaa, että eritelmissä esitetyt vaatimukset on testattu. Usein kuvattu vaatimusten jäljitettävyysmatriisissa.

yksikkötestaus – testaus suoritetaan ohjelmisto-tai laitteistoyksiköllä tai matalan tason moduulilla.

validointi – määritetään objektiivisen näytön avulla, että laitteen eritelmät ovat käyttäjien tarpeiden ja käyttötarkoituksen mukaisia.

Validointipaketti – kokoelma validointiprojektin aikana tuotettuja asiakirjoja.

todentaminen – vahvistus tutkimalla ja toimittamalla objektiivista näyttöä siitä, että tietyt vaatimukset on täytetty.

v&V suunnitelma – suunnitelma, jossa määritellään todennettavat ja validoitavat vaatimukset sekä v&V pyyntiponnistus.

Yleiset suunnittelun Validointilyhenteet

CC – Change Control

CCB – Change Control Board (ryhmä henkilöitä, jotka valvovat, mitä muutoksia tehdään ja milloin)

DS – Suunnittelumääritelmä

FAT – tehtaan Hyväksymistestaus

FS – toiminnallinen spesifikaatio

FRS – toiminnallinen Vaatimusmääritelmä (KS. toiminnallinen spesifikaatio)

GCP – hyvä kliininen käytäntö (kliinisten operaatioiden laatuohjeet)

/ p>

GLP – Good Laboratory Practice (quality guidelines for pharmaceutical Laboratory Operations)

GMP – good manufacturing Practice (quality guidelines for manufacturing of devices or pharmaceuticals)

RTM – Requirement Traceability Matrix

SAD – Software Architecture Document or System Architecture Document

SAT – Site Acceptance Testing

SCCB – Software Change Control Board (sama kuin CCB, mutta ohjelmisto)

SDD – Software Detail Design Document

SDS – Software Design Specification

Spec – Specification

SRS – Software vaatimusmäärittely

TM – jäljitettävyysmatriisi

UAT – käyttäjän hyväksymistestaus

Urs – käyttäjän vaatimus Specification

UUT – Unit Under Test

VMP – Validation Master Plan

VP – Validation Plan

V&V – Verification and Validation