BİLGİ BANKASI
E-ticaret yazılımı gereksinim belgesi nasıl hazırlanır?
İçindekiler — Türkçe
Başlamadan önce hangi bilgiler gerekir?
Ürün ve varyant yapısı, müşteri grupları, sipariş akışı ve kullanılan dış sistemler bilinmelidir. Operasyon, satış ve teknik ekipten süreci bilen kişiler belirlenmelidir. Belgenin sahibi, kararları toplayan ve çelişkileri ilgili kişilere çözdüren sorumludur; tüm iş kurallarını tek başına üretmesi beklenmez.
Önce mevcut akışı gözlemleyin. Bir siparişin nasıl alındığını, kim tarafından kontrol edildiğini ve hangi durumda durduğunu kaydedin. Kişilerin yıllardır bildiği fakat yazılı olmayan kurallar özellikle önemlidir. Yazılım bu kuralları kendiliğinden tahmin edemez.
Bir gereksinim hangi sırayla yazılır?
1. Kullanıcı rolünü ve yapmak istediği işi tanımlayın. “Operasyon uzmanı, sevk edilmemiş siparişin teslimat adresini düzeltebilir” ifadesi görevi açıklar.
2. Ön koşulu belirtin. Örneğin sipariş henüz sevkiyat sistemine aktarılmamış olmalıdır. “Sevk edilmemiş” ile “kargo etiketi oluşmamış” farklı durumlar olabilir; tanımı netleştirin.
3. İş kuralını ve sonucu yazın. Değişiklik kaydında eski ve yeni değer, işlemi yapan kişi ve zaman tutulmalıdır. Dış sisteme aktarım başlamışsa farklı bir düzeltme süreci gerekebilir.
4. Başarısızlık davranışını ekleyin. Yetkisiz kullanıcı değişiklik yapamamalı; koşulu karşılamayan siparişte açıklayıcı mesaj gösterilmelidir.
5. Kabul örneklerini kaydedin. Uygun siparişte işlem başarılı, sevkiyata aktarılmış siparişte reddedilmiş ve yetkisiz rolde engellenmiş olmalıdır.
Kabul testi nasıl somutlaştırılır?
“Stok yönetimi çalışmalı” yerine “satılabilir stoku bir olan varyanta iki eşzamanlı sipariş geldiğinde tanımlı stok aşımı politikasına uyulmalı” yazın. Politika stok eksiye düşmeyecekse yalnızca bir rezervasyonun başarıyla oluşması beklenir. Ön siparişe izin veriliyorsa sonuç farklıdır; teknik ekip iş kararını varsaymamalıdır.
Öncelik ve bağımlılık nasıl eklenir?
Her gereksinime kimlik verin: G-001, G-002 gibi. Zorunlu, sonraki aşama ve isteğe bağlı ayrımı yapın. Bir gereksinim başka bir veri modeline veya dış servis erişimine bağlıysa bunu belirtin. Ürün kimlikleri belirlenmeden stok eşlemesi tamamlanmış sayılmaz.
Kapsam dışındaki işleri açıkça kaydedin. İlk sürümde çoklu dil veya kısmi iade olmayacaksa bu karar görünür olmalıdır. Açık noktaların sahibi ve yanıt tarihi bulunmalıdır. Yanıtlanmamış bir soru, sessizce onaylanmış gereksinime dönüşmemelidir.
Belgenin kullanılabilirliği nasıl kontrol edilir?
Bir gereksinimi geliştiriciye ve test sorumlusuna ayrı ayrı okutun. İkisi de aynı sonucun nasıl doğrulanacağını tarif edebiliyorsa metin yeterince açıktır. Farklı yorumlar çıkıyorsa örnek veri ve istisna ekleyin. Belgeyi tek seferlik teslim olarak değil, değişiklik geçmişi olan ortak kayıt olarak yönetin.
Çıktı; gereksinim kimliği, görev, ön koşul, iş kuralı, istisna, kabul örneği, öncelik ve sorumludan oluşmalıdır. Bu yapı teklif kapsamını, geliştirmeyi ve kullanıcı kabul testini birbirine bağlar.
Sık sorulan sorular nelerdir
Sonraki adım nedir
İlk üç kritik gereksiniminizi bu yapıyla yazın; kapsamı ve kabul örneklerini PROJX Digital ile değerlendirin.
