MIL-STD-498 -SRS

Giriş
System Software Specification (SSS) ve Software Requirements Specification (SRS), Hardware Requirements Specification (HRS) bir çok projede karşımıza çıkan iki belge. Aşağıda bu belgeler ile ilgili aldığım notlar var. SSS, SRS ve HRS gibi belgelerin sadece yazıya dayalı olması iyi değil. Çünkü aşağıdaki cümlede ifade edildiği gibi yazıyı zihnimizde canlandırmak kolay değil.

Most people are bad at mentally mapping documentation to actions.

Dolayısıyla bu belgelerin şekiller ile desteklenmesi gerekiyor. SSS ve SRS genellikle CDRL listesine dahil edilirler.

Açık Kaynak/Open Source Projeler

Bu projelerin çoğunda SRS bulunmaz.

Requirements Analysis
SRS kullanılan yaşam döngüsü modeline göre Requirements Analysis (Gereksinim Analizi) safhasının veya yinelemelerinin sonucunda ortaya çıkar. Açıklaması şöyle.

Requirement Analysis is that it is a process and the document created during this process is SRS (Software Requirement Specification).

CDRL (Contract Data Requirements List) Nedir?

CDRL sözleşmenin bir lahikası olarak belirtirlir. Müsteriye teslim edilecek dokümanları listeler. Türkçesi SVIL'dir (Sozleşme Veri İsteri Listesi).

SRS

Bir CSCI'ın geliştirilmesi için kullanılan gereksinimleri içeren doküman. Projede her CSCI bileşeninin kendi SRS dokümanının olması gerekir. Bazı projelerde User Requirements diye bir belge de üretiliyor ama tam ne işe yarar bilmiyorum.

Türkçe Karşılığı
Yazılım Gereksinim Özellikleri (YGÖ) kelimesi kullanılıyor. Bence makul bir karşılık.

Dili
SRS belgesini bir çok firma İngilizce olarak hazırlamaya çalışıyor. Hazırlayanların ana dili İngilizce olmadığı için ifade bozuklukları, anlaması güç cümleler ile dolu olabiliyor. Türkçe hazırlanırsa da karşılıkları olmadığı için mecburen İngilizce kavramlar/kelimeler kullanılıyor. Her iki durum da hoş değil.

İngilizce yazılan gereksinimlerde niçin "shall" kelimesinin kullanıldığı burada açıklanmış. Türkçesi "yapacaktır" gibi düşünülürse, daha bir kesinlik manası sağladığı için "will" yerine "shall" kullanılıyor.

IEEE SRS
IEEE SRS dokümanında şu konulara değinilmesini istiyor

1.Interfaces
2.Functional Capabilities
3.Performance Levels
4.Data Structures/Elements
5.Safety
6.Reliability
7.Security/Privacy
8.Quality
9.Constraints and Limitations

Başlıklar olarak şöyle yapılabilir.

1.Introduction 1.1 Purpose 1.2 Document conventions 1.3 Intended audience 1.4 Additional information 1.5 Contact information/SRS team members 1.6 References

2.Overall Description 2.1 Product perspective 2.2 Product functions 2.3 User classes and characteristics 2.4 Operating environment 2.5 User environment 2.6 Design/implementation constraints 2.7 Assumptions and dependencies

3.External Interface Requirements 3.1 User interfaces 3.2 Hardware interfaces 3.3 Software interfaces 3.4 Communication protocols and interfaces

4.System Features 4.1 System feature A 4.1.1 Description and priority 4.1.2 Action/result 4.1.3 Functional requirements 4.2 System feature B

5.Other Nonfunctional Requirements 5.1 Performance requirements 5.2 Safety requirements 5.3 Security requirements 5.4 Software quality attributes 5.5 Project documentation 5.6 User documentation

6.Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined

Interfaces Nedir
1. User Interfaces
2. Hardware interfaces
3. Software interfaces
4. Communication Interface

olarak düşünülebilir.

User Interfaces başığı altına (the buttons, sliders, text boxs etc..) gibi şeyler yazılabilir deniyor. ancak ben hiç yazıldığını görmedim.

SRS Mimari ve Tasarım
SRS problem uzayı, tasarım ve mimari ise çözüm uzayında gibi düşünülüyor. Ancak bence tam olarak birbirlerinden bu kadar bağımsız şeyler değiller.

Örnek
Şöyle bir soru olsun.

A software Requirements Specification (SRS) document should avoid discussing which one of the following ?
(A) User interface issues
(B) Non-functional requirements
(C) Design specifications
(D) Interfaces with third party software

Cevabı (C) Design Specifications.

Örnek
"A Comparison of Requirements Specification Methods from a Software Architecture Perspective" makalesi SRS maddelerinin, yazılımın mimarisini ne kadar etkilediği konusunu işliyor. Makaleden bir kaç cümle şöyle.

"If functionality is the only concern in designing an architecture, any structure will do. This conclusion stems from the work of Parnas more than 30 years ago."

Devam ediyor.

"Connecting requirements to architecture can be viewed as a special case of connecting a system's problem space and its solution space".

SRS Geliştirme Eforu
Geliştirme eforunun yaklaşık yüzde 40'ı gereksinim ve tasarım aşamasına ayrılırsa iyi olur.

SRS Belgesinde Kullanılan Bazı Sütünlar

Derived Requirement

Aşağıda açıkladım
Verification Method

Doğrulama yöntemi. Test, Analysis, Inspection (Code Review, Design Review), Demonstration olabilir. Verification (doğrulama) yöntemi olmayan madde olmamalı.
Notes

Gereken notlar

Derived Gereksinimler Nedir
Bazı projelerde gereksinimler "Derived" olarak işaretlenirler. Derived Requirement sistem tasarımından kaynaklanmayan, sistem izlenebilirliği olmayan ister anlamına geliyor. Örneğin sistem tasarımı, yazılımın kaç bölümlenmeden (partition) oluşacağını söylemeyebilir. Ancak SRS'te bu ister bulunabilir. Bu durumda SRS'teki ister "Derived Requirement" olarak işaretlenir. Aşağıdaki cümle de önemli.

"These are requirements that are generated by the development team, based on a number of sources such as regulatory agencies, corporate guidelines, and past experiences on similar projects."

DO-178B kullanan projelerde bir gereksinimin derived olarak işaretlenebilmesi için "Safety Assesment" süreci tarafından onaylanmış olması gerekir.

Non-Functional Gereksinimler Nedir?
Non-Functional Gereksinimler yazısına taşıdım.

SRS ve Tasarım Arasında İzlenebilirlik Tablosu
Her SRS dokümanında, isterlerin hangi CSC'de ele alındığını gösteren bir izlenebilirlik tablosu bulunur. Aslında bu tablo genellikle işe yaramaz, çünkü SRS ve gerçek tasarım/kod arasında çoğunlukla büyük boşluklar bulunur. Mühendisler izlenebilirlik tablosunu kabaca kestirimlerine dayanarak doldururlar. SRS'i eline alıp okuyarak geliştirmeye başlayan bir mühendis, tek bir maddenin kaç bileşene dokunacağını, maliyetinin ne olacağını kestiremeyebilir.

DO-178B gibi süreçlerde ise bu boşluğu doldurmak üzere, High Level (bahse konu SRS belgesi) ve Low Level Requirements isimli iki belge üretilir. Low Level Requirements belgesi SRS ve kod/arasındaki boşluğu kapatır.

SRS ve Test Arasında İzlenebilirlik Tablosu
SRS ve Test (STD) arasında da izlenebilirlik kurmak gerekir. Hatta Test ve Test Sonuçları arasında da bağlantı kurulur.

Yazılım Kalite Etkenleri ile İlgili Gereksinimler

SRS belgelerinde bazen aşağıdakine benzer yazılım kalite etkenleri (software quality factors) görüyorum. Bunları not etmek istedim.

Functionality Requirements
Örnek yaz

Reliability Requirements
Örnek

X shall be able to process following data during N hours.

Maintainability Requirements
Örnek yaz

Availability Requirements
Örnek yaz

Flexibility Requirements
Örnek yaz

Portability Requirements

X shall be developed independent from OS specific system calls.

Reusability Requirements
Örnek yaz

Testability Requirements
Bu iyi bir örnekmi bilmiyorum ancak aşağıdakine benzer cümleler gördüm.

X shall provide health status. X shall perform BIT upon request.

Efficiency Requirements
Örnek yaz

Usability Requirements
Örnek yaz

Kalite Etkenleri Nasıl Test Edilir
Sistem veya Yazılım Kalite Etkenleri netice itibariyle birer gereksinim olduklarına göre, test edilmeleri de gerekir. Bu iş için "Fonksiyonel Olmayan Testler" başlığı altında toplanabilecek bazı faaliyetler gerçekleştirilir.
Performans Testleri :
Yükleme (Load) Testleri : Sistemin belli bir yük altında testi
Stres Testleri: Sistemin aşırı yük altında testi
Uyumluluk (Compatibility) Testleri :
Güvenlik Testleri :
Kullanılabilirlik Testleri :
Yerelleştirme (Localization) Testleri : Çeviriler, tarih, saat formatı vs.

SRS Hataları
SRS'e donanım özelliklerini yazmak gördüğüm hatalardan birisi. Örneğin software shall run on 1 GB memory, 1GHz processor gibi. Bu tür bir gereksinim bence sistem seviyesinde olmalı.

Yazılımın kapasitesini belirten ancak throughput, gecikme, bir işin ne kadar birim zamanda yapılacağını belirtmeyen gereksinim maddeleri bence doğru değiller. Örneğin bir yazılım 5000 nesneyi bellekte tutacaktır denirse ancak bu 5000 nesneyi veya 1 tanesini ne kadar zamanda işleyeceği belirtilmezse, yazılımı test etmek için referans zamanı verilmemiş olur.


SRS Hangi Ölçütlere Göre Gözden Geçirilebilir
SRS Kontrol Listesi yazısına taşıdım.

Müşterinin SRS'e Yorum Vermesi
Sözleşmede genellikle SRS teslim edildikten X gün sonrasına kadar müşteri yorum verebilir şeklinde bir madde bulunur.

Benzer şekilde SRS'i hazırlayan taraf ta yine Y gün içerisinde yorumlara cevap vermekle mükelleftir, şeklinde bir madde ile taraflar SRS'i ciddiye aldıklarını belirtirler.

SRS Örnekleri
SRS Örnekleri yazısına taşıdım.

Baseline
İngilizce açıklaması şöyle

A specification or software product that has been formally reviewed or agreed upon, that thereafter serves as the basis for further development, and that can be changed only through a formal change control process.

Türkçe açıklaması şöyle

Resmi olarak gözden geçirilmiş veya üzerinde anlaşılmış ileriki geliştirmeler için temel teşkil edecek ve sadece resmi değişiklik kontrol süreci ile değiştirilebilen özellik veya yazılım ürünü.

SRS Değişiklikleri
SRS değiştiğinde eski ana hat (baseline) ile yeni anahatın farkını çıkarıp ekibe dağıtmak gerekir. Doors'ta Baseline Comparison Report alınabilir.