Projelerde başarının ilk adımı, doğru ve eksiksiz hazırlanmış bir analiz dokümanıdır. Geliştirici, testçi, ürün sahibi ya da müşteri fark etmeksizin tüm paydaşların aynı dili konuşmasını sağlar. Yalnızca teknik detayları değil; işin amacı, kapsamı, kısıtları ve kullanıcı ihtiyaçlarını da net biçimde ortaya koyar. Böylece proje başlangıcında veya süreç içinde yaşanabilecek belirsizlikler en aza indirilir. Sağlam bir analiz, yazılım yaşam döngüsünün tüm aşamalarında rehber niteliğindedir. Bu nedenle analiz dokümanı, projenin omurgasını oluşturan en kritik yapı taşlarından biridir.
İş analisti olarak çalışmaya başladığım ilk yıllarda doğru doküman nasıl hazırlanır?, Analiz dokümanında neler olmalıdır? gibi kafamda birçok soru işareti vardı. Bu konuyla ilgili bir çok araştırma yaptım kaynaklar satın aldım, benden daha tecrübeli analist arkadaşlarımın analiz dokümanlarını inceledim, farklı firmalardaki şablonları karşılaştırdım ve zamanla kendi şablonumu oluşturdum.
Bu yazıda, edindiğim tüm bu deneyimlerin bir sonucu olarak hazırladığım iş analizi dokümanı şablonunu paylaşıyorum. Umarım okuyan herkes için yol gösterici ve faydalı bir kaynak olur.
İş analisti olarak çalışmaya başladığım ilk yıllarda doğru doküman nasıl hazırlanır?, Analiz dokümanında neler olmalıdır? gibi kafamda birçok soru işareti vardı. Bu konuyla ilgili bir çok araştırma yaptım kaynaklar satın aldım, benden daha tecrübeli analist arkadaşlarımın analiz dokümanlarını inceledim, farklı firmalardaki şablonları karşılaştırdım ve zamanla kendi şablonumu oluşturdum.
Bu yazıda, edindiğim tüm bu deneyimlerin bir sonucu olarak hazırladığım iş analizi dokümanı şablonunu paylaşıyorum. Umarım okuyan herkes için yol gösterici ve faydalı bir kaynak olur.
Giriş
Bu bölüm, analiz konusu olan projenin amacı, kapsamı ve temel iş ihtiyacına dair özet bilgileri içerir; tercihe bağlı olarak bu bilgiler tablo formatında sunulabilir.| Alan | Bilgi |
|---|---|
| Proje/Talep Numarası | JIRA-1001 Ana Sayfa Redesign |
| Proje/Talep Adı | Ana Sayfa Redesign |
| Proje Yöneticisi | - |
| Dokümanı Hazırlayan | Umut Alkan |
| Proje/Talep Sahibi ve Sponsor | E-ticaret |
| Güncel Sürüm | v1 |
Doküman Tarihçesi
Bu bölüm, analiz dokümanının versiyon geçmişini kayıt altına almak amacıyla oluşturulur. Dokümanın hangi tarihte kim tarafından hazırlandığı ve her bir sürümde yapılan güncellemeler ile ilgili detaylar burada yer alır.| Tarih | Sürüm | Hazırlayan | Açıklama |
|---|---|---|---|
| 01.01.2025 | v1 | Umut Alkan | Doküman oluşturuldu. |
Semboller ve Kısaltmalar
Bu bölümde, dokümanda kullanılan sembollerin ve kısaltmaların anlamlarına yer verilmiştir. Okuyucunun dokümanı daha kolay anlayabilmesi amacıyla hazırlanır.| Kısaltma | Açıklama |
|---|---|
| AS-IS | Mevcut süreç durumu (şu anki işleyişin analiz edildiği durum) |
| MVP | Minimum Viable Product (Asgari Uygulanabilir Ürün) |
| KPI | Key Performance Indicator (Anahtar Performans Göstergesi) |
| API | Application Programming Interface (Uygulama Programlama Arayüzü) |
Problemin Tanımı ve Hedefler
Bu alanda iş ihtiyacı netleştirilir. Neden bu geliştirme yapılmak isteniyor? Mevcut durumda ne eksik veya problemli?
- Mevcut Durum Özeti (As-Is): Şu an sistem ne durumda çalışıyor
- Hedef Durum (To-Be): Geliştirme sonrası nasıl bir değişim bekleniyor?
- İş Gerekçesi: Bu talep kuruma nasıl bir değer katacak?
Kapsam ve Kısıtlar
Kapsama Dahil Olanlar: Bu geliştirme neleri kapsıyor?Kapsam Dışı Bırakılanlar: Bilinçli olarak yapılmayacaklar.
Varsayımlar: Proje için başlangıçta kabul edilen ön koşullar.
Kısıtlar: Zaman, bütçe, sistemsel ya da regülasyon kaynaklı sınırlamalar.
Etki Alanları / Etki Analizi
Proje kapsamında yapılacak çalışmaların hangi departmanları, sistemleri veya iş süreçlerini etkileyeceği bu bölümde belirtilir. Etki alanları, projenin etki düzeyinin ve kapsamının daha net anlaşılmasını sağlanır.| Alan | Etkisi |
|---|---|
| Yeni Rol Ekleme | Diğer kullanıcı profillerinde yetki çakışması ya da erişim açıkları oluşuyor mu? |
| Kampanya Tanım Ekranı Değişikliği | Kampanyaların doğru şekilde son kullanıcıya yansıdığı kontrol edildi mi? Eski kampanyalar etkileniyor mu? |
| Teklif Hesaplama Algoritması | Fiyatlama sonuçları ERP, faturalama ve raporlama sistemlerinde tutarlı görünüyor mu? |
Gereksinimler
Bu bölüm, dokümanın en kritik kısmıdır. Gereksinimler; projenin ne yapması gerektiğini, hangi kurallar çerçevesinde hareket edeceğini açıklar. Gereksinimler işlevsel (fonksiyonel) ve işlevsel olmayan (non-fonksiyonel) olarak ikiye ayrılır. Fonksiyonel Gereksinimler (Functional Requirements) : Sistemden beklenen davranışların User Story formatında yazılması, hem teknik ekiplerin hem de iş biriminin aynı dili konuşmasına yardımcı olur. Agile projelerde özellikle tercih edilen bu yapı, her bir gereksinimin kullanıcı merkezli bir şekilde ifade edilmesini sağlar.User Story Formatı:
Bir kullanıcı olarak [rol], [şu işlevi] yapmak istiyorum ki [şu faydayı] elde edebileyim. Örnekler:
- Bir müşteri olarak, siparişlerimi geçmişe dönük görebilmek istiyorum ki teslimat durumunu kontrol edebileyim.
- Bir yönetici olarak, kullanıcı raporlarını Excel’e aktarabilmek istiyorum ki dönemsel analiz yapabileyim.
- Sistem yanıt süresi 3 saniyeyi geçmemeli.
- Mobil cihazlarda %100 uyumlu çalışmalı.
- Veriler KVKK ve GDPR ile uyumlu şekilde saklanmalı.
Akış Diagramları
Bu bölümde, sistem veya iş süreçlerinin işleyişini görsel olarak ifade eden akış diyagramlarına yer verilir. Diyagramlar, süreçlerin adımlarını, karar noktalarını ve olası yolları net bir şekilde göstermek amacıyla hazırlanır. Bu görseller, ilgili paydaşların süreci daha iyi anlamasına ve analiz sürecinin şeffaflaşmasına yardımcı olur. BAŞLA
İŞLEM
KARAR
SON
Ekran Tasarımları & Mockups
Mockup’lar; işlevsellik, kullanıcı akışı ve görsel yerleşim hakkında fikir vererek analiz sürecinde paydaşlarla ortak bir anlayış geliştirilmesini sağlar. Ayrıca, yazılım geliştirme ve test süreçleri için referans niteliği taşır.Profesyonel ekran tasarımları ise genellikle UI/UX tasarımcıları tarafından hazırlanır ve kullanıcı deneyimini iyileştirmeye yönelik detaylı çalışmalar içerir. Bu tasarımlar, mockup’lara kıyasla daha yüksek görsel kesinlik sunar; renk paletleri, tipografi, ikonografi, spacing gibi görsel detayların yanı sıra buton davranışları, hata durumları ve responsive kırılımlar gibi UI davranışlarını da barındırır. Tasarımlar çoğunlukla Figma gibi araçlar üzerinden paylaşılır ve ilgili bileşenlerin CSS bilgileri de bu dosyada yer alır.
Servis & API Bilgileri
Bu bölümde, proje kapsamında kullanılacak mevcut servisler veya geliştirilecek yeni API’ler hakkında bilgilere yer verilir.- İlgili servislerin endpoint, metotları, veri yapıları, request / response parametreleri ve entegrasyon senaryoları detaylandırılır.
- Bu bilgiler, yazılım geliştiriciler ve entegrasyon ekipleri için teknik bir referans oluşturur. Ayrıca servislerin kullanım kısıtları, kimlik doğrulama yöntemleri (örneğin: OAuth, API Key) ve hata yönetimi mekanizmaları da bu bölümde açıklanabilir.
Kabul Kriterleri
Bu bölümde, bir iş gereksiniminin ya da fonksiyonun tamamlanmış ve kabul edilebilir sayılabilmesi için karşılaması gereken koşullar tanımlanır.Kabul kriterleri, ürünün doğru şekilde geliştirilip geliştirilmediğini belirlemek, test edilebilirlik sağlamak ve paydaşlarla ortak bir anlayış oluşturmak amacıyla yazılır.
Her bir kullanıcı hikayesi veya iş kalemi için açık, ölçülebilir ve net kriterler belirlenmesi; geliştirme, test ve kabul süreçlerinin sorunsuz ilerlemesine katkı sağlar. Örnekler
- Kullanıcı, giriş yaptıktan sonra ana sayfa en fazla 2000 ms içinde yüklenmelidir.
- Formda tüm zorunlu alanlar doldurulmadan Gönder butonu aktif olmamalıdır.
- Raporlar menüsü sadece yönetici rolüne sahip kullanıcılar tarafından görüntülenebilir olmalıdır.
Sonuç İyi hazırlanmış bir analiz dokümanı, projenin sadece başlangıcı değil, aynı zamanda rotasıdır. Gereksinimlerin eksiksiz, kullanıcı odaklı ve anlaşılır şekilde yazılması; analiz sürecini sadece belgeleyen değil, yön veren bir yapıya dönüştürür.
Yukarıda sunduğum şablonun her aşaması her projeye birebir uygulanmak zorunda değildir. Ancak bu şablonda yer alan başlık ve içeriklerin, projeye ve ihtiyaca göre uyarlanarak kullanılması analiz sürecinin daha sağlıklı ilerlemesine katkı sağlar.
Yukarıda sunduğum şablonun her aşaması her projeye birebir uygulanmak zorunda değildir. Ancak bu şablonda yer alan başlık ve içeriklerin, projeye ve ihtiyaca göre uyarlanarak kullanılması analiz sürecinin daha sağlıklı ilerlemesine katkı sağlar.
Not: Bu blog yazısı, GPT-4o yapay zeka modelinden yardım alınarak editlenmiştir. 🦾