Bir yazılım projesi, ihtiyacın tam olarak anlaşılmadığı noktada yanlış yönde ilerlemeye başlar. Geliştirici ekranı çizer, iş sahibi ise başka bir şey hayal etmiştir ve bu fark ancak ürün kullanılmaya başlandığında görünür hâle gelir. İhtiyaç analizi, bu farkı kodlama başlamadan kapatmak için yapılan çalışmadır.
Bu yazıda ihtiyaç analizinin neleri kapsadığını, hangi soruların cevaplanması gerektiğini ve gereksinimlerin nasıl yazılı hâle getirileceğini anlatıyoruz. Analiz, bir projenin kapsamını ve gecikme riskini doğrudan belirlediği için özel yazılım hizmetimizin ilk aşamasında da bu çalışma yer alır.
İhtiyaç analizi neden ilk adımdır?
İhtiyaç analizi, “ne yapılacak?” sorusunun yazılı cevabıdır. Bu cevap olmadan tasarım, veritabanı ya da entegrasyon kararları sağlıklı verilemez, çünkü her biri ihtiyacın ne olduğuna bağlıdır.
Analiz atlandığında bedel genellikle geliştirme sırasında ödenir. Bir modül bittiğinde eksik fark edilir, veri yapısı yeniden kurulur ve ekranlar baştan çizilir. Aynı soruların proje başında cevaplanması, bu yeniden yapma döngüsünü büyük ölçüde engeller. Kapsam kaymasının nasıl önleneceği için yazılım projesi neden gecikir yazımıza da bakabilirsiniz.
Analizden önce hangi sorular netleşmeli?
Her analiz birkaç temel soruyla başlar. Bu sorulara verilen cevaplar, sonraki bütün kararların zeminini oluşturur:
- Projeyle çözmek istediğiniz somut sorun nedir ve bugün bu sorun nasıl yaşanıyor?
- Sistemi kimler kullanacak ve her kullanıcının günlük işi ne?
- Başarıyı nasıl ölçeceksiniz; hangi çıktı ya da süre değişmeli?
- Sistemin bağlanması gereken mevcut araçlar ya da veriler var mı?
- İlk sürümde olmayacak, sonraya bırakılacak işler neler?
Analizde ayrıca varsayımları ayrı bir başlık altında yazmak yararlıdır. “Kullanıcılar zaten bilgisayar başında çalışıyor” ya da “veriler düzenli tutuluyor” gibi cümleler, doğrulanmadığı sürece gerçek bir gereksinim değildir. Varsayım olarak yazıldığında ise hangisinin yanlış çıktığı, proje sırasında hızla görülebilir.
Bu soruların hepsine tek bir toplantıda cevap almak zor olabilir. Bu yüzden analiz, birkaç kısa görüşme ve yazılı taslak turu şeklinde ilerler. Her turun sonunda açık kalan sorular ayrıca listelenirse, kimin neye karar vermesi gerektiği de görünür olur.
Mevcut süreç nasıl haritalanır?
Yeni bir yazılım çoğu zaman var olan bir sürecin yerine geçer. Bu nedenle analizin ilk adımı, bugünkü işin nasıl yürüdüğünü adım adım yazmaktır. Excel dosyası, WhatsApp grubu, kâğıt form ya da bir kişinin hafızası bu sürecin parçası olabilir ve hiçbiri gözden kaçırılmamalıdır.
Süreç haritası çıkarılırken her adımın üç bilgisi kaydedilmelidir: adımı kimin yaptığı, hangi girdiyi kullandığı ve çıktısının nereye gittiği. Bu harita, yeni sistemde hangi adımın otomatikleşeceğini ve hangisinin insan kararı olarak kalacağını gösterir. Bu çalışmanın genel mantığı için iş süreçlerini otomatikleştirmek için nereden başlanır yazısına bakabilirsiniz.
Haritayı çıkarırken sürecin “olması gereken” hâli değil, “gerçekte olan” hâli yazılmalıdır. Kâğıt üzerindeki prosedür ile sahadaki uygulama çoğu zaman birbirinden farklıdır ve yeni sistem, sahadaki gerçek akışa göre tasarlanmalıdır.
Süreci en iyi bilen çoğu zaman o işi her gün yapan kişidir. Yönetici sürecin genel akışını anlatabilir, ama küçük istisnaları, el ile yapılan düzeltmeleri ve gecikmenin nerede biriktiğini sahadaki personel daha net görür. Bu yüzden görüşmeler, yöneticiden çok uygulayan kişilerle de yapılmalıdır. İki anlatımın çeliştiği yerler, analizin en değerli bulgularıdır.
Kullanıcı rolleri nasıl ayrılır?
Aynı sistemi farklı kişiler farklı amaçlarla kullanır. Yönetici rapor görmek isterken, saha personeli kayıt girmek ister. Rolleri analizde ayırmak, ekran sayısını ve yetki yapısını netleştirir.
| Rol | Temel ihtiyaç | Örnek yetki |
|---|---|---|
| Yönetici | Özet raporlar ve onay | Görüntüleme, onaylama |
| Operasyon personeli | Hızlı kayıt girişi | Ekleme, düzenleme |
| Dış paydaş | Sınırlı bilgiye erişim | Yalnızca okuma |
Roller belirlenirken, bir kişinin birden fazla rolü olup olmadığına da bakmak gerekir. Muhasebeci hem rapor okuyan hem de fatura kaydı giren biri olabilir ve bu iki yetki aynı ekranda karışmamalıdır. Yetki matrisi, bu tür çakışmaları proje başında görünür kılar.
Tablo örnek amaçlıdır; gerçek roller her işletmede farklı çıkar. Önemli olan, her rolün hangi ekranı ve hangi işlemi görebildiğinin yazılı olmasıdır. Bir rolün hiçbir işlemi yapamıyorsa, o rolün sistemde neden bulunduğu da sorgulanmalıdır.
Gereksinimler nasıl yazılır?
Gereksinimler, belirsiz cümleler yerine test edilebilir ifadelerle yazılmalıdır. “Sistem hızlı olsun” gibi bir cümle kimse için ölçülebilir değildir. Bunun yerine “müşteri kaydı arama ekranında yazılan ilk harften sonra listelensin” gibi bir cümle, geliştiricinin ve iş sahibinin aynı şeyi kabul etmesini sağlar.
Pratik bir kalıp, kullanıcı hikâyesi formatıdır: bir rol olarak, bir işi yapabilmek istiyorum, böylece bir sonuca ulaşırım. Bu kalıp, her gereksinimin kime hizmet ettiğini ve neden gerektiğini kaydeder. Cümle kısa tutulduğunda, toplantıda herkes aynı metni okuyup aynı yorumu yapabilir. Her gereksinimin yanına bir de kabul kriteri eklemek, “bitti” kararını kişiden bağımsız hâle getirir. Kabul kriteri, bir ekranın ya da işlemin hangi koşulda tamamlanmış sayılacağını söyler ve test aşamasında tartışmayı kapatır.
Gereksinimlerin dili de önemlidir. Aynı işi tarif eden iki farklı kelime, geliştirme ekibinde iki farklı özelliğe dönüşebilir. “Müşteri”, “cari” ve “alıcı” gibi terimler ilk sayfada tanımlanıp belgenin geri kalanında aynen kullanılmalıdır. Bu küçük disiplin, sonradan çıkan ve sadece isimlendirmeden kaynaklanan tartışmaların önüne geçer.
Gereksinimleri yazarken iki ayrı liste tutmak da faydalıdır. Birincisi zorunlu olanlar, ikincisi olsa iyi olacak ama olmadan da çalışabilecek olanlardır. Bu ayrım, zaman baskısı oluştuğunda kapsamı kontrollü biçimde daraltmaya yarar.
Kapsam dışı neler yazılmalı?
Analizin en çok unutulan parçası, dışarıda bırakılanların yazılmasıdır. Yazılmayan bir özellik, ileride “bunu da yapmıyor muydunuz?” sorusuna dönüşür.
Örneğin bir sipariş takip sisteminde mobil uygulama, mevcut muhasebe programına entegrasyon ya da çok dilli arayüz ilk sürümde yer almayabilir. Bunları açıkça dışarıda bırakmak, kabul kriterlerinin de netleşmesini sağlar. Sonradan eklenecek işlerin nasıl değerlendirileceği ise ayrı bir konudur ve sözleşmede de karşılığını bulmalıdır.
Önceliklendirme nasıl yapılır?
Gereksinim listesi uzadığında her maddeyi aynı önemde görmek, teslim tarihini kaçırmanın en kısa yoludur. Önceliklendirmenin basit bir yolu, her maddeyi üç gruba ayırmaktır: ilk sürümde mutlaka olmalı, olmalı ama ikinci aşamada olabilir ve ileride düşünülebilir.
Bu sınıflandırmayı yaparken her maddenin iş değerine ve teknik maliyetine birlikte bakmak gerekir. Çok değerli ama çok karmaşık bir özellik, ilk aşamada yerini daha basit bir geçici çözüme bırakabilir. Karar, iş sahibinin onayıyla yazılı olarak kaydedilmelidir. Aksi hâlde, teslimata yakın bir dönemde “bu da ilk sürümde olacaktı” cümlesi tartışma konusu olur.
Önceliklendirme bir kez yapılıp bırakılmamalıdır. Proje ilerledikçe öğrenilen şeyler, bir maddenin değerini ya da maliyetini değiştirir. Bu nedenle her aşamanın sonunda öncelik listesinin gözden geçirilmesi, kapsamın gerçek bilgiye göre ayarlanmasını sağlar. Güncellenen her öncelik de belgeye tarihiyle birlikte işlenmelidir.
Analiz çıktısı hangi belgede toplanır?
Analizin sonunda elde edilmesi gereken şey, tek bir okunabilir belgedir. Bu belge uzun olmak zorunda değildir, ama geliştirme sırasında herkesin başvuracağı tek kaynak olmalıdır. Sayfalarca dağınık not, kısa sürede kimsenin takip edemeyeceği bir karmaşaya dönüşür.
Belgede sırasıyla projenin amacı, kullanıcı rolleri, süreç haritası, gereksinim listesi ve kabul kriterleri yer almalıdır. Ardından kapsam dışı kalanlar ve açık sorular ayrı bölümlerde listelenmelidir. Açık soruların her birinin yanında bir sorumlu ve bir karar tarihi yazılırsa, belge yalnızca bir kayıt olmaktan çıkıp bir takvime dönüşür.
Son olarak belgenin iki tarafça onaylanması gerekir. Onay, sonradan yapılacak her değişikliğin hangi kararla yapıldığını izlemeyi kolaylaştırır. Belge güncellenmeye devam ettikçe, projenin gerçek hafızası da bu belgede birikir.
Kontrol listesi
- Projenin çözdüğü sorun ve başarı ölçütü yazılı mı?
- Mevcut süreç adım adım haritalandı mı?
- Her kullanıcı rolünün ihtiyacı ve yetkisi tanımlandı mı?
- Gereksinimler test edilebilir cümlelerle yazıldı mı?
- Kapsam dışı kalanlar açıkça listelendi mi?
- Önceliklendirme iş sahibinin onayıyla kaydedildi mi?
