Teknik Şartnameyi Ayrıştırma ve Açıklama Soruları

Ön koşul: Modül 19'un ilk dersindeki geçerli belge defteri, zeyilname izi ve yanıt charter'ı hazır olmalıdır. Bu derste uzun teknik şartnameyi madde madde okuyup her cümleyi tekil, doğrulanabilir gereksinimlere; kabul ölçüsüne, kanıta, açıklama sorusuna ve çözüm etkisine bağlayacaksın. Yaklaşık 30 dakika anlatı, 27 dakika uygulama ve 12 dakika kontrol önerilir. NASA Sistem Mühendisliği El Kitabı iyi gereksinimi açık, tek anlamlı, uygulanabilir ve doğrulanabilir olarak tarif eder; tek cümlede birden çok yükümlülük saklanmamasını önerir. NASA iç süreçleri Arven teklifine zorunlu standart değildir, fakat okuma ve ayrıştırma yöntemi olarak yararlıdır. Şartnamede 'sistem güvenli, ölçeklenebilir ve kesintisiz olacaktır' yazıyorsa bu tek satır değildir. Kimlik/erişim, kapasite/yük, hata toleransı, veri kaybı ve hizmet saatleri ayrı alt gereksinimlere bölünür. Her biri için iş sahibi, kullanım senaryosu ve test yöntemi aranır. Cümleyi aynen kopyalayıp üç ürüne 'uygun' işareti koymak kanıt değildir.

Kaynak madde numarasını ve zeyilname sürümünü asla kaybetme. RFP 4.2 maddesi üç alt iddia içeriyorsa 4.2-a, 4.2-b ve 4.2-c gibi iç kimlik üret; bu kimlikler resmî şartname numarasının yerine geçmez, yanıtın izini güçlendirir. Her iç kimliğe orijinal metin, yorum, sistem sınırı, hedef değer, kabul kanıtı, kaynak mimari/BoM satırı, owner ve durum ekle. İstek 'müşteri tarafından sağlanacaktır' diyorsa tedarik bağımlılığını işaretle. İstek 'yüklenici sağlayacaktır' diyorsa ürün, lisans ve hizmet maliyetini kontrol et. Bir maddede hem asgari hem tercih edilen değer varsa aynı kategoriye koyma. Gereksinimi atomik hâle getirmek, müşteri talebini tek taraflı yeniden yazmak değildir; yorumun onay ve açıklama gerektiren tarafı ayrıca kaydedilir.

Kabul ölçüsü olmadan şartname iddiası fiyat, mimari ve test üzerinde farklı yorumlara yol açar. '99,9% erişilebilirlik' hangi hizmette, hangi saat diliminde, planlı bakım dahil mi, üçüncü taraf ERP kesintisi hariç mi, hangi ölçüm noktasında? '1.000 işlem/saniye' ortalama mı tepe mi; yük profili, veri boyutu ve gecikme eşiği nedir? Bir sayı bile tanım olmadan yeterli değildir. NASA gereksinim doğrulama yaklaşımı neyin hangi yöntemle gösterileceğini netleştirmeyi vurgular. Arven için her gereksinime test, analiz, inceleme veya gösterim türünden uygun kanıt atanır; yöntem müşteri kabul yetkilisiyle doğrulanır. Örneğin üretim portalında failover davranışı laboratuvarda gösterilebilir, ancak gerçek ERP işlemlerinin tutarlılığı ayrı veri uzlaştırması gerektirir. 'Demo geçti' yazıp bütün iş sonucu kabulünü kapatma.

Sistem sınırını ayrı çiz. Pre-sales'in önerdiği altyapı 7/24 çalışsa bile portal uygulaması bakım penceresinde durabilir; ERP servisinin yavaşlığı son kullanıcı gecikmesini belirleyebilir. Teklif hangi katmanı ve hangi arıza alanını kapsıyor? Müşterinin sağladığı ağ, kimlik, test verisi, API erişimi ve operasyon personeli varsayımlarını açık yaz. Bu girdiler gelmezse performans ve takvim etkisi ne olur? FAR 37.6 ABD federal performans temelli hizmet alımlarında ölçülebilir performans standartları ve değerlendirme yöntemini vurgular; Arven veya Türkiye alımında hukuki hüküm değildir. Yöntemsel ders, 'yüksek performans' gibi sıfatı müşteri tarafından ölçülebilir sonuca çevirmektir. Kabul hesabını kim yapacak, ölçüm ne kadar sürecek ve itiraz yolu ne olacak soruları teklif başında cevaplanmalıdır.

Şartnamede iki madde birbiriyle çelişebilir: biri on-prem veri saklama isterken diğeri belirli bulut servisinde yönetilen veri tabanı şart koşar. Bir zeyilname eski kapasite değerini değiştirirken fiyat şablonu eski değeri taşıyabilir. Pre-sales bir maddeyi sessizce tercih etmez; belge öncelik sırası, resmî açıklama ve müşteri kararı gerekir. Çelişki kartında iki kaynak/madde, yorum seçenekleri, iş ve maliyet etkisi, önerilen açıklama sorusu, cevap son tarihi ve owner görünür. NASA gereksinim pratiği çözümlenmemiş alanları TBR olarak gerekçe, kapatma işi, sorumlu ve tarih ile izlemeyi önerir. Bu durum 'bilinmiyor' yazıp unutmak değildir. Arven için ERP API sürümü bilinmiyorsa test planı ve entegrasyon maliyeti aralıkla yazılır; sürüm teyidi son tarihine bağlanır.

Bazı şartnameler belirli bir marka, model veya ürün terimi kullanır. Bunun gerçekten zorunlu ürün mü, mevcut altyapıyla uyumluluk göstergesi mi, yoksa örnek mimari mi olduğunu müşteri belgelerinden anlamaya çalış. Alternatif teklifin izinli olup olmadığını teklif talimatından oku; eşdeğerliği kendi kendine ilan etme. Tek ürün şartı rekabet veya satın alma hukuku açısından sorunlu görünüyorsa pre-sales hukuk hükmü vermez, bid manager ve hukuk/satın alma uzmanına taşır. Müşteriye sorulabilecek teknik soru iş sonucuna odaklanır: hangi fonksiyon, performans ve mevcut çevre uyumu zorunlu? Yanıtta marka eşdeğerliği iddiası varsa sürüm, sertifikasyon, test ve destek kanıtı verilmelidir. Cevap gelene kadar BoM ve fiyat kesinleşmez. Sözlü partner vaadi veya başka ihale belgesi, bu müşterinin geçerli şartnamesinin yerine geçmez.

İyi açıklama sorusu kısa ama karar verdiricidir. Madde referansı, görülen belirsizlik, mümkün yorumlar ve hangi cevapta neyin değişeceği birlikte yazılır. Müşterinin resmî soru kanalı ve son tarihi dışında özel konuşmayı tüm katılımcılar için geçerli değişiklik sayma. Arven için 'ERP entegrasyonu nedir?' yerine '4.2 maddesindeki 15 dakika sınırı ERP'de kaydın oluşmasına mı, üretim sistemine görünmesine mi uygulanır; testte kullanılacak sürüm ve veri seti nedir?' diye sor. Müşteri cevaplayamazsa iki seçenek kalır: belgede izin veriliyorsa açık varsayımla koşullu çözüm sunmak veya teklif kapsamından istisna etmek. Her ikisi de ticari onay ve görünür müşteri metni gerektirir. Soru-cevap, çözüm ekibinin kendi arasında kararlaştırdığı yorumun resmî kanıtı değildir; cevap kaynağı ve tarihi kaydedilir.

Yanıt geldiğinde yalnız soru defterini 'kapalı' işaretlemek yetmez. Değişen alt gereksinimler, kabul protokolü, HLD, BoM, lisans, destek, TCO, teslim takvimi ve teklif cümleleri yeniden kontrol edilir. Bir API sürümü yanıtı yazılım adaptörünü ve partner destek kapsamını değiştirebilir. Değişiklik yönü çift taraflı olmalı: her şartname alt maddesi çözüm ve kanıta, her çözüm iddiası da şartname maddesine bağlanmalıdır. Bu iz sonraki modülün compliance/response matrix dersine girdi olur. Önceki dersin belge defteri, bu dersin atomik kartı ve soru kaydı aynı sürüm numarasını taşımalıdır. Bir madde resmî zeyilnameyle silinirse eski iç kart arşive alınır; sessizce güncelmiş gibi teklife taşınmaz. Son kontrol, kritik tüm maddeler için Pass, Conditional, Fail veya Unknown durumu, eksik kanıt owner'ı ve sonraki eylemi olduğundan emin olur.