Gereksinim Analizi ile Sistem Analizi Arasındaki Fark: İhtiyaçtan Sistem Davranışına

İki analiz, iki farklı soru

Gereksinim analizi, paydaşların gerçekte neye ihtiyaç duyduğunu ortaya çıkaran, bu ihtiyaçları netleştiren, önceliklendiren ve doğrulanabilir ifadelere dönüştüren çalışmadır. Sorduğu soru şudur: çözüm neyi sağlamalı ve neden? İş hedefleri, kullanıcı ihtiyaçları, iş kuralları, kalite beklentileri ve kısıtlar bu çalışmanın konusudur. Çıktısı, teknolojiden bağımsız olarak okunabilen gereksinimlerdir.

Sistem analizi ise mevcut ya da kurulacak bir bilgi sisteminin nasıl davranması gerektiğini inceler. Sorduğu soru şudur: sistem bu ihtiyaçları hangi işlevler, veri yapıları, ekranlar, entegrasyonlar ve kurallarla karşılayacak? Mevcut sistemin incelenmesi, veri akışlarının ve süreçlerin modellenmesi, sistem bileşenleri arasındaki ilişkilerin çıkarılması ve geliştirme ekibinin doğrudan kullanabileceği ayrıntı düzeyine inilmesi bu çalışmanın işidir. Kısaca gereksinim analizi problem alanına, sistem analizi çözüm alanına daha yakındır; ikisi arasındaki köprüyü fonksiyonel gereksinimler kurar.

Ölçüt ölçüt gereksinim analizi ve sistem analizi

Çalışmanın içeriği ve çıktıları açısından farklar şöyledir:

• Ölçüt: Odak. Gereksinim analizi: iş ihtiyacı, paydaş beklentisi, iş kuralı. / Sistem analizi: sistem işlevi, veri, arayüz, entegrasyon ve sistem davranışı.
• Ölçüt: Temel girdiler. Gereksinim analizi: paydaş görüşmeleri, atölyeler, mevcut iş süreçleri, mevzuat, iş hedefleri. / Sistem analizi: onaylanmış gereksinimler, mevcut sistem belgeleri ve veri tabanı yapıları, kaynak sistem arayüzleri, mimari kısıtlar.
• Ölçüt: Tipik teknikler. Gereksinim analizi: görüşme, gözlem, anket, atölye, süreç modelleme, kullanıcı hikayesi, önceliklendirme. / Sistem analizi: kullanım senaryosu (use case) tanımı, UML sınıf, sıralama ve durum diyagramları, veri modelleme, ekran ve arayüz tasarımı, API analizi.
• Ölçüt: Tipik çıktılar. Gereksinim analizi: iş gereksinim dokümanı, kullanıcı hikayeleri ve kabul kriterleri, gereksinim izlenebilirlik matrisi. / Sistem analizi: fonksiyonel tasarım ya da sistem gereksinim spesifikasyonu, veri sözlüğü, arayüz tanımları, entegrasyon akışları.
• Ölçüt: Başlıca muhatap. Gereksinim analizi: iş birimleri, ürün sahibi, yönetim. / Sistem analizi: yazılım geliştiriciler, mimarlar, test ekibi, entegrasyon ekipleri.
• Ölçüt: Teknoloji bilgisi. Gereksinim analizi: zorunlu değildir; alan bilgisi ve iletişim öne çıkar. / Sistem analizi: veri tabanı, entegrasyon ve yazılım mimarisi bilgisi gerekir.

Proje yaşam döngüsünde nerede dururlar?

Şelale yaklaşımını izleyen projelerde gereksinim analizi genellikle önce yapılır ve onaylanmış bir gereksinim seti oluşur; sistem analizi bu set üzerine kurulur ve tasarım ile geliştirme aşamasına girdi üretir. Kamu, savunma ve finans gibi sözleşmeye dayalı projelerde bu sıralama, belge onayları ve temel çizgi (baseline) ile resmî hâle getirilir; bir gereksinimin değişmesi, bağlı sistem analizi çıktılarının da etki analizinden geçmesini gerektirir.

Çevik ekiplerde ise iki çalışma iç içe ve parça parça ilerler. Bir epic için iş ihtiyacı netleştirilir, kullanıcı hikayeleri ve kabul kriterleri yazılır; hikaye sprint'e girmeden önce ilgili veri alanları, servis çağrıları ve hata durumları sistem analizi düzeyinde ayrıntılandırılır. Bu ayrıntılandırma genellikle backlog iyileştirme toplantılarında geliştiricilerle birlikte yapılır. Yaşam döngüsü değişse de sorulan iki soru aynıdır: neye ihtiyaç var ve sistem bunu nasıl sağlayacak.

Örnek: aynı ihtiyacın iki analiz düzeyi

Örneğin bir sigorta şirketi, poliçe sahiplerinin hasar başvurusunu mobil uygulamadan yapabilmesini istiyor. Gereksinim analizi bu ihtiyacı paydaşlarla çalışarak netleştirir: hangi hasar türleri kapsamda, başvuruda hangi belgeler zorunlu, başvuru sonrası müşteri hangi bilgileri görmeli, hangi durumda eksper ataması gerekir, mevzuat hangi saklama koşullarını getirir. Çıktı, kullanıcı hikayeleri, iş kuralları ve kabul kriterleridir; örneğin poliçe sahibinin başvurusunun durumunu uygulamadan takip edebilmesi gibi.

Sistem analizi aynı ihtiyacı sistem düzeyine indirir: başvuru verisi hangi tablolarda tutulacak, poliçe doğrulaması çekirdek sigorta sisteminin hangi servisiyle yapılacak, yüklenen fotoğraflar hangi depolama alanına gidecek, eksper atama sistemiyle hangi mesajlar değişecek, servis yanıt vermezse kullanıcıya ne gösterilecek. Çıktı, sıralama diyagramları, veri modeli, arayüz tanımları ve hata senaryolarıdır. İki çıktı birbirine izlenebilirlik ile bağlanır; her sistem işlevinin hangi gereksinimi karşıladığı görülebilmelidir.

Hangi durumda hangisine ağırlık verilmeli?

Gereksinim analizine ağırlık verin: • Proje yeni bir iş modeli, yeni bir ürün ya da köklü bir süreç değişikliği getiriyor ve paydaşlar ne istediği konusunda henüz uzlaşmamış. • Önceki projelerde teslim edilen sistem çalışıyor ama iş birimi beklediğini alamadığını söylüyor. • Mevzuat, sözleşme ya da denetim gerekliliklerinin eksiksiz yakalanması kritik.

Sistem analizine ağırlık verin: • İhtiyaç net, ancak çözüm birden fazla eski sistemi, veri kaynağını ve dış servisi kapsıyor. • Mevcut bir sistem yenileniyor ve eski sistemin belgelenmemiş kuralları çıkarılmalı. • Geliştirme dış tedarikçiye verilecek ve tedarikçinin ayrıntılı, yoruma açık olmayan bir tanıma ihtiyacı var.

İki çalışmadan birinin atlanması tipik sorunlar doğurur: gereksinim analizi zayıfsa doğru çalışan ama yanlış işi yapan bir sistem; sistem analizi zayıfsa doğru ihtiyacı tanımlayan ama entegrasyonda ve veri tutarlılığında dağılan bir teslimat ortaya çıkar.

Sık karıştırılan noktalar

Bu iki çalışma konusunda sahada sık rastlanan karışıklıklar şunlardır: • Fonksiyonel gereksinimi sistem tasarımı ile karıştırmak: kullanıcının başvuru durumunu görebilmesi bir gereksinimdir; bu bilginin hangi servisten ve hangi alanla okunacağı sistem analizinin konusudur. • Gereksinim belgesine ekran tasarımı ve tablo yapısı yazmak: çözümü erkenden kilitler, alternatif çözümlerin değerlendirilmesini engeller. • Sistem analizini yalnız teknik ekibin işi saymak: iş kuralları sistem düzeyinde yeniden yorumlanırken iş biriminin onayı alınmazsa anlam kaymaları oluşur. • İzlenebilirliği atlamak: değişiklik geldiğinde hangi sistem bileşeninin ve hangi testin etkilendiği bulunamaz.

Rol açısından da karışıklık olur: bazı kurumlarda iki çalışmayı aynı kişi yapar ve unvanı iş analisti, sistem analisti ya da iş sistem analisti olabilir. Unvan ne olursa olsun, çıktının hangi soruya yanıt verdiği belgenin başında açıkça yazılmalıdır.

Mindset programlarında iki analiz disiplini

Gereksinim tarafında derinleşmek isteyen iş analistleri ve ürün ekipleri için Gereksinim Analistliği Sertifika Programı; bilgi toplama teknikleri, paydaş analizi, gereksinim yazımı ve dokümantasyon kalitesi, çevik gereksinimler, doğrulama ve onaylama ile izlenebilirlik ve değişiklik yönetimi başlıklarını içerir. Savunma ve kamu gibi temel çizgi ve izlenebilirliğin sözleşmeyle bağlandığı projelerde çalışanlar için Gereksinim Yönetimi ve İzlenebilirlik (Savunma Projeleri) programı, ayrıştırma ve tahsis ile değişiklik etki analizine odaklanır.

Sistem tarafına geçmek isteyen analistler için Sistem Analistliği Sertifika Programı; UML ile sistem modelleme, veri modelleme ve veri yönetimi, entegrasyon ve API analizi ile çözüm mimarisi temellerini kapsar. Bu iki program birlikte, analiz ekiplerinde iş ve sistem tarafı arasındaki devir noktasını netleştirmek isteyen yöneticilere ortak bir çerçeve sunar.