“Bir yönetim paneli istiyoruz” cümlesi teklif almak için başlangıçtır; geliştirme ekibinin ne yapacağını anlaması için yeterli değildir. Panelde kimlerin çalışacağı, hangi kararların onay gerektirdiği ve yanlış bir işlemde ne olacağı belli değilse aynı talebe verilen teklifler de farklılaşır.
Özel yazılım ihtiyaç analizi, işin bugün nasıl yürüdüğünü ve geliştirilecek sistemin hangi sonuçları üretmesi gerektiğini tarif eder. Çıktısı uzun bir özellik listesi olmak zorunda değildir. Anlaşılır bir süreç haritası, rol tablosu ve test edilebilir kabul kriterleri çoğu görüşmeyi somutlaştırır.
Örnek bir satın alma sürecini düşünün. Çalışan malzeme ister, bölüm yöneticisi ihtiyacı değerlendirir, satın alma ekibi teklif toplar ve finans ödeme koşulunu kontrol eder. “Talep ekranı” bu zincirin yalnızca görünen yüzüdür.
Analizde bir gerçek kaydı baştan sona izleyin. Talep nereden geliyor? Eksik bilgi varsa kim tamamlıyor? İzinli yönetici yerine kim onay veriyor? Sonradan değiştirilen tutar için eski onay geçerli mi? Cevaplar yazılımın durumlarını ve geçiş kurallarını belirler.
Mevcut sürecin bütün alışkanlıklarını aynen taşımak da doğru olmayabilir. Sadece eski dosyada bulunduğu için istenen bir alanın hangi karara katkı sağladığını sorun. Kullanılmayan veri, yeni sistemde de doldurulması gereken yük olarak kalır.
Bir çalışanın “yönetici” olması her kaydı görmesi gerektiği anlamına gelmez. Şube yöneticisi kendi şubesini, finans personeli ödeme alanlarını, operasyon ekibi teslimat durumunu görebilir. Yetki tablosu bu ayrımı görünür kılar.
Bu tablo örnektir; işletmenizin yetki modelini temsil etmez. Tasarım görüşmesinde her satırın sahibini belirlemek için kullanılabilir. Yetki kontrolünün sadece buton gizlemeyle sınırlı kalmayacağını da kapsamda belirtin.
“Onay sistemi olacak” ifadesi yoruma açıktır. Daha kullanışlı tanım şöyledir: Onay bekleyen talebin tutarı değişirse kayıt yeniden incelemeye düşer ve önceki onay geçmişte görünür kalır. Test yapan kişi beklenen sonucu anlayabilir.
Senaryo: Onaydan sonra tutar değişikliği
Başlangıç: Bölüm onayı verilmiş bir satın alma talebi
Eylem: Yetkili kullanıcı tutarı değiştirir
Beklenen: Eski onay korunur; yeni sürüm tekrar onay bekler
Kayıt: Değiştiren kullanıcı, zaman ve değişen alan saklanır
Bir kriter tek bir davranışı açıklamalıdır. Ekran düzeni, e-posta gönderimi ve raporlama aynı cümleye sıkıştırılırsa hatanın hangi şartı ihlal ettiği belirsizleşir. Kritik sürecin olumlu örneğinin yanında reddedilme ve iptal örneğini de yazın.
İlk yayında temel talep ve onay akışı gerekebilir; gelişmiş tahmin raporları sonraya kalabilir. Buna karşılık kullanıcı yetkileri ve kayıt geçmişi, sonradan kolayca eklenecek süs özellikler gibi değerlendirilmemelidir.
Kapsamı “ilk sürüm”, “sonraki sürüm” ve “kapsam dışı” olarak ayırın. Her özellik için işletme sorumlusunu, dış sistem bağlantısını ve kabul yöntemini kaydedin. ERP erişimi henüz verilmemişse entegrasyonun hazır olduğu varsayımıyla takvim oluşturmayın.
API entegrasyonu örnekleri, hangi verilerin sistemler arasında dolaşacağını belirlemek için yardımcı olabilir. Analiz dosyanızda her bağlantının veri sahibi ve hata durumundaki sorumlusu ayrıca bulunmalıdır.
Görüşülen yazılım ekiplerine farklı bilgiler vermek karşılaştırmayı zorlaştırır. Aynı kapsam sürümünü paylaşın; sorulara verilen yanıtları da ortak ek dokümana ekleyin. Bir ekibin fark ettiği önemli gereksinim yalnızca o ekibin teklifinde kalmamalıdır.
Karşılaştırmada teslim edilecek modülleri, veri taşımayı, eğitim kapsamını ve bakım koşullarını ayrı satırlarda değerlendirin. Kaynak kodun teslimi, erişim hesapları ve üçüncü taraf ücretleri de açıkça konuşulmalıdır. Bu unsurların yazılmamış olması dahil olduklarını göstermez.
Varsayımsal satın alma projesinde ilk görüşmenin sonunda elinizde dört çıktı bulunabilir: mevcut akış, rol tablosu, örnek kabul senaryoları ve açık sorular listesi. Son listedeki “finans onayı hangi tutarda başlıyor?” sorusunun cevabı alınmadan ilgili kural tamamlanmış sayılmaz. Açık soruyu saklamak yerine sorumlu ve karar tarihi atayın.
Ön değerlendirme alınabilir; ancak kapsam belirsizse teklif farklı varsayımlara dayanır. Karşılaştırılabilir teklifler için kullanıcı rolleri, temel iş akışı, bağlantı kurulacak sistemler ve ilk sürümün sınırları açıklanmalıdır. Bütün ayrıntıların baştan kusursuz olması gerekmez. Açık kalan kararların ayrıca listelenmesi, kim tarafından yanıtlanacağının belirlenmesi ve tahminlere etkisinin konuşulması gerekir. Entegrasyon bağımlılıkları bu dosyada açıkça işaretlenmelidir.
Özellik listesi sistemde bulunacak yetenekleri söyler; kabul kriteri belirli koşullarda beklenen sonucu tarif eder. “Dosya yükleme” bir özelliktir. Desteklenmeyen dosya türünde kullanıcının açıklayıcı hata görmesi ise bir kabul kriteridir. İkisini birlikte hazırlamak, geliştirme ile test arasındaki yorumu azaltır ve teslim sırasında aynı davranışın kontrol edilmesine yardımcı olur. Test sonucunu değerlendirecek sorumlu da kriterde belirtilmelidir.
İlk sürüm, seçilen iş akışını kullanılabilir biçimde tamamlamalıdır. Sadece kolay geliştirilen ekranları seçmek yerine zorunlu yetkileri, hata durumlarını ve dış sistem bağımlılıklarını değerlendirin. Daha sonra eklenebilecek raporlar ertelenebilir; temel veri modeliyle ilgili kararlar ise bütün projeyi etkileyebilir. Önceliği süreç sahibiyle birlikte, beklenen fayda ve risk üzerinden belirleyin. İlk yayının dış sistem bağımlılıkları ayrıca kontrol edilmelidir.
Bütün işletmeyi aynı anda modellemeye çalışmak analizi uzatabilir. En sık yaşanan ve sonucu açık olan bir süreci seçin. İşi yapan çalışan, karar veren yönetici ve teknik ekip aynı örneği değerlendirsin; farklı yorumları geliştirme başlamadan çözsün.
Hazırladığınız kapsamı ARKTECH özel yazılım hizmetleri üzerinden değerlendirmeye açarken örnek veri ve kabul kriterlerini de paylaşın. İlk görüşmeye ekran isimlerinden önce tamamlanmasını istediğiniz iş akışını götürün.
