Özel yazılım talebi çoğu zaman “bir panel istiyoruz” cümlesiyle başlar. Ancak panel bir araçtır; çözülmek istenen iş problemi değildir. Teklifin doğru hazırlanabilmesi için hangi kişinin hangi işi, hangi bilgiyle ve hangi kısıt altında yapacağı anlaşılmalıdır. İhtiyaç analizi bütün ayrıntıları peşinen kesinleştirmek değil, bilinenleri ve araştırılması gerekenleri görünür hale getirmektir.
Mevcut süreci bir örnek kayıt üzerinden anlatın
Bir müşteri talebi geldiğinde nereden başlıyor, kim değerlendiriyor, kim onaylıyor ve nasıl kapanıyor? Gerçek kişisel verileri çıkartarak bir örnek üzerinden ilerleyin. Kullanılan tablolar, e-postalar ve manuel kopyalamalar iş akışının parçasıdır. Yalnızca yöneticinin ideal sürecini değil, işi yapan ekibin günlük istisnalarını da dinleyin. Yazılımın başarısız olduğu noktalar çoğu zaman bu istisnalarda ortaya çıkar.
Kullanıcıları unvanla değil yetkiyle tanımlayın
Satış temsilcisi, operasyon sorumlusu ve yönetici farklı işlemler yapabilir. Kimin hangi kayıtları görebileceğini, değiştirebileceğini ve onaylayabileceğini yazın. Şube veya müşteri bazlı erişim sınırı varsa ayrıca belirtin. Aynı ekranın görünmesi aynı yetkiye sahip olmak anlamına gelmez. Yetki kararının yalnızca arayüzde düğme saklayarak uygulanamayacağı teknik kapsamda açık olmalıdır.
Veri kaynaklarını ve sahiplerini belirleyin
Müşteri, ürün, teklif ve belge bilgileri nerede tutuluyor? Hangi sistem doğru kaynak sayılacak? Eski tablolardaki tutarsızlıkları kimin düzelteceği belli olsun. Veri taşıma ayrı bir teslim işidir; sadece “eski kayıtlar aktarılacak” demek yeterli olmayabilir. Alan eşlemesi, eksik kayıtlar, tekrarlar ve örnek doğrulama süreci planlanmalıdır. Dosya ekleri de veri hacmine ve erişim ihtiyacına dahildir.
Örnek bir bakım firmasında talep, cihaz, randevu ve servis raporu ayrı kayıtlar olabilir. Hepsini tek serbest metin alanında toplamak başlangıçta kolay görünür; ancak ileride cihaz geçmişi raporu çıkarmayı zorlaştırır. Buna karşılık henüz kullanılmayacak onlarca alan eklemek de ekibin işini ağırlaştırır. Veri modelini gerçek karar ve rapor ihtiyaçlarından türetin.
Gereksinimi doğrulanabilir davranışla yazın
“Kolay raporlama” yerine “yetkili yönetici seçilen tarih aralığındaki açık talepleri şube bazında indirebilir” gibi bir ifade kullanın. Ardından sınır durumlarını ekleyin: boş sonuç, yetkisiz kullanıcı ve büyük veri aralığı. Her gereksinimin kabulü için hangi örneğin gösterileceği belli olsun. Bu yaklaşım hem geliştiricinin tahminini hem müşterinin teslim değerlendirmesini somutlaştırır.
- Çözülecek iş problemi ve öncelikli kullanıcı belli mi?
- Normal akışın yanında istisnalar kaydedildi mi?
- Veri kaynağı ve temizleme sorumlusu tanımlı mı?
- Yetki sınırları kayıt düzeyinde düşünülmüş mü?
- İlk sürümün kabul senaryoları yazılı mı?
İlk sürümü bütün hayallerin toplamı yapmayın
Yayın için zorunlu akışı, sonraki geliştirmelerden ayırın. Bir özelliği ertelemek onun değersiz olduğu anlamına gelmez; öğrenme ve kaynak sırası belirlenir. Açık sorular için keşif çalışması planlayın. Teklifte varsayımların, kapsam dışı maddelerin ve değişiklik sürecinin bulunması gerekir. Belirsiz bir gereksinimi kesin fiyat gibi sunmak, ileride tarafların farklı işler beklemesine yol açabilir.
Yetki uygulaması için OWASP yetkilendirme rehberi teknik kaynak sağlar. Kabul ve teslim rehberi analizi somut kontrole bağlar. Proje görüşmesinde mevcut iş akışınızdan başlayabiliriz.