Gereksinimler
Bir yazılım gereksinimi, yazılımın uyması gereken bir kuraldır: neyi, ne kadar iyi ve hangi kısıtlamalar veya sınırlar dahilinde yapması gerektiği.
Gereksinim Türleri
İki ana gereksinim türü vardır:
- İşlevsel gereksinimler "Bir sistemin belirli koşullar altında sergileyeceği davranışın tanımıdır" (Wiegers & Beatty, 2013, s. 599). Örneğin, "Kullanıcı 'oturum aç' düğmesini etkinleştirirse, oturum açma sayfası görünecektir." İşlevsel gereksinimler "Yazılım ne yapmalıdır?" sorusuna yanıt verir.
- İşlevsel olmayan gereksinimler, "bir sistemin sergilemesi gereken bir özellik veya karakteristiğin ya da uyması gereken bir kısıtlamanın tanımıdır" (Wiegers & Beatty, 2013, s. 600). Örneğin, "Kullanıcı 'oturum aç' düğmesini etkinleştirirse, oturum açma sayfası 500 milisaniye içinde görünecektir." Bu işlevsel olmayan gereksinim, sistemin sergilemesi gereken bir özelliğe sahiptir: yanıt verebilirlik. Duyarlılık aynı zamanda bir kalite niteliği olarak da adlandırılır. Bir kısıtlamaya uymakla ilgili işlevsel olmayan bir gerekliliğe örnek olarak "GUI araç seti dikdörtgen olmayan pencereleri görüntüleyebilmelidir." verilebilir.
Şekil 3.1, işlevsel olmayan bir gereksinimi ve işlevsel bir gereksinimi yansıtmayan bir tasarımın basit bir örneğini göstermektedir.
Not. Bu tekerlekli masa, ortalama bir kapıdan geçme işlevsel olmayan gerekliliğini ve dört ayaklı olma işlevsel gerekliliğini karşılayamamaktadır.
Gereksinimler Neden Önemlidir?
Yazılımın tasarımı ve uygulaması ideal olarak gereksinimlerden yola çıkılarak yapılmalıdır. İşte gereksinimlerin yardımcı olduğu bazı yollar ve önemli olmalarının nedenleri:
- Geliştiricilere gereksinimler verilmediğinde, kişisel olarak uygulamanın önemli veya eğlenceli olduğunu düşündükleri işlevlere öncelik verebilirler, ancak geliştiricilerin uygulamak istedikleri şey projeyi başarılı kılmayabilir.
- Birden fazla geliştirici aynı kod üzerinde çalıştığında, gereksinimler senkronize olmalarına ve aynı hedefi takip etmelerine yardımcı olabilir. Gereksinimler olmadan, zaman, çaba ve para birbiriyle çelişen kodların uygulanması için boşa harcanabilir.
- Gereksinimler belirlenmediğinde, proje paydaşlarının (örneğin, müşteriler, ortaklar, yatırımcılar, danışmanlar, yönetim) projeyi kendi (muhtemelen geçici) isteklerini veya ihtiyaçlarını karşılamaya yönelik olarak etkilemesi daha kolaydır. Bu da projenin başlangıçta amaçlanandan uzaklaşmasına ve projenin başarısız olmasına yol açabilir.
- Gereksinimler, paydaşlarla yazılım hakkında iletişim kurmak, yapılması gereken her şeyi takip etmek ve sizin ve müşterinin gerçekten neyin yapılması gerektiğine karar vermesine yardımcı olmak için yararlıdır (müşteriler bazen gerçekten neye ihtiyaçları olduğunu bilmezler).
İyi Bir Gereksinimi Ne Oluşturur?
Ekipler veya kuruluşlar neyin iyi bir gereklilik olduğuna dair kendi standartlarını seçebilirler. İşte bir dizi standart (Texas Department of Information Resources, 2008):
Gereksinimler . . .
- Doğru: Söyledikleri doğrudur.
- Kesin: Onları yorumlamanın tek bir yolu vardır.
- Eksiksiz: Önemli olan her şeyi kapsar.
- Tutarlı: Çelişkili değildirler.
- Önem ve/veya istikrar açısından sıralanmıştır.
- Doğrulanabilir veya test edilebilir: Tatmin olup olmadıklarını anlamanın bir yolu vardır.
- Değiştirilebilir: Değiştirilebilirler.
- İzlenebilir: Nereden geldiklerini bulmak mümkündür.
Gereksinimler ayrıca . . .
- İlgili önceki belgelere çapraz referanslı.
- Benzersiz bir şekilde tanımlanabilir.
- Maksimum okunabilirlik için düzenlenmiştir.
Gereksinimlerin Ortaya Çıkarılması
Gereksinimlerin toplanması sürecine gereksinim belirleme denir. Gereksinimler, müşteriler, yöneticiler, kullanıcılar, hükümetler, sizinkiyle entegre edilecek yazılımın geliştiricileri, geliştirme ekibi ve kendiniz de dahil olmak üzere herhangi bir paydaştan gelebilir. Gereksinimlerin ortaya çıkarılması, hem paydaşların istek ve ihtiyaçlarını tespit etmeyi hem de hangi gereksinimlere odaklanılacağına karar vermek için profesyonel muhakemenizi kullanmayı içerir.
Paydaşların istek ve ihtiyaçlarını tespit etmek, iletişim kurmak ve gözlemlemek. Bazı yöntemler:
- Mülakatlar: Yapılandırılmış (önceden tanımlanmış sorular), yarı yapılandırılmış (bazı sorular önceden tanımlanmış, bazıları görüşme sırasında oluşturulmuş) veya yapılandırılmamış görüşmeler.
- Odak grupları: Katılımcıların moderatör rehberliğinde kendi aralarında konuları tartıştıkları küçük grup sohbetleri.
- Laboratuvar çalışmaları: Katılımcılar kontrollü bir ortamda görevleri yerine getirir (örneğin, erken bir prototipi kullanmayı dener, ardından geri bildirim verir).
- Keşifsel araştırma: Paydaşlar hakkında bilgi edinmek ve empati geliştirmek amacıyla ilgili kişilerin ve ürünlerin dünyasına dalmaya yönelik çoklu yöntemler. Örneğin, bir gözlem yaptıktan sonra insanların 25 numaralı reyonu bulamadığını, çünkü reyonun beklenmedik bir yerde olduğunu fark ettiniz. Mağazanın uygulamasında Koridor Haritası özelliğine öncelik vermeye karar veriyorsunuz.
Yazılım geliştirme ortamına bağlı olarak, bu yöntemler pazarlama veya etkileşim tasarımı alanında uzman araştırmacıların yetki alanına girebilir. Hanington ve Martin (2019) bu uzmanlık yöntemlerini (ve diğer birçok ilgili yöntemi) daha ayrıntılı olarak açıklamaktadır.
Geliştiriciler de paydaşlarla konuşarak gereksinimleri ortaya çıkarabilir. Ancak bu yaklaşımın başarısını etkileyebilecek faktörler vardır.
- Paydaşlar deneyim veya uzmanlığa sahip olmayabilir. Geliştiriciler, paydaşın ne istediği ile teknik olarak uygulanabilir ve makul olan (örneğin, üçlü kısıt olarak da bilinen zaman, maliyet ve kapsam göz önüne alındığında) arasındaki boşluğu doldurmaya yardımcı olabilir.
- Paydaşların iyi fikirleri olmayabilir. Kendilerinin ya da diğer insanların ne istediği ya da ne kullanacağı konusunda hatalı olabilirler. Geliştiriciler bazen daha iyi fikirler için rehberlik sağlayabilir, ancak geliştiricilerin de kötü fikirleri olabilir. Odak grupları, kullanılabilirlik testleri ve minimum uygulanabilir ürün (MVP) yayınlama gibi yöntemler, kullanıcıların yazılımı kullanıp kullanmayacağını (ve ödeme yapıp yapmayacağını) anlamaya yardımcı olabilir.
- Paydaşlar ne istediklerini bilmiyor olabilir. Kaba bir fikirleri ya da istek veya ihtiyaçlarıyla çelişen bir fikirleri olabilir.
- Paydaşlar kendileri veya başkaları için kötü olanı isteyebilir. Örneğin, kullanıcılar fotoğraflarda yüzlerini güzelleştiren uygulamalar isterler, bu tür özellikler gerçekçi olmayan güzellik standartlarını teşvik edebilir.
- Paydaşlar insanlardır. Kusurlu bir şekilde iletişim kurarlar.
Deneyimle, paydaşlardan ilgili bilgileri etkili bir şekilde nasıl toplayacağınızı öğrenebilir ve bu bilgilerin gereksinimlere nasıl dönüşeceği konusunda kendi yargılarınızı oluşturabilirsiniz.
İşlevsel Olmayan Gereksinimler
İşlevsel olmayan gereksinimler, yazılımın ne kadar iyi performans göstermesi gerektiğini veya hangi kısıtlamalara uyması gerektiğini açıklar.
İşlevsel olmayan gereksinimlere örnekler:
- Yanıt süresi tüm çalışma ortamlarında birkaç saniye veya daha az olmalıdır.
- Ön uç tasarımı, her Sprint'te en az iki kişi tarafından Kapsayıcılık Sezgiselliği kullanılarak değerlendirilmelidir.
- Yazılım haftanın yedi günü, günde 24 saat kullanılabilir olmalı ve %99,99 çalışma süresine sahip olmalıdır.
Her işlevsel olmayan gereksinimin bir niceliği olduğuna dikkat edin. Bu, test edilebilir olmasına yardımcı olur (iyi bir gereksinim için bir kriter).
Kalite Özellikleri
| Wikipedia’nın “Sistem kalite nitelikleri listesi” sayfasında uzun bir kalite nitelikleri listesi bulunmaktadır (Wikimedia Foundation, 2023). |
Kalite nitelikleri "yazılımın bir hizmet veya performans özelliğini" tanımlayan kelimelerdir (Wiegers & Beatty, 2013, s. 601). Bazı yaygın kalite nitelikleri aşağıdaki gibidir.
- Sürdürülebilirlik: Geliştiricilerin yazılım kodunu güncellemesi, yeniden düzenlemesi veya başka bir şekilde değiştirmesi için gereken çaba miktarı.
- Taşınabilirlik: Yazılımı farklı platformlarda çalıştırmak için gereken çaba miktarı.
- Güvenilirlik: Yazılımın işlevlerinin ne sıklıkla başarılı veya başarısız olduğu.
- Verimlilik: Yazılımın ihtiyaç duyduğu kaynak sayısı.
- Bütünlük: Yazılımın ne sıklıkla veri kaybettiği.
- Akılda kalıcılık: Kullanıcıların işlevselliği yeniden öğrenmek için harcaması gereken zaman miktarı.
- Esneklik: Yazılımın kullanılabileceği farklı yolların sayısı.
- Birlikte çalışabilirlik: Yazılımın diğer yazılımlarla entegre olabilme kolaylığı.
- Yeniden kullanılabilirlik: Kodun başka problemleri çözmek için kolayca kullanılabilme derecesi.
Her kalite özelliği bir ölçeğe dönüştürülebilir. Örneğin, bir tekli için güvenilirlik ölçeğindeki en düşük değer "işlev %0 oranında başarılı olur" olabilir ve %100 de elbette zıt kutup olacaktır. Bu ölçek göz önüne alındığında, bir performans eşiği tanımlayarak işlevsel olmayan bir gereksinim belirleyebiliriz:
- İşlev yüksek güvenilirliğe sahip olmalıdır (zamanın >%99'unda başarılı olur).
Yazılımınız için kalite niteliklerini seçtiğinizde, sizin/ekibiniz/projeniz için en önemli olan niteliklere öncelik vermiş olursunuz. İdeal olan, ekibinizin bu kalite özelliklerini (ve bunlara karşılık gelen işlevsel olmayan gereksinimleri) proje süresince akılda tutmasıdır. Eğer yazılım işlevsel olmayan gereksinimleri karşılamıyorsa, ya yazılımın ya da kabul edilebilirlik eşiğinin değişmesi gerekir.
Kısıtlamalar
Bazı işlevsel olmayan gereksinimler kalite özellikleriyle ilgili değildir ve bunun yerine kısıtlamalar dahilinde kalmakla ilgilidir. Aşağıda örnek kısıtlama türleri verilmiştir (Wiegers & Beatty, 2013):
- Teknoloji seçimlerini sınırlayanlar (programlama dilleri, çerçeveler, veritabanları, uygulama programlama arayüzü (API) türleri, vb.)
- Hangi platformların hedeflendiğini sınırlayanlar (örneğin, mobile karşı masaüstü, iOS'a karşı Android).
- Bunlar yazılımla ilgili nelerin değişebileceğini sınırlar (örneğin, geriye dönük uyumluluk için).
- Kodun nasıl yazılabileceğini sınırlayanlar (örneğin, belirli kodlama ve dokümantasyon standartlarına uyulması).
- Verilerin nasıl işlenebileceğini sınırlayanlar (örneğin, yalnızca ABD sunucularında saklanmalıdır).
Kısıtlamalar ve kalite nitelikleri arasındaki kavramsal fark, kısıtlamaların genellikle dışarıdan zorunlu kılınması, kalite niteliklerinin ise ekip tarafından dahili olarak seçilebilmesidir.
İşlevsel Gereksinimler
İşlevsel gereksinimler yazılımın ne yapması gerektiğini tanımlar.
Örnek işlevsel gereksinimler:
- "Kayıt ol" düğmesi etkinleştirildiğinde, kullanıcının bilgileri veritabanına eklenir ve bir "kayıt olduğunuz için teşekkür ederiz" ekranı görüntülenir.
- Bir toptancı olarak, ne kadar para kazanacağımı bilmek için "ürün görünümüne" gittiğimde toptan ve perakende fiyatları görmek istiyorum.
- Bir kullanıcı en az bir düzenleme eylemi gerçekleştirdiğinde, "eylem geçmişi" penceresini etkinleştirdiğinde, gerçekleştirdiği düzenleme eylemlerinin bir listesini görür.
Bu işlevsel gereksinimlerin her biri farklı biçimlendirilmiştir. İlk format için bir isim yoktur; sadece yazılımda belirli bir eylem gerçekleştirildiğinde ne olması gerektiğini belirtir. İkincisi, Çevik yazılım geliştirmede yaygın olan kullanıcı hikayesi formatını kullanır. Bu format kullanıcıyı, kullanıcının ne yapmaya çalıştığını ve motivasyonlarını vurgular. Üçüncü gereklilik, bağlamı içeren given-when-then formatını kullanır (daha fazla bilgi için Agile Alliance'a bakın). Bu format genellikle kullanıcı hikayesi kabul kriterlerini yazmak için kullanılır: doğru olduğunda kullanıcı hikayesinin tamamlandığını gösteren bir dizi ifade.
İşlevsel gereksinimleri yazmanın daha resmi bir yolu, bir şablonu izleyen kullanım senaryosu biçimidir. Şekil 3.2 basit bir şablon kullanan örnek bir kullanım durumu içermektedir.
| İsim: İyileşen hastaların listesini oluşturun Aktör: Klinisyen Akış: 1. Klinisyen akıllı kart kullanarak kimlik doğrulaması yapar. 2. Yazılım, belirli bir makine için kullanıcı kimlik bilgilerini ve izinlerini onaylar. 3. Yazılım erişimi kaydeder. 4. Yazılım hasta aramasını görüntüler. 5. Klinisyen “Gelişmiş Hasta Arama”yı seçer. 6. Yazılım, gelişmiş arama sayfası için kullanıcı erişim izinlerini onaylar. 7. Klinisyen hastalığı ve hasta durumunu seçer. 8. Klinisyen “Ara” düğmesini kullanarak aramayı gerçekleştirir. 9. Yazılım sonuçları döndürür. 10. Yazılım sorguyu günlüğe kaydeder. |
Kullanıcı Hikayeleri
Kullanıcı hikayeleri, işlevsel gereksinimleri belirlemeye yönelik bir yöntemdir. Yazılımın işlevselliğinin küçük bir parçasını basit ve okunması kolay bir cümleyle tanımlarlar. Teknik olmayan kişilerin (örn. kullanıcılar, müşteriler, diğer paydaşlar) anlayabilmesi için sade bir İngilizce ile yazılırlar.
| Bir kullanıcı hikayesinin gövdesi genellikle şu format kullanılarak yazılır Bir <ROL> olarak, <BAZI İŞLEVSELLİK> istiyorum, böylece <BAZI FAYDALAR> elde ediyorum |
Kullanıcı hikayeleri 3 × 5 indeks kartlarına yazılabilir ve daha sonra bir duvara veya beyaz tahtaya yapıştırılabilir. Ayrıca görev ve proje yönetim sistemlerine (örneğin Jira, Asana ve benzerleri) de yazılabilirler. Şekil 3.3, bir proje bağlamında birkaç kullanıcı hikayesi örneği sunmaktadır (bunlara öncelikler ve projeyle ilgili diğer bilgiler eklenmiştir).
| US-023: Yorumları Devre Dışı Bırakma Öncelik: En Yüksek (8) Sprint: 2 Görevlendirildi: Emrah Tuukka Bir yönetici olarak, spam ve dezenformasyonun yayılmasını kontrol edebilmek için yorumları devre dışı bırakmak istiyorum. |
| US-034: Kişiselleştirilmiş Avatar Arka Planı Öncelikli: En Düşük (1) Sprint: 3 Görevlendirildi: Ade Einarr Kayıtlı bir kullanıcı olarak, deneyimimi kişiselleştirebilmek için avatarımda yüzümün etrafındaki arka planı değiştirmek istiyorum. |
| US-012: Uygulama Amacı Öncelik: En Yüksek (8) Sprint: 1 Görevlendirildi: Randomira Philibert Yeni bir kullanıcı olarak, uygulamayı kullanıp kullanmayacağıma karar verebilmek için uygulamanın hangi özellikleri sağladığını okumak istiyorum. |
Daha fazla kullanıcı hikayesi örneği ister misiniz? Mountain Goat Software 200 örnek kullanıcı hikayesi sunmaktadır [PDF] (Cohn, 2004). Kullanıcı hikayesi gereksiniminin yalnızca "As a . . ." kısmını listelemektedirler.
Ekipteki herhangi biri -veya herhangi bir proje paydaşı- kullanıcı hikayeleri oluşturabilir. Kullanıcı hikayeleri başlangıçta tanımlandıktan sonra, müşteri ve ekipteki diğer kişilerle bir konuşma başlatmak için kullanılabilir. Müşteriler, kullanıcı hikayeleri için öncelikleri belirlemede size rehberlik edebilir. Bu konuşma, karta eklenmesi gereken kullanıcı hikayeleri hakkında daha fazla ayrıntı almak için de iyi bir zamandır.
| Komik derecede kötü kullanıcı hikayelerinden örnekler mi istiyorsunuz? Shit User Story Twitter akışına göz atın (@ShitUserStory) |
İyi bir kullanıcı hikayesi nasıl olur? Bu bölümde daha önce listelenen iyi gereksinimlerin özelliklerinin yanı sıra, INVEST kısaltması (Wake, 2003) iyi kullanıcı hikayelerinin özelliklerini hatırlamanıza yardımcı olabilir:
- (I) Bağımsız: Gereksiz bağımlılıklara sahip değildir veya diğer kullanıcı hikayeleriyle çakışmaz.
- Çakışan iki kullanıcı hikayesi:
- "Yeni bir kullanıcı olarak kayıt olmak istiyorum, böylece …"
- "Yeni bir kullanıcı olarak Google hesabımı kullanarak kaydolmak istiyorum, böylece …"
- Çakışmayan kullanıcı hikayeleri kümesi (ancak bazı kullanıcı hikayelerinin diğerlerinden önce tamamlanması gerekir - sorun değil):
- "Yeni bir kullanıcı olarak kayıt sayfasını görüntülemek istiyorum, böylece …"
- "Yeni bir kullanıcı olarak, Facebook kullanarak kaydolmak istiyorum, böylece …"
- "Yeni bir kullanıcı olarak, Google'ı kullanarak kaydolmak istiyorum, böylece …"
- "Yeni bir kullanıcı olarak, kayıt bilgilerimin saklanmasını istiyorum, böylece …"
- Çakışan iki kullanıcı hikayesi:
- (N) Müzakere edilebilir: Tartışmayı caydırmak yerine teşvik eder ve geliştiricilere esneklik sağlar.
- Tartışmayı teşvik etmez: "Oturum açmış bir kullanıcı olarak siyah veya beyazı seçmek istiyorum, böylece …"
- Tartışmayı teşvik eder: "Oturum açmış bir kullanıcı olarak, birden fazla renk arasından seçim yapmak istiyorum, böylece . . ."
- (V) Değerli: Bir kullanıcı ihtiyacını karşılar.
- Bir kullanıcı ihtiyacını karşılamıyor: "Bir Kurumsal kullanıcı olarak, API uç noktalarını talep ederken eğlenceli bir şeyler yapabilmem için ekranın etrafında küçük bir yarış arabasının dolaşmasını izlemek istiyorum."
- Bir kullanıcı ihtiyacını karşılar: "Bir Kurumsal kullanıcı olarak, API uç noktası taleplerimi içe aktarmak istiyorum, böylece taleplerim daha az zaman alıyor ve daha az yorucu oluyor."
- (E) Tahmin edilebilir: Tahmini bir zaman verilebilir.
- Bir zaman tahmini vermek zor: "Yeni bir kullanıcı olarak, kaydolmak için yeterince teşvik istiyorum, böylece kaydolacağım."
- Tahmin etmesi daha kolay: "Yeni bir kullanıcı olarak, hangi planı seçeceğime karar verebilmek için plan fiyatlarını karşılaştırmak istiyorum."
- (S) Küçük: Tek bir geliştirme dönemine sığabilir (örneğin, iki haftalık bir Sprint)
- Muhtemelen bir Sprint için çok büyük: "Bir kullanıcı olarak, eczanede beklerken yapacak bir şeyim olması için telefonumda satranç oynamak istiyorum."
- Daha küçük: "Bir kullanıcı olarak, satrançta sıramı alabilmek için piyonumu hareket ettirmek istiyorum."
- (T) Test edilebilir: Yapıldığını belirlemek mümkün.
- Yapılıp yapılmadığını belirlemek zor: "Misafir kullanıcı olarak deneyimimden memnun kalmak istiyorum, böylece kaydolmak isteyeceğim."
- Daha az zor: "Misafir bir kullanıcı olarak, abone olup olmayacağıma karar verebilmek için önce kaydolmadan AI metin oluşturucuyu denemek istiyorum."
INVEST ile yukarıda belirtilen iyi gereksinimlerin genel özellikleri arasında bir miktar örtüşme vardır (bu rahatlatıcıdır), ancak INVEST'i hatırlamanın daha kolay olduğunu düşünebilirsiniz.
Bir kullanıcı hikayesinin tamamlandığını nasıl anlarsınız? Bu, müşteri ile müzakere edilir ve kullanıcı hikayesine kabul kriteri olarak eklenir. Kabul kriterleri, kullanıcı hikayesinin tamamlanmış sayılması için kullanıcı hikayesi tarafından belirtilen işlevsellik hakkında neyin doğru olması gerektiğini söyler (yani, kullanıcı hikayesi için Tamamlandı Tanımını oluşturur). Şekil 3.4, Şekil 3.3'teki kullanıcı hikayelerinden birine bir DoD ekler. DoD, verilen-ne zaman-sonra formatını izleyen kabul kriterlerinden oluşur.
| US-023: Yorumları Devre Dışı Bırakma Öncelik: En Yüksek (8) Sprint: 2 Görevlendirildi: Emrah Tuukka Bir yönetici olarak, spam ve dezenformasyonun yayılmasını kontrol edebilmek için yorumları devre dışı bırakmak istiyorum. Yapıldı’nın Tanımı -Kullanıcı bir kullanıcı olarak oturum açtığında, “Ayarlar”a gittiğinde, “Yorumları Devre Dışı Bırak” düğmesi vardır. -Kullanıcı “Ayarlar” sayfasındayken “Yorumları Devre Dışı Bırak” seçeneğini etkinleştirdiğinde, eylemin başarılı olduğunu belirten bir durum mesajı görüntülenir. Mesaj 10 milisaniye içinde görünür. -Kullanıcı “Yorumları Devre Dışı Bırak” seçeneğini etkinleştirdiğinde, bir “Gönderi” sayfasına gittiğinde, “Yorumlar” bölümünde “Yorumlar devre dışı” görünür ve hiçbir yorum gösterilmez. |
Kabul kriterlerinin her birinin tamamlandığı onaylandıktan sonra, kullanıcı hikayesi "TAMAMLANDI" olarak kabul edilebilir.
İdeal olarak, kabul kriterlerinin test edilmesi otomatikleştirilebilir. Şekil 3.5'te bir kabul kriterinin test edilmesi için örnek sözde kod verilmiştir.
| def test_go_to_time(): # given assert os.isWindows(),”Not Windows!” player.open() player.play_video(‘test.mkv’) # when user.send_keyboard_shortcut(“Ctrl-T”) # then assert player.screen.is_showing(GOTOTIME) |
Kullanım Örnekleri
Kullanım senaryoları, işlevsel gereksinimleri belirlemenin daha resmi bir yöntemidir. Bir kullanıcı etkileşime girdiğinde bir sistemin ne yapması gerektiğine dair yapılandırılmış açıklamalardır. Şekil 3.2'de basit bir kullanım senaryosu örneği gösterilmektedir ve kullanım senaryoları ve personalar hakkında Digital.gov Kullanılabilirlik Başlangıç Kiti PDF'sinde ek örnekler bulunabilir (ABD Genel Hizmetler İdaresi, 2014).
Agile'da kullanım senaryoları daha az yaygın olduğundan, bu bölümün geri kalanında kullanım senaryolarının nasıl yapılandırıldığına dair yalnızca bir özet sunulacaktır.
Bir Use Case'in Gerekli Parçaları
Her kullanım senaryosunda aşağıdakiler vardır.
- İsim: Kullanım senaryosu için genellikle bir fiille başlayan kısa bir başlık (örneğin, "Haftalık sağlık kontrolü planla"). Ad, kullanım senaryosunun tanımlayacağı kullanıcı hedefini kısaca belirtir.
- Aktör(ler): Yazılımla etkileşime giren kullanıcı veya kullanıcılar (insan/insan olmayan/bilgisayar) (örneğin, "Sağlık personeli").
- Olayların akışı: Aktör ve yazılım arasındaki etkileşimi tanımlayan eylemler dizisi (diğer bir deyişle "temel hareket tarzı" veya "başarı senaryosu").
Bazen aktör, olayların akışı aracılığıyla ima edilir (örneğin, "Alışveriş yapan kişi takvim simgesini seçer"). Diğer zamanlarda, aktör olay akışından ayrı olarak belirtilir (örneğin, "Aktör: Alışverişçi").
Kullanım Örneğinin Ek Parçaları
Aşağıdakiler bazen kullanım durumlarına dahil edilir.
- Tanımlayıcı: Kullanım örneğine atıfta bulunmanın benzersiz bir yolu (örn. UC-002).
- Ön koşullar: Akıştan önce doğru olması gerekenler (örneğin, "Alışveriş yapan kişi alışveriş sepetine en az bir ürün ekledi").
- Son koşullar: Akıştan sonra doğru olması gerekenler (örneğin, "Müşteri bir sipariş onay e-postası aldı").
- İşle alaka düzeyi: Kullanım senaryosunun neden var olduğuna dair gerekçe.
- Bağımlılıklar: Kullanım senaryosunun dayandığı diğer kullanım senaryoları. Benzersiz tanımlayıcı bu bölüm için kullanışlıdır.
- Uzantılar: Beklenmedik durumlar, alternatif rotalar ve diğer kullanım durumlarına giden dallar.
- Öncelikler: Kullanım durumunun önemi.
- İşlevsel olmayan gereksinimler: Yazılımın akış sırasında ne kadar iyi performans göstermesi gerektiği.
Gereksinim Spesifikasyonu
Gereksinimlerin yazılması sürecine gereksinim spesifikasyonu denir. İsim olarak kullanıldığında gereksinim spesifikasyonu, gereksinimleri içeren belgeyi ifade eder. Bu belge aynı zamanda bir yazılım gereksinimleri spesifikasyonu (SRS) olabilir. SRS'ler hakkında bilgi edinmenin en iyi yolu bazılarına bakmaktır.
| Bazen SRS ile karıştırılan bir başka yazılım belgesi türü de yazılım tasarım belgesidir (SDD). SRS yazılımın ne olması gerektiğini ifade ediyorsa, SDD de yazılımın ne olduğunu ifade eder. Bu iki belge arasında genellikle örtüşme vardır. |
Ücretsiz olarak temin edilebilen SRS örnekleri (bazıları açık kaynak yazılımlar için):
- SRS for apps and a data repository for distributing manufacturing data [PDF] (Hedberg et al., 2017).
- SRS for data system that assesses conservation practices [PDF] (CEAP, 2006).
- SRS for an app that splits and merges PDFs [PDF] (Spyridonos, 2010).
- SRS for software that processes electroencephalography data [PDF] (OpenVIBE, 2018).
- SRS for library software [PDF] (Eaker, 2006).
Bağlantılardan herhangi biri bozuksa Wayback Machine'i deneyin.
Özet
İki ana tür yazılım gereksinimi vardır: işlevsel ve işlevsel olmayan.
İşlevsel gereksinim, "bir sistemin belirli koşullar altında sergileyeceği bir davranışın tanımıdır" (Wiegers & Beatty, 2013, s. 599). İşlevsel gereksinimleri yazmak için verilen-ne zaman-sonra formatı, kullanıcı hikayeleri ve kullanım senaryoları gibi farklı formatlar vardır. Kullanıcı hikayeleri çevik yazılım geliştirmede kullanılır. Kullanıcı hikayesi kabul kriterlerini yazmak için given-when-then formatı kullanılır. Bir kullanıcı hikayesinin tamamlanıp tamamlanmadığını belirlemek için bir dizi kabul kriteri kullanılır ( Tamamlandı Tanımı).
İşlevsel olmayan bir gereksinim "bir sistemin sergilemesi gereken bir özellik veya karakteristiğin ya da uyması gereken bir kısıtlamanın tanımıdır" (Wiegers & Beatty, 2013, s. 600). Kalite nitelikleri ise "yazılımın bir hizmet veya performans özelliğini" tanımlamak için kullanılan kelimelerdir (Wiegers & Beatty, 2013, s. 601).
Doğru, açık, eksiksiz, tutarlı, önem ve/veya istikrar açısından sıralanmış, doğrulanabilir, değiştirilebilir ve izlenebilir olmak gibi iyi bir gereksinimi oluşturan standartlar vardır. INVEST, iyi kullanıcı hikayeleri için standartları hatırlamak için kullanılan bir kısaltmadır: bağımsız, pazarlık edilebilir, değerli, tahmin edilebilir, küçük ve test edilebilir.
Bir SRS hem işlevsel olmayan hem de işlevsel gereksinimleri içerebilir.
Yorumlar
Yorum Gönder