Yazılım Projesinde İhtiyaç Analizi Nasıl Yapılır?

Sorunu çözüm önerisinden ayrı tanımlayın

Kullanıcılar ihtiyacı çoğu zaman bir çözüm önerisi olarak anlatır: “Buraya bir bildirim ekleyelim” veya “Yeni bir rapor istiyoruz.” Önce bu talebin arkasındaki durumu sorun. Bildirim neden gerekli, mevcut kaydın görülmemesi hangi sonuca yol açıyor, raporu alan kişi hangi kararı verecek? Bu sorular farklı bir çözümün daha uygun olup olmadığını gösterir.

Varsayımsal bir dağıtım işletmesinde geciken teslimatlar için sürekli mesaj gönderiliyor olabilir. Sorun bildirim eksikliğinden çok, teslim tarihinin baştan kaydedilmemesi olabilir. Böyle bir durumda yeni mesajlar eklemek karışıklığı artırır. Sorun cümlesini “Teslimat planı güncel olmadığı için operasyon ekibi günlük programı güvenilir biçimde çıkaramıyor” şeklinde yazmak, çözüm alanını daha sağlıklı açar.

Mevcut süreci gerçek kayıt üzerinden izleyin

Yönetimin anlattığı resmi süreç ile günlük uygulama arasında fark bulunabilir. Bu nedenle yalnızca toplantı yapmak yerine bir işlemin başlangıçtan kapanışa kadar nasıl ilerlediğini inceleyin. Kullanılan dosyaları, mesaj kanallarını, onayları ve beklemeleri not edin. Sürecin her adımında işlemi yapan kişiyi ve üretilen bilgiyi kaydedin. Kişisel verileri çalışma örneklerinden temizleyin.

Normal akışın yanında istisnaları da konuşun. Sipariş bölünürse, yanlış fiyat girilirse, müşteri vazgeçerse veya yetkili kişi izinliyse ne oluyor? Bir uygulamanın kullanım sırasında zorlanmasının nedeni çoğu zaman ana akıştan çok bu ayrıntılardır. Gözlem sırasında mevcut bütün alışkanlıkları otomatik olarak yeni sisteme taşımayın; bazı adımlar yalnızca eski aracın sınırlılığı nedeniyle oluşmuş olabilir.

• Başlangıç: İş hangi olay veya talep ile açılıyor?
• Devir: Kayıt kimden kime ve hangi bilgiyle geçiyor?
• Bekleme: İş nerede duruyor, devam kararını kim veriyor?
• Bitiş: Tamamlandı sayılması için hangi koşullar gerekiyor?

Kullanıcı rollerini işlem bazında belirleyin

“Yönetici” ve “personel” adında iki rol tanımlamak her projede yeterli olmaz. Kayıt görüntüleme, oluşturma, düzenleme, onaylama, silme ve dışa aktarma ayrı yetkilerdir. Şube, ekip veya müşteri bazında erişim sınırları da gerekebilir. Özellikle raporlar üzerinden normalde görülmemesi gereken verilere erişim olup olmadığını düşünün.

Yetki tasarımında kişilerin isimleri yerine görevleri temel alın. Bugün bir kişinin üstlendiği iki görev ileride ayrılabilir. Geçici vekâlet, işten ayrılma ve hesap kapatma durumlarını da tarif edin. Bu hazırlık, hem ekran tasarımını hem de yazılımda veri güvenliği yaklaşımını etkiler. Kullanıcının hangi işlemi neden yapabildiği anlaşılır olduğunda eğitim ve destek de kolaylaşır.

Verileri ve bağlantıları kapsamın merkezine alın

Ekranların arkasındaki veriyi tanımlamadan sağlıklı kapsam oluşturmak zordur. Müşteri kaydının zorunlu alanlarını, sipariş numarasının nasıl üretildiğini, tarihlerin anlamını ve eski kayıtların nasıl saklanacağını belirleyin. Aynı terim farklı ekiplerde farklı anlam taşıyorsa ortak bir sözlük oluşturun. Örneğin “teslim tarihi” planlanan günü mü, gerçekleşen günü mü ifade ediyor?

Mevcut dosyalardan küçük bir örnek seçip tutarlılığı kontrol edin. Tekrarlanan kayıtlar, boş alanlar ve farklı biçimlerde yazılan kodlar aktarım işini büyütebilir. Dış sistemden alınacak veriler için erişimin mevcut olup olmadığını araştırın. Bir bağlantıyı “entegrasyon yapılacak” diye tek satırla geçmek yerine gönderilen veri, yön, sıklık ve hata halinde sorumlu kişi gibi ayrıntıları API entegrasyonu planına dahil edin.

İstekleri sınanabilir kabul koşullarına çevirin

Kabul koşulu, bir işin tamamlandığını nasıl anlayacağınızı söyler. “Rapor hızlı çalışmalı” ifadesi yoruma açıktır. Hangi raporun, yaklaşık kaç kayıt üzerinde ve hangi kullanım koşulunda ne kadar sürede dönmesi beklendiği konuşulmalıdır. Bu değerleri rastgele belirlemek yerine mevcut iş ihtiyacından çıkarın; günlük küçük liste ile yıllık ayrıntılı döküm aynı beklentiyi taşımayabilir.

Bir örnek koşul şöyle olabilir: “Şube sorumlusu, seçtiği tarih aralığındaki açık siparişleri görebilir; başka şubenin siparişlerini göremez.” Sonra boş sonuç, eksik veri ve yetkisiz erişim durumlarını ekleyin. Çalışan parçaların düzenli değerlendirilmesi, Çevik Bildiri ilkelerinde yer alan erken geri bildirim yaklaşımıyla uyumludur. Teste işletmeden kimin katılacağını ve kararın nasıl kayda geçirileceğini baştan belirleyin.

İlk sürümün sınırını ve değişiklik yolunu yazın

Analizin çıktısı yüzlerce sayfalık bir belge olmak zorunda değildir. Kısa süreç açıklamaları, rol listesi, veri örnekleri, öncelikli senaryolar ve kabul koşulları çoğu başlangıç görüşmesini somutlaştırır. İlk sürümde nelerin bulunacağını yazmak kadar, ertelenen ihtiyaçları da belirtmek önemlidir. Ertelenen isteklerin kaybolmaması için neden ertelendiklerini ve hangi koşulda ele alınacaklarını kaydedin.

Yeni bir ihtiyaç geldiğinde etkisini değerlendirecek bir kişi veya küçük ekip belirleyin. İstek; süre, bütçe ve mevcut akış bakımından incelendikten sonra plana alınsın. Böylece gelişim devam ederken beklentiler de güncel kalır. İlk sürümün kapsamını daraltmak için minimum uygulanabilir ürün yaklaşımını kullanabilir; en değerli iş akışını önce kullanılabilir hale getirebilirsiniz.