Giriş
System Software Specification (SSS) ve Software Requirements Specification (SRS) bir çok projede karşımıza çıkan iki belge. Aşağıda bu iki belge ile ilgili aldığım notlar var.
SSS Notları
Sistem Kalite Etkenleri ile İlgili Gereksinimler
SSS belgelerinde bazen aşağıdakine benzer sistem kalite etkenleri görüyorum. Bunları not etmek istedim.
Sistem kalite etkenleri, işlevsel olmayan ancak bir yazılımın "iyi", "sürdürülebilir", "güvenilir", "verimli", "kabul edilebilir" olması gibi "yüksek kalite" özelliklerini belirtirler.
Kalite ile "ölçülebilirlik" ayrılmaz ikilidirler. Aşağıdaki kavramların bir çoğu dolaylı olarak ölçülebiliyor.
Reliability
Bu kavram ile maturity,fault tolerance,recoverability kelimeleri genellikle iç içe kullanılırlar. Örnek:
System shall run on two identical servers for redundancy.
Maintainability
System shall have ethernet interface for maintenance purpose.
System shall record failures onto disk.
Availability
Örnek yaz
Flexibility
Örnek yaz
Portability
Bu kavram ile Adaptability, Instability, Co-existance, Replacability kelimeleri genellikle iç içe kullanılırlar.
Örnek yaz
Reusability
Örnek yaz
Testability
Örnek yaz
Usability
Bu kavram ile Undestandability, Learnability, Operability, Attractiveness kelimeleri genellikle iç içe kullanılırlar.
Örnek yaz
Deployability
Örnek yaz
SSS'in SRS'e Aktarımı
SSS belgesi SRS için girdi teşkil eder. Aktarımın tam yapıldığından emin olmak için izlenebilirlik (traceability) matrisinin olması ve her iki belgenin de gözden geçirilmesi (review) gerekir.
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.
Türkçe Karşılığı
Aselsan'da 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.
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.
Bazı gereksinimler ise "Non-Functional" olarak sınıflandırılırlar. Bu tür gereksinimler genellikle (performance, reliability, and interoperability) yazılımın tasarım ve mimarisini şekillendiren gereksinimlerdir.
İ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.
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
Bazı örnek gereksinimler :
Maintainability Requirements
Örnek yaz
Availability Requirements
Örnek yaz
Flexibility Requirements
Örnek yaz
Portability Requirements
Reusability Requirements
Örnek yaz
Testability Requirements
Bu iyi bir örnekmi bilmiyorum ancak aşağıdakine benzer cümleler gördüm.
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
Bazı ölçütleri not ediyorum.
Clarity
Anlaşılabilirlik. Örneğin kullanılan terminolji anlaşılabilir olmalı.
Completeness
Bütünlük. Bir örneği buradan aldım.
Consistency
Tutarlılık. Bir örneği buradan aldım.
Interfaces
Sistemin tüm arayüzleri tanılanmış olmalı. Arayüzlerde kullanılacak iletişim yöntemi belirlenmiş olmalı.
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.
DOORS Notları
Aşağıda DOORS ile ilgili notlarım mevcut.
Favorites
Doors Database ekranında bu menü kullanılarak bir modüle kısayol konulabilir.
Object ID
Object ID'sine gitmek için Ctrl + G kısayolu kullanılabilir.
Başka Object'e Giden Linki Takip Etmeke
Doors'ta sağ taraftaki dışarı bakan kırmızı oka tıklanınca seçili maddenin başka bir belgedeki hangi maddeden kaynaklandığı görülebilir. (out link)
Dizin Yapısı
Doors dizinleri aşağıdaki gibi Sistem ve Yazılım ayrımını gösterecek şekilde olabilir.
Doors 8.1 ile gereksinimleri Word dokümanına aktarmak için araç çubuğundaki Word simgesine tıklanır. Açılan pencereden "Layout" olarak "Table" seçilir ve gereksinimler Word belgesine aktarılır.
Doors'u Şifre Girmeden Çalıştırmak
-d databasenam -u username -p password seçenekleri kullanılır. Örnek:
"C:\Program Files (x86)\Telelogic\DOORS_8.1\bin\doors.exe" -d databasename -u username -p password
DXL
Doors için scripting yapabilme imkanı tanır. C'ye benzer. Açılımı Doors Extension Language. Aşağıda bazı örnekler var. Bu dil büyük küçük harf farkına hassas değildir. (case insensitive) Bir değişkeni tipini tanımlamaya gerek kalmadan kolayca i =5 yazabiliriz.
Modulu Dolaşan Kod
string modulePath = "/Path/..."
string viewName = "MyView"
Module m = read (modulePath,true)
if (m != null)
{
bool success = load (m,view (viewName))
if (success)
{
Object o
for o in m do
{
print o."Last Modified By" "\n"
}
}
else
{
print "Could not load view" viewName
}
}
else
{
print "Could not open view" modulePath
}
DXL ile If Koşulu
DB dlgBox = create ("Input Box") //Formu başlık ile yarat
fileName (dlgBox,"Choose file","*.txt","Text Files") //Forma widget ekle
void okClick (DB dlgBox) {...}//Click handler
realize dlgBox
show dlgBox //Formu göster
Modul'e Ait Attribute Bulma
Stream ofstream;
ofstream = write ("C:\\file.txt")
ofstream << "test" nl
System Software Specification (SSS) ve Software Requirements Specification (SRS) bir çok projede karşımıza çıkan iki belge. Aşağıda bu iki belge ile ilgili aldığım notlar var.
SSS Notları
Sistem Kalite Etkenleri ile İlgili Gereksinimler
SSS belgelerinde bazen aşağıdakine benzer sistem kalite etkenleri görüyorum. Bunları not etmek istedim.
Sistem kalite etkenleri, işlevsel olmayan ancak bir yazılımın "iyi", "sürdürülebilir", "güvenilir", "verimli", "kabul edilebilir" olması gibi "yüksek kalite" özelliklerini belirtirler.
Kalite ile "ölçülebilirlik" ayrılmaz ikilidirler. Aşağıdaki kavramların bir çoğu dolaylı olarak ölçülebiliyor.
Reliability
Bu kavram ile maturity,fault tolerance,recoverability kelimeleri genellikle iç içe kullanılırlar. Örnek:
System shall run on two identical servers for redundancy.
Maintainability
System shall have ethernet interface for maintenance purpose.
System shall record failures onto disk.
Availability
Örnek yaz
Flexibility
Örnek yaz
Portability
Bu kavram ile Adaptability, Instability, Co-existance, Replacability kelimeleri genellikle iç içe kullanılırlar.
Örnek yaz
Reusability
Örnek yaz
Testability
Örnek yaz
Usability
Bu kavram ile Undestandability, Learnability, Operability, Attractiveness kelimeleri genellikle iç içe kullanılırlar.
Örnek yaz
Deployability
Örnek yaz
SSS'in SRS'e Aktarımı
SSS belgesi SRS için girdi teşkil eder. Aktarımın tam yapıldığından emin olmak için izlenebilirlik (traceability) matrisinin olması ve her iki belgenin de gözden geçirilmesi (review) gerekir.
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.
Türkçe Karşılığı
Aselsan'da 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.
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."Non-Functional Gereksinimler Nedir?
Bazı gereksinimler ise "Non-Functional" olarak sınıflandırılırlar. Bu tür gereksinimler genellikle (performance, reliability, and interoperability) yazılımın tasarım ve mimarisini şekillendiren gereksinimlerdir.
İ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.
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
Bazı örnek gereksinimler :
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
Bazı ölçütleri not ediyorum.
Clarity
Anlaşılabilirlik. Örneğin kullanılan terminolji anlaşılabilir olmalı.
Completeness
Bütünlük. Bir örneği buradan aldım.
An incomplete requirement provided to the business analyst that led to a bug in implementation. Example: The user says to the analyst "We only record a customer when a sale is made". A developer getting this requirement may end-up creating a DDL rule that makes the relationship of customer and invoice mandatory such that when an invoice is deleted the corresponding customer information is also deleted. Unless the developer and business analyst confirm with the user that this required, this searing may be considered as a bug in requirements (and development).
Consistency
Tutarlılık. Bir örneği buradan aldım.
A requirement provided by the end-user that conflicts with another requirement or constraint. Example: The user wants to email all customers but does not want the system to collect customer emails.
Interfaces
Sistemin tüm arayüzleri tanılanmış olmalı. Arayüzlerde kullanılacak iletişim yöntemi belirlenmiş olmalı.
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.
DOORS Notları
Aşağıda DOORS ile ilgili notlarım mevcut.
Favorites
Doors Database ekranında bu menü kullanılarak bir modüle kısayol konulabilir.
Object ID
Object ID'sine gitmek için Ctrl + G kısayolu kullanılabilir.
Başka Object'e Giden Linki Takip Etmeke
Doors'ta sağ taraftaki dışarı bakan kırmızı oka tıklanınca seçili maddenin başka bir belgedeki hangi maddeden kaynaklandığı görülebilir. (out link)
Dizin Yapısı
Doors dizinleri aşağıdaki gibi Sistem ve Yazılım ayrımını gösterecek şekilde olabilir.
Software Products/SSS/XXXWord'e Aktarım
Software Products/SRS/YYY
Doors 8.1 ile gereksinimleri Word dokümanına aktarmak için araç çubuğundaki Word simgesine tıklanır. Açılan pencereden "Layout" olarak "Table" seçilir ve gereksinimler Word belgesine aktarılır.
Doors'u Şifre Girmeden Çalıştırmak
-d databasenam -u username -p password seçenekleri kullanılır. Örnek:
"C:\Program Files (x86)\Telelogic\DOORS_8.1\bin\doors.exe" -d databasename -u username -p password
DXL
Doors için scripting yapabilme imkanı tanır. C'ye benzer. Açılımı Doors Extension Language. Aşağıda bazı örnekler var. Bu dil büyük küçük harf farkına hassas değildir. (case insensitive) Bir değişkeni tipini tanımlamaya gerek kalmadan kolayca i =5 yazabiliriz.
Modulu Dolaşan Kod
string modulePath = "/Path/..."
string viewName = "MyView"
Module m = read (modulePath,true)
if (m != null)
{
bool success = load (m,view (viewName))
if (success)
{
Object o
for o in m do
{
print o."Last Modified By" "\n"
}
}
else
{
print "Could not load view" viewName
}
}
else
{
print "Could not open view" modulePath
}
DXL ile If Koşulu
if (null current Module) {Hata Kutusu Çıkartma
ack "Hata"
halt
}
string mesaj = "Hata mesajı\n. Hata açıklaması"Dosya Dizini Alan Kutu
ack mesaj
halt
DB dlgBox = create ("Input Box") //Formu başlık ile yarat
fileName (dlgBox,"Choose file","*.txt","Text Files") //Forma widget ekle
void okClick (DB dlgBox) {...}//Click handler
realize dlgBox
show dlgBox //Formu göster
Modul'e Ait Attribute Bulma
AttrDef attr1 = find (current Module, "Attr1")Stream
if (null attr1) {
halt
}
Stream ofstream;
ofstream = write ("C:\\file.txt")
ofstream << "test" nl
Hiç yorum yok:
Yorum Gönder