İşlevsel Gereksinimlerin Özellikleri ve İşlevsel Olmayan Gereksinimler

features functional requirements

Bu Eğitici Örneklerle Türleri, Özellikleri, İşlevsel Gereksinimlerle İşlevsel Olmayan Gereksinimleri Karşılaştırmayı ve İşle İşlevsel Gereksinimleri Açıklar:

Fonksiyonel gereksinimler, bir yazılım sisteminin ne yapması gerektiğini tanımlar. Bir yazılım sisteminin veya modülünün bir işlevini tanımlar. İşlevsellik, test edilen sisteme, sistemden çıktıya kadar bir dizi girdi olarak ölçülür.

Bir sistemde işlevsel gereksinim uygulaması Sistem Tasarımı aşamasında planlanırken, işlevsel olmayan gereksinimler olması durumunda Sistem Mimarisi belgesinde planlanır. İşlevsel gereksinim, işlevsel olmayan gereksinimlerin oluşturulmasını destekler.

Ne öğreneceksin:

• İşlevsel Gereksinimler ve İşlevsel Olmayan Gereksinimler
  • İşlevsel gereksinimler
    • İşlevsel Gereksinim Türleri
  • İş Gereksinimleri ve İşlevsel Gereksinimler
  • İşlevsel Olmayan Gereksinim
    • İşlevsel Olmayan Gereksinim Türleri
  • İşlevsel Gereksinimlerden İşlevsel Olmayan Gereksinimlerin Türetilmesi
• Fonksiyonel Vs Fonksiyonel Olmayan Gereksinimler
• Sonuç
  • Önerilen Kaynaklar

İşlevsel Gereksinimler ve İşlevsel Olmayan Gereksinimler

İşlevsel gereksinimler

Örnekler yardımıyla işlevsel gereksinimlerin ne olduğunu anlayalım-

Misal: Bir Otomotiv ADAS projesinde, çevre görüş sistemi işlevsel gereksinimi 'Arka Kamera bir tehdit veya nesneyi algılamalı' olabilir. Buradaki işlevsel olmayan gereksinimler, 'kamera sensörleri tarafından bir tehdit algılandığında bir kullanıcıya verilen uyarının ne kadar hızlı görüntülenmesi gerektiği' olabilir.

Başka al misal Bilgi-eğlence sistemleri projesinin. Kullanıcı burada Bluetooth'u HMI'dan etkinleştirir ve Bluetooth'un etkin olup olmadığını kontrol eder. Not , diğer Bluetooth hizmetleri, kullanıcı Bluetooth'u etkinleştirdiğinde etkinleştirilir (griden koyu renge).

varsayılan ağ geçidi sürekli olarak kullanılamaz

Dolayısıyla, işlevsel gereksinimler, kullanıcı tarafından üzerlerinde bir görev gerçekleştirildiğinde belirli bir sistem sonucundan bahseder. Öte yandan, işlevsel olmayan gereksinim, sistemin veya bileşeninin genel davranışını verir ve işlev üzerinde değildir.

İşlevsel Gereksinim Türleri

Fonksiyonel gereksinimler, fonksiyonel testin bir parçası olarak ölçülebilen aşağıdaki bileşenleri içerebilir:

# 1) Birlikte Çalışabilirlik: Gereksinim, bir yazılım sisteminin farklı sistemler arasında birlikte çalışıp çalışmadığını açıklar.

Misal: Araç bilgi-eğlence sistemindeki Bluetooth işlevsel gereksinimi için, kullanıcı Bluetooth özellikli Android tabanlı bir Akıllı Telefonu QNX tabanlı bilgi-eğlence sistemine eşleştirdiğinde, Telefon Rehberini bilgi-eğlence sistemine aktarabilmeli veya Telefon cihazımızdan bilgi-eğlence sistemine müzik akışı yapabilmeliyiz.

Böylece birlikte çalışabilirlik, iki farklı cihaz arasında iletişimin mümkün olup olmadığını kontrol eder.

Bir diğeri misal Gmail gibi e-posta hizmet sistemlerindendir. Gmail, Yahoo.com veya Rediffmail.com gibi başka bir posta değişim sunucusundan e-postaların içe aktarılmasına izin verir. Bu, e-posta sunucuları arasındaki birlikte çalışabilirlik nedeniyle mümkündür.

# 2) Güvenlik: İşlevsel gereksinim, yazılım gereksinimlerinin güvenlik yönünü açıklar.

Misal: Sistemi güvenlik tehdidinden koruyan Denetleyici Alan Ağını (CAN) kullanan ADAS çevre görüş kamerası tabanlı sistemdeki siber Güvenlik tabanlı hizmetler.

Bir diğeri misal Facebook sosyal ağ sitesinden . Bir kullanıcının verileri güvenli olmalı ve dışarıdan birine sızdırılmamalıdır. Bu Facebook örneğinin, Facebook'taki son veri ihlali vakası ve Facebook'un karşılaştığı sonuçlar nedeniyle okuyuculara daha geniş bir güvenlik alanı sağladığını umuyoruz.

# 3) Doğruluk: Doğruluk, sisteme girilen bir verinin doğru hesaplanıp sistem tarafından kullanıldığını ve çıktının doğru olduğunu ifade eder.

Misal: Kontrolör Alan Ağında, bir CAN sinyal değeri bir ECU (yani ABS ünitesi, HVAC ünitesi, Alet kümesi ünitesi vb.) Tarafından CAN veriyolu üzerinden iletildiğinde, başka bir ECU gönderilen verilerin doğru olup olmadığını belirleyebilecektir. CRC kontrolü yoluyla.

Bir diğeri misal bir çevrimiçi bankacılık çözümünden olabilir. Kullanıcı bir fon aldığında, alınan miktar tam olarak hesaba yatırılmalıdır ve doğrulukta hiçbir değişiklik kabul edilmez.

# 4) Uyum: Uyumluluk fonksiyonel gereksinimleri, geliştirilen sistemin Endüstriyel standartlarla uyumlu olduğunu doğrular.

Misal: Bluetooth profilleri işlevlerinin (A2DP aracılığıyla ses akışı, HFP aracılığıyla telefon görüşmesi) Bluetooth SIG sürüm profili sürümleriyle uyumlu olup olmadığı.

Bir diğeri misal Araba bilgi-eğlence sistemindeki Apple Car oyunu olabilir. Bilgi-eğlence sistemindeki Uygulama, elma Apple web sitesinde belirtilen tüm ön koşullar üçüncü taraf Car Play cihazları tarafından yerine getirilmişse (bu durumda bilgi-eğlence).

Bir diğeri misal demiryolu bilet sistemi için Web tabanlı bir uygulamadan olabilir. Web sitesi, siber güvenlik kurallarına uymalı ve erişilebilirlik açısından World Wide Web ile uyumlu olmalıdır.

Gereksinim formu örneği:

Bazı örneklerle fonksiyonel gereksinimin ne olduğunu zaten gördük. Şimdi, IBM DOORS gibi gereksinim yönetimi araçlarına entegre edildiğinde işlevsel bir gereksinimin nasıl görüneceğini görelim. Gereksinim yönetimi aracında işlevsel bir gereksinimi belgelerken dikkate alınması gereken birden çok özellik vardır.

Aşağıda dikkate alınması gereken birkaç özellik bulunmaktadır:

1. Nesne türü: Bu öznitelik, gereksinim belgesinin hangi bölümünün bu özniteliğin parçası olduğunu açıklar. Bunlar Başlık, Açıklama, Gereksinim vb. Olabilir. Daha çok 'Gereksinim' bölümü uygulama ve test için değerlendirilirken, başlık ve açıklama bölümleri daha iyi anlaşılması için gereksinimler için destekleyici açıklamalar olarak kullanılır.
2. Sorumluluk sahibi kişi: Gereksinim yönetimi aracındaki gereksinimi belgeleyen bir yazar.
3. Proje / Sistem adı: İhtiyacın geçerli olduğu proje, Örneğin, 'XYZ OEM (Orijinal Ekipman Üreticisi) için Bilgi-Eğlence Sistemleri bir otomotiv şirketi veya ABC bankacılık limited şirketi için Web uygulaması'.
4. Gereksinim sürüm numarası: Bu alan / özellik, gereksinim, müşteri güncellemeleri veya sistem tasarımındaki değişiklikler nedeniyle birden fazla değişikliğe uğramışsa, gereksinimin sürüm numarasını bildirir.
5. Gereksinim Kimliği: Bu özellik, benzersiz gereksinim kimliğinden bahseder. Gereksinim Kimliği, veri tabanındaki ihtiyaçların kolayca izlenmesinde ve ayrıca koddaki gereksinimlerin verimli bir şekilde haritalanmasında kullanılır. Hata izleme araçlarındaki kusurları günlüğe kaydederken gereksinimlere bir referans sağlamak için de kullanılabilir.
6. Gereksinim açıklaması: Bu özellik, gereksinimi açıklayan en önemli özelliklerden biridir. Bu özelliği okuyarak, bir mühendis gereksinimi anlayabilir.
7. Gereksinim durumu: Gereksinim durumu özniteliği, gereksinim yönetimi aracındaki bir gereksinimin durumunu, yani projenin kabul edilip edilmediğini, beklemede mi, reddedildiğini veya silindiğini söyler.
8. Yorumlar: Bu özellik, Sorumlu kişiye veya gereksinim yöneticisine, gereksinimle ilgili herhangi bir yorumu belgeleme seçeneği sunar. Misal: işlevsel bir gereksinim için olası bir yorum, 'gereksinimi uygulamak için üçüncü taraf bir yazılım paketine bağımlılık' olabilir.

DOORS'dan bir anlık görüntü

İş Gereksinimlerinden İşlevsel Gereksinimleri Türetme

Bu zaten bölümün bir parçası olarak ele alınmıştır ' İş gereksinimlerinden İşlevsel gereksinimleri türetme ' altında İhtiyaç analizi makale.

İş Gereksinimleri ve İşlevsel Gereksinimler

Bu fark, İhtiyaç analizi makale. Bununla birlikte, deneyeceğiz aşağıdaki tabloda birkaç noktayı daha vurgulayın:

İşlevsel Olmayan Gereksinim

İşlevsel olmayan gereksinim, 'bir sistemin ne yapması gerektiğinden' (işlevsel gereksinim) ziyade 'bir sistemin ne olması gerektiği' hakkında söyler. Çoğunlukla müşteriden ve diğer paydaşlardan gelen girdilere dayanan işlevsel gereksinimlerden türetilirler. İşlevsel olmayan gereksinim uygulama ayrıntıları, Sistem Mimarisi belgesinde belgelenmiştir.

İşlevsel olmayan gereksinimler, inşa edilecek sistemin kalite yönlerini açıklamaktadır. performans, taşınabilirlik, kullanılabilirlik vb. İşlevsel olmayan gereksinimler, işlevsel gereksinimlerin aksine, herhangi bir sistemde aşamalı olarak uygulanır.

URPS (Kullanılabilirlik, Güvenilirlik, Performans ve Desteklenebilirlik) KÜRKLER Bir yazılım geliştiricisinin kalitesini ölçmek için BT endüstrisinde yaygın olarak kullanılan (İşlevsellik, Kullanılabilirlik, Güvenilirlik, Performans ve Desteklenebilirlik) kalite özelliklerinin tümü, işlevsel olmayan gereksinimler kapsamındadır. Ayrıca, başka kalite özellikleri de vardır (ayrıntılar bir sonraki bölümde).

Wikipedia, taşınabilirlik ve kararlılık gibi çeşitli kalite özelliklerinin varlığı nedeniyle bazen işlevsel olmayan gereksinimi 'hastalıklar' olarak adlandırır.

İşlevsel Olmayan Gereksinim Türleri

İşlevsel olmayan gereksinimler aşağıdaki alt türlerden oluşur (kapsamlı olmayan):

# 1) Performans:

İşlevsel olmayan gereksinimin performans özniteliği türü, sistem performansını ölçer. Misal: ADAS çevre görüş sisteminde, 'arka kamera görüntüsü Araç kontağı başlatıldıktan sonra 2 saniye içinde gösterilmelidir'.

Bir diğeri misal performans bir bilgi-eğlence sistemi Navigasyon sisteminden olabilir. “Bir kullanıcı Navigasyon ekranına gittiğinde ve varış noktasına girdiğinde rota“ X ”saniye” içinde hesaplanmalıdır. Bir tane daha misal web uygulaması oturum açma sayfasından. 'Oturum açtıktan sonra kullanıcı profili sayfasının yüklenmesi için geçen süre.'

Lütfen sistem performans ölçümünün yük ölçümünden farklı olduğunu unutmayın. Yük testi sırasında, sistem CPU'sunu ve RAM'ini yükleriz ve sistem verimini kontrol ederiz. Performans durumunda, sistem verimini normal yük / stres koşullarında test ediyoruz.

# 2) Kullanılabilirlik :

Kullanılabilirlik, geliştirilmekte olan yazılım sisteminin kullanılabilirliğini ölçer.

Örneğin , tesisatçılar ve elektrikçinin bölgenizdeki mevcudiyeti hakkında size bilgi veren bir mobil web uygulaması geliştirildi.

Bu uygulamaya giriş, geçerli konumunuzdan posta kodu ve yarıçaptır (kilometre cinsinden). Ancak bu verileri girmek için, kullanıcının birden fazla ekrana göz atması gerekiyorsa ve veri girişi seçeneği, bir kullanıcı tarafından hemen görülemeyen küçük metin kutularında görüntüleniyorsa, bu uygulama kullanıcı dostu değildir ve dolayısıyla uygulamanın kullanılabilirliği Çok düşük.

# 3) Sürdürülebilirlik :

Bir yazılım sisteminin sürdürülebilirliği, sistemin sürdürülme kolaylığıdır. Geliştirilen sistem için Arızalar Arasındaki Ortalama Süre (MTBF) düşükse veya Ortalama Onarım Süresi (MTTR) yüksekse, sistemin bakımının düşük olduğu kabul edilir.

Sürdürülebilirlik genellikle Siklomatik karmaşıklık kullanılarak kod düzeyinde ölçülür. Siklomatik karmaşıklık, kod ne kadar az karmaşıksa, yazılımı korumanın o kadar kolay olduğunu söylüyor.

Misal: Çok sayıda ölü kod içeren (diğer işlevler veya modüller tarafından kullanılmayan kodlar), if / else koşulunun aşırı kullanımı, iç içe döngüler vb. Nedeniyle oldukça karmaşık olan veya sistem çalışan kodlarla çok büyükse bir yazılım sistemi geliştirilmiştir. milyonlarca satır kod ve uygun yorum yok. Böyle bir sistemin bakımı düşüktür.

Bir diğeri misal çevrimiçi alışveriş web sayfası olabilir. Web sitesinde, kullanıcının ürüne genel bir bakış elde edebilmesi için birçok harici bağlantı varsa (bu, bellekten tasarruf etmek için), bu web sitesinin sürdürülebilirliği düşüktür. Bunun nedeni, harici web sayfası bağlantısı değişirse, çevrimiçi alışveriş sitesinde de ve çok sık güncellenmesi gerekmesidir.

# 4) Güvenilirlik :

Güvenilirlik, kullanılabilirliğin başka bir yönüdür. Bu kalite özelliği, bir sistemin belirli koşullar altında kullanılabilirliğini vurgular. Bakım kolaylığı gibi MTBF olarak ölçülür.

Misal: ADAS çevre görüş kamerası sistemindeki arka görüş kamerası ve Treyler gibi birbirini dışlayan özellikler, birbirleriyle herhangi bir girişim olmadan sistemde güvenilir bir şekilde çalışmalıdır. Bir kullanıcı Römork özelliğini çağırdığında, her iki özellik de aracın arka kamerasına eriştiği için arka görüş engellememelidir ve bunun tersi de geçerlidir.

Bir diğeri misal çevrimiçi sigorta talep sisteminden. Bir kullanıcı talep raporlamaya başladığında ve ardından ilgili gider faturalarını yüklediğinde, sistem yüklemenin tamamlanması için yeterli zaman vermeli ve yükleme işlemini hızlı bir şekilde iptal etmemelidir.

# 5) Taşınabilirlik:

windows yazılım onarım aracı windows 10

Taşınabilirlik, temelde yatan bağımlı çerçeve aynı kalırsa, bir yazılım sisteminin farklı bir ortamda çalışabilmesi anlamına gelir.

Misal: Bir otomotiv otomobil üreticisi için geliştirilen bir bilgi-eğlence sistemindeki (yani Bluetooth hizmeti veya multimedya hizmeti) yazılım sistemi / bileşeni, iki bilgi-eğlence sistemi tamamen farklı olmasına rağmen, kodda çok az değişiklik olan veya hiç değişiklik yapılmadan başka bir bilgi-eğlence sisteminde kullanılmasına izin vermelidir. .

Başka alalım misal WhatsApp'tan. Mesajlaşma servisini IOS, Android, Windows, Tablet, Dizüstü Bilgisayar ve Telefona yüklemek ve kullanmak mümkündür.

# 6) Desteklenebilirlik:

Bir yazılım sisteminin servis kolaylığı, bir servis / teknik uzmanın yazılım sistemini gerçek zamanlı bir ortamda kurma, sistemi çalışırken izleme, sistemdeki teknik sorunları belirleme ve sorunu çözmek için bir çözüm sağlama becerisidir.

Servis kolaylığı sağlamak için sistem geliştirilmişse servis kolaylığı mümkündür.

Misal: Kullanıcıya bir yazılım güncellemesi için periyodik hatırlatıcı açılır penceresinin sağlanması, sorunların giderilmesi için günlük / izleme mekanizması sağlanması, geri alma mekanizması aracılığıyla arızadan otomatik kurtarma (yazılım sistemini önceki çalışma durumuna geri alma).

Bir diğeri misal itibaren Rediffmail. Web tabanlı posta hizmetinin sürümünde bir güncelleme olduğunda, sistem, kullanıcının posta sisteminin daha yeni bir sürümüne geçmesine izin verdi ve eskisini birkaç ay boyunca sağlam tuttu. Bu, kullanıcı deneyimini de geliştirir.

# 7) Uyarlanabilirlik:

Bir sistemin uyarlanabilirliği, bir yazılım sisteminin davranışında herhangi bir değişiklik olmaksızın bir ortamdaki değişime uyum sağlama yeteneği olarak tanımlanır.

Misal: Araçta Kilitlenmez Fren Sistemi, her türlü hava koşulunda (sıcak veya soğuk) standart olarak çalışmalıdır. Bir diğeri misal bir Android işletim sistemi olabilir. Farklı cihaz türlerinde, yani. Akıllı telefonlar, Tablet bilgisayarlar ve Bilgi-Eğlence sistemleri ve son derece uyarlanabilir.

Yukarıda listelenen 7 işlevsel olmayan gereksinime ek olarak, aşağıdakiler gibi birçok başka gereksinime sahibiz:

Erişilebilirlik, Yedekleme, Kapasite, Uyumluluk, Veri bütünlüğü, Veri saklama, Bağımlılık, Dağıtım, Dokümantasyon, Dayanıklılık, Verimlilik, Yararlanma, Genişletilebilirlik, Hata yönetimi, Hata toleransı, Birlikte çalışabilirlik, Değiştirilebilirlik, Çalışabilirlik, Gizlilik, Okunabilirlik, Raporlama, Esneklik, Yeniden Kullanılabilirlik, Sağlamlık, Ölçeklenebilirlik, Kararlılık, Test Edilebilirlik, Verimlilik, Şeffaflık, Bütünleştirilebilirlik.

Tüm bu işlevsel olmayan gereksinimleri karşılamak bu makalenin kapsamı dışındadır. Bununla birlikte, bu işlevsel olmayan gereksinim türleri hakkında daha fazla bilgiyi şurada okuyabilirsiniz: Wikipedia.

İşlevsel Gereksinimlerden İşlevsel Olmayan Gereksinimlerin Türetilmesi

İşlevsel olmayan gereksinimler birçok yoldan türetilebilir, ancak en iyi ve çoğu endüstrinin denenip test edilen yolu işlevsel gereksinimlerdir.

Bu makalede daha önce birkaç yerde ele aldığımız Bilgi-Eğlence sistemlerimizden bir örnek alalım. Kullanıcı Bilgi ve Eğlence sisteminde birçok eylem gerçekleştirebilir, yani. şarkıyı değiştirin, şarkı kaynağını USB'den FM veya Bluetooth sese değiştirin, Navigasyon hedefini ayarlayın, bilgi-eğlence yazılımını bir yazılım güncellemesiyle güncelleyin, vb.

# 1) İşlevsel olmayan gereksinimlerin toplanması:

İşlevsel gereksinimlerin bir parçası olan bir kullanıcı tarafından gerçekleştirilen görevleri listeleyeceğiz. Kullanıcı eylemleri UML kullanım durumu şemasında (her oval) not edildikten sonra, her kullanıcının eylemiyle ilgili sorulara (her dikdörtgen) başlayacağız. Bu soruların yanıtları işlevsel olmayan gereksinimlerimizi sağlayacaktır.

# 2) İşlevsel olmayan gereksinimlerin sınıflandırılması:

Bir sonraki adım, sorularla belirlediğimiz işlevsel olmayan gereksinimlerin sınıflandırılmasıdır. Bu aşamada, olası yanıtı kontrol edebilir ve olası işlevsel olmayan kategorilere veya farklı niteliklere yanıtları kategorize edebiliriz.

Aşağıdaki resimde, cevaplardan belirlenen olası kalite niteliklerini görebilirsiniz.

Fonksiyonel Vs Fonksiyonel Olmayan Gereksinimler

İşlevsel ve işlevsel olmayan gereksinimlerin ne olduğunu ve bunların nasıl türetildiğini zaten görmüştük. İşlevsel ve işlevsel olmayan gereksinimler arasındaki temel farklılıklara bir göz atalım.

Sonuç

Gereksinimler, herhangi bir yazılım sistemi geliştirmek için temel yapı taşını oluşturur. Fonksiyonel gereksinimleri olan bir sistem kurmak mümkündür ancak yetenekleri belirlenemez ve ölçülemez. Bununla birlikte, yüksek kalitede çalışan bir yazılım sistemine sahip olmak için bir iş gereksiniminden türetilen kaliteli işlevsel gereksinimlere sahip olmak çok önemlidir.

Dolayısıyla, işlevsel gereksinimler bir yazılım sisteminin uygulanmasına yön verir, ancak işlevsel olmayan gereksinimler, son kullanıcıların deneyimleyeceği uygulama kalitesini belirler.

Önerilen Kaynaklar

• Yazılım Gereksinimleri Spesifikasyonu (SRS) Nasıl Test Edilir?
• Fonksiyonel Test ve Fonksiyonel Olmayan Test
• Gereksinimler Olmadan Bir Uygulama Nasıl Test Edilir?
• SDLC'de Gereksinim Analizi ve Toplama Nedir?
• Gereksinim Yönetiminde 5 Ölümcül Hata ve Bunların Üstesinden Gelme
• İşlevsel Gereksinimlerin Özellikleri ve İşlevsel Olmayan Gereksinimler
• Gereksinimler İzlenebilirlik Matrisi (RTM) Nasıl Oluşturulur: Örnek ve Örnek Şablon
• İlk 20'den Fazla En İyi Gereksinim Yönetim Aracı (Tam Liste)