Yazılım geliştirme sürecinin gereksinimler aşamasının üretilmesi Yazılım Gereksinimleri Özellikleri (SRS) (ayrıca denir gereksinimler belgesi ). Bu rapor, yazılım mühendisliği faaliyetleri için bir temel oluşturur ve tüm gereksinimler ortaya çıkarılıp analiz edildiğinde oluşturulur. SRS Müşterilerin yazılımın (SRS) kendi gereksinimlerine uygun olup olmadığını gözden geçirmesine olanak tanıyan yazılımın temsili görevi gören resmi bir rapordur. Ayrıca, bir sistem için kullanıcı gereksinimlerinin yanı sıra sistem gereksinimlerinin ayrıntılı özelliklerini de içerir.
SRS, belirli bir ortamda belirli işlevleri gerçekleştiren belirli bir yazılım ürünü, program veya uygulama kümesi için bir spesifikasyondur. Kimin yazdığına bağlı olarak çeşitli amaçlara hizmet eder. İlk olarak, SRS bir sistemin istemcisi tarafından yazılabilir. İkincisi, SRS sistemin geliştiricisi tarafından yazılabilir. İki yöntem tamamen farklı durumlar yaratır ve belge için tamamen farklı amaçlar oluşturur. İlk durum olan SRS, kullanıcıların ihtiyaç ve beklentilerini tanımlamak için kullanılır. İkinci durum olan SRS, çeşitli amaçlarla yazılır ve müşteri ile geliştirici arasında bir sözleşme belgesi görevi görür.
İyi SRS'nin özellikleri
İyi bir SRS belgesinin özellikleri şunlardır:
1. Doğruluk: Kullanıcı incelemesi, SRS'de belirtilen gereksinimlerin doğruluğunu sağlamak için kullanılır. Sistemden gerçekten beklenen tüm ihtiyaçları karşılıyorsa SRS'nin mükemmel olduğu söylenir.
2. Tamlık: SRS ancak ve ancak aşağıdaki unsurları içeriyorsa tamamlanır:
(1). İşlevsellik, performans, tasarım, kısıtlamalar, nitelikler veya harici arayüzlerle ilgili tüm temel gereksinimler.
3. çeyrekte hangi aylar var
(2). Yazılımın, mevcut tüm durum kategorilerinde gerçekleştirilebilir tüm girdi verileri sınıflarına verdiği yanıtların tanımı.
Not: Hem geçerli hem de geçersiz değerlere verilen yanıtların belirtilmesi önemlidir.
(3). SRS'deki tüm şekillere, tablolara ve diyagramlara ilişkin tam etiketler ve referanslar ile tüm terim ve ölçü birimlerinin tanımları.
3. Tutarlılık: SRS, ancak ve ancak kendi çelişkisinde açıklanan bireysel gerekliliklerin alt kümesi yoksa tutarlıdır. SRS'de üç tür olası çatışma vardır:
(1). Gerçek dünyadaki nesnelerin belirtilen özellikleri çatışabilir. Örneğin,
(a) Bir çıktı raporunun formatı bir gereksinimde tablo halinde, diğerinde ise metinsel olarak tanımlanabilir.
(b) Bir koşul tüm ışıkların yeşil olacağını belirtirken diğer bir koşul tüm ışıkların mavi olacağını belirtebilir.
(2). Belirtilen iki eylem arasında makul veya zamansal bir çelişki olabilir. Örneğin,
(a) Bir gereksinim, programın iki girdi ekleyeceğini belirleyebilir ve bir başka gereksinim, programın bunları çoğaltacağını belirleyebilir.
(b) Koşullardan biri 'A'nın her zaman 'B'yi takip etmesi gerektiğini belirtirken, diğeri 'A ve B'nin birlikte ortaya çıkmasını gerektirebilir.
(3). İki veya daha fazla gereksinim aynı gerçek dünya nesnesini tanımlayabilir ancak o nesne için farklı terimler kullanabilir. Örneğin, bir programın kullanıcı girişi talebi, bir gereksinimde 'istem', diğerinde ise 'işaret' olarak adlandırılabilir. Standart terminoloji ve açıklamaların kullanılması tutarlılığı artırır.
4. Açıklık: Her sabit gereksinimin yalnızca bir yorumu olduğunda SRS açıktır. Bu, her öğenin benzersiz şekilde yorumlandığını gösterir. Birden fazla tanımla kullanılan bir yöntemin olması durumunda, gereksinimler raporu, SRS'deki etkileri açık ve anlaşılması kolay olacak şekilde belirlemelidir.
5. Önem ve istikrar sıralaması: SRS, içindeki her gereksinimin söz konusu gereksinimin önemini veya istikrarını gösteren bir tanımlayıcıya sahip olması durumunda önem ve kararlılığa göre derecelendirilir.
Tipik olarak tüm gereksinimler eşit derecede önemli değildir. Bazı önkoşullar, özellikle hayati önem taşıyan uygulamalar için gerekli olabilirken, diğerleri istenebilir. Bu farklılıkları açık ve net hale getirmek için her bir öğe tanımlanmalıdır. Gereksinimleri sıralamanın başka bir yolu da öğe sınıflarını temel, koşullu ve isteğe bağlı olarak ayırmaktır.
6. Değiştirilebilirlik: SRS mümkün olduğu kadar değiştirilebilir hale getirilmeli ve sistemde bir dereceye kadar değişiklikleri hızlı bir şekilde elde edebilme yeteneğine sahip olmalıdır. Değişiklikler mükemmel bir şekilde indekslenmeli ve çapraz referanslanmalıdır.
dar açı
7. Doğrulanabilirlik: Nihai yazılımın bu gereksinimleri karşılayıp karşılamadığını kontrol etmek için belirtilen gereksinimler uygun maliyetli bir sistemle doğrulanabildiğinde SRS doğrudur. Gereksinimler incelemeler yardımıyla doğrulanır.
8. İzlenebilirlik: Gereksinimlerin her birinin kaynağı açıksa ve gelecekteki geliştirme veya iyileştirme belgelerinde her bir koşulun referans alınmasını kolaylaştırıyorsa SRS izlenebilirdir.
İki tür İzlenebilirlik vardır:
1. Geriye Doğru İzlenebilirlik: Bu, her gereksinimin daha önceki belgelerde kaynağına açıkça atıfta bulunmasına bağlıdır.
2. İleriye Doğru İzlenebilirlik: Bu, SRS'deki her öğenin benzersiz bir ada veya referans numarasına sahip olmasına bağlıdır.
SRS'nin ileriye dönük izlenebilirliği özellikle yazılım ürünü işletme ve bakım aşamasına girdiğinde çok önemlidir. Kod ve tasarım belgesi değiştirildikçe, bu değişikliklerle ilgili olabilecek tüm gereksinimler setini tespit edebilmek gerekir.
9. Tasarım Bağımsızlığı: Nihai sistem için birden fazla tasarım alternatifi arasından seçim yapma seçeneği bulunmalıdır. Daha spesifik olarak SRS, herhangi bir uygulama ayrıntısı içermemelidir.
10. Test Edilebilirlik: Bir SRS, rapordan test senaryoları ve test planları oluşturmayı kolaylaştıracak bir yöntemle yazılmalıdır.
11. Müşteri tarafından anlaşılabilir: Son kullanıcı kendi alanında uzman olabilir ancak bilgisayar bilimi konusunda eğitim almamış olabilir. Bu nedenle, biçimsel gösterim ve sembollerin amacından mümkün olduğunca kaçınılmalıdır. Dil basit ve anlaşılır tutulmalıdır.
12. Doğru düzeyde soyutlama: Eğer SRS gereksinimler aşaması için yazılmışsa detayları açıkça açıklanmalıdır. Oysa fizibilite çalışması için daha az analiz kullanılabilir. Dolayısıyla soyutlama düzeyi SRS'nin amacına göre değişir.
İyi bir SRS belgesinin özellikleri
İyi bir SRS belgesinin temel özellikleri şunlardır:
Özlü: SRS raporu kısa ve aynı zamanda net, tutarlı ve eksiksiz olmalıdır. Ayrıntılı ve alakasız açıklamalar okunabilirliği azaltır ve hata olasılığını da artırır.
ABD'deki eyaletler
Yapılandırılmış: İyi yapılandırılmış olmalıdır. İyi yapılandırılmış bir belgenin anlaşılması ve değiştirilmesi kolaydır. Uygulamada, SRS belgesi, kullanıcı gereksinimlerinin karşılanması için çeşitli revizyonlara tabi tutulur. Çoğu zaman, kullanıcı gereksinimleri belirli bir süre içinde gelişir. Bu nedenle SRS belgesinde değişiklik yapılmasını kolaylaştırmak için raporun iyi yapılandırılmış olması hayati önem taşımaktadır.
Kara kutu görünümü: Sadece sistemin ne yapması gerektiğini tanımlamalı ve bunların nasıl yapılacağını belirtmekten kaçınmalıdır. Bu, SRS belgesinin sistemin dış davranışını tanımlaması ve uygulama sorunlarını tartışmaması gerektiği anlamına gelir. SRS raporu, geliştirilecek sistemi bir kara kutu olarak görmeli ve sistemin dışarıdan görünen davranışını tanımlamalıdır. Bu nedenle SRS raporu bir sistemin kara kutu spesifikasyonu olarak da bilinir.
Kavramsal bütünlük: Okuyucunun anlayabilmesi için kavramsal bütünlük göstermelidir. İstenmeyen olaylara tepki: İstenmeyen olaylara verilen kabul edilebilir tepkileri karakterize etmelidir. Bunlara olağanüstü koşullara sistem tepkisi denir.
Doğrulanabilir: SRS belgesinde belgelendiği gibi sistemin tüm gereksinimleri doğru olmalıdır. Bu, bir uygulamada gereksinimlerin karşılanıp karşılanmadığına karar verilmesinin mümkün olması gerektiği anlamına gelir.