Vizör Çözümleri


Destek
Kaydol
Giriş Yap
Ücretsiz Deneme başlat

Sistem Gereksinim (SRS) Belgeleri Nasıl Yazılır?

Sistem Gereksinim (SRS) Belgeleri Nasıl Yazılır?

İçindekiler

Yazılım Gereksinim Spesifikasyonu Belgesi (SRS), belirli bir projenin gereksinimlerinin ve gereksinimlerinin ayrıntılı bir tanımını sağlayan yazılım geliştirme için temel bir belgedir. Amaçları, kapsamı, arka plan bilgilerini, tasarım ayrıntılarını, uygulama planını ve diğer ilgili faaliyetleri ana hatlarıyla belirtir. SRS belgesi, her iki tarafın da geliştirilmekte olan ürünün özelliklerini ve beklentilerini anlamasını sağlamak için müşteri ile geliştirici arasında bir sözleşme görevi görür. Ayrıca, tüm paydaşların projenin her aşamasında kendilerinden ne beklendiğini tam olarak anlamalarını sağlayarak risklerin azaltılmasına yardımcı olur. 

İyi hazırlanmış bir SRS belgesi, hem geliştiriciler hem de müşteriler tarafından kolayca anlaşılabilecek şekilde eksiksiz, açık ve öz olmalıdır. Ayrıca, yerinde bir SRS'ye sahip olmak, geliştirme sırasında üründe yapılan herhangi bir değişikliğin veya güncellemenin kolayca belgelenmesini ve takip edilmesini sağlar. Bu, karışıklığı en aza indirmeye yardımcı olur ve son ürünün belgede belirtilen tüm gereksinimleri karşılamasını sağlar. Genel olarak, bir SRS, başarı için net bir çerçeve sağladığı için başarılı yazılım geliştirme projeleri için kritik bir araçtır. Doğru kullanımla, ekiplerin en az çabayla kaliteli sonuçlar elde etmesine yardımcı olabilir.

Yazılım Gereksinim Spesifikasyonu ve İş Gereksinim Spesifikasyonu

İnsanlar bazen yazılım kavramlarını ve iş gereksinimleri belirtimlerini karıştırırlar. Aslında ikisi de oldukça farklı.

Yazılım gereksinimi belirtimi ile iş gereksinimi belirtimi arasındaki temel fark, birincisinin yazılımla ilgili tüm bilgileri, ikincisinin ise işle ilgili tüm bilgileri yakalamasıdır.

S. No.
Yazılım Gereksinimleri Belirtimi (SRS)
İş Gereksinimleri Spesifikasyonu (BRS)
1.
Yazılımda bulunan işlevsel ve işlevsel olmayan gereksinimleri belirtir.
Müşteri/paydaşlar tarafından sağlanan çeşitli gereksinimleri açıklayan resmi bir belgedir.
2.
İş Gereksinimleri Spesifikasyonundan (BRS) türetilmiştir.
Müşterinin gereksinimlerinden ve etkileşimlerinden türetilir.
3.
Bir sistem analisti veya sistem mimarı veya bir iş analisti tarafından oluşturulur.
Bir iş analisti tarafından oluşturulur.
4.
Yazılımın hem teknik hem de işlevsel özelliklerini de üst düzeyde açıklar.
Yazılımın işlevsel özelliklerini çok yüksek düzeyde açıklar.
5.
Şirketin sağladığı kaynaklarla ilgilenir.
İş gereksinimleriyle ilgilenir.
6.
Yazılımı veya uygulamayı kullanırken işletmenin nasıl çalıştığını açıklar.
Müşterinin ihtiyaçlarını tanımlar. Belge, projenin başından sonuna kadar kullanılır.
7.
Tablolar ve kullanım durumları dahildir.
Tablolar ve kullanım durumları dahil değildir.

Bir SRS'nin Temel Bileşenleri

Bir yazılım gereksinimleri belirtiminin ana bölümleri şunlardır:

  • İşletmeye yön veren – Müşterinin bir sistem kurmak istemesinin nedenleri bu bölümde açıklanmaktadır. Bu bölüm ayrıca müşterinin mevcut sistemle karşılaştığı sorunları ve yeni sistemin sağlayacağı fırsatları içerir.
  • İş Modeli – Sistemin desteklemesi gereken iş modeli bu bölümde tartışılmaktadır. Ayrıca, organizasyon ve iş bağlamı, ana iş fonksiyonları ve sistemin süreç akış diyagramları gibi çeşitli diğer detayları içerir.
  • Fonksiyonel ve Sistem Gereksinimleri – Bu bölüm genellikle hiyerarşik bir yapıda düzenlenen gereksinimlerin ayrıntılarını verir. İşlevsel gereksinimler en üst düzeyde olup, ayrıntılı sistem gereksinimleri alt öğeler olarak listelenmiştir.
  • Sistem Kullanım Durumları – Bu bölüm, sistemle etkileşime girecek tüm önemli harici varlıkları ve gerçekleştirmeleri gereken farklı kullanım durumlarını açıklayan Birleşik Modelleme Dili (UML) kullanım durumu diyagramından oluşur.
  • Teknik gereksinimler – Bu bölüm, teknik ortamı oluşturan tüm işlevsel olmayan gereksinimleri ve yazılımın çalışacağı teknik sınırlamaları tartışır.  
  • Sistem Nitelikleri – Bu bölümde, sistemin güvenilirlik, hizmet verilebilirlik, güvenlik, ölçeklenebilirlik, kullanılabilirlik ve bakım kolaylığı gibi sayısız niteliği tanımlanmıştır.
  • Sınırlamalar ve Varsayımlar – Müşterinin bakış açısından sistem tasarımına getirilen tüm sınırlamalar bu bölümde açıklanmıştır. Mühendislik ekibinin geliştirme sırasında neler bekleyeceğine ilişkin çeşitli varsayımları da burada tartışılmaktadır.
  • Kabul Kriterleri – Sistem nihai müşterilere teslim edilmeden önce yerine getirilmesi gereken tüm koşullara ilişkin detaylar bu bölümde ele alınmaktadır.

Bir SRS'nin yapısı

1. Giriş -

Giriş, genel olarak SRS'nin anlamını, ekibiniz için kapsamını ve yapısını açıklar.

1.1. Amaç

Burada, SRS yazılım belgelerinin amacını ve yapısını açıklayın: ele alınacak gereksinim türleri ve onu kullanacak personel.

Bu bölümü kısa tutun: 1-2 paragraf yeterlidir.

1.2. Hedef kitlesi

Daha derine inebilir ve paydaşların ve ekiplerin SRS ile nasıl çalışacağını açıklayabilir ve gelişimine katılabilirsiniz. Bunlar genellikle ürün sahipleri, yatırımcılar, iş analistleri, geliştiriciler, bazen testçiler ve operasyon personelidir. Tüm yapı, yazılım geliştirme yaklaşımınız ve ekibin organizasyonel kurulumu tarafından belirlenir.

1.3. Kullanım Amacı

Ekibinizin SRS'yi hangi durumlarda kullanacağını açıklayın. Genellikle, aşağıdaki durumlarda kullanılır:

  • yeni özellikler tasarlamak ve beyin fırtınası yapmak
  • proje süresini planlama, sprintler, maliyetleri tahmin etme
  • riskleri değerlendirmek
  • ekibin başarısını izlemek ve ölçmek
  • İlgili tarafların iyi uygulanmış bir ürün hakkında farklı vizyonları olduğunda çelişkili durumlar.

1.4. kapsam

Bu bölüm ürünün kapsamını kapsar, bu nedenle sisteme - birincil amacı, işlevi ve konumu - hakkında hızlı bir genel bakış vermeniz gerekir. Teknik ayrıntıları daha derinlemesine incelemenize izin verilmesi dışında, bir paydaş toplantısında bir ürünü nasıl açıklayacağınızla karşılaştırılabilir.

Bu bölüm şunları açıklamalıdır:

  • Her türden kullanıcının sistemle etkileşim kurması beklenir.
  • Mimarinin tüm önemli parçaları

1.5 Tanımlar ve Kısaltmalar

Ekip, belgeniz boyunca sıklıkla belirli sözcükleri kullanır. Bu kelimelerin anlamlarını temizlerseniz olası yanlış anlamaları ortadan kaldırmak, yeni geliştiricilerin dahil olmasına izin vermek ve çelişkili durumları çözmek daha kolay olacaktır.

Yukarıda belirtilen bileşenler bir tanım oluşturur. Tanımlar, işlev, temel teknolojiler, hedef kişiler, ticari varlıklar (kullanıcılar, müşteriler, aracılar) ve paydaşlar hakkında bilgi sağlar. İsterseniz, SRS'nizi daha hızlı yazmak için bir kısaltma kullanabilirsiniz. Tanımlar tablosu içerdiği sürece belge okunabilir olacaktır.

2. Genel Açıklama

İkinci bölümde okuyuculara ürünün ana özelliklerini, hedef kullanıcıları ve sistem kapsamını anlatırsınız. Bu açıklama, eklentiler ve bağlantılar hakkında ayrıntılara girmeden yalnızca temel özelliklere ve yazılım mimarisine odaklanır.

2.1 Kullanıcı İhtiyaçları

Bu kısım bir tercih meselesidir, bu nedenle bazı kuruluşlar bunu SRS mühendislik belgelerine dahil etmemeyi tercih eder. Şu anda işlevselliğinizle çözmek istediğiniz sorunları listelemenin daha iyi olduğuna inanıyoruz. Beyin fırtınası yaparken ve işlevleri izlerken daha sonra kullanışlı olacaktır. Ürün geliştirme sürecinde istediğiniz zaman bu bölüme geri dönebilir ve kullanıcı deneyimi ekibinin hedeflenen yoldan sapıp sapmadığını görebilirsiniz.

İhtiyaçlar, kullanıcıların sistemle çözebilecekleri sorunları ifade eder. Yüksek düzeyde segmentlere ayrılmış bir kitleyle ilgileniyorsanız, bu ihtiyaçları alt kategorilere ayırabilirsiniz. Her kullanıcının ihtiyaçlarıyla ilgili ayrıntılara girmemeye çalışın. Bir problemin başlangıçta düşündüğünüzden daha önemli olduğu ortaya çıkarsa, yorum için biraz yer bırakmanız gerekir.

2.2 Varsayımlar ve Bağımlılıklar

Varsayımlar, ekibin, durumların %99'unda doğru olacak ürün ve yetenekleri hakkındaki varsayımlarıdır. Örneğin, sürücülerin gece seyir yapmasına yardımcı olan bir platformun çoğunlukla gece modunda kullanılacağını varsaymak doğaldır.

Varsayımların önemi nedir? Önce uygulamanın en önemli özelliklerine konsantre olmanızı sağlarlar. Bu varsayım, tasarımcıların bir gece sürüş asistanı için karanlıkta görüşe uygun bir arayüz geliştirmesi gerektiği anlayışına yardımcı olur. Bazı kullanıcılar kesinlikle uygulamayı gün içinde açabilir, ancak bu uzun bir ihtimal, bu nedenle ilgili öğeleri prototipe hemen eklemeniz gerekmez.

3. Sistem Özellikleri ve Gereksinimleri

Bu bölüm, ürün özelliklerini ve uygulama kriterlerini detaylı olarak kapsar. Önceki iki bölüm ürünü bir bütün olarak ele aldığından, burada daha kapsamlı bir açıklama bulacaksınız.

3.1 Fonksiyonel Gereksinimler

bir sistemde gerçekleştirilecek işlevlerin bir listesinde belirtilir. Bu kriterler “ne yaratılacak?” "nasıl" ve "ne zaman" yerine.

İşlevsel gereksinimler, uygulama için ne kadar önemli olduğuna bağlı olarak gereken işlevselliği tanımlayarak başlar. İlk önce üzerinde çalışmak istiyorsanız, tasarımla başlayabilirsiniz, ancak daha sonra geliştirme aşamasına geçmelisiniz. Proje ilerledikçe değişebilecekleri için fonksiyonel gereksinimler teknoloji yığınları hakkında çok fazla ayrıntıya girmez. İç mantığa odaklanmak yerine, işlevsel gereksinimler son kullanıcı işlevselliğine odaklanır.

3.2 Harici Arayüz gereksinimleri

İşlevsel gereksinimler, bir sistem gereksinimleri belirtiminin önemli bir parçasıdır. Sistemin tüm gerekli özelliklerini kapsamak için 4-5 sayfalık bilgiye ihtiyacınız olacak. Bazı ekipler, belgenin daha kolay okunmasını sağlamak için bunları temalara göre ayırır.

Tipik olarak, SRS tasarım bileşenleri, arka uç ve iş mantığından ayrı olarak adlandırılır. Bu, bu alanın çoğunluğunu geliştiricilerden ziyade tasarımcılar üstlendiği için, aynı zamanda ürün geliştirme sürecinin başlayacağı yer olduğu için mantıklıdır.

Projeye bağlı olarak, harici arayüz gereksinimleri dört türden oluşabilir:

  • Kullanıcı arabirimi
  • Yazılım arayüzü
  • Donanım arabirimi
  • İletişim arayüzü

Harici arayüz gereksinimleri, son istemci tarafından görülebilecek sayfa öğelerini tanımlar. Ürün için gerekliyse sayfaların listesini, tasarım öğelerini, temel stilistik temaları, hatta sanatsal öğeleri ve daha fazlasını içerebilirler.

3.3 Sistem Gereksinimleri

Ürünün sistem gereksinimleri, ürünün kullanılabileceği koşulları belirtir. Genellikle donanım spesifikasyonları ve özellikleri ile ilgilidir. SRS donanım gereksinimleri, genellikle minimum ve maksimum aralıkların yanı sıra optimum ürün performans eşiği ile tanımlanır.

Bir ürün oluşturmaya başlamadan önce sistem gereksinimlerini oluşturmak zor görünebilir, ancak esastır. Geliştiriciler, projeyi daha sonra yeniden başlatmak zorunda kalmamak için donanım gereksinimlerine uymalıdır. Mobil uygulamalar (dikkate alınması gereken pek çok değişkenle birlikte) ve yüksek reaktivite gerektiren uygulamalar (oyunlar, VR/AR'lı herhangi bir ürün veya IoT) özellikle savunmasızdır.

3.4 İşlevsel Olmayan Gereksinimler 

Birçok kuruluş için bir SRS'nin bu kısmı en zor olanıdır. İşlevsel gereksinimler neyin yaratılacağı sorusunu ele alıyorsa, işlevsel olmayan standartlar nasıl yapılacağını tanımlar. Sistemin ne kadar etkin çalışması gerektiğine göre kriterleri belirlerler. Performans, güvenlik ve kullanılabilirlik eşikleri bu alana dahildir.

Gerçek değer, işlevsel olmayan gereksinimleri tanımlamayı zorlaştıran şeydir. “Eşzamanlılık” veya “taşınabilirlik” gibi ifadeleri tanımlamak, ilgili tüm taraflar için çeşitli yorumlara sahip olabileceğinden zordur. Sonuç olarak, işlevsel olmayan her gereksinime bir puan vermeyi savunuyoruz. Mevcut sistemin ilk beklentileri karşılayıp karşılamadığını görmek için proje gereksinimlerinizi istediğiniz zaman tekrar ziyaret edebilirsiniz.

Sistem Gereksinimleri Spesifikasyonu Hazırlanırken Hangi Hatalardan Kaçınılmalıdır?

SRS geliştirme konusundaki becerileriniz arttıkça, süreç hızlanacaktır. Bununla birlikte, yeni başladığınızda, referans için kullanışlı olan tipik hataların bir listesine sahip olmak akıllıca olacaktır. Bunun için şunlar üzerinde kafa yorun:  

  • Kapsamlı Bir Sözlük Eklemeyi İhmal Etmek: SRS'niz yalnızca sektördeki kişilerin aşina olduğu bir jargon mu içeriyor? Öyleyse, anlaşılması kolay bir sözlük bölümü oluşturun ve yaygın olarak bilinmeyen herhangi bir kelime veya ifadenin tanımlarını ekleyin. Bu, tüm kullanıcıların hem belgenin amacını hem de terminolojisini anlamasına yardımcı olacaktır.
  • Fikirleri Birleştirerek Kargaşa Yaratmak: Belgenizi düzenli bir şekilde yapılandırın ve bilgileri okuyuculara mantıksal bir ilerleme içinde ilettiğinizden emin olun. Herhangi bir yanlış anlaşılmayı veya karışıklığı önlemek için metin boyunca kavramları birbirine karıştırmayın.
  • Hedef Kitlenin İhtiyaç ve İsteklerinin Cehaleti: Yazılımdan beklenen çıktıyı anlamak için, onu kimin kullanacağını ve hangi sonuçların beklendiğini ayırt etmek önemlidir. Örneğin rapor oluşturmak için bir uygulama oluşturuldu diyelim. Gereksinimlerinden bazıları, kullanıcıların farklı belgeler elde etmek için belirli düğmelere nasıl basabileceklerini içermelidir. Bu raporlama programından neyin gerekli olduğunu gerçekten anlamak ve ayrıca onu kimlerin kullanacağını anlamak için, hem kullanıcı hem de işlevsellik açısından beklentileri hakkında fikir sahibi olmanız gerekir.  
  • Belirsiz Olmak: İhtiyaçlarınızın açık olduğundan emin olun. Bir SRS, yanlış anlamaları önlemek için formüle edilmiştir ve bu nedenle, belgenin karışıklık yaratmadığından emin olmak çok önemlidir. Her özellik veya koşul açıklaması için henüz belirtilmemiş işlevleri dahil etmediğinizden emin olun.

SRS Belgelerini Yazmaya Yönelik En İyi Uygulamalar

Bir Sistem Gereksinimi Belirtimi (SRS) belgesi yazmak, yazılım geliştirmenin çok önemli bir yönüdür ve en iyi uygulamalara bağlı kalmak, belgenin kalitesini ve etkinliğini önemli ölçüde artırabilir. SRS belgelerini yazmaya yönelik en iyi uygulamalardan bazıları şunlardır:

  • Açık ve Kısa Bir Dil Kullanın:
    • Evrensel olarak anlaşılmayabilecek teknik jargondan ve kısaltmalardan kaçının. Tüm paydaşların içeriği kolayca anlayabilmesini sağlayacak şekilde açık ve anlaşılır bir dil kullanın.
  • Görsel Yardımcıları Dahil Et:
    • Gereksinimlerin metinsel açıklamalarının yanı sıra diyagramları, akış şemalarını ve maketleri birleştirerek anlayışı geliştirin. Görsel yardımcılar, karmaşık kavramların ve sistem davranışlarının daha sezgisel bir temsilini sağlayabilir.
  • Öncelik Gereksinimleri:
    • Her gereksinimin önceliğini açıkça tanımlayın. Farklı özelliklerin göreceli önemini belirtmek için "olmazsa olmaz", "olmalı" ve "olması güzel" gibi etiketleri kullanın. Önceliklendirme, geliştirme ekibinin öncelikle kritik işlevselliğe odaklanmasına yardımcı olur.
  • Güncel Tutun:
    • SRS belgesinin sürüm kontrolünü koruyun. Proje gereksinimlerindeki, kapsamdaki veya paydaş geri bildirimlerindeki değişiklikleri yansıtacak şekilde belgeyi düzenli olarak güncelleyin. Zaman içindeki değişiklikleri izlemek için net bir değişiklik günlüğü tutun.
  • Paydaşları Dahil Edin:
    • SRS geliştirme süreci boyunca ilgili tüm paydaşlarla yakın işbirliği yapın. Tartışmalara katılın, geri bildirim toplayın ve ihtiyaçlarının ve beklentilerinin belgede doğru bir şekilde yansıtıldığından emin olun. Bu katılım, proje hedeflerine ilişkin ortak bir anlayışı teşvik eder.
  • Kapsamlı Olun:
    • Yoruma veya varsayıma yer bırakmayın. İşlevsel ve işlevsel olmayan yönler de dahil olmak üzere her gereksinimin ayrıntılı ve kapsamlı açıklamalarını sağlayın. Gereksinimlerdeki belirsizlik, yanlış anlamalara ve proje gecikmelerine yol açabilir.
  • Yapılandırılmış Biçim Kullanın:
    • SRS belgesini Giriş, Paydaş Gereksinimleri, Sistem Mimarisi, İşlevsel Gereksinimler, İşlevsel Olmayan Gereksinimler, Kısıtlamalar, Varsayımlar, Bağımlılıklar ve İzlenebilirlik Matrisi gibi iyi tanımlanmış bölümler halinde düzenleyin. Yapılandırılmış bir format, okuyucuların belirli bilgileri bulmasını kolaylaştırır.
  • Test Edilebilirliği Sağlayın:
    • Gereksinimleri test ve doğrulamayı kolaylaştıracak şekilde yazın. Her gereksinim doğrulanabilir olmalı ve test uzmanlarının sistemin belirtilen kriterleri karşılayıp karşılamadığını doğrulayan test senaryoları oluşturmasına olanak sağlamalıdır. Her gereksinim için açık kabul kriterleri esastır.
  • Belirsizlikten Kaçının:
    • Gereksinimlerdeki belirsizliği ortadan kaldırma konusunda dikkatli olun. Kesin bir dil kullanın, belirsiz terimlerden kaçının ve bir gereksinimin birden fazla yorumlanmasına yer olmadığından emin olun. Belirsizlikler yanlış anlamalara ve projenin yeniden çalışmasına yol açabilir.
  • Gelecekteki Ölçeklenebilirliği Düşünün:
    • Yazılım sisteminin uzun vadeli ölçeklenebilirliğini düşünün. Gelecekteki potansiyel ihtiyaçları tahmin edin ve SRS belgesinin bunları karşıladığından emin olun. Bu proaktif yaklaşım gelecekte zamandan ve kaynaklardan tasarruf sağlayabilir.
  • İnceleyin ve Doğrulayın:
    • Müşteri, geliştirme ekibi ve konunun uzmanları da dahil olmak üzere paydaşlarla SRS belgesinin kapsamlı incelemelerini gerçekleştirin. İnceleme süreci sırasında ortaya çıkan tutarsızlıkları, tutarsızlıkları veya belirsizlikleri ele alın. Doğrulama, belgenin projenin hedeflerini doğru şekilde temsil etmesini sağlar.
  • Resmi Onay Alın:
    • SRS belgesini tamamladıktan sonra müşteriden veya proje sponsorundan resmi onay ve imza alın. Bu, projenin kapsamı ve gereksinimlerine ilişkin anlaşmayı resmileştirir ve geliştirme için açık bir temel sağlar.

Bu en iyi uygulamaları SRS belgeleri yazma sürecine dahil etmek, yazılım geliştirme projelerinin başarısına katkıda bulunabilir. İyi hazırlanmış bir SRS belgesi, hem geliştirme ekibi hem de paydaşlar için güvenilir bir kılavuz görevi görerek, nihai yazılım sisteminin beklentiler ve gereksinimlerle uyumlu olmasını sağlamaya yardımcı olur.

Sonuç

Etkili bir Sistem Gereksinimi Belirtimi (SRS) belgesi yazmak, yazılım geliştirme sürecinde kritik bir adımdır. Başarılı proje planlama, geliştirme, test etme ve doğrulama için bir temel görevi görür. Bu makalede özetlenen adımları takip ederek ve en iyi uygulamalara bağlı kalarak, paydaşların ihtiyaç ve beklentilerini karşılayan yazılım sistemleri oluşturmak için güvenilir bir kılavuz görevi gören SRS belgeleri oluşturabilirsiniz.

Bu gönderiyi paylaşmayı unutmayın!

Iyi