Bağlam diyagramı çizmek: sistemin sınırını tek sayfada göstermek

Bağlam diyagramı neyi gösterir?

Bir sistem ya da çözüm üzerinde çalışırken ilk sorulması gereken soru, neyin içeride neyin dışarıda olduğudur. Bağlam diyagramı bu soruyu tek sayfalık bir çizimle yanıtlar. Ortada sistemi temsil eden tek bir kutu, çevresinde dış varlıklar ve aralarında etiketli oklar bulunur.

Diyagram sistemin nasıl çalıştığını değil, kimlerle ne alışverişi yaptığını gösterir. Bu yüzden teknik ekip kadar iş birimi, yönetici ve müşteri tarafından da okunabilir. İş analizinde kapsam modelleme tekniklerinin başlangıcıdır ve sonraki akış diyagramları, kullanım senaryoları ve arayüz gereksinimleri bu çizimin üzerine kurulur.

Amaç güzel bir şekil çizmek değil, ortak bir anlayış oluşturmaktır. Çizimi inceleyen herkes şu sorulara aynı cevabı vermelidir: sistem kimlerle konuşuyor, kimlerden ne alıyor, kimlere ne veriyor, ve çizimde olmayan kim ya da ne var?

Diyagramın dört öğesi

Merkezdeki sistem kutusu, çözümün tamamını tek bir adla temsil eder. Adı sade tutulur: "Sipariş Yönetim Sistemi" gibi. Kutunun içine modül ya da ekran yazılmaz.

Dış varlıklar sistemle bilgi alışverişi yapan her şeydir. Kişi gruplarını rol olarak yazmak doğrudur: "Müşteri" ya da "Depo Sorumlusu"; belirli bir kişinin adı değil. Başka sistemler ve kurumlar da dış varlıktır: ödeme sağlayıcı, muhasebe sistemi, kargo firması.

Bilgi akışları oklarla gösterilir ve yönü, içeriği anlatan bir ad taşır: "Sipariş talebi", "Ödeme onayı", "Gönderi bilgisi". Aynı iki uç arasında iki yönde akış varsa iki ayrı ok çizmek daha okunaklıdır.

Son öğe kapsam sınırıdır. Kutu ve oklar sınırı sezdirir; metinsel bir not ise bilinçli olarak dışarıda bırakılanları yazar. Örneğin "kargo takip arayüzü bu sürümde kapsam dışı" notu, sonradan çıkacak bir tartışmayı önler.

Adım adım nasıl çizilir?

Çizim bir toplantı tahtasında ya da paylaşımlı bir çizim aracında, paydaşlarla birlikte yapılırsa daha doğru çıkar. Kimin sisteme bilgi verdiğini ve kimin sistemden bilgi aldığını en iyi iş birimi bilir.

Önce sistemin adı ve amacı tek cümleyle yazılır. Sonra sistemi kullanan ya da etkileyen herkes ve her şey sıralanır: kullanıcılar, yöneticiler, düzenleyiciler, diğer sistemler, kurumlar. Liste, her adayın "sistemle bilgi alışverişi yapıyor mu" sorusuyla elenir.

Ardından her dış varlık için gelen ve giden akışlar yazılır. Akış adları isim biçiminde, somut tutulur. Son olarak çizim paydaşlarla gözden geçirilir: eksik biri var mı, okların yönü doğru mu, kapsam dışı bırakılanlar yazılı mı?

Örnek: çevrimiçi sipariş sistemi

Bir mağazanın sipariş yönetim sistemini ele alalım. Kutunun adı "Sipariş Yönetim Sistemi" olsun. Çevresinde şu dış varlıklar bulunur: Müşteri, Depo Sorumlusu, Ödeme Sağlayıcı, Kargo Firması ve Muhasebe Sistemi.

Müşteri sisteme sipariş talebi ve iade talebi gönderir, sistemden sipariş onayı ve gönderi bilgisi alır. Ödeme sağlayıcıya ödeme isteği gider, ondan ödeme onayı ya da red bilgisi gelir. Depo sorumlusu stok durumunu girer ve toplanacak sipariş listesi alır. Kargo firmasına gönderi bilgisi gider, teslim durumu gelir. Muhasebe sistemine fatura verisi aktarılır.

Bu çizim bir bakışta işin kapsamını gösterir ve eksikleri sorgulatır: müşteri hizmetleri ekibi sistemle konuşuyor mu, kampanya yönetimi ayrı bir sistem mi? Her cevap ya yeni bir dış varlık ya da kapsam dışı notu olarak çizime işlenir. Çizimdeki her akış, daha sonra bir arayüz gereksinimine ve bir test senaryosuna dönüşür.

Sık yapılan hatalar

En sık hata sistemin içini çizmektir. İç modül çizilince diyagram sınırı değil mimariyi anlatmaya başlar; okuyucu kapsamı değil yapıyı tartışır.

İkinci hata, dış varlıkları belirli kişi adlarıyla yazmaktır. Roller kalıcıdır, kişiler değişir.

Üçüncü hata etiketsiz ok çizmektir. Hangi bilginin aktığı bilinmediğinde diyagram doğrulanamaz.

Dördüncü hata, kapsam dışı olanları yazmamaktır. Gelecekte "bu da dahil sanıyorduk" tartışmasını doğurur.

Çizimi bitirmeden önce şu kontrol listesi uygulanır:

• Sistem tek kutu mu ve içinde modül ya da ekran adı yok mu?
• Her dış varlık rol, kurum ya da sistem adıyla mı yazıldı?
• Her okun yönü ve somut bir adı var mı?
• Gelen ve giden akışlar ayrı çizildi mi?
• Kapsam dışı bırakılanlar çizimin yanında yazılı mı?
• Paydaşlar çizimi gördü ve açıkça onayladı mı?

Diyagramı gereksinime çevirmek

Bağlam diyagramının asıl değeri, çizimden sonra başlar. Her dış varlık için bir arayüz sorusu sorulur: bu varlıkla bilgi nasıl alınıp verilecek? Müşteri örneğinde sipariş talebi bir ekran ya da servis çağrısı olabilir; ödeme sağlayıcı için bu bir sistemler arası entegrasyondur; muhasebe sistemi içinse çoğu zaman periyodik bir veri aktarımıdır.

Bu soruların yanıtları bir akış tablosunda toplanabilir:

• Akışın adı ve yönü
• Kaynak ve hedef dış varlık
• Akışın içeriği: hangi bilgi alanları taşınıyor?
• Tetikleyen olay: müşteri bir işlem yaptığında mı, zamana bağlı mı?
• Sorumlu: bu bilginin doğruluğundan kim sorumlu?

Tablo, hem arayüz gereksinimlerinin hem de test senaryolarının iskeletini oluşturur. Tabloya bakıp "bu akışın sahibi yok" ya da "bu varlıktan gelen bilginin biçimi belli değil" diyebilmek, geliştirme başlamadan önce yakalanan en ucuz hatalardır.

Diyagram ile tablo birlikte sürümlenir. Kapsam değiştiğinde önce çizim güncellenir, sonra tablo; böylece iki belge birbirinden kopmaz ve yeni gelen ekip üyesi sistemi tek bakışta kavrar.

Paydaş oturumunu yönetmek

Bağlam diyagramı çoğu zaman bir atölyede çizilir ve oturumun kalitesi, çizimin kalitesini belirler. Oturumdan önce katılımcılar belirlenir: sistemi kullanan iş birimi, teknik ekip, ilgili sistemlerin sahipleri ve mümkünse kapsamı onaylayacak sponsor. Eksik bir iş birimi, çizimde eksik bir dış varlık demektir.

Oturum sırasında moderatör sistem kutusunu tahtanın ortasına yerleştirir ve her katılımcıdan kendi alanına dokunan akışları söylemesini ister. Tartışma sistemin içine kayarsa "bu ayrıntı sonraki diyagramın konusu" denerek not alınır ve konu park edilir. Bir akışın nereye ait olduğu tartışmalıysa, ya yeni bir dış varlık eklenir ya da kapsam dışı olarak yazılır.

Oturum sonunda çizim fotoğraflanıp ya da dijital araca aktarılıp katılımcılara gönderilir ve kısa bir süre içinde onay istenir. Sessiz kabul yerine açık onay almak, kapsamın sonradan genişlemesini sınırlar.

Bu beceriyi Mindset programlarında nerede çalışırsınız

İş analizi uzmanlığı programında strateji analizi ve gereksinim analizi başlıkları, kapsamı belirleme ve çözüm tanımlama çalışmalarını birlikte ele alır. Gereksinim toplamaya başlamadan önce kapsamı paydaşlarla netleştirmek isteyen iş analistleri ve ürün sahipleri için uygulamaya yakın bir zemin sunar.