“Satın alma taleplerimizi tek yerden yönetmek istiyoruz” cümlesi, yazılım teklifi hazırlamak için henüz yeterli değil. Talebi kimin açacağı, hangi durumda geri döneceği ve onaydan sonra nereye aktarılacağı belirsizse her firma farklı bir iş hesaplayabilir. İhtiyaç analizi, teklifleri aynı kapsam üzerinden konuşabileceğiniz noktaya getirir.
Hazır bir araç mı kullanacağınız, mevcut programı mı uyarlayacağınız henüz belli değilse önce özel yazılımla hazır programların ayrıldığı noktaları değerlendirin. Geliştirme ihtiyacı belirginleştiğinde ise ekran sayısından önce aşağıdaki altı hazırlığa odaklanın. Mevcut iş Excel dosyalarında yürüyorsa dosya düzeniyle çözülebilecek aksaklıkları uygulama gerektiren iş kurallarından ayırmak, gereksiz özellikleri baştan elemenize yardım eder.
1. Yazılımın Çözeceği İş Sorununu Tanımlayın
“Bir yönetim paneli lazım” yerine günlük işte neyin aksadığını yazın. Varsayımsal bir satın alma ekibinde talepler e-posta üzerinden ilerliyor, eksik ürün bilgileri farklı mesajlarda tamamlanıyor ve çalışanlar hangi talebin kimde beklediğini göremiyor olsun. Başlangıç hedefi, talebin durumunu ve sorumlusunu takip edebilmek olabilir.
İşi yapan kişilerden yakın zamanda yaşanmış birkaç işlemi anlatmalarını isteyin. Bekleme nerede başladı, hangi bilgi eksikti, çözüm için kim devreye girdi? Elinizde kayıt yoksa “onay süresi yarıya inecek” gibi bir sonuç yazmayın. Önce mevcut süreyi ve bekleme nedenlerini nasıl ölçeceğinizi belirleyin.
GOV.UK kullanıcı ihtiyacı yaklaşımı, insanların neyi başarmaya çalıştığını araştırmayı çözüm önerilerinden ayırır. İşletme tarafındaki karşılığı basit: talep edilen özelliğin arkasındaki işi anlayın; yöneticinin tahminini çalışanların deneyimiyle kontrol edin.
2. Normal Akışı ve İstisnaları Birlikte Çizin
Satın alma örneğinde ilk çizim “talep açılır, incelenir, onaylanır” kadar kısa olabilir. Sonra akışı gerçek hayata yaklaştırın: ürün kodu eksikse kim tamamlayacak, yetkili kişi izinliyse kime gidecek, onaylanan talep sonradan değiştirilebilecek mi? İşin kapsamını çoğu zaman ana ekranlardan çok cevaplanmamış geçişler büyütür.
Akışı çizerken her geçişin yanına işlemi yapan rolü yazın. “Talep sahibi”, “inceleyen kişi” ve “onay yetkilisi” aynı çalışan olabilir; yetkileri yine de ayrı tarif edilmelidir. Birim yöneticisinin yalnız kendi ekibinin kayıtlarını görmesi gerekiyorsa erişim sınırını baştan belirtin.
Toplantıya boş bir özellik listesiyle gitmek yerine, kişisel ve ticari bilgileri çıkarılmış örnek talep formu ile sorunlu bir işlemin adımlarını götürün. Geliştirme ekibi, “kolay kullanım” beklentisini hangi iş üzerinden değerlendireceğini görsün.
3. İstekleri Kontrol Edilebilir Gereksinimlere Çevirin
Gereksinim, yazılımın karşılaması beklenen ihtiyacın açık tarifidir. İşlevsel gereksinim yapılacak işi anlatır; örneğin talebi gerekçesiyle geri gönderme. İşlevsel olmayan gereksinim ise hız, erişilebilirlik veya hizmetin toparlanması gibi nitelikleri ve koşulları tanımlar. “Hızlı ve güvenli olsun” ifadesi ikisi için de yeterli ayrıntıyı vermez.
| İlk İstek | Teklife Esas Olacak Açıklama |
|---|---|
| Herkes kendi işini görsün | Talep sahibi kendi kayıtlarını; birim yöneticisi sorumlu olduğu birimin taleplerini görür. Rol değiştiğinde erişimin nasıl güncelleneceği belirlenir. |
| Eksik talepler geri dönsün | İnceleyen kişi gerekçe yazar. Talep sahibi gerekçeyi görür, kaydı düzeltir ve yeniden incelemeye gönderir. |
| Rapor hızlı açılsın | Hangi raporun, ne büyüklükte veriyle ve kaç eşzamanlı kullanıcı altında hangi sürede hazırlanacağı ekiplerle kararlaştırılır. |
| Geçmişi takip edelim | Durum değişikliğinin zamanı, işlemi yapan kişi ve açıklaması saklanır. Kayıtları kimlerin göreceği ve saklama süresi tanımlanır. |
Yetki kuralını yalnız ekranda görünen düğmeyle tarif etmeyin. Onay düğmesini gizlemek, işlemin başka bir yoldan yapılmasını tek başına engellemez. OWASP yetkilendirme rehberi, erişimin her istekte denetlenmesini önerir. İşletmenin katkısı, kimin hangi kayıt üzerinde hangi işlemi yapabileceğini doğru anlatmaktır.
Hız beklentisinde de bağlamı koruyun. Az kayıtla yapılan gösterim, yoğun kullanım koşulunu temsil etmeyebilir. Microsoft’un performans hedefleri açıklaması ölçülebilir, iş yüküne bağlı hedefleri temel alır. Sayısal eşiği örnek bir projeden kopyalamak yerine kendi kullanımınıza göre belirleyin.
4. Verileri ve Dış Sistem Bağlantılarını Listeleyin
“Muhasebeye bağlansın” cümlesini aktarılacak kayıtlar düzeyine indirin. Ürün listesi muhasebe sisteminden mi gelecek? Onaylanan talep satın alma siparişine mi dönüşecek? Hangi sistemdeki kayıt esas alınacak? Aynı bilginin iki yerde değiştirilmesi gerekiyorsa çelişkinin nasıl çözüleceğini konuşun.
API, yazılımların belirli kurallarla veri alışverişi yapmasını sağlayan arayüzdür. Kullandığınız hizmetin API sunması, ihtiyacınız olan her işlemi desteklediği anlamına gelmez. Teknik ekip; erişim iznini, desteklenen alanları, kullanım sınırlarını ve test imkânını kontrol etmelidir. Aktarılacak kayıtları ve hata sorumlusunu belirlemek için API entegrasyonunun kapsamını beş soruyla hazırlayabilirsiniz. Abonelikle çalışan bir araç söz konusuysa SaaS hizmetinde işletmenin ve sağlayıcının sorumlulukları bağlantı beklentisini değerlendirmenize yardımcı olur.
- Eski kayıtlardan hangileri taşınacak, hangileri yalnız arşivde kalacak?
- Eksik veya mükerrer kayıtları kim temizleyecek?
- Aktarımın hangi sıklıkta yapılması gerekiyor?
- Bağlantı kesildiğinde kullanıcı ne görecek, hatayı kim takip edecek?
İlk görüşmede canlı sisteme erişim parolası paylaşmak yerine araç adlarını, kullanılan sürümleri ve erişilebilir teknik belgeleri hazırlayın. Veri örneği gerekiyorsa bilgileri gizlenmiş bir örnek yeterli başlangıç sağlar; gerçek veri incelemesinin koşulları sonradan netleştirilir.
5. İlk Sürümü ve Kapsam Dışını Ayırın
İlk sürüm, günlük bir işi baştan sona tamamlayabilmelidir. Örnekte talep açma, inceleme, geri gönderme, onaylama ve durum takibi birlikte değerlendirilebilir. Gelişmiş harcama tahmini veya tedarikçi puanlama daha sonraki sürüme bırakılabilir. Fakat onay için zorunlu bir yetki kuralını çıkarmak, kapsamı küçültürken işin çalışmasını da engelleyebilir.
Her ihtiyacı “ilk sürüm”, “sonraki aşama” veya “henüz karar verilmedi” olarak işaretleyin. Son gruptaki sorulara bir sorumlu ve karar tarihi ekleyin. Atlassian’ın gereksinim belgesi şablonu, varsayımları, açık soruları ve kapsam dışını görünür tutmak için yararlı alanlar sunar; şablonu doldurmak tek başına iş analizi yerine geçmez.
Kritik entegrasyonun mümkün olup olmadığı bilinmiyorsa, kesin kapsamın içine doğrulanmış gibi yazmayın. Teknik incelemeyi ayrı bir çalışma olarak tanımlayın; çıkacak sonucun geliştirme kararını veya teklif varsayımını nasıl değiştireceğini belirtin.
6. Kabul Koşullarını ve Teklifin Dayanaklarını Yazın
Kabul koşulu, bir işlevi tamamlanmış saymak için gözlemlenecek sonucu anlatır. Örneğin geri gönderme işleminde yalnız durumun değişmesi yetmez: gerekçe talep sahibine görünmeli, düzeltilen talep yeniden inceleme sırasına girmeli ve eski işlem geçmişi korunmalıdır. Hangi koşulların sizin süreciniz için gerekli olduğuna işletme ve geliştirme ekibi birlikte karar verir.
Microsoft’un kullanıcı hikâyesi açıklaması, beklentilerin işe başlamadan netleştirilmesini ve kabul testleriyle ilişkilendirilmesini önerir. Teklif aşamasında bütün test senaryolarını yazmanız gerekmez; kritik akışların hangi sonuçla kabul edileceği anlaşılır olmalıdır.
Firmalara aynı tarihli kapsamı gönderin. Teklifin hangi sürüme dayandığını, nelerin varsayıldığını, sizden beklenen girdileri ve sonradan gelen taleplerin nasıl değerlendirileceğini sorun. Kapsam henüz araştırma aşamasındaysa ön tahmin ile net teslim kapsamına bağlı teklifi aynı kesinlikte değerlendirmeyin.
Gereksinimlerin zamanla değişmesi olağandır. Scrum Guide da ürün iş listesini öğrenildikçe gelişen bir yapı olarak tanımlar. Amaç değişimi yasaklamak değil; talebin kapsam, takvim ve bütçe üzerindeki etkisi kararlaştırıldıktan sonra ilerlemektir. Değişikliğin bedelini konuşurken yazılım teklifini etkileyen kapsam belirsizliklerini de yeniden değerlendirin.
Yazılım Fikrinizi Birlikte Netleştirelim
Elinizde uzun bir teknik şartname olmasa da kullandığınız araçları, aksayan süreci ve ilk çözmek istediğiniz işi anlatabilirsiniz. Metazen’de yazılım planını kullanıcılar, iş adımları ve veri akışı üzerinden kuruyoruz. Ekibimizin yazılım ve entegrasyon deneyimini inceleyin; ihtiyaç analizinden ilk çalışan sürüme nasıl ilerlediğimizi özel yazılım hizmetimizde görebilirsiniz.
