yazılım gereksinimleri

Yazılım gereksinimleri, hedef sistemin özelliklerinin ve işlevlerinin açıklamalarıdır. Gereksinimler, kullanıcıların yazılım ürününden beklentilerini iletir. Gereksinimler açık veya gizli, bilinen veya bilinmeyen, müşterinin bakış açısından beklenen veya beklenmeyen olabilir.

Gereksinim Mühendisliği

Yazılım gereksinimlerini müşteriden toplama, analiz etme ve belgeleme süreci, gereksinim mühendisliği olarak bilinir.

Gereksinim mühendisliğinin amacı, sofistike ve açıklayıcı 'Sistem Gereksinimleri Belirtimi' belgesini geliştirmek ve sürdürmektir.

Gereksinim Mühendislik Süreci

Bu, aşağıdakileri içeren dört adımlı bir süreçtir:

Fizibilite çalışması
Şartlı toplantı
Yazılım Gereksinimi Özellikleri
Yazılım Gereksinim Doğrulaması

Süreci kısaca görelim -

Fizibilite çalışması

Müşteri, istenen ürünü geliştirmek için kuruluşa yaklaştığında, yazılımın tüm işlevlerini yerine getirmesi gerektiği ve yazılımdan hangi özelliklerin beklendiği konusunda kabaca bir fikir ortaya çıkar.

Analistler, bu bilgilere başvurarak, istenen sistemin ve onun işlevselliğinin geliştirilmesinin uygun olup olmadığı hakkında ayrıntılı bir çalışma yapar.

Bu fizibilite çalışması, organizasyonun amacına odaklanmıştır. Bu çalışma, yazılım ürününün uygulama, projenin organizasyona katkısı, maliyet kısıtlamaları ve organizasyonun değer ve hedeflerine göre pratik olarak gerçekleştirilip gerçekleştirilemeyeceğini analiz etmektedir. Kullanılabilirlik, sürdürülebilirlik, üretkenlik ve entegrasyon yeteneği gibi proje ve ürünün teknik yönlerini araştırır.

Bu aşamanın çıktısı, projenin üstlenilip üstlenilmemesi konusunda yönetim için yeterli yorum ve tavsiyeleri içermesi gereken bir fizibilite çalışması raporu olmalıdır.

Şartlı toplantı

Fizibilite raporu projeyi üstlenmeye yönelik olumlu ise, sonraki aşama kullanıcıdan gereksinimlerin alınmasıyla başlar. Analistler ve mühendisler, yazılımın ne sağlaması gerektiği ve yazılımın hangi özellikleri içermesini istedikleri konusundaki fikirlerini öğrenmek için müşteri ve son kullanıcılarla iletişim kurar.

Yazılım Gereksinimi Özellikleri

SRS, ihtiyaçlar çeşitli paydaşlardan toplandıktan sonra sistem analisti tarafından oluşturulan bir belgedir.

SRS, amaçlanan yazılımın donanım, harici arayüzler, çalışma hızı, sistemin yanıt süresi, yazılımın çeşitli platformlarda taşınabilirliği, bakım kolaylığı, çökme sonrası kurtarma hızı, Güvenlik, Kalite, Sınırlamalar vb. İle nasıl etkileşime gireceğini tanımlar.

Müşteriden alınan talepler doğal dilde yazılmıştır. Yazılım geliştirme ekibi tarafından anlaşılabilmeleri ve faydalı olabilmeleri için gereksinimleri teknik dilde belgelemek sistem analistinin sorumluluğundadır.

SRS aşağıdaki özelliklerle gelmelidir:

Kullanıcı Gereksinimleri doğal dilde ifade edilir.
Teknik gereksinimler, organizasyon içinde kullanılan yapılandırılmış bir dille ifade edilir.
Tasarım açıklaması Pseudo kod ile yazılmalıdır.
Form Formatı ve GUI ekran baskıları.
DFD'ler vb. İçin koşullu ve matematiksel gösterimler

Yazılım Gereksinim Doğrulaması

Gereksinim özellikleri geliştirildikten sonra, bu belgede belirtilen gereksinimler doğrulanır. Kullanıcı yasa dışı, pratik olmayan çözüm isteyebilir veya uzmanlar gereksinimleri yanlış yorumlayabilir. Bu, başlangıçta engellenmezse maliyette büyük artışla sonuçlanır. Gereksinimler aşağıdaki koşullara göre kontrol edilebilir -

Pratik olarak uygulanabilirse
Geçerliyse ve yazılımın işlevselliği ve etki alanına göre
Herhangi bir belirsizlik varsa
Eğer tamamlanmışlarsa
Gösterilebilirlerse

Gereksinim Ortaya Çıkarma Süreci

Gereksinim belirleme süreci aşağıdaki diyagram kullanılarak gösterilebilir:

Requirements gathering - Geliştiriciler, müşteri ve son kullanıcı ile tartışır ve yazılımdan beklentilerini bilir.
Organizing Requirements - Geliştiriciler, gereksinimleri önem, aciliyet ve uygunluk sırasına göre önceliklendirir ve düzenler.
Negotiation & discussion - Gereksinimler belirsizse veya çeşitli paydaşların gereksinimlerinde bazı çatışmalar varsa, öyleyse, paydaşlarla müzakere edilir ve tartışılır. Gereksinimler daha sonra önceliklendirilebilir ve makul ölçüde tehlikeye atılabilir.

Gereksinimler çeşitli paydaşlardan gelir. Belirsizliği ve çatışmaları ortadan kaldırmak için açıklık ve doğruluk için tartışılırlar. Gerçekçi olmayan gereksinimler makul bir şekilde tehlikeye atılır.
Documentation - Tüm resmi ve gayri resmi, işlevsel ve işlevsel olmayan gereksinimler belgelenir ve bir sonraki aşama işleme için hazır hale getirilir.

Gereksinim Ortaya Çıkarma Teknikleri

Gereksinimler Ortaya Çıkarma, müşteri, son kullanıcılar, sistem kullanıcıları ve yazılım sistemi geliştirmede payı olan diğer kişilerle iletişim kurarak amaçlanan bir yazılım sistemi için gereksinimleri bulma sürecidir.

Gereksinimleri keşfetmenin çeşitli yolları vardır

Mülakatlar

Mülakatlar, gereksinimleri toplamak için güçlü bir araçtır. Kuruluş, aşağıdakiler gibi birkaç tür görüşme yapabilir:

Toplanacak her bir bilginin önceden kararlaştırıldığı yapılandırılmış (kapalı) görüşmeler, düzeni ve tartışma konusunu sıkı bir şekilde takip ederler.
Toplanacak bilgilerin önceden kararlaştırılmadığı, daha esnek ve daha az önyargılı olduğu yapılandırılmamış (açık) görüşmeler.
Sözlü görüşmeler
Yazılı görüşmeler
Masanın karşısında iki kişi arasında yapılan bire bir görüşmeler.
Katılımcı grupları arasında yapılan grup görüşmeleri. İşin içinde çok sayıda insan olduğu için eksik gereksinimleri ortaya çıkarmaya yardımcı olurlar.

Anketler

Kuruluş, gelecek sistemden beklentilerini ve gereksinimlerini sorgulayarak çeşitli paydaşlar arasında anketler yapabilir.

Anketler

Önceden tanımlanmış nesnel sorular ve ilgili seçenekler içeren bir belge, toplanıp derlenen yanıtlamaları için tüm paydaşlara verilir.

Bu tekniğin bir dezavantajı, ankette bazı konular için bir seçenek belirtilmezse, sorunun gözetimsiz bırakılabilmesidir.

Görev Analizi

Mühendis ve geliştiricilerden oluşan ekip, yeni sistemin gerekli olduğu operasyonu analiz edebilir. Müşterinin belirli bir işlemi gerçekleştirmek için halihazırda bir yazılımı varsa, incelenir ve önerilen sistemin gereksinimleri toplanır.

Alan Analizi

Her yazılım bazı alan kategorilerine girer. Alandaki uzman kişiler, genel ve özel gereksinimleri analiz etmek için çok yardımcı olabilir.

Beyin fırtınası

Çeşitli paydaşlar arasında gayri resmi bir tartışma yapılır ve tüm girdileri daha ileri gereksinim analizi için kaydedilir.

Prototipleme

Prototip oluşturma, kullanıcının amaçlanan yazılım ürününün özelliklerini yorumlaması için ayrıntı işlevselliği eklemeden kullanıcı arayüzü oluşturmaktır. Gereksinimler hakkında daha iyi fikir vermeye yardımcı olur. Müşterinin sonunda geliştiricinin referansı için kurulu bir yazılım yoksa ve müşteri kendi gereksinimlerinin farkında değilse, geliştirici başlangıçta belirtilen gereksinimleri temel alan bir prototip oluşturur. Prototip müşteriye gösterilir ve geri bildirim not edilir. Müşteri geri bildirimi, gereksinim toplama için bir girdi görevi görür.

Gözlem

Uzmanlardan oluşan ekip, müşterinin organizasyonunu veya işyerini ziyaret eder. Mevcut kurulu sistemlerin fiili çalışmasını gözlemlerler. İş akışını müşterinin sonunda ve yürütme sorunlarının nasıl ele alındığını gözlemlerler. Ekibin kendisi, yazılımdan beklenen gereksinimleri oluşturmaya yardımcı olan bazı sonuçlar çıkarır.

Yazılım Gereksinimlerinin Özellikleri

Yazılım gereksinimlerinin toplanması, tüm yazılım geliştirme projesinin temelidir. Bu nedenle açık, doğru ve iyi tanımlanmış olmalıdırlar.

Tam bir Yazılım Gereksinimi Spesifikasyonu şöyle olmalıdır:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Güvenilir kaynak

yazılım gereksinimleri

Gereksinim belirleme aşamasında ne tür gereksinimlerin ortaya çıkabileceğini ve yazılım sisteminden ne tür gereksinimler beklendiğini anlamaya çalışmalıyız.

Genel olarak yazılım gereksinimleri iki kategoriye ayrılmalıdır:

İşlevsel gereksinimler

Yazılımın işlevsel yönüyle ilgili gereksinimler bu kategoriye girer.

Yazılım sistemi içindeki ve yazılım sisteminden işlevleri ve işlevselliği tanımlarlar.

Örnekler -

Kullanıcıya çeşitli faturalardan arama yapma imkanı verilen arama seçeneği.
Kullanıcı herhangi bir raporu yönetime postalayabilmelidir.
Kullanıcılar gruplara ayrılabilir ve gruplara ayrı haklar verilebilir.
İş kurallarına ve idari işlevlere uymalıdır.
Yazılım, aşağı doğru uyumluluğu sağlam tutarak geliştirilmiştir.

İşlevsel Olmayan Gereksinimler

Yazılımın işlevsel yönüyle ilgili olmayan gereksinimler bu kategoriye girer. Yazılımın, kullanıcıların varsaydığı, örtük veya beklenen özellikleridir.

İşlevsel olmayan gereksinimler şunları içerir:

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Felaket kurtarma
Accessibility

Gereksinimler mantıksal olarak şu şekilde kategorize edilir:

Must Have : Yazılımlar olmadan çalışır durumda olduğu söylenemez.
Should have : Yazılımın işlevselliğini geliştirmek.
Could have : Yazılım, bu gereksinimlerle hala düzgün bir şekilde çalışabilir.
Wish list : Bu gereksinimler, herhangi bir yazılım hedefiyle eşleşmez.

Yazılım geliştirirken 'Olmalı' uygulanmalıdır, 'Olmalı' paydaşlarla tartışma ve olumsuzluk konusudur, oysa 'olabilir' ve 'dilek listesi' yazılım güncellemeleri için tutulabilir.

Kullanıcı Arayüzü gereksinimleri

UI, herhangi bir yazılımın veya donanımın veya hibrit sistemin önemli bir parçasıdır. Bir yazılım yaygın olarak kabul edilir:

kullanımı kolay
hızlı yanıt
operasyonel hataların etkin bir şekilde ele alınması
basit ama tutarlı bir kullanıcı arayüzü sağlamak

Kullanıcı kabulü, büyük ölçüde kullanıcının yazılımı nasıl kullanabileceğine bağlıdır. Kullanıcıların sistemi algılamasının tek yolu UI'dir. İyi performans gösteren bir yazılım sistemi ayrıca çekici, net, tutarlı ve duyarlı bir kullanıcı arayüzü ile donatılmalıdır. Aksi takdirde yazılım sisteminin işlevleri rahat bir şekilde kullanılamaz. Bir sistemin verimli bir şekilde kullanılması için araçlar sağlıyorsa iyi olduğu söylenir. Kullanıcı arayüzü gereksinimleri aşağıda kısaca belirtilmiştir -

İçerik sunumu
Kolay Gezinme
Basit arayüz
Responsive
Tutarlı UI öğeleri
Geribildirim mekanizması
Varsayılan ayarları
Amaca yönelik düzen
Renk ve dokunun stratejik kullanımı.
Yardım bilgileri sağlayın
Kullanıcı merkezli yaklaşım
Grup bazlı görünüm ayarları.

Yazılım Sistem Analisti

Bir BT organizasyonundaki sistem analisti, önerilen sistemin gerekliliğini analiz eden ve gereksinimlerin doğru ve doğru bir şekilde tasarlanmasını ve belgelendirilmesini sağlayan kişidir. Bir analistin rolü, SDLC'nin Yazılım Analizi Aşamasında başlar. Geliştirilen yazılımın müşterinin gereksinimlerini karşıladığından emin olmak analistin sorumluluğundadır.

Sistem Analistleri aşağıdaki sorumluluklara sahiptir:

Amaçlanan yazılımın gereksinimlerini analiz etmek ve anlamak
Projenin organizasyon hedeflerine nasıl katkıda bulunacağını anlamak
Gereksinim kaynaklarını belirleyin
Gereksinimin doğrulanması
İhtiyaç yönetimi planı geliştirin ve uygulayın
İş, teknik, süreç ve ürün gereksinimlerinin dokümantasyonu
Gereksinimlere öncelik vermek ve belirsizliği ortadan kaldırmak için müşterilerle koordinasyon
Müşteri ve diğer paydaşlar ile kabul kriterlerinin tamamlanması

Yazılım Metrikleri ve Önlemleri

Yazılım Ölçüleri, yazılımın çeşitli niteliklerini ve yönlerini ölçmek ve simgelemek için bir süreç olarak anlaşılabilir.

Yazılım Ölçütleri, yazılım sürecinin ve yazılım ürününün çeşitli yönleri için önlemler sağlar.

Yazılım önlemleri, yazılım mühendisliğinin temel gereksinimidir. Yalnızca yazılım geliştirme sürecini kontrol etmeye yardımcı olmakla kalmaz, aynı zamanda nihai ürünün kalitesini mükemmel tutmaya da yardımcı olurlar.

Bir (Yazılım Mühendisi) olan Tom DeMarco'ya göre, "Ölçemediğiniz şeyi kontrol edemezsiniz." Onun sözüyle, yazılım önlemlerinin ne kadar önemli olduğu çok açık.

Bazı yazılım ölçütlerini görelim:

Size Metrics - Çoğunlukla teslim edilen binlerce kaynak kodu satırında hesaplanan LOC (Kod Satırları) KLOC olarak adlandırılır.

Function Point Count, yazılım tarafından sağlanan işlevselliğin ölçüsüdür. İşlev Nokta sayısı, yazılımın işlevsel yönünün boyutunu tanımlar.
Complexity Metrics - McCabe'nin Siklomatik karmaşıklığı, programın veya modüllerinin karmaşıklığı olarak algılanan bir programdaki bağımsız yolların sayısının üst sınırını ölçer. Kontrol akış grafiği kullanılarak grafik teorisi kavramları ile temsil edilir.
Quality Metrics - Kusurlar, türleri ve nedenleri, sonuçları, ciddiyet yoğunluğu ve sonuçları ürünün kalitesini tanımlar.

Ürün müşteri tarafında kurulduktan veya teslim edildikten sonra geliştirme sürecinde bulunan kusurların sayısı ve müşteri tarafından bildirilen kusurların sayısı, ürünün kalitesini tanımlar.
Process Metrics - SDLC'nin çeşitli aşamalarında, kullanılan yöntemler ve araçlar, şirket standartları ve geliştirme performansı, yazılım süreci metrikleridir.
Resource Metrics - Kullanılan çaba, zaman ve çeşitli kaynaklar, kaynak ölçümü için ölçütleri temsil eder.