Gereksinim ve Toplantı Özeti

Ön koşul: hazırlık kartı, beş katmanlı soru ağacı ve kanıt günlüğünü tamamlamış olmalısın. Bu dersin sonunda talep, ihtiyaç, gereksinim, tercih ve kısıtı ayırabilecek; müşteri ifadesini tekil ve test edilebilir gereksinime dönüştürebilecek; her gereksinime kaynak, gerekçe, öncelik, ölçüm, kabul eşiği, sahip ve durum ekleyebilecek; toplantı özetini katılımcıların düzeltebildiği doğrulama aracına çevirebileceksin. Sürenin 25 dakikası anlatı ve örneklere, 17 dakikası Arven register’ına, 10 dakikası kontrollere ayrılır.

Talep müşterinin ilk söylediği çözüm veya eylemdir: “Yeni storage istiyoruz.” İhtiyaç değişmesi gereken iş ya da operasyon sonucudur: “Yoğun saatte sipariş işlemleri geciktiği için bayi kaybını azaltmalıyız.” Gereksinim seçilecek çözümün karşılaması gereken doğrulanabilir koşuldur. Tercih zorunlu olmayan fakat seçim değerini etkileyen istektir. Kısıt ise seçenek alanını gerçekten sınırlayan bütçe, zaman, teknoloji, politika, beceri veya entegrasyon sınırıdır. Bu sınıflar müşterinin sözünü değersizleştirmez. Ürün talebi geçmiş deneyim veya standartlaşma gerekçesi taşıyabilir. “X marka olmalı” ifadesini hemen yanlış sayma; nedenini sor. Onaylı kurumsal standart ve mevcut otomasyon bağımlılığı varsa kısıt olabilir. Ekibin alışkanlığı ise tercih olabilir. Ayrımı belirleyen ürün adı değil, gerekçe, karar sahibi ve değişirse doğacak etkidir. İhtiyaç ile gereksinim de karıştırılır. “Kesinti azalsın” ihtiyaç yönünü gösterir fakat test eşiği taşımaz. “Tanımlı yoğunlukta siparişlerin yüzde 95’i iki saniyede tamamlanmalı” ölçülebilir gereksinimdir. Bu sayı iş sahibi ve baseline tarafından doğrulanmadan fact değildir; TBD hedef olarak kaydedilir. Discovery’nin görevi sahte hassasiyet üretmek değil, hedefin kim tarafından hangi kanıtla kapanacağını göstermektir. Bir ifade birden çok sınıf taşıyorsa böl. “Mevcut protokol korunmalı ve performans artmalı” iki ayrı düşüncedir: entegrasyon kısıtı ile performans gereksinimi. Tek satırda kaldığında biri sağlanıp diğeri kaçabilir; öncelik ve test yöntemi ayrı yönetilemez.

İyi gereksinim gerekli, uygun, açık, tamamlanmış, tekil, uygulanabilir ve doğrulanabilir olmalıdır. INCOSE bu nitelikleri tek tek ve gereksinim kümesi düzeyinde ele alır. Pre-Sales register’ında pratik karşılığı şudur: her satır tek beklenti taşır; özne ve beklenen sonuç bellidir; belirsiz sıfat yerine ölçüm vardır; çözüm tasarımı gereksiz yere cümlenin içine gizlenmez; kaynak ihtiyaca kadar izlenebilir; test veya inceleme yöntemi tanımlanabilir. “Sistem hızlı olmalı” belirsizdir. “Tanımlı kampanya yükünde bayi siparişlerinin yüzde 95’i kullanıcıdan alınan zaman damgasıyla iki saniyede tamamlanmalı” daha güçlüdür; yine de yük profili, ölçüm noktası, veri seti ve istisnalar eksik olabilir. Gereksinim cümlesi her ayrıntıyı taşımak zorunda değildir; register ölçüm yöntemi ve kabul koşulu alanlarıyla tamamlar. Tekillik değişiklik yönetimini kolaylaştırır. “Platform hızlı, yedekli ve ucuz olmalı” üç ayrı beklentidir. Ayrıldığında performansın nasıl ölçüleceği, dayanıklılığı kimin test edeceği ve maliyet sınırını kimin onaylayacağı görünür olur. Çelişkiler de bulunabilir: sıfıra yakın kesinti ile çok dar bütçe aynı anda uygulanabilir olmayabilir. Gereksinim seti tek tek doğru görünse bile birlikte uygulanabilir ve tutarlı olmalıdır. Her gereksinime kimlik ver: ARV-REQ-001. Kaynak ihtiyacı, gerekçe, öncelik, bilgi durumu, kabul eşiği, doğrulama yöntemi, veri sahibi ve hedef tarih ekle. “Must/Should/Could” gibi öncelik etiketi karar sahibi olmadan anlamlı değildir. Yüksek öncelik maliyet veya trade-off yaratıyorsa onay izi gerekir.

Toplantı özeti tutanak arşivi değil, elicitation sonucunu doğrulama aracıdır. İlk bölüm amaç ve karar bağlamını; ikinci bölüm doğrulanan bulguları; üçüncü bölüm assumption, unknown, TBD ve çelişkileri; dördüncü bölüm gereksinim adaylarını; son bölüm ise eylem, sahip ve tarihleri taşır. İlk yön veya seçenek konuşulduysa “nihai çözüm” diye değil, hangi kanıtla sınanacak hipotez olarak yazılır. Özeti karar bağlamı tazeyken paylaş. Kitaptaki 24 saat yararlı bir hizmet seviyesi önerisidir, evrensel yasa değildir. Kritik konu, taraflar farklı hatırlamaya başlamadan doğrulama istemektir. “Yanıt gelmezse kabul edilmiş sayılır” yaklaşımı ancak kurumun önceden açık yönetişim kuralı varsa kullanılabilir; sessizlik teknik onay değildir. Özette kaynak dili korunur. “Müşteri storage kaynaklı performans problemi olduğunu doğruladı” yazma; eğer yalnız gecikme bildirdiyse “Ay sonu rapor işleminde gecikme gözlendi; storage katkısı ASSUMED, ortak metrik bekleniyor” yaz. Her düzeltme register durumunu günceller. Yeni bilgi önceki kaydı geçersiz kıldığında değişim izini koru. Kapanışta bir sonraki toplantının adını değil karar kapısını tanımla: “16 Eylül kapasite ve uygulama raporları geldikten sonra performans nedenini ve geçiş kapsamını onaylayacağız.” Böylece takip takvim faaliyeti değil, kanıtla kapanan karar olur.

Arven kanıt günlüğü üç doğrulanmış bulgu verir: mevcut platform desteği ocakta bitiyor, kasım sonunda değişiklik dondurma dönemi başlıyor ve ay sonu rapor işleminde kullanıcı gecikmesi gözleniyor. Storage’ın gecikmenin nedeni olduğu hâlâ ASSUMED; kapasite raporunun kapsamı ve uçtan uca metrikler bekleniyor. Bu nedenle yenileme ihtiyacı yaşam döngüsü ve geçiş riskiyle doğrulanabilir, performans iyileştirmesi ise ölçüm kapanmadan garanti edilemez. Register’da yaşam döngüsü kısıtı, geçiş takvimi, hizmet sürekliliği ve performans hedefini ayrı satırlara yaz. Örneğin ARV-CON-001 kasım dondurmasından önce üretim kabulünü; ARV-REQ-001 onaylı yükte sipariş işlem süresini; ARV-REQ-002 geçiş sırasında izin verilen iş etkisini taşıyabilir. RTO/RPO veya performans eşikleri iş sahibi onaylamadıysa TBD kalır. Her satırı kanıt günlüğüne bağla. Kapasite raporu gelince yalnız ilgili kapasite kaydını güncelle; bütün çözümü fact yapma. Bir gereksinim belirli ürüne işaret ediyorsa bunun ölçütlerden türeyip türemediğini göster. Alternatif ürün aynı kabulü sağlıyorsa marka gereksinim değildir. Mevcut otomasyon yalnız belirli API ile çalışıyorsa entegrasyon kısıtı ve değişim maliyeti ayrı kaydedilir. Arven toplantı özeti şu karar cümlesiyle kapanır: yaşam döngüsü nedeniyle değişim planı gerekli; ürün ve kapasite konfigürasyonu performans/kapsam kanıtları kapanınca karşılaştırılacak. Eylemler: platform ekibi kapasite raporu, uygulama ekibi zaman eşlemeli işlem metriği, iş sahibi performans ve kesinti kabul eşiği, değişiklik kurulu geçiş penceresi sağlar. Her eylem tarihlidir.