User Requirement Specifications - Ringkasan dari GAMP 5

• URS adalah dokumen yang menentukan kebutuhan untuk sistem komputerisasi atau komponen system.
• Luasan dan rincian kebutuhan harus sepadan dengan risiko, kompleksitas, dan kebaruan, dan harus cukup untuk mendukung analisis risiko, spesifikasi, konfigurasi/desain, dan verifikasi selanjutnya sesuai kebutuhan.
• Hasil studi yang ada, seperti analisis kebutuhan bisnis, dapat membantu menentukan cakupan dan detail kebutuhan.
• Pendekatannya harus bersifat top-down, dan didasarkan pada pemahaman produk dan proses termasuk Critical Quality Attributes (CQAs), dan pemahaman tentang kebutuhan peraturan yang relevan jika diperlukan. Pemahaman ini memfasilitasi penerapan filosofi Quality by Design (QbD).

PANDUAN UMUM

1. URS Mendefinisikan Kebutuhan Sistem:

Dokumen URS harus secara jelas dan tepat mendefinisikan apa yang diharapkan dari sistem yang akan diadopsi oleh perusahaan yang diatur. Ini harus mencakup tugas dan fungsi sistem serta harus didorong oleh kebutuhan proses bisnis.

2. Kebutuhan Dapat Dikembangkan Independen dari Solusi Spesifik:

Ini berarti bahwa perusahaan dapat menentukan kebutuhan sistem tanpa terikat pada solusi teknologi tertentu pada tahap awal. 

3. Pertimbangan Pemasok dan Keputusan Berbasis pada Risiko, Kompleksitas, dan Kebaruan:

Pemilihan pemasok atau solusi dapat bergantung pada faktor-faktor seperti risiko, kompleksitas, dan sejauh mana suatu solusi dianggap inovatif atau baru. Keputusan semacam itu harus diperhitungkan dengan mempertimbangkan faktor-faktor tersebut. Contoh untuk kategori 4 atau 5.

4. Pada kebanyakan kategori 3, kebutuhan sistem dapat bergantung pada solusi yang tersedia di pasar.

5. Kepentingan Tetap pada Keselamatan Pasien, Kualitas Produk, dan Integritas Data:

Meskipun keputusan terkait dengan pilihan solusi mungkin bergantung pada faktor-faktor tertentu, kebutuhan terkait keselamatan pasien, kualitas produk, dan integritas data harus tetap ditetapkan dan diutamakan, tanpa mengorbankan hal-hal tersebut.

6. Kebutuhan (requirements) mungkin tidak sepenuhnya terdefinisi dengan jelas pada awalnya, terutama untuk beberapa sistem Kategori 5.

7. Kebutuhan akan dikembangkan selama fase-fase berikutnya dari proyek. 

Ini mungkin melibatkan pengumpulan lebih banyak informasi, analisis lebih lanjut, dan pemahaman yang lebih baik tentang kebutuhan pengguna dan bisnis.

8. Dokumen URS harus fleksibel dan dapat diperbarui sejalan dengan perkembangan proyek. 

Oleh karena itu, dokumen URS (User Requirement Specification) awal harus menyadari hal ini dan diperbarui ketika informasi tambahan menjadi tersedia. 

Biasanya URS Terdiri dari :

1. operational requirements
2. functional requirements
3. data requirements
4. technical requirements
5. interface requirements
6. environment requirements
7. performance requirements
8. availability requirements
9. security requirements
10. maintenance requirements
11. regulatory requirements
12. migration of any electronic data
13. constraints to be observed
14. life cycle requirements

Quality Critical Requirement

persyaratan (requirements) yang memiliki dampak signifikan terhadap kualitas suatu sistem atau produk.

Mengacu pada Regulasi GxP yang Berlaku.

1. Menyoroti Aspek Kritis untuk Keselamatan Pasien, Kualitas Produk, dan Integritas Data. 
2. Menghindari Istilah Umum seperti "Part 11 Compliant" atau "GMP-Compliant“. Dokumen User Requirement Specification (URS) tidak seharusnya menyertakan persyaratan yang bersifat umum seperti "Part 11 Compliant" atau "GMP-Compliant." Sebaliknya, URS seharusnya mendefinisikan secara rinci fungsionalitas apa yang dibutuhkan oleh pengguna dalam sistem untuk mengelola risiko terhadap keselamatan pasien, kualitas produk, dan integritas data.
3. Identifikasi Persyaratan Kritis untuk Kualitas. fokus pada aspek-aspek sistem yang sangat penting untuk keselamatan pasien, kualitas produk, dan integritas data selama analisis risiko, perancangan, konfigurasi/desain, dan kegiatan verifikasi berikutnya

Requirement Good Practice

panduan, norma, atau aturan-aturan praktik terbaik yang harus diikuti atau diterapkan saat merinci atau mendefinisikan persyaratan

Kebutuhan harus:

• sufficient (cukup) and appropriate (pantas): 

• Spesifik (Specific): Jelas dan terinci tentang apa yang diinginkan atau dibutuhkan.
• Terukur (Measurable): Dapat diukur untuk menentukan apakah telah dicapai atau tidak.
• Dapat Dicapai (Achievable): Realistis dan dapat dicapai dengan sumber daya yang tersedia.
• Realistis (Realistic): Sesuai dengan kemampuan dan ketersediaan.
• Dapat Diuji (Testable): Dapat diuji untuk memastikan bahwa persyaratan telah terpenuhi.

• Persyaratan harus cukup spesifik untuk pengujian dan pemeriksaan:

• Tidak Ambigu (Unambiguous): Tidak memunculkan interpretasi yang bermacam-macam atau tidak jelas.
• Jelas (Clear): Mudah dipahami tanpa kebingungan.
• Tepat (Precise): Didefinisikan dengan akurat dan tanpa ketidakpastian yang berarti.
• Mandiri (Self-contained): Mandiri dan tidak memerlukan informasi tambahan untuk pemahaman yang lengkap.

• Mampu mendukung ketertelusuran (traceability) penuh melalui konfigurasi/desain dan pengujian.
• Memberikan dasar untuk pengujian formal, dan digunakan selama pemilihan pemasok.
• Diprioritaskan dengan penekanan pada identifikasi persyaratan wajib. Misalnya, skema prioritas tiga tingkat dapat digunakan:

• Mandatory (High)
• Beneficial (Medium)
• Nice to Have (Low)