Gereksinim Mühendisliği
Nedir?
• Bu bölümde köprü gibi komplex bir sistem üzerinden örnek verilmiş.
• Nerede olacağı ne tarz özellikleri olacağı gibi…
• Burada görülen problem yeteri kadar ayrıntılı bilgi içermemesi
fakat genel anlamıyla ne olduğu nasıl olması gerektiği anlaşılıyor.
• Diğer karışık sistemlerde biomekanikal ve nanoteknoloji gibi çok fazla özelliği olduğu belirtilmiş.
• Pamela Zave ise şu şekilde bir açıklama getirmiş:
• Gereksinim mühendisliğinin yazılım mühendisliğinin bir dalı
olduğunu gerçek yaşamla alakasını yazılım özellik davranışını ve zaman geçtikçe değişimi şeklinde açıklamış
• Fakat biz bu yorumu bütün sistemlere entegre edecek olursak şu şekilde bir açıklama daha uygun oluyor. Gereksinim mühendisliği gerçek dünya problemleriyle ilgilenen sistemlerle bağlantılı olan mühendisliğin bir dalı. Sistemin davranış kesinliği ile ilgili olması ve zamanla değişime uğraması aynı zamanda diğer alakalı
sistemlerle bağlantılı olmasıdır.
• Kırmızı ile işaretlenenler ise Zave’in yorumundan yaptığımız
farklılıklar. Diğer bölümlerde de bu tanımın daha ayrıntılı şekilde
incelenecek
Büyük İhtimalle Yeteri Kadar Gereksinim
Mühendisliği Yapmıyorsunuz
• Araştırmalar gösteriyor ki sektörde yeteri kadar iyi gereksinim mühendisliği yapılmıyor.
• Farklı markaların yaptığı anketlerde karışık gömülü sistemlerin
gereksinim incelemesinde gereksinim mühendisliğinin yetersiz kaldığı gözüküyor
• Yetersiz kalmasında diğer bir sebep de aktivite ölçeklendirmesin sıkıntı yaşadıkları diğer sebep endüstriyel mühendislikte gereksinim
mühendisliği bariz yetersizlik yaşadığıdır.
• Bu yetersizliklerin düzeltilmesinde de önemli bir yol kat edilmesi gerekmektedir
Gereksinimler Nelerdir?
• Asıl zorluk aslında gereksinim kelimesinin ne olduğundan geliyor.
• Gereksinimler yüksek seviyeli peçetinin arka yüzü çizimleri gibi matematiksel şeyler olabilir
• Paydaşların ne istediğine bağlı olarak farklı seviye gereklilik soyutlama gibi özelliklere sahip olabilir. Paydaşlar aynı zamanda bu sunumları
okur ve anlayabilir.
Gereksinimler ve Hedefler
• Müşteriler genelde gereklilik amacı karıştırıyor. Gereksinim mühendisi için de asıl sorun bu oluyor.
• Amaç genel anlamda oluşacak projeyi belirtir fakat gereksinim bu sistem için amaç nasıl olacak anlamı taşır.
• Bu kısımda bir örnek verilmiş ulaştırma bakanlığının amacı dünyadaki en güvenli köprüyü yapmaktır fakat bu köprü yapılırken hangi
malzemelerin kullanılacağı nasıl yapılacağı gibi sorular gereksinime girer.
• Bir hedef gereklilik olarak ele alınmamalı. Bununla birlikte paydaşlar amaç kısmında fikirlerini değiştirebilir.
Gereksinimlerin Sınıflandırılması
• Kullanıcı, sistem, dizayn olarak 3’e ayrılır
• Kullanıcı ifadeleri kendi dilleriyle söylenmiş sözlerdir. Ne olması gerektiği veya olmaması gerektiğini anlatır.
• Toplanan kullanıcı gereksinimleri conops adı verilen bir dosyada
toplanır(consept of operations). Birçok durumda kullanıcı hikayeleri kullanıcı gereksinimi olarak kullanılır.
• Sistem gereksinimleri ise servis ve kısıtlamalarla ilgili daha çok ayrıntı içerir. Bu gereksinimler SRS denilen bir belgede toplanır. Use- case
diyagramları çoğu zamanda sistem gereksinimi olarak rol oynar. Farkı anlamak için şu örnek incelenebilir.
• Kullanıcı gereksinimi: Sistem dakikada 20 çantayı işlemeli
• Sistem gereksinimi:Her çanta yeni bir olayı başlatmalı bu yüzden her dakikada 20 olay olmalı.
• Bununla bağlantılı son sistem gereksinimleri: Sistem operasyonel modda her dakikada 20 çanta olayını işlemeli
• Eğer 1 dakika içerisinde 20’den daha fazla çanta olayı gerçekleşirse sistem… gibi
• Aynı şekilde bir pet shop için kullanıcı gereksinimi: Sistem dükkanda gerçekleşen bütün olayı doğru şekilde hesaplamalı
• Bazı sistem gerksinimleri her satışa bir satış kimliği atanacaktır, bir veya daha fazla satış öğesi olabilir, bir veya daha fazla indirim olabilir, yalnızca bir makbuz yazdırılabilir.
• Son olarak bununla bağlanıtılı yazılım özelliği sistem her satış işlemine benzersiz bir satış kimlik numarası atayacaktır. Her satış kimliğinin
kendisiyle ilişkilendirmiş sıfır veya daha fazla satış öğesi olabilir ancak her satış öğesi tam olarak bir satış kimliğine atanmalıdır
• Böylece ilk keşfedilen kullanıcı gereksinimleri temel alınır.
• Genellikle kullanıcı gereksinimlerinden sonra geliştirilen sistem gereksinimleri, emtegrasyon testi için temel olarak kullanılır ve bu kabul testinden önce gelir. Son olarak tasarım özellikleri sistem
gereksinimlerinden türetilen her bir kod birimi olarak birim testi için kullanılır
