Kullanıcı Gereksinimleri Belirtimi (URS) – İşlevsel İhtiyaçlar

Bu konu, şu konunun bir parçasıdır: SG Systems Global düzenleyici ve operasyonel terimler sözlüğü.

Ekim 2025'te güncellendi • Gereksinimler, Doğrulama ve Tedarik • Kalite, BT, Üretim, Laboratuvar, Tedarik Zinciri

Kullanıcı Gereksinimleri Spesifikasyonu (URS) , bir sistemin düzenlenmiş bir operasyonda amaçlanan kullanıma uygun olması için ne yapması ve nasıl davranması gerektiğine dair işletmeye ait bir açıklamadır . Seçim, yapılandırma, doğrulama ve değişiklik kontrolü için temel oluşturur: tedarikçiler seçilir ve çözümler URS'yi karşılayacak şekilde oluşturulur; test senaryoları ve UAT'ler ona dayanır; ve gelecekteki geliştirmeler değişiklik sürecinden geçer. GAMP 5 ile uyumlu bir CSV yaşam döngüsünde , URS fonksiyonel/tasarım spesifikasyonlarından önce gelir ve testleri, elektronik kayıt beklentilerini ve veri bütünlüğü taahhütlerini yönetir.

"URS'yi sanki bir müfettiş sisteminizi ve kayıtlarınızı doğrulamak için bir alışveriş listesi olarak kullanacakmış gibi yazın; çünkü kullanacaklar."

1) URS Neleri Kapsar ve Neleri Kapsamaz

Kapsam: Gereksinimler olarak ifade edilen iş ve düzenleyici ihtiyaçlar : hangi işlemlerin mümkün olması gerektiği (örneğin, zorunlu tutmalarla eBMR oluşturma/yürütme ), hangi kayıtların mevcut olması ve erişilebilir olması gerektiği, kimin hangi eylemleri hangi kontroller altında gerçekleştirebileceği ve sistemin ne kadar hızlı, doğru ve erişilebilir olması gerektiği. Raporlama, etiketler, arayüzler, veri geçiş sınırları, denetlenebilirlik ve saklama/felaket kurtarma ihtiyaçlarını içerir. URS, kasıtlı olarak teknolojiden bağımsızdır.

Çözüm tasarımı veya uygulama detaylarını kapsamaz . Alan adları, veritabanı şemaları ve ekran düzenleri, tedarikçinin işlevsel/tasarım özelliklerine aittir. Kullanıcı referans standardı (URS), mekanizmaları ("X tablosunu kullan" veya "soldaki düğme") belirlemekten kaçınmalı ve bunun yerine sonuçlara ("değiştirilemez denetim izi ve elektronik imza bağlamasıyla kimin/ne/ne zaman/neden yaptığını gösteren kayıt") odaklanmalıdır.

2) Düzenleyici ve Sistem Çapaları

Düzenleyiciler, amaçlanan kullanımın tanımlanmasını ve doğrulanmasını bekler. GAMP 5 ile uyumlu, kontrollü bir URS, orantılı CSV ve test kapsamını yönlendirir . Elektronik kayıtlar ve imzalarla ilgili gereksinimler, Bölüm 11 / Ek 11 davranışlarını (benzersiz kullanıcılar, e-imzalar, denetim izleri, kayıt koruması) açıkça belirtmelidir . Veri yaşam döngüsü beklentileri—ALCOA(+), meta veri, arşivleme, zaman çerçeveleri içinde alma— Veri Bütünlüğü ve Kayıt Saklama ile bağlantılıdır . Belge, resmi onaylar ve sürüm geçmişi ile Belge Kontrolü altındadır.

3) İyi Bir URS Ne İçerir?

Güçlü bir URS (Kullanıcı Gereksinimleri Spesifikasyonu), kapsam ve sınırları (kapsam dahilindeki uygulamalar, siteler, ürünler ve süreçler) belirterek başlar ve amaçlanan kullanımı açık bir dille ifade eder. Ardından, süreç alanına göre fonksiyonel gereksinimleri çerçevelendirir: malzeme ve depo kontrolü, üretim yürütme, kalite kayıtları, laboratuvar iş akışları, etiketleme ve izlenebilirlik ve raporlama/analiz. Her gereksinim atomiktir , benzersiz bir şekilde numaralandırılmıştır ve test edilebilir. Fonksiyonel olmayan gereksinimler de şunların yanında yer alır: roller ve izinler, veri güvenliği ve gizliliği, en yüksek yüklerde kullanılabilirlik ve performans beklentileri, yedekleme/geri yükleme ve felaket kurtarma, yerelleştirme ve saat dilimleri ve üretim sahası cihazları için kullanılabilirlik kısıtlamaları. Entegrasyon gereksinimleri, ERP, cihazlar veya ortaklarla hangi verilerin hangi kalite temposunda değiş tokuş edilmesi gerektiğini tanımlar. Son olarak, URS kabul kriterlerini ve geçerli politikalara ve SOP'lere (Standart Çalışma Prosedürleri) referansları listeler.

4) Keşiften Onaylamaya - Standart Bir Yol

Öncelikle süreç sahipleriyle görüşün ve mevcut standart işletim prosedürlerini (SOP'ler), sorun noktalarını ve denetim bulgularını gözden geçirin. Modüller genelinde "günlük iş akışı" senaryolarını haritalandırın; örneğin, mal kabulünden depoya yerleştirmeye , gravimetrik kontrollerle tartım ve dağıtıma , süreç içi kontrollere ve nihai işleme kadar. Gereksinimleri taslak haline getirin, risk ve öncelik etiketleriyle işaretleyin ve fonksiyonlar arası inceleme için (Kalite Güvence, BT, Üretim, Laboratuvar, Tedarik Zinciri) dağıtın. Çatışmaları çözün, test edilebilirliği doğrulayın ve resmi onay için gönderin. Onaylanan Kullanıcı Gereksinimleri Spesifikasyonu (URS), tedarikçi seçimi, yapılandırma ve Kullanıcı Kabul Testi (UAT) için temel oluşturur; onaydan sonraki sapmalar veya kapsam değişiklikleri kontrollü bir Değişiklik Yönetimi (MOC) sürecinden geçmelidir.

5) Müfettişlerin Saygı Duyduğu Yazma Gereksinimleri

Her gereksinimi ölçülebilir ve net hale getirin. "Kullanıcı dostu" ifadesini, "sistem gerçek zamanlı olarak aralık dışı okumalar gösteriyor ve bir yönetici bir sapmayı elektronik olarak imzalayana kadar ilerlemeyi engelliyor" gibi nesnel ölçütlerle değiştirin. Ayrı ihtiyaçları gizleyen paketleme ("ve/veya") ifadelerinden kaçının; bunları ayırın. Tutarlı fiiller ("yapacaktır ...") kullanın ve aktörleri (rol adları), girdileri (veri öğeleri), çıktıları (kayıtlar/raporlar/etiketler) ve kısıtlamaları (zaman sınırları, doğruluk, cihazlar) belirtin. Kritik gereksinimleri risk gerekçelerine bağlayın, böylece test derinliği belirgin ve orantılı olsun.

6) İşlevsel Olmayan Gereksinimler Önemlidir

Performans, kullanılabilirlik ve dayanıklılık BT'nin ekstra özellikleri değil, iş riskleridir. Hat hızlarında yanıt sürelerini, etiket baskı verimliliğini, kabul edilebilir kesinti sürelerini ve kurtarma hedeflerini belirtin. Veri bütünlüğü beklentileri dahilinde parola politikalarını, oturum zaman aşımı sürelerini ve hesap kilitlemelerini açıklayın. Düşük bağlantı ortamlarındaki davranışlar da dahil olmak üzere tarayıcılar, teraziler ve HMI'lar için cihaz kısıtlamalarını tanımlayın. Sistemin çalışacağı yere (örneğin, temiz oda tabletleri ve masaüstü bilgisayarlar) uygun yerelleştirme (birimler, tarih biçimleri), erişilebilirlik ve tarayıcı veya işletim sistemi desteği ekleyin.

7) Veri ve Entegrasyon Gereksinimleri

Ana veri sahipliğini (ürünler, formüller , müşteriler/tedarikçiler), anahtarları (parti/seri, GTIN , SSCC ) ve senkronizasyon sıklığını belirtin. Laboratuvar ve üretim için, cihaz ve aygıt veri yakalama ve gerekli TMV veya kalibrasyon izlenebilirliğini tanımlayın. Giden izlenebilirlik için, EPCIS veya EDI yüklerini ve zamanlamasını belirtin. URS ayrıca, geçiş sırasında geç sürprizlerden kaçınmak için veri geçiş sınırlarını (hangi geçmiş verilerin hangi ayrıntı düzeyinde içe aktarılması gerektiğini) de tanımlamalıdır.

8) Açıkça Dahil Edilecek Uyumluluk İçeriği

Bölüm 11 / Ek 11 davranışlarını (benzersiz kullanıcı kimlikleri, elektronik imza istemleri, imza anlamı, kayıt koruması), denetim izi beklentilerini (kim/ne/ne zaman/neden ve raporlama) ve saklama/arşivleme kurallarını (değiştirilemezlik, erişim süresi) ayrıntılı olarak açıklayın . İlgili durumlarda, alan düzenlemeleriyle (örneğin, 21 CFR Bölüm 211 , ISO 13485 , GDP ) uyumlu hale getirin. Raporların, etiketlerin ve dışa aktarılan dosyaların içerik ve biçim beklentilerini karşıladığını ve barkod doğrulamasının kullanıldığını doğrulayın.

9) Kabul Kriterleri ve URS'nin Testleri Nasıl Yönettiği

Her gereksinimin, test uzmanının tahmine dayalı olmadan uygulayabileceği kabul kriterleri olmalıdır. Kriterler, belirli çıktıları (örneğin, bir eBMR bölüm kimliği, bir etiket şablonu sürümü, bir rapor adı), rol davranışını ve geçme/kalma eşiklerini referans alır. Kullanıcı kabul testi (UAT) sırasında , senaryolar bu kriterlere, hatalar ise gereksinim kimliklerine kadar izlenebilir; bu da risk kapsamını ve sürüm kararlarını şeffaf hale getirir.

10) URS'den Kanıta İzlenebilirlik

Her URS gereksinimini tasarım/yapılandırma nesnelerine, test betiklerine ve sonuçlarına, ilişkili risklere ve kontrollere ve eğitim/SOP güncellemelerine bağlayan bir izlenebilirlik matrisi oluşturun. Bu tek iş parçacığı, denetçilerin herhangi bir gereksinimi seçip kanıta ulaşmasını sağlar ve yetim testleri veya doğrulanmamış özellikleri önler. Gereksinimler değiştiğinde, matris tam olarak hangi kanıtların yeniden işlenmesi gerektiğini gösterir.

11) Tedarikçi Seçiminde URS Kullanımı

Kullanıcı Gereksinimleri Spesifikasyonunu (URS) bir Teklif İstek Formu (RFP) kontrol listesine dönüştürün. Tedarikçilerden gereksinimlere tek tek "hazır çözüm", "konfigürasyon" veya "özel" göstergelerle yanıt vermelerini ve yüksek riskli öğeleri canlı olarak göstermelerini isteyin. Teklifleri, URS'yi ne kadar eksiksiz ve doğal bir şekilde karşıladıklarına ve özel kod olmadan uyumluluğu (örneğin, değiştirilemez denetim izleri) koruma yeteneklerine göre puanlayın. Bu, doğrulayamayacağınız veya destekleyemeyeceğiniz özellikleri satın almaktan kaçınmanızı sağlar.

12) Değişimi Yönetmek - URS'yi Canlı Tutmak

Sistem devreye alındıktan sonra yeni ihtiyaçlar ortaya çıkacaktır. URS güncellemelerini MOC kapsamındaki kontrollü değişiklikler olarak ele alın : etkiyi değerlendirin, riskleri güncelleyin, izlenebilirlik matrisini gözden geçirin ve hedefli yeniden testler planlayın. Gereksinimlerin yalnızca krizler veya denetimler sırasında değil, makul aralıklarla yenilenmesi için politika ve kalite planlamasıyla uyum sağlayın.

13) URS Kalitesini Gösteren Ölçütler

• İzlenebilirlik tamlığı: onaylı testlere ve geçme kanıtlarına bağlı gereksinimlerin yüzdesi.
• Risk teminatı: Açık, test edilebilir gereksinimler ve UAT senaryoları ile yüksek/orta risklerin payı.
• Belirsizlik oranı: 100 gereksinim başına gözden geçiren tarafından işaretlenen öğeler (hedef < 2).
• Stabiliteyi değiştir: taslak ile onay arasındaki gereksinim değişimi; yüksek değişim, kapsamın belirsiz olduğunu gösterir.
• Kusur sızıntısı: Eksik/belirsiz gereksinimlere dayanan UAT kusurları (sıfıra doğru gidiş).

Bunları takip etmek, kuruluşların gereksinim netliğini artırmasına ve doğrulamayı orantılı ve verimli tutmasına yardımcı olur.

14) Yaygın Tuzaklar ve Bunlardan Nasıl Kaçınılır

• Tasarıma atlıyoruz. URS'de "nasıl" ifadesini kullanmayın; gözlemlenebilir sonuçları belirtin.
• Belirsiz sıfatlar. “Sezgisel/sağlam/hızlı” ifadesini ölçülebilir ölçütler ve eşiklerle değiştirin.
• Çok büyük bir gereksinim. Başarılı veya başarısız olabilen, atomik, benzersiz numaralandırılmış ifadelere bölün.
• İşlevsel olmayan ihtiyaçların göz ardı edilmesi. Performans, kullanılabilirlik ve güvenlik ayrı bir BT notunda değil, URS'de yer alır.
• Kullanıcı sahipliği yok. İşletmenin yazması ve onaylaması gerekir; BT kolaylaştırır, QA yönetir.
• Kontrolsüz düzenlemeler. Kullanım Döküman kontrolu sürüm geçmişi ve resmi onay iş akışı.

15) URS Kaydında Neler Bulunur?

Kapsam ve sistem tanımlayıcılarını; amaçlanan kullanımı; paydaşları ve rolleri; benzersiz kimlikler, öncelikler ve risk etiketleri içeren gereksinim listesini; işlevsel olmayan gereksinimleri; entegrasyon ve veri kapsamını; kabul kriterlerini; politikalara, standartlara ve SOP'lara referansları; ve veri sözlükleri veya süreç haritaları için ekleri ekleyin. Onay imzalarını, sürüm geçmişini ve izlenebilirlik matrisine, test planlarına ve eğitim etkilerine bağlantıları aynı kontrollü kayıtta yakalayın.

16) Bu V5 ile Nasıl Uyumlu? SG Systems Global

Yazma ve Yönetişim. V5 platformu, Kalite Yönetim Sistemi (QMS) modülünde yönetilen URS şablonları sunar. Yazarlar, Belge Kontrolü altında gereksinimler oluşturur, risk etiketleri uygular ve Onay İş Akışı aracılığıyla elektronik imza onayına yönlendirir . Sürümleme otomatik ve değiştirilemez olup, denetim izi beklentilerini karşılar.

URS'den Testlere. V5, her gereksinimi test edilebilir bir nesneye dönüştürür: UAT senaryolarını başlatır , CSV'deki doğrulama planlarına bağlantı kurar ve gereksinim → yapılandırma → test → sonuç → eğitim/SOP güncellemeleri arasında canlı bir izlenebilirlik matrisi sağlar.

Risk Orantılı Kapsam. Gereksinimler risk etiketli olduğundan, V5 test derinliğini ve kanıt yükünü otomatik olarak önceliklendirir. Yüksek riskli kontroller (örneğin, elektronik imza bağlama, WMS'de envanter durumu değişiklikleri , MES'te parti onayı , LIMS'te laboratuvar onayları ) tasarım gereği daha güçlü kapsama alanı alır.

Entegrasyon ve Kayıtlar. Arayüzler (EDI, EPCIS , cihazlar, yazıcılar) için V5, URS gereksinimlerini gerçek yük kontrollerine ve cihaz olaylarına bağlar. Kanıtlar (ekran görüntüleri, PDF'ler, etiket görüntüleri, yük örnekleri) otomatik olarak yakalanır ve Kayıt Saklama altında saklanır.

Değişiklik Kontrolü. Kapsam değiştiğinde, V5 bağlantılı bir Değişiklik Kontrolü (MOC) oluşturur , URS sürümünü günceller ve etkilenen testleri ve SOP'leri yeniden çalışma için işaretler; böylece tüm zincir denetime hazır halde kalır.

Özetle: V5, URS'yi seçilim, doğrulama ve sürekli iyileştirmeyi yönlendiren, yaşayan ve yönetilen bir unsur haline getiriyor; dosyalanıp unutulan bir PDF dosyası olmaktan çıkarıyor.

17) SSS

S1. URS, Fonksiyonel veya Tasarım Spesifikasyonundan nasıl farklıdır?
URS şöyle diyor: ne kullanıcıların ihtiyacı ve nedeni; işlevsel/tasarım özellikleri belirtilir Nasıl Sistem bu ihtiyaçları karşılayacaktır. URS bir işletmenin mülkiyetindedir; tasarım genellikle satıcı/BT'nin mülkiyetindedir.

S2. URS'yi kim onaylar?
Süreç sahipleri ve QA, BT ve doğrulama onayıyla birlikte. Onaylar, yönetilen iş akışı yani hesap verebilirlik açıktır.

S3. Çevikliği kullanıp yine de bir URS'ye sahip olabilir miyiz?
Evet. Kontrollü bir URS temel çizgisini koruyun ve değişiklik kontrolünü yineleyin. Büyük gereksinimleri destanlara/hikayelere bölün, ancak izlenebilirliği ve onayları koruyun.

S4. Ne kadar ayrıntılı olmalı?
Test edilebilir ve seçim/yapılandırma konusunda bilgi verebilecek kadar ayrıntılı, ancak bir tasarım kılavuzu değil. Bir okuyucu bir kabul testi yazamıyorsa, yeterince ayrıntılı değildir; düğme yerleşimini belirtiyorsa, çok ayrıntılıdır.

S5. Bir gereksinimin yerine getirilmemesi durumunda ne olur?
Bir değişikliği şu şekilde yükseltin: MOC, riskleri ve izlenebilirlik matrisini güncelleyin ve canlıya geçmeden önce veya canlıya geçtikten sonra kontrollü bir iyileştirme olarak hedefli testleri planlayın.

S6. URS'yi SOP'larla nasıl uyumlu tutabiliriz?
Gereksinimleri SOP referanslarına bağlayın ve gereksinimler değiştiğinde izlenebilirlik matrisinde SOP/eğitim güncellemelerini tetikleyin. Eğitim Matrisi Rol hazırlığını doğrulamak için.

İlgili Okuma
• Doğrulama ve Yönetişim: CSV | Gamp 5 | Döküman kontrolu | Onay İş Akışı | QRM
• Uyumluluk Temelleri: 21 CFR Bölüm 11 | Ek 11 | Denetim İzi | Veri bütünlüğü | Kayıt tutma
• Yürütme Bağlamları: MES | LIMS | WMS | eBMR | Etiket Doğrulaması | EPCIS
• Değişiklikler ve Testler: MOC | UAT | Sapma/NC | CAPA