Yazılım Gereksinim Analizi ve Teknik Şartname

“Bir yönetim paneli istiyoruz” yerine bugün kimin hangi işi nasıl yaptığını anlatın. Verinin tekrar girildiği, onayların kaybolduğu veya durumun takip edilemediği adımları gösterin. Mevcut dosya ve ekran örnekleri, soyut özellik adlarından daha açıklayıcı olabilir.

İlk sürümün iş sonucunu ve kapsam dışını birlikte belirtin. Örneğin satın alma talebinin kaydedilip yöneticinin kararının izlenmesi hedeflenebilir; muhasebe fişi üretme sonraki sürüme bırakılabilir. Bu sınırı teklif metninde de koruyun.

REQ-01 gereksinimi için üç rol tanımlayalım: talep sahibi, birim yöneticisi ve sistem yöneticisi. Talep sahibi kendi taslağını düzenleyebilir; gönderilmiş talebin kararını birim yöneticisi verir. Yöneticinin yalnızca kendi birimindeki taleplere erişmesi bu örneğin iş kuralıdır.

Durumları taslak, onay bekliyor, onaylandı ve reddedildi olarak yazın. Reddetme gerekçesinin zorunlu olup olmadığını, karar sonrası değişiklik yapılıp yapılamayacağını ve yöneticinin kendi talebini onaylayıp onaylayamayacağını karar listesine ekleyin. Bu sorular cevaplanmadan ekranın görünmesi, akışın tamamlandığını kanıtlamaz.

Her alan için veri türünü, zorunluluğu ve kaynağı belirleyin. Örneğin birim bilgisi şirket dizininden geliyorsa kullanıcının bunu değiştirme yetkisi ayrı karardır. Eski talepler taşınacaksa alan eşlemeleri, eksik kayıtlar ve kontrol yöntemi yazılmalıdır.

Bağlantı kesildiğinde kullanıcı ne görecek, işlem tekrar denenecek mi ve aynı kayıt iki kez gönderilirse ne olacak? Entegrasyon şartnamesinde başarılı yanıt kadar bu istisnaları da ele alın. Test ortamı ve teknik muhatap bilgisini ekleyin; gerçek erişim anahtarlarını şartnameye koymayın.

Performans şartında hangi işlem, hangi veri hacmi, hangi eşzamanlı kullanıcı yükü ve hangi ölçüm ortamının kullanılacağını belirtin. Kabul eşiğini paydaşlarla belirleyin. Sayısal bir hedefin gerçek ihtiyaçtan ve test düzeninden bağımsız yazılması, tek başına kalite güvencesi sağlamaz.

Yetki kontrolleri, yedek geri yükleme, hata kaydı ve erişilebilirlik için sorumlu ve doğrulama yöntemi tanımlayın. Scrum Guide içindeki tamamlanma tanımı, bir işin ortak kalite ölçütleriyle değerlendirilmesini açıklar; gereksinime özel kabul senaryoları ise beklenen davranışı somutlaştırır. Bu iki katmanı birlikte kullanabilirsiniz.

Her gereksinime bir kimlik verin. İlgili ekran, iş kuralı, kabul senaryosu ve açık soruyu bu kimliğe bağlayın. Böylece bir talep değiştiğinde hangi geliştirme ve testlerin etkilendiği görülebilir.

Yeni bir ihtiyaç geldiğinde gerekçesini, ilk sürüme etkisini, tahmin değişikliğini ve onaylayan kişiyi kaydedin. Sadece belgenin son halini paylaşmak yerine karar geçmişini koruyun. Kabul toplantısında hangi sürümün esas alındığı da belli olsun.

Özel yazılım maliyeti rehberi ile bu iş paketlerini bütçeye dönüştürün. Teslim koşullarını kaynak kod ve hesap devri üzerinden kontrol edin. İş akışlarınızı birlikte incelemek için özel yazılım geliştirme hizmetimizin kapsamına bakabilirsiniz.

Kabul testleri rehberi ile her kritik gereksinimi bir doğrulama senaryosuna dönüştürün. Teknik devir listesi üzerinden kod, veri ve operasyon belgelerini teslim kapsamına ekleyin. İlk sürümü daraltmak için MVP kapsamı rehberini kullanabilirsiniz.

Müşteri portalı yetki matrisi kullanıcı, kurum ve kayıt ilişkisini gereksinimlere dönüştürür. Yetkili işlemler kadar reddedilmesi gereken senaryoları da şartnameye ekleyin.