Yazılım Satın Alma Şartnamesinde API, Yetkilendirme ve Kabul Testleri Nasıl Tanımlanır?

Teknik Şartname Hangi İş Senaryolarını Tanımlamalı?

Kurumsal yazılım teknik şartnamesi, kullanıcının sistemde gerçekleştireceği temel iş senaryolarını başlangıç noktası olarak tanımlamalıdır. “Sipariş modülü olacak” veya “ERP entegrasyonu yapılacak” gibi genel ifadeler yerine işlemi kimin başlattığı, hangi verilerin kullanıldığı, hangi kontrol ve onaylardan geçtiği ve işlemin hangi sonuçla tamamlandığı açıklanmalıdır.

Özellik listesinden doğrulanabilir gereksinime nasıl geçilir?

Her gereksinim mümkün olduğunca aktör, işlem, veri, iş kuralı ve beklenen sonuç bileşenleriyle yazılabilir. Örneğin bir satış siparişinin ERP sistemine aktarılması isteniyorsa aktarımı tetikleyen olay, gönderilecek alanlar, başarısız aktarım davranışı ve kullanıcıya gösterilecek durum da kapsamın parçasıdır. kurumsal yazılım mimarisi ve API entegrasyonlarının planlanması konusunda olduğu gibi teknik bileşenleri gerçek iş süreçleriyle ilişkilendirmek teklif kapsamındaki belirsizliği azaltır.

• Sistemi kullanacak kullanıcı veya sistem aktörlerini belirleyin
• Her temel işlemin başlangıç ve bitiş koşulunu yazın
• Kullanılacak ve üretilecek verileri tanımlayın
• İş kurallarını ve kontrol noktalarını belirtin
• Başarılı ve başarısız senaryoları ayrı tarif edin
• Her gereksinimi teslimde sınanabilecek hale getirin

“Quality means doing it right when no one is looking.” - Henry Ford

API ve Sistem Bağlantıları Ne Kadar Ayrıntılı Yazılmalı?

Yazılım API gereksinimleri, yalnızca hangi sistemlerin birbirine bağlanacağını değil, bağlantının hangi iş amacıyla kullanılacağını ve hangi veri hareketlerini gerçekleştireceğini açıklayacak ayrıntıda yazılmalıdır. Teknik şartnamenin doğrudan bütün endpoint ayrıntılarını içermesi her zaman gerekmez; ancak entegrasyonun kapsamını etkileyen veri, işlem, kimlik doğrulama ve hata senaryoları açık olmalıdır.

Entegrasyon şartnamesinde hangi bilgiler bulunmalı?

Kaynak ve hedef sistem, veri yönü, aktarılacak temel veri kümeleri, işlemin gerçek zamanlı mı yoksa zamanlanmış mı çalışacağı ve hata durumunda beklenen davranış belirtilmelidir. Mevcut API dokümantasyonunun kim tarafından sağlanacağı da sorumluluk matrisine eklenmelidir. SaaS ürünü ve API entegrasyonlarının planlanmasında olduğu gibi bağlantının teknik varlığından çok iş sürecindeki görevi netleştirilmelidir. Böylece “entegrasyon dahil” ifadesinin iki tedarikçi tarafından tamamen farklı yorumlanması önlenebilir.

• Kaynak ve hedef sistemleri açıkça tanımlayın
• Verinin hangi yönde hareket edeceğini belirtin
• Temel veri nesnelerini ve işlemleri listeleyin
• Kimlik doğrulama yönteminin sorumluluğunu belirleyin
• Hata, tekrar deneme ve kayıt beklentilerini açıklayın
• API dokümantasyonu ve erişim sorumlularını yazın

Rol Bazlı Yetkilendirme Şartnamede Nasıl Tarif Edilmeli?

Yazılım rol bazlı yetkilendirme gereksinimleri yalnızca yönetici, kullanıcı veya personel gibi rol adlarından oluşmamalıdır. Her rolün hangi verileri görebileceği, hangi işlemleri başlatabileceği, hangi kayıtları değiştirebileceği, hangi işlemleri onaylayabileceği ve hangi yönetim fonksiyonlarına erişebileceği ayrı biçimde tanımlanmalıdır.

Rol ile onay akışı arasındaki ilişki nasıl kurulmalı?

Yetkilendirme matrisi, iş akışındaki sorumluluklarla birlikte hazırlanmalıdır. Örneğin sipariş oluşturan kullanıcı ile aynı siparişi onaylayan kullanıcının farklı olması gerekiyorsa bu ayrım açık bir iş kuralına dönüştürülmelidir. Şube, departman, müşteri grubu veya organizasyon seviyesine göre veri görünürlüğü değişiyorsa bu kapsam da belirtilmelidir. Böylece tedarikçi yalnızca ekran bazlı yetki kontrolü değil, iş kurallarını uygulayan bir erişim modeli için teklif hazırlayabilir.

• Her kullanıcı rolünü ve sorumluluğunu tanımlayın
• Görüntüleme, oluşturma, değiştirme ve silme yetkilerini ayırın
• Onay verme ve işlemi başlatma yetkilerini belirtin
• Organizasyon veya şube bazlı veri kapsamını açıklayın
• Kritik işlemlerde görev ayrılığı gereksinimini yazın
• Yetki değişikliklerinin kayıt beklentisini tanımlayın

Güvenlik ve İşlem Kayıtları Nasıl Gereksinime Dönüşür?

Yazılım güvenlik gereksinimleri, “sistem güvenli olmalıdır” gibi ölçülemeyen ifadeler yerine uygulanabilir kontroller üzerinden tanımlanmalıdır. Kimlik doğrulama, oturum yönetimi, yetkisiz erişimin engellenmesi, hassas verilerin korunması, işlem kayıtları ve yönetici faaliyetlerinin izlenmesi gibi ihtiyaçlar kurumun kullanım senaryosuna göre ayrı gereksinimlere dönüştürülmelidir.

Denetim izi hangi işlemleri kapsamalı?

Kurumsal sistemlerde hangi kullanıcının hangi kritik işlemi ne zaman gerçekleştirdiğinin izlenebilmesi operasyonel kontrol açısından önem taşıyabilir. Bu nedenle oluşturma, değiştirme, silme, onaylama, yetki değiştirme ve entegrasyon hataları gibi olayların hangilerinin kaydedileceği şartnamede belirtilmelidir. Güvenlik kapsamı belirlenirken tedarikçiden genel güvenlik beyanı istemek yerine, kurumun doğrulayabileceği somut davranışlar ve teslim çıktıları tanımlanmalıdır.

• Kimlik doğrulama beklentilerini açıkça yazın
• Oturum ve erişim kontrollerini tanımlayın
• Kritik kullanıcı işlemlerinin kayıt kapsamını belirleyin
• Yetki değişikliklerinin izlenmesini talep edin
• Entegrasyon hatalarının kayıt davranışını açıklayın
• Hassas veriler için uygulanacak kontrolleri kapsamlandırın

Entegrasyonun Çalıştığı Teslimde Nasıl Doğrulanmalı?

Teklif edilen entegrasyonun çalıştığı, yalnızca bağlantının kurulmasıyla değil, şartnamede tanımlanan iş senaryolarının uçtan uca başarıyla tamamlanmasıyla doğrulanmalıdır. Bir API isteğinin teknik olarak yanıt vermesi, verinin doğru alanlarla aktarıldığını, iş kurallarının uygulandığını veya hata durumlarının doğru yönetildiğini tek başına kanıtlamaz.

Entegrasyon kabul senaryosu nasıl hazırlanmalı?

Her kritik entegrasyon için başlangıç verisi, gerçekleştirilecek işlem, beklenen hedef sistem sonucu ve kontrol edilecek kayıtlar önceden belirlenebilir. Örneğin ERP entegrasyonlu yazılım satın alma sürecinde bir siparişin oluşturulması, aktarılması, ERP tarafında doğru alanlarla kaydedilmesi ve sonucun uygulamaya geri dönmesi tek bir kabul senaryosu olarak ele alınabilir. yetkilendirme ve entegrasyon modellerini karşılaştırırken de vaat edilen işlevin hangi yöntemle doğrulanacağı teklif aşamasında sorgulanmalıdır.

• Her entegrasyon için uçtan uca senaryo hazırlayın
• Testte kullanılacak başlangıç verisini tanımlayın
• Hedef sistemde beklenen sonucu belirtin
• Alan eşleştirmelerini kontrol kapsamına alın
• Hata ve başarısız aktarım senaryolarını test edin
• Sonucun hangi kanıtlarla kabul edileceğini yazın

Kurumsal Yazılım Kabul Testleri Nasıl Hazırlanmalı?

Kurumsal yazılım kabul testleri, proje tamamlandığında ilk kez düşünülmemeli; teknik şartname hazırlanırken gereksinimlerle birlikte tasarlanmalıdır. Her kritik gereksinimin teslim sırasında nasıl doğrulanacağı önceden tanımlandığında hem kurum hem tedarikçi “tamamlandı” ifadesinin hangi ölçüte dayandığını bilir ve kapsam yorumları daha kolay yönetilir.

Örnek veri ve başarı ölçütlerini kim hazırlamalı?

Kabul testleri ortak bir hazırlık gerektirir. Kurum, gerçek operasyonu temsil eden iş senaryolarını, kuralları ve uygun test verilerini sağlamalı; tedarikçi ise çözümün teknik davranışını doğrulayacak test adımlarını ve gerekli ortamı hazırlamalıdır. Veri gizliliği veya güvenlik nedeniyle gerçek üretim verisi kullanılamıyorsa temsili test verileri oluşturulabilir. yazılım geliştirme firmasında test ve teslim yaklaşımını değerlendirirken kabul yönteminin proje sonuna bırakılmaması önemli bir karşılaştırma kriteridir.

• Her kritik gereksinime bir kabul senaryosu bağlayın
• Kurumun sağlayacağı örnek verileri belirleyin
• Tedarikçinin hazırlayacağı test adımlarını tanımlayın
• Beklenen sonuçları ölçülebilir biçimde yazın
• Başarısız ve sınır durumlarını kapsama alın
• Hata düzeltme ve yeniden test yöntemini belirleyin

Kurum ve Tedarikçi Sorumlulukları Nasıl Ayrılmalı?

Yazılım entegrasyon şartnamesi, yalnızca tedarikçinin geliştireceği işleri değil, kurumun projeyi ilerletebilmek için sağlayacağı erişim, dokümantasyon, test verisi ve kararları da tanımlamalıdır. Bir entegrasyonun tamamlanması mevcut sistem sağlayıcısından API erişimi alınmasına bağlıysa bu bağımlılık tedarikçinin tek taraflı teslim yükümlülüğü gibi yazılmamalıdır.

Şartname görüşmesine hangi kurum ekipleri katılmalı?

Teknik ekip tek başına bütün operasyonel kuralları, süreç sahipleri de tek başına bütün teknik bağımlılıkları tanımlayamayabilir. Bu nedenle satın alma veya proje yönetimi, ilgili iş birimi, bilgi teknolojileri, bilgi güvenliği ve entegrasyon yapılacak sistemlerin sorumluları ihtiyaç ölçüsünde aynı hazırlık sürecine dahil edilmelidir. Sorumlulukların erken ayrılması, teklif veren firmaların kurum tarafından sağlanacak girdiler ile kendi geliştirme yükümlülüklerini daha doğru ayırmasına yardımcı olur.

• Süreç sahiplerinden iş kurallarını doğrulayın
• BT ekibiyle mevcut sistem bağımlılıklarını belirleyin
• Gerekli güvenlik kontrollerini ilgili ekiplerle değerlendirin
• Satın alma ekibiyle teklif kapsamını eşitleyin
• Mevcut sistem sorumlularından entegrasyon bilgilerini alın
• Her teslim girdisinin sorumlusunu açıkça belirleyin

Aynı Teknik Kapsamla Yazılım Teklifi Nasıl Alınmalı?

Sağlayıcılardan karşılaştırılabilir teklif almanın temel koşulu, kurumsal yazılım satın alma teknik şartnamesindeki gereksinimlerin aynı kapsam, sorumluluk ve kabul yaklaşımıyla paylaşılmasıdır. Tedarikçilerin yalnızca toplam proje kapsamını değil, entegrasyonları, kullanıcı rollerini, güvenlik kontrollerini, testleri, dokümantasyonu ve destek sınırlarını nasıl karşıladıklarını açıklamaları istenmelidir.

Teklif değerlendirmesinde hangi teknik sorular sorulmalı?

Kurumsal yazılım teknik değerlendirme sırasında her gereksinimin standart üründe mevcut mu, yapılandırma mı gerektiriyor, özel geliştirme mi gerektiriyor yoksa üçüncü taraf bağımlılığı mı taşıyor olduğu sorulabilir. Ayrıca kabul testlerini kimin yürüteceği, entegrasyon hatalarının nasıl ele alınacağı ve teslim sonrasında hangi teknik desteğin kapsamda bulunduğu açıklanmalıdır. Böyle bir yapı, fiyatların yanında kapsam farklılıklarının da görülmesini ve tekliflerin daha anlamlı karşılaştırılmasını sağlar.

• Her tedarikçiye aynı gereksinim setini iletin
• Standart özellik ve özel geliştirmeyi ayrı göstermelerini isteyin
• Entegrasyon sorumluluklarını teklif içinde doğrulatın
• Kabul testi ve dokümantasyon kapsamını karşılaştırın
• Varsayım ve kapsam dışı maddeleri açıkça isteyin
• Geçiş sonrası destek sorumluluklarını netleştirin