Yazılım projelerinde müşteri gereksinimlerini belirlemek

Yazılım geliştirme açısından gereksinim, bir kullanıcının bir sorunu çözmesi veya bir amaca ulaşması için gereken bir durum ya da bir sözleşmeyi, standardı, şartnameyi veya resmi olarak dayatılan diğer belgeleri yerine getirmek için bir sistem veya sistem bileşeni tarafından önerilen bir durum veya yetenek olarak tanımlanabilir. 

İyi tanımlanmış gereksinimler, yazılım kullanıcılarının ihtiyaçlarının anlaşıldığından emin olunmasına ve ayrıca potansiyel problemlerin büyümeden giderilmesine yardımcı olur. Bir yazılım için ihtiyaç duyulan gereksinimleri ortaya çıkarmak, müşteri ve son kullanıcılar ile görüşme sonucu ortaya çıkan etkileşimli ve araştırmacı bir süreçtir. Müşteriler yazılımı satın alan kişiler, son kullanıcılar ise yazılımı kullanacak olan kişilerdir. Müşterilerin n "ne istediklerini" ve neye "ihtiyaç duyduklarını" anlamak yazılım ürün yöneticisinin görevidir. Bu nedenle yazılım ürün yöneticisi, bir yazılımda müşteri açısından "istek" olanla "ihtiyaç" olanı birbirinden ayırmalıdır. Müşterilerin "ihtiyaçlarını" ve "isteklerini" keşfetmek ve geliştirmek için en iyi yol, müşterinizle birlikte ürün hakkında tartışmaya girerek gereksinimleri ortaya çıkarmaktır. Ancak gereksinimleri ortaya çıkarmak, "gereksinim toplama" ile karıştırılmamalıdır. "Gereksinim toplama", müşteriye ne yapmak istediğini sorarak elde edilen daha pasif bir yaklaşımdır.

Gereksinimleri ortaya çıkararak müşterilerin ihtiyaçları belirlendikten sonra, gereksinimleri belirleme faaliyeti devreye girer. Genellikle, gereksinimler ilk önce müşterilerle görüşme notlarıyla belirlenir. Proje için en iyi sonucu verecek ifadeleri belirlemek ve kullanmak, yazılım ürün yöneticisi ve ekibine kalmaktadır. Özellikle Scrum metodolojisinde müşteri ihtiyaçlarını öncelikli kılmak önemlidir.

Bir projenin açık, eksiksiz ve tutarlı olmasını sağlamak için listelenen gereksinimleri inceleme süreci, gereksinimlerin analizi olarak bilinir. Bir proje sürekli olarak değerlendirilmeli ve ilerledikçe gereksinimler geliştirilmelidir. Bu uyarlanabilir doğal durum, Çevik sistemlerde önemlidir.

Burada aşağıdaki gereksinim türlerinden bahsedeceğim:

•  iş gereksinimleri
•  iş kuralları
• kullanıcı gereksinimleri
• fonksiyonel gereksinimler
•  fonksiyonel olmayan gereksinimler
•  harici arabirimler
• fiziksel ürün ayarları
• geliştirme kısıtlamaları

Kullanıcı gereksinimleri, fonksiyonel gereksinimler ve fonksiyonel olmayan gereksinimler temel gereksinimler olarak kabul edilirken, iş gereksinimleri ve iş kuralları projeyi etkileyebilen gereksinimlerdir. Diğerleri; harici arabirimler, fiziksel ürün ayarları ve geliştirme kısıtlamaları ise ürünün tasarımı ve uygulanması için gereken gereksinimlerdir.

İş gereksinimleri, projenin amacını içeren gereksinimleri ifade eder. Bu hedefler genellikle iş analistleri tarafından kullanılabilen somut veya ölçülebilir iş değerleridir. Örneğin "Yıllık gelirlerini 10.000$ artırmak için, müşterilerin, şirketlerine yapılan siparişlerindeki hataları gelecek yıla kadar % 25 azaltması gerekir." ifadesi bir iş gereksinimidir.

İş kuralları, iş gereksinimleri ile karıştırılmamalıdır. İş gereksinimleri, projenin neden takip edildiği ile ilgilenirken, iş kuralları ürünün nasıl işlevini yerine getireceği konusunda kısıtlamalar oluşturmaktadır. İş kuralları karşımıza genellikle bütçeler, politikalar, yönergeler ve düzenlemeler şeklinde çıkmaktadır.

Son kullanıcılar, yazılımı oluşturduktan sonra kullanacak olan kişilerdir. Kullanıcı gereksinimleri son kullanıcılarla beraber ortaya çıkarılır. Kullanıcı gereksinimlerini ifade etmenin birçok yolu vardır. Bunlar;  Use case’ler, User story’ler, Storyboard’lar, Senaryolar olabilir. Bunlardan burada bahsedeceğim. Örneğin senaryolar, müşterinin veya son kullanıcıların kullanıcı gereksinimlerini kendi sözleriyle ifade ettiği durumlardır. 

Fonksiyonel gereksinimler genellikle ürün girdileri, ürün çıktıları veya davranışın kendisinin bir açıklaması olarak ifade edilir. Örneğin girdi, bir kullanıcının online satın alıma ilişkin, ad, adres, satın alınan ürün ve ödeme bilgileri gibi veriler olabilir. Bu senaryodaki çıktı, işlem gerçekleştirildikten sonra bir bildirim e-postası olabilir. 

Fonksiyonel gereksinimler bilgi akış şemaları ile ifade edilebilir. Aşağıda, bir ürünle birlikte bir kredi kartı kullanan bir müşteri için bilgi akışı şeması örneği bulunmaktadır. bu örnekte kredi kartı bilgileri kullanıcı için bir fatura oluşturulmadan önce nerede kullanıldığı ile ilgilidir.

Bilgi akış şeması örneği

Bilgi akış şemaları, bilgi veya verilerin bir sistem üzerinden nasıl hareket ettiğini göstermek için kullanılan görsel tekniklerdir. Bu şemalar veya diyagramlar, kullanıcıların ürünle nasıl etkileşime geçebileceğini göstermek açısından kullanışlıdır.

Fonksiyonel olmayan gereksinimler, kalite gereksinimleri olarak da bilinir. Yukarıdaki senaryoda fonksiyonel olmayan bir gereksinim, e-postaların ürün satın alındıktan iki saat sonra kullanıcılara teslim edilmesidir.

Harici arabirim gereksinimleri, ürünün daha büyük bir sistem içinde nasıl yer aldığı ile ilgili gereksinimleri ifade eder. Bu gereksinim türü ürünün fiziksel çevresi ile ilgilenmez, daha çok ürünün dışındaki diğer varlıklarla olan ilişkisi ile ilgilidir. Örneğin uzak bir veritabanından veri alan bir yazılım uygulamasında veritabanından gelen veriler ve son kullanıcılar arasında harici bir arabirim gerektirir.

Fiziksel ürün ayarları, ürünün fiziksel ortamını tanımlar. Örneğin su altında çalışacak şekilde geliştirilecek  bir telefon su geçirmez özelliği olacak şekilde tasarlanmalıdır.

Geliştirme kısıtlamaları ise hangi cihazların veya platformların destekleneceği veya ürünün ne kadar bellek, bant genişliği veya işlem gücü ile sınırlı olduğu gibi ürünün oluşturulması ile ilgili kısıtlamaları içerir. Teknoloji hızla geliştiğinden genellikle en sona bırakılan bir gereksinim türüdür.

Projede zaman içinde değişiklikler olabilir, bu durum ürünün amacını ve kapsamını etkilememelidir. Örneğin masa üstü bilgisayarlar için tasarlanan bir oyunun, ürün geliştirme aşamasına girdikten sonra mobil ortama göre de uygun şekilde tasarlanmasının istenmesi projenin başarısını büyük oranda etkileyecektir. Bu durum proje kapsamının büyümesi (scope creep) anlamına gelir ve proje başarısı düşer. Bu nedenle baştan müşteri ile geliştirme ekibi arasındaki beklentilerin netleştirilmesi, kapsamın çizilmesi (use case diyagramları), ve gereksinimlerin önceliklendirilmesi (en önce istenenlerin ilk olarak geliştirilmesi) gerekir. Bunun için gereksinimlere yönelik somut zaman çizelgeleri oluşturmak çözüm olabilir.

Çevik manifestonun temel ilkesi, önerilen her değişikliğin durum bazında değerlendirilmesi ve bu değişikliğin projeyi nasıl etkileyebileceğinin değerlendirilmesidir.

Çevik yazılım geliştirme felsefesine göre yazılım sadece bir kere tanımlanamaz, sürekli gelişen bir süreçtir. Geliştirme süreci içinde müşterilerin genellikle ürünün fonksiyonelliği hakkındaki düşünceleri değişir. Bu durum, gelişim aşamasının ortasında bile olabilir. Çevik yazılım geliştirme ilkelerine göre değişen gereksinimler hoş karşılanmalı ve hatta değişim beklenmelidir.

Çevik manifestonun diğer ilkeleri aşağıdaki şekildedir (http://www.agilemanifesto.org/):

1. En yüksek önceliğimiz, müşteriyi memnun etmek için değerli bir yazılımı devamlı ve erken telim etmek.
2. Değişen gereksinimleri hoş karşılamak, gelişim sürecinin sonunda bile olsa. Çevik süreçler, müşterilerine rekabetçi avantaj sağlamak için değişimden yararlanır. 
3. Çalışan yazılımı sık sık teslim etmek, bir kaç haftadan bir kaç aya kadar, ama tercihen kısa aralıklarla.
4. Müşteriler ve geliştiriciler proje boyunca her gün beraber çalışmalı.
5. İyi anlaşan motive olmuş bireylerle proje oluştur. Onlar için ihtiyaç duydukları ortamı ve desteği ver, ve işi yapabilecekleri konusunda onlara güven.
6. Çevik süreçler sürdürülebilir gelişimi destekler. Sponsorlar, geliştiriciler, ve kullanıcılar süresiz olarak sabit hızla destek verebilmeli.
7. Çalışan yazılım gelişimin ilk ölçüsüdür.
8. Bir gelişim ekibi içinde ve dışına bilgi aktarmanın en etkin ve etkili yöntemi yüz yüze konuşmadır.
9. Teknik mükemmeliyete ve iyi tasarıma devamlı dikkat etmek çevikliği geliştirir.
10.  Basitlik- yapılmayan işlerin miktarına arttırma sanatı- önemlidir.
11. En iyi mimariler, gereksinimler, ve tasarımlar kendi kendine organize olan ekiplerden doğar.
12. Düzenli aralıklarla, ekip daha etkili nasıl olabileceklerini yansıtmalı, sonra düzenli olarak bunu davranışlarına yansıtmalıdır.

12 Çevik Yazılım İlkesi

Gereksinimler Çevikliğin ayrılmaz bir parçasıdır. User story'ler, usecase'ler, wireframeler ve storyboard'lar gibi teknikler, müşteri gereksinimlerini toplamak ve ifade etmek için kullanılır. 

Kullanıcı Hikayeleri

Kullanıcı hikâyeleri, çok fazla teknik ayrıntı kullanmadan bir gereksinimi ifade etmenin açık ve yapılandırılmış bir yoludur. Yazılım ürün yöneticileri çoğu zaman daha deneyimli oldukları için kullanıcı hikâyelerini yazarlar veya yazmaya yardımcı olurlar.

Örnek bir kullanıcı hikayesi (user story);

“Sıkça sinemaya giden bir izleyici olarak, yakınımdaki sinema salonlarında vizyona yeni girecek filmler hakkında bütün bilgilere telefonumdan ulaşabilmek istiyorum, böylece her film için ayrı ayrı arama yapmak durumunda kalmayacağım.” (https://sherpa.blog)

Bir kullanıcı hikayesi, çok belirsiz veya geniş açıklamalar içeriyorsa, ne kadar süreceği veya nasıl yapılacağını tahmin etmek zorsa muhtemelen epik bir kullanıcı hikayesidir. Bir epik tespit edilirse, muhtemel küçük hikayelere bölünebilir. 

Örneğin epik bir kullanıcı hikayesi; 

"Müşteri olarak, faturamı ödemek istiyorum, böylece borcum kalmamış olur."

Bu epik hikaye daha küçük parçalara ayrılabilir:

• "Müşteri olarak, sipariş listemle birlikte faturamı görmek istiyorum, böylece siparişimin ne kadara mal olacağını görebilirim.
• “Müşteri olarak, faturamı görüntülerken "şimdi öde" seçeneğini görmek istiyorum, böylece faturayı hemen ödeyebilirim."
• “Müşteri olarak, VISA ve MasterCard kredi kartlarım ile ödeme bilgilerimi girmek istiyorum, böylece uygun bir yöntemle ödeme yapabilirim.”

Bir kullanıcı hikâyesinin gereksinimleri tamamlanıp tamamlanmadığını doğrulamak için kabul testi (acceptance test) kullanılır. Yukarıdaki kullanıcı durumu için kabul testi örneği;

"Bir müşteri olarak, VISA ve Master Card kredi kartlarını kullanarak ödeme bilgilerimi girmek istiyorum, böylece uygun bir yöntemle ödeme yapabilirim."

Bu kullanıcı hikayesi için aşağıdaki adımlardan geçmek kabul kriterini doğrular;

• Ödeme bir VISA kredi kartı kullanılarak yapılabilir.
• Ödeme, bir MasterCard kredi kartı kullanılarak yapılabilir.
• Ödeme çevrimiçi bir finansal hizmet kullanılarak yapılabilir.
• Kredi kartı ile ödeme yaparken "kart numarası" alanı girildiğinde kart türü otomatik olarak algılanır.
• Müşteri, seçilen ödeme yöntemine bağlı olarak yalnızca ilgili giriş alanlarını görür. 

Bir ölçütü kabul testine dönüştürmek için birkaç adım hazırlamak yararlı olacaktır. Örneğin, "Ödeme bir VISA kredi kartı kullanılarak yapılabilir" testi şu şekilde olabilir:

• Bir çip okuyucuya bir VISA kartı takın.
• VISA'nın PIN numarasını girin.
• Ödemenin kabul edildiğini onaylayın.

Eğer tüm kabul testleri kullanıcı hikâyelerinin kabul kriterlerini geçerse, kullanıcı hikâyesinin başarıyla test edildiği kabul edilir. Kullanıcı hikâyeleri gibi kabul testleri de, yazılım ürünü yöneticisi ve geliştirme ekibinin yardımıyla müşteri tarafından geliştirilmelidir.

Use case Diyagramları

Use case diyagramları, bir sistemin hangi fonksiyonlarının hangi hangi aktörler tarafından gerçekleşeceğini belirten diyagramlardır. Bu diyagram, ürünün tamamını, ürünle etkileşime girerken üstlenilebilecek görevleri ve ürün tarafından desteklenen rolleri göstermelidir.

Online yemek siparişi için bir Use case örneği

Ancak bazı use case'ler başka use case'ler olmadan tamamlanamaz. Yukarıdaki örnekte sipariş vermek için öncelikle menüyü görüntülemek ve sepete ürün eklemek gerekir. Bunu ifade etmek için include adı verilen bir ilişki türü kullanılır.

Use case örneğinde include

Use case'lerde kullanılan diğer bir ilişki türü extend'tir. Bir use case'in durumunun başka bir use case ile genişletilmesi durumunda kullanılır yani mevcut use case'in adımlarına yeni adımlar eklenerek kapsamı genişletilir.

Use case örneğinde extend

Yukarıdaki örnekte banka müşterisi bankamatikten kredi kartı ödemesi yapabilir. Ödeme yaptıktan sonra isterse bu işlemi yaptığına dair makbuz alabilir. Bu durumda makbuz yazdır adında bir use case'le extend ilişkisi kurulabilir.

Use case diyagramları müşteri gereksinimlerini belirlemek için kullanılan iyi bir yöntemdir. Use case diyagramı çizmek için ArgoUML programı kullanılabilir.

Wireframe'ler

Bir tür erken plan ya da test model olarak düşünülebilir. Ürünün temel bir görsel sunumudur. Wireframe’ler genellikle müşteri ile ilk görüşmelerin ardından hızlı bir şekilde geliştirilir. Müşteriler daha sonra ürünlerinin neye benzeyebileceğinin erken bir sürümünü görmek ve geri bildirim vermek için bir şansa sahip olurlar. Aynı zamanda hem müşteri hem de geliştirme ekibinin aynı görüş doğrultusunda çalışması sağlanır. 

Wireframe çizmek için wireframesketcher programı kullanılabilir.

Storyboard'lar

Yazılım geliştirmede, storyboard'lar, yazılım ürünü ile olan etkileşimin sıralı, görsel temsilidir. Üründe birden fazla özellik varsa, her biri için bir storyboard yapılması gerekir. Genel olarak, bir storyboard’da öngörülen kullanıcı ya da katılan aktör (use case'lerde açıklandığı gibi) bir kişidir. Kişiler, yaş, etnik köken, gelir düzeyi, iş, kişilik gibi ayrıntılar da dahil katılımcı aktörlere daha ayrıntılı hikayeler sağlar. Böyle üst düzey ayrıntılar sağlamak, belirli sorunların önceden belirlenmesine yardımcı olur.

Storyboard Örneği

Ürün Backlog ve Sprint 

Bir ürün backlog’u, yazılım ürün yöneticisi ve geliştirme ekibinin bir ürün için bir proje boyunca geliştirmeyi planladığı yazılım özelliklerinin bir listesidir. Bir işi organize etmek, projedeki görevleri önceliklendirmek için iyi bir araçtır. Scrum ve dolayısıyla Çevik için kritik öneme sahiptir.

Kullanıcı hikayelerinin ürün backlogunda önceliklendirilmesi, müşteriler, yazılım ürün yöneticisi ve geliştirme ekibi arasındaki tartışmalar yoluyla yapılır. Ürün backlogların gelen kullanıcı hikayeleri, belirli zaman aralıklarında yapılacak iş birimleri halinde gruplandırılır. Bu aralıklar “sprint” olarak bilinir. Ürün backloglarından gelen en önemli görevlere sprint'te öncelik verilir. Scrum bir defada bir “sprint” geliştirmeye odaklanır.

Bir “sprint” sonunda, müşteriler yapılan işi değerlendirebilir ve ürün için yeni kullanıcı hikayeleri veya gereksinimleri ekleyebilir veya mevcut kullanıcı hikayelerinin veya gereksinimlerin önceliğini değiştirebilir. Bir sonraki “sprint” buna göre ayarlanabilir. Ürün backlogu bu nedenle zamanla değişebilecek; daha küçük, daha büyük veya sırası değişken olabilecektir. 

Ürün Backlog ve Sprint Örneği

Ürün Backlog oluşturmak için visual-paradigm programı kullanılabilir. 

Hikaye Haritaları

Hikâye haritaları, gereksinimleri organize etmek ve bir projenin yapılandırılmasına yardımcı olmak için kullanılır. Hikaye haritaları, bir ürün backlogu yapısı ile gereksinimlerin bir listesini oluşturur. Kullanıcı hikayeleri belirli fonksiyonel kategorilere ayrılarak görsel bir şekilde burada sunulur. Hikaye haritalarında, ürünün nasıl gelişeceğini ve parçaların nasıl bir araya geleceğini daha iyi anlamak, bir ürünün sırayla nasıl gelişeceğini görmek mümkündür; bu da projeye zaman kazandırır.

Hikaye Haritası Örneği

Hikâye haritaları, birden fazla fonksiyonelliğe vurgu yapması nedeniyle çevik ilkelere iyi bir örnektir. Hikâye haritasının Kanban tahtası olmadığını hatırlamak önemlidir. Kanban, projenin mevcut durumunu görüntülemek ve proje görevlerinin ilerlemesini izlemek için kullanılan bir yöntemdir. Bir hikaye haritası ise yalnızca kullanıcı hikayelerini planlamak ve düzenlemek için bir araç olarak kullanılır. 

Kaynak: 

Alberta Üniversitesi, Müşteri İhtiyaçları ve Yazılım Gereksinimleri Ders Notları, 2015
Çevik İlkeler https://www.knowledgetrain.co.uk/resources/practice/agile-principles
Use case diyagramları https://www.linkedin.com/pulse/use-case-analizi-1-emre-alag%C3%B6z/
Use case Modelleme https://www.youtube.com/watch?time_continue=278&v=66VDvthM3S4
Wireframe Örnekleri https://www.lucidchart.com/pages/examples/wireframe