Yazılım Gereksinimlerinde Kullanıcı Hikayesi ve Kullanım Durumu
Yazılım geliştirme süreçlerinde analiz süreci kritik bir rol oynar. Projenin başarıya ulaşması için yazılımın hangi ihtiyaçları karşılayacağını doğru belirlemek gerekiyor. Bu nedenle gereksinimleri tanımlarken müşteri ile yapılan görüşmeler, ihtiyaçların doğru analiz edilmesi önemli bir husus.
Özellikle orta ve büyük ölçekli projelerde hem müşteri ile birlikte çalışırken, hem de proje içerisindeki grupların (geliştirici, test uzmanı gibi) çalışmalarına girdi olacak şekilde gereksinimlerin belgelenmesine ihtiyaç var. Burada geçmiş projelerimde deneyimlediğim yaygın olarak kullanılan 2 yöntem üzerinde duracağım:
– Kullanım Durumu (Use Case)
– Kullanıcı Hikayesi (User Story)
Kullanım Durumu
Kullanım durumu aktör (bir kullanıcı veya sistem olabilir) ile sistem arasındaki etkileşimin her bir adımını tanımlar. Alistair Cockburn¹ tarafından önerilen format yaygın olarak kullanılmaktadır:
– Kullanım Durumu İsmi: KD’yi ifade eden basit bir isim seçilebilir — Kullanıcı Ekle gibi.
– Aktör: KD’yi gerçekleştirecek aktör.
– Ön Koşul: KD’ye başlamak için gerekli ön koşul — kullanıcının oturum açmış olması gibi.
– Başarı Kriteri: Hangi durumda KD başarıyla gerçekleşmiş sayılır?
– Ana Senaryo: Gerçekleştirilecek temel senaryo (happy path).
– Alternatif Senaryolar: Temel senaryo dışında ele alınması gereken alternatif durumlar.
Daha iyi anlaşılması için aşağıdaki örnek açıklayıcı olacaktır:
Bu yapıda aktör ile sistem arasındaki etkileşim detaylı bir şekilde ifade ediliyor. Gereksinimi sürekli bir etkileşim şeklinde yazmanın okunabilir bir gereksinim seti çıkarmadığı düşüncesindeyim. Gerçek yaşamda yukarıdakine kıyasla çok daha kompleks kullanım durumları olacağını düşündüğümüzde, müşterinin dikkatle okuyabileceği bir ürün ortaya çıkmıyor. Dolayısıyla analiz görüşmeleri sırasında kullanmak için çok da uygun değil. Yazmak için harcanan eforun yanında ileride gerçekleşmesi muhtemel değişiklikleri bu yapıya yansıtmak da zor. Hele gereksinimi yazarken bazı arayüz detayları da kullanım durumlarına gömüldüyse (kullanıcı şu butona basar gibi) iş daha da zorlaşıyor. Bunun sonucunda bakımını yapmanın gerçekten zor olduğu bir gereksinim setini proje boyunca yönetme yükünü alıyoruz. Gereksinimlerin analiz sonucunda belirlendikten sonra değişime kapandığı waterfall yönteminde böyle bir yapıyı kullanmak daha uygun olabilir. Öte yandan geliştirici ve test senaryolarını yazan çalışanlarımızı akışın ince detaylarına kadar yönlendirme taraftarıysak, kullanım durumunu kullanmak değerlendirilebilir.
Kullanıcı Hikayesi
Kullanıcı hikayesi, gereksinimleri ifade etmenin bir yöntemi olarak çevik metotlardan biri olan XP (Extreme Programming)² tarafından önerilmiştir. Kullanıcı hikayesinin içeriğini oluşturan temel kısımlar:
– Aktör ve sistem etkileşiminden ziyade ihtiyaç duyulan işlevi son kullanıcı bakış açısıyla anlatır. Dolayısıyla daha çok kullanıcının hedefi nedir buna odaklanır. Neden sorusu iş analizinde çok önemlidir, bu sorunun hem müşteri hem de yüklenici tarafından sorulması gereklidir.
– Gereksinimleri yazma sürecinden çok, görüşme aşamasına önem verir. Başlangıçta basit bir cümle ile yazılır, son kullanıcı / müşteri ile yapılan görüşmelerde detayları ortaya çıkar.
– Kullanıcı hikayesini oluşturan kısımlar: Kısa açıklama, görüşmelerde eklenen detaylar, kabul-tamamlanma kriterleri (test edilmesi gereken koşullara karşılık gelir)
Genelde tavsiye edilen format aşağıdadır:
– <Rol / Aktör> olarak, <İş Faydasını> sağlamak için, <Hedefi> gerçekleştirmek istiyorum.
– Örnek: Sistem Yöneticisi olarak, kullanıcının sisteme girmesi ve yetkileri çerçevesinde işlem yapabilmesi için, kullanıcıyı sisteme eklemek istiyorum.
Görüşme öncesinde bir karta yazılır (card), görüşme sırasında müşteri / son kullanıcı beklentileri ile detaylandırılır (conversation) ve kabul kriterleri de test aşamasında kontrol etmek üzere eklenir (confirmation). Çevik yaklaşım low tech — high touch araçları benimsediğinden fiziksel bir kart önerilmiş. Böyle bir zorunluluk yok tabi ki, takibini daha iyi yapmak için Jira gibi araçların bu yapıları destekleyen şablonları var.
Kabul kriterlerini kullanım durumunda ifade ettiğimiz alternatif senaryoların bir karşılığı gibi düşünebilirsiniz:
– Bir kullanıcı sisteme bir defa eklenebilir.
– Kullanıcı bilgileri eksiksiz olmalıdır.
– Kullanıcı adı ve soyadı en fazla 30 karakter olabilir vb.
Sizce kullanım durumundaki alternatif senaryolarla kıyasladığımızda daha anlaşılır ve iletişimi kolay değil mi ? Bu yöntem müşteri iletişimini ön planda tutan bir yapı. Kıyaslama yaptığımda kullanım durumu daha çok içerideki geliştirici ve test uzmanı personel için yazılmış duruyor.
Kullanıcı hikayelerinin hepsi ilk aşamada detaylandırılmayabilir. İleride bölünmesi gerekecek büyük kullanıcı hikayeleri de olacaktır. Bunlara da epic ismini veriyoruz. ‘Sistem Yöneticisi Kullanıcı Yetkilerini Yönetir’ gibi. Projenin ilerleyen fazlarında bunun alt kullanıcı hikayelerine bölünmesi gerekecektir. Bu konuyu da ayrı bir yazıda detaylı konuşalım.
Gereksinimlerin yönetiminde önemli olan — geliştirici, test uzmanı, müşteri / son kullanıcı — herkesin aynı dili konuşuyor olmasıdır. Paydaşların beklentilerinin doğru alınması, neden sorusunun ön planda tutularak gerçekten değer yaratan işlevler için efor harcanması gerekiyor. Bunun için gereksinimlerin dokümantasyonu önemli olsa da paydaşlarla iletişimin sağlıklı yapılması birinci önceliğimizdir.
Kaynaklar:
1: Writing Effective Use Cases, Alistair Cockburn (2000)
2: Essential XP, Ron Jeffries (2001), https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
3: Advantages of User Stories for Requirements, Mike Cohn (2004), https://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-for-requirements
