İyi hazırlanmış bir SRS belgesinin faydaları
Bir yazılım gereksinim belgesi, tüm projenin sonucunu şekillendirir. Ekip, işi düzenleyen ve riski azaltan bir araca sahip olur.
Görevle ilgili ortak anlayış
Projede yer alan herkes aynı tabloyu görür. Geliştirici, hangi işlevselliği geliştireceğini anlar. Test uzmanı, neyi kontrol edeceğini bilir. Proje yöneticisi, net kriterlere göre ilerlemeyi takip eder. Müşteri, sonucun beklentileriyle uyumlu olduğunu doğrular.
Proje sınırlarını belirler
Bir SRS, kapsam genişlemesine karşı koruma sağlar. Geliştirme sürecinde, yeni sistem yeteneklerine yönelik fikirler sürekli ortaya çıkar. Belge, kritik işlevsellikleri "olsa iyi olur" türündeki iyileştirmelerden ayırmaya yardımcı olur. Ekip, temel görevlere odaklanır ve ekstra özellikleri bir sonraki sürüme erteler.
Tahmin ve planlama için bir temel sağlar
Proje yöneticisi gereksinimleri analiz eder ve gereken çabayı tahmin eder. Müşteri, iş kapsamının maliyetle nasıl ilişkili olduğunu görür. Geliştirme ekibi, yinelemeleri planlar, görevleri atar ve uygulamayı sıralar.
Yeniden çalışma ihtiyacını azaltır
Kodlama aşamasında bir gereksinim hatasını düzeltmek, planlama aşamasında düzeltmekten çok daha pahalıdır. İyi yazılmış bir SRS, programcılar çalışmaya başlamadan önce çelişkileri ve yanlışlıkları ortaya çıkarmaya yardımcı olur. Ekip, tartışmalı noktaları tartışır, ayrıntıları netleştirir ve kararlar üzerinde anlaşır; tüm bunlar kodda değil, belgede gerçekleşir.
Testler için temel oluşturur
Test uzmanları, test senaryoları oluşturmak için SRS’deki gereksinimleri kullanır. Her bir işlevsellik, bir dizi kontrol haline gelir. Kalite güvence ekibi, neyin doğru sonuç olarak kabul edileceğini anlar. Testlerden sonra, sistemin gereksinimleri karşılayıp karşılamadığını kesin olarak söyleyebilirsiniz.
Bilgi aktarımını kolaylaştırır
Projeye yeni bir geliştirici katılır, SRS'yi açar ve sistemin mantığını anlar. Bir destek uzmanı belgeyi inceler ve kullanıcılara yardım etmeye hazır hale gelir. Ekip, kaliteden ödün vermeden büyür.
Yasal koruma
B2B projelerinde SRS, sözleşmenin bir eki haline gelir. Belge, işin tamamlanması için gerekli kriterleri tanımlar. Müşteri ile yüklenici arasında bir anlaşmazlık ortaya çıkarsa, her iki taraf da üzerinde anlaşmaya varılan gereksinimlere başvurur. Açıkça yazılmış şartlar, her iki tarafın da çıkarlarını korur.
SRS nasıl yazılır: adım adım kılavuz
Yazılım gereksinimleri belgesinin oluşturulması yapılandırılmış bir süreçtir. Net bir plan izleyerek ekip, önemli bilgileri gözden kaçırmaz ve eksiksiz bir gereksinim listesi oluşturur.
Adım 1. Paydaşları bir araya getirin
Projede yer alan herkesi belirleyin. Bu listeye müşteri, iş temsilcileri, sistemin gelecekteki kullanıcıları, analistler, mimarlar, geliştiriciler ve test uzmanları dahildir.
Bir imalat şirketi, hammadde takip sistemi kurmayı planlamaktadır. Toplantıya üretim müdürü, depo sorumlusu, baş proses mühendisi, BT müdürü ve bir iş analisti katılır. Her katılımcı, sistemden ne beklediğini açıklar.
Adım 2. Görüşmeler ve atölye çalışmaları düzenleyin
Her kullanıcı grubuyla ayrı ayrı görüşün. Sistemin hangi görevleri yerine getireceğini, şu anda hangi sorunların olduğunu ve uygulama sonrasında iş akışlarının nasıl olması gerektiğini öğrenin.
Spesifik sorular sorun. "Sistemden ne bekliyorsunuz?" yerine şunu sorun: "Şu anda bir müşteri siparişini nasıl işliyorsunuz? Bu ne kadar sürüyor? Hangi belgeleri hazırlıyorsunuz? Bunları kim onaylıyor? Gecikmeler nerede yaşanıyor?"
Adım 3. İşlevselliği tanımlayın
Topladığınız bilgileri bir işlev listesine dönüştürün. En üst seviyeden başlayarak ana özellikleri belirleyin. Ardından genel işlevselliği belirli kullanıcı eylemlerine ayırın.
Adım 4. İşlevsel gereksinimleri yazın
Her bir gereksinimi şu şablonu kullanarak belirtin: aktör + eylem + sonuç. Ölçülebilir kriterler kullanın. Belirsiz ifadelerden kaçının.
Yanlış: "Sistem, talepleri hızlı bir şekilde işlemelidir."
Doğru: "Bir yönetici bir müşteri talebi oluşturur. Sistem, verileri kaydeder ve 2 saniye içinde talebe benzersiz bir numara atar."
Adım 5. İşlevsel olmayan gereksinimleri tanımlayın
Sistemin teknik özelliklerini kaydedin. Performans, güvenilirlik, güvenlik, ölçeklenebilirlik ve uyumluluk gereksinimlerini belirtin.
Adım 6. Arayüzleri ve entegrasyonları tanımlayın
Sistemin kullanıcılar ve diğer programlarla nasıl etkileşime girdiğini kaydedin. Veri formatlarını, veri alışverişi protokollerini ve API'leri belirtin.
Adım 7. Kısıtlamaları ve varsayımları kaydedin
Geliştirmeyi etkileyen faktörleri listeleyin. Kısıtlamalar, değiştirilemeyen kesin sınırlardır. Varsayımlar ise temel alınan öncüllerdir.
Adım 8. Belgenin onaylanmasını sağlayın
Taslağı tüm paydaşlara gönderin. Tartışmak üzere bir toplantı düzenleyin. Yorumları toplayın, düzeltmeleri yapın ve nihai onayı alın.
Onay, önemli bir aşamadır. Her katılımcı, üzerinde anlaşmaya varılan gereksinimleri anlamalı ve kabul etmelidir. Uyuşmazlıkların bu aşamada çözülmesi kolaydır, ancak geliştirme aşamasında çözülmesi maliyetlidir.
Adım 9. Değişiklikleri yönetin
Gereksinimlerdeki her değişikliği ayrı ayrı kaydedin. Değişikliğin zaman çizelgesini ve bütçeyi nasıl etkileyeceğini değerlendirin. Belgeye eklemeden önce müşteri ile mutabık kalın.
Belgenin sürümlerini tarih ve değişiklik listesiyle birlikte saklayın. Ekip, her bir gereksinimin ne zaman ve neden ortaya çıktığını takip edebilecektir. Sürüm geçmişi, kararların ardındaki mantığı açıklamaya ve anlaşmazlıkları önlemeye yardımcı olur.
Yazılım gereksinimleri belgesi şablonu
Belgenin yapısı, geliştirme metodolojisine ve projenin özelliklerine göre değişebilir.
1. Giriş
1.1. Belgenin amacı — belgenin neden oluşturulduğunu ve kimler tarafından kullanıldığını açıklayın.
1.2. Kapsam — sistemin adını, amacını ve işlevselliğinin sınırlarını belirtin.
1.3. Tanımlar, kısaltmalar ve baş harfler — belgede kullanılan terimleri tanımlayın. Örnek: API — Uygulama Programlama Arayüzü.
1.4. Referanslar — ilgili belgeleri listeleyin: iş tanımı, standartlar, politikalar.
1.5. Belgeye genel bakış — belgenin yapısını tanımlayın ve her bölümün içeriğini açıklayın.
2. Genel açıklama
2.1. Ürün perspektifi — sistemin amacını, kuruluşun iş süreçlerindeki yerini ve diğer sistemlerle olan bağlantılarını açıklayın.
2.2. Ürün işlevleri — sistemin temel yeteneklerini genel hatlarıyla kısaca listeleyin.
2.3. Kullanıcı özellikleri — kullanıcı türlerini, rollerini, teknik beceri düzeylerini ve sistemi ne sıklıkla kullandıklarını açıklayın.
2.4. Kısıtlamalar — geliştirmeyi etkileyen faktörleri kaydedin: yasal gereklilikler, donanım sınırlamaları, bütçe, son tarihler.
2.5. Varsayımlar ve bağımlılıklar — gereksinimleri hazırlarken yapılan varsayımları belirtin. Dış faktörlere olan bağımlılıkları açıklayın.
3. İşlevsel gereksinimler
Her işlev için şunları belirtin:
FR-XXX. İşlev adı
- kullanıcı ve sistem eylemlerinin açıklaması;
- giriş verileri;
- sonuç;
- hata işleme;
- uygulama önceliği (kritik, önemli, arzu edilen).
Örnek:
FR-001. Yeni kullanıcı kaydı
Kullanıcı kayıt formunu doldurur: e-posta, şifre, şifre onayı. Sistem, e-postanın geçerli olup olmadığını, şifrelerin eşleşip eşleşmediğini ve e-postanın veritabanında benzersiz olup olmadığını kontrol eder. Kontroller başarılı olursa, sistem bir hesap oluşturur ve verilen adrese bir onay e-postası gönderir. Kullanıcı, kaydın başarılı olduğu konusunda bir bildirim alır. Doğrulama başarısız olursa, sistem sorunu açıklayan bir mesaj gösterir.
Öncelik: kritik.
4. İşlevsel olmayan gereksinimler
4.1. Performans gereksinimleri Tepki süresi, işleme kapasitesi, işlenen veri hacmi.
4.2. Güvenilirlik gereksinimleri Sistem kullanılabilirliği, kabul edilebilir kesinti süresi, yedekleme prosedürleri.
4.3. Güvenlik gereksinimleri Kimlik doğrulama, yetkilendirme, veri şifreleme, kullanıcı eylemlerinin denetimi.
4.4. Uyumluluk gereksinimleri Desteklenen işletim sistemleri, tarayıcılar, veri formatları.
4.5. Ölçeklenebilirlik gereksinimleri Artan yükü yönetme, kullanıcı ekleme ve işlevselliği genişletmeyeteneği .
4.6. Arayüz gereksinimleri Erişilebilirlik standartları, farklı cihazlarda yanıt verme hızı, dil sürümleri.
5. Arayüzler
5.1. Kullanıcı arayüzü Ekranların, gezinme ve denetimlerin açıklaması. Maketler veya şemalar ekleyebilirsiniz.
5.2. Yazılım arayüzleri Harici sistemlerleentegrasyon : veri formatları, protokoller, veri alışveriş sıklığı.
5.3. Donanım arayüzleri Varsa, ekipmanlarla etkileşim.
6. Veri gereksinimleri
6.1. Mantıksal veri modeli Ana varlıklar, öznitelikler ve nesneler arasındaki ilişkiler.
6.2. Depolama gereksinimleri Veri hacimleri, saklama süreleri, arşivleme gereksinimleri.
6.3. Veri taşıma gereksinimleri Veri kaynakları, dönüştürme kuralları, taşıma sonrası doğrulama.
7. Kabul kriterleri
Her bir gereksinim için, işlevselliğin doğru bir şekilde uygulandığı kabul edilecek koşulları belirtin. Test senaryolarını açıklayın.
Örnek:
Kullanıcı kaydı aşağıdaki durumlarda uygulanmış sayılır:
- geçerli bir e-posta adresi ve şifreye sahip bir kullanıcı başarıyla bir hesap oluşturursa;
- sistem, geçersiz bir e-posta adresiyle yapılan kaydı reddederse;
- şifreler eşleşmediğinde sistem kaydı reddederse;
- e-posta adresi halihazırda kullanılıyorsa sistem kayıt işlemini reddeder;
- kullanıcı 1 dakika içinde bir kayıt onayı e-postası alır.
8. Ekler
Destekleyici materyaller: süreç şemaları, arayüz taslakları, örnek raporlar, veri formatı özellikleri, projeye özgü terimler sözlüğü.
SRS yazarken sık karşılaşılan sorunlar ve hatalar
Gereksinim belgesi yazmak zorlu bir görevdir. Ekipler, geliştirme ve test aşamalarında sorunlara yol açan tipik hatalar yaparlar.
Hata: belirsiz ifadeler
En yaygın hata, soyut ifadelerin kullanılmasıdır. "Hızlı", "kullanımı kolay", "güvenilir" ve "verimli" gibi kelimeler, geliştiriciye gereksinimleri net bir şekilde anlamasını sağlamaz. Geliştirici, "hızlı"nın 1 saniye mi yoksa 10 saniye mi anlama geldiğini bilemez.
Çözüm: Her zaman ölçülebilir kriterler kullanın. "Sistem istekleri hızlı bir şekilde işlemelidir" yerine, "sistem bir kullanıcı isteğini işler ve sonucu 3 saniye içinde görüntüler" yazın. "Yüksek kullanılabilirlik" yerine, "ayda %99,5 oranında" ifadesini kullanın.
Hata: Kısıtlamaları göz ardı etmek
Gereksinimler, projenin gerçek kısıtlamalarını (bütçe, teslim tarihleri, altyapının teknik yetenekleri) hesaba katmamaktadır. Ekip, verilen koşullar altında kurulamayacak ideal bir sistem planlamaktadır. Müşteri, kısıtlı bir bütçe ve üç aylık bir teslim süresi içinde, makine öğrenimi özelliğine sahip ve 15 hizmetle entegre bir sistem istemektedir.
Çözüm: Gerçekçiolun . Gereksinimler belirlenirken kısıtlamaları müşteriyle görüşün. Öncelikleri belirleyin. Aşamalı bir devreye alma planı yapın: önce temel işlevler, ardından iyileştirmeler. Hangi gereksinimlerin bütçe ve zaman çizelgesi dahilinde karşılanabileceğini anlamak için çaba miktarını erken aşamada tahmin edin.
Hata: Çelişen gereksinimler
Belgede birbiriyle çelişen gereksinimler bulunmaktadır. Bir grup paydaş bir şeyi isterken, bir diğeri tam tersini istemektedir. Satış departmanı onay gerektirmeden sipariş oluşturmak isterken, finans departmanı büyük siparişlerin onaylanması gerektiği konusunda ısrarcıdır.
Çözüm: Sorun, belge onay aşamasında çözülür. Tüm paydaşları bir araya getirin, çelişkiyi tartışın, bir uzlaşmaya varın ve bunu SRS'ye kaydedin. Örneğin, belirli bir tutarın altındaki siparişlerin onay gerektirmeden işleme alınacağı, daha büyük siparişlerin ise bir yöneticinin onayı gerektireceği konusunda anlaşın.
Hata: Aşırı ayrıntı
Ekip her ayrıntıyı anlatır ve SRS'yi 200 sayfalık bir kullanım kılavuzuna dönüştürür. Analist, işlevsel gereksinimlere ve iş mantığına odaklanmak yerine her tıklamayı, düğme rengini ve arayüz animasyonunu kaydeder. Sonuç olarak, belge okunamaz hale gelir, temel gereksinimlere odaklanma kaybolur ve geliştiricilerin ve tasarımcıların karar vermesi gereken uygulama ayrıntılarını açıklamak için zaman harcanır.
Çözüm: Bir gereksinim belgesi, bir kullanım kılavuzu değildir. Her tıklamayı açıklamak zorunda değilsiniz. İşlevselliğe ve iş kurallarına odaklanın ve uygulama ayrıntılarını geliştiricilere bırakın. "Kullanıcı sağ alt köşedeki düğmeye tıklar, düğmenin rengi değişir, bir ilerleme çubuğu belirir" yerine, "kullanıcı değişiklikleri kaydeder, sistem verileri veritabanına yazar ve kaydın başarılı olduğunu belirten bir onay mesajı gösterir" yazın.
Sorun: Önceliklerin belirtilmemiş olması
Tüm gereksinimler eşit derecede önemli görünür. Geliştiriciler, teslim tarihleri sıkışık olduğunda neyi önce uygulamaya koyacaklarını veya nereden zaman kazanacaklarını bilemezler.
Çözüm: Her gereksinimi bir öncelik derecesiyleişaretleyin . Kritik: Bu işlevsellik olmadan sistem kullanılamaz. Önemli: İşlevsellik gereklidir, ancak geçici çözümler mevcuttur. Tercih Edilebilir: Kullanıcı deneyimini iyileştirir, ancak ertelenebilir. Önceliklendirme, ekibin önemli konulara odaklanmasına ve kaynaklar sınırlı olduğunda kararlar almasına yardımcı olur.
Sorun: Son kullanıcıların sürece dahil edilmemesi
Gereksinimler, sistemi her gün kullanacak kişilerle konuşulmadan yöneticiler ve analistler tarafından belirlenir. Sonuç olarak, sistem gerçek ihtiyaçları karşılamaz. Bir şirket, depo işlemlerini bölüm başkanının fikirlerine dayanarak otomatikleştirir ve depo personeli, kullanımı zor bir arayüz ve gereksiz alanlardan şikayet eder.
Çözüm: Her zaman son kullanıcılarla görüşün. Onlara gereksinim taslaklarını gösterin ve geri bildirim toplayın. Süreçlerle her gün çalışan kişiler, bu süreçlerin inceliklerini yöneticilerden daha iyi bilir. Kullanıcıların görevlerini anlattıkları ve şu anda nasıl çalıştıklarını adım adım gösterdikleri atölye çalışmaları düzenleyin.
SRS yazmak için en iyi uygulamalar
Yüksek kaliteli bir gereksinim belgesi oluşturmak, deneyimle gelişen bir beceridir. SRS belgeleriyle başarılı bir şekilde çalışan ekipler, kanıtlanmış yaklaşımları izler.
En başından itibaren tüm paydaşları sürece dahil edin
Gereksinimleri tek başınıza yazmayın. İşletme temsilcilerini, son kullanıcıları, geliştiricileri, test uzmanlarını ve mimarları düzenli toplantılar için bir araya getirin. Her grup, sisteme kendi açılarından bakar ve diğerlerinin gözden kaçırdığı önemli ayrıntıları fark eder.
Görseller kullanın
Diyagramlar, grafikler ve arayüz maketleri, karmaşık kavramları metinden daha iyi açıklar. Tek bir resim, bir sayfalık açıklamayı ikame edebilir.
Eylemlerin sırasını gösteren süreç diyagramları ekleyin. Harici sistemlerle entegrasyonların diyagramlarını çizin. Kritik işlevler için ekran prototipleri oluşturun. Görsel materyalleri "Ekler" bölümüne yerleştirin ve gereksinim metninde bunlara atıfta bulunun.
Test edilebilir gereksinimler yazın
Her gereksinim şu soruyu yanıtlamalıdır: "İşlevselliğin doğru çalıştığını nasıl doğrularız?" Gereksinimleri, bir test uzmanının net bir test senaryosu oluşturabileceği şekilde ifade edin.
Yanlış: " Sistem, kullanıcı verilerinin güvenliğini sağlar." Bunu nasıl kontrol edersiniz? Bu net değildir.
Doğru: " Sistem, veritabanında depolanan tüm kullanıcıların kişisel verilerini AES-256 algoritması kullanarak şifreler. Şifreler, maliyet faktörü 12 olan bcrypt hash'leri olarak saklanır. İstemci ile sunucu arasındaki veriler, TLS 1.3 kullanılarak HTTPS üzerinden iletilir."
Gereksinimleri bağımsız atomik birimlere ayırın
Tek bir maddede farklı işlevleri karıştırmayın. Her gereksinim kendi içinde tam olmalı: diğerlerinden ayrı olarak anlaşılabilmeli ve uygulanabilmelidir.
Kötü: "Kullanıcı oturum açar, sipariş listesini görür, bunları duruma ve tarihe göre filtreleyebilir, bir elektronik tabloya aktarabilir ve seçilen siparişleri yazdırmaya gönderebilir."
Doğru: bunu ayrı gereksinimlerebölün :
- FR-010: Kullanıcı, kullanıcı adı ve şifre ile oturum açar;
- FR-011: Sistem, kullanıcının sipariş listesini görüntüler;
- FR-012: Kullanıcı, siparişleri duruma göre filtreler;
- FR-013: Kullanıcı, siparişleri tarih aralığına göre filtreler;
- FR-014: Kullanıcı, sipariş listesini bir elektronik tabloya (XLSX) aktarır;
- FR-015: kullanıcı, seçtiği siparişleri yazdırmaya gönderir.
Gereksinimleri tanımlamak için şablonları kullanın
Biçimi standartlaştırın. Her işlevsel gereksinimi aynı yapı kullanarak tanımlayın: tanımlayıcı, ad, açıklama, öncelik, girdi verileri, sonuç, hata işleme.
Örnek şablon:
FR-XXX. İşlev adı
Öncelik: kritik / önemli / arzu edilen
Açıklama: kullanıcının ne yaptığı ve sistemin nasıl yanıt verdiği
Giriş verileri: kullanıcınınneyi girdiği veya seçtiği
Sonuç: İşlem tamamlandıktan sonra kullanıcının elde ettiğisonuç
Hatalar: sistemin geçersiz verilerenasıl tepki verdiği
İlgili gereksinimler: bağımlı işlevselliğe bağlantılar
Bir şablon, önemli ayrıntıları gözden kaçırmamanıza yardımcı olur ve belgede gezinmeyi kolaylaştırır.
MoSCoW önceliklendirme yöntemini kullanın
MoSCoW yöntemi, gereksinimleri dört kategoriye ayırır:
- Olmazsa olmaz: sistemin çalışması için zorunlu olan gereksinimler;
- Olması iyi olur: önemli gereksinimler, ancak geçici çözümler mevcuttur;
- Olabilir: arzu edilen iyileştirmeler;
- Olmayacak: mevcut sürüme kesinlikle dahil edilmeyecek gereksinimler.
Bu sınıflandırma, kaynaklar sınırlı olduğunda karar vermenize yardımcı olur. Her şeyi sunamıyorsanız, önce "Olması Gerekenler"i, ardından "Olması Tercih Edilenler"i ve en son olarak da "Olabilirse İyi Olur"ları gerçekleştirin.
