Gereksinim Mühendisliği (requirement engineering) (Kaynak: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

Geçmişi ve Temelleri Gereksinim Müh. deyimi lk defa 1979’da, yazılım alanı için kullanıldı. Amaç, büyük hacimli ve karmaşık yazılımların birden fazla alt yüklenici tarafından yapılıp bir araya getirilmesindeki olası riskleri azaltmaktı. 2003’te “30 Metrelik Teleskop” (TMT) projesinde, yazılım alanının dışında kullanılmaya başlandı.30 Metrelik Teleskop Şimdilerde, çeşitli ürünlerin, işçiliğin ucuz fakat eğitimli işgücünün bulunmadığı yerlerde üretilmesinde de kullanılıyor. “Yapı” son derece geniş ve karmaşıklığı yüksek olabilecek bir alan olduğu için, gereksinimlerin ortaya konulması (şartname) ve uygulanması aşamalarında kullanımı kaçınılmaz bir teknik olarak ortaya çıkıyor.

Geçmişi ve Temelleri (devam) “Yapı” son derece geniş ve karmaşıklığı yüksek olabilecek bir alan olduğu için, gereksinimlerin ortaya konulması (şartname) ve uygulanması aşamalarında kullanımı kaçınılmaz bir teknik olarak ortaya çıkıyor. Bu sunum, belirtilen kaynaktaki açıklamaların –mümkün olabildiğince- yazılım dışı alanlara da uygulanmasını kolaylaştıracak biçimde uyarlanmıştır. Beklentimiz, GM dalının, yüksek öğretim kurumlarının mühendislik dallarının hepsinde ortak bir disiplin olarak öğretilmesidir. Buna paralel bir diğer beklenti, iş örgütlerimizin bu konuda bir “talep ortamı” yaratmalarıdır.

Gereksinim Mühendisliği (GM) Gereksinim pratikleri ile ilgili sorunlar GM görevleri Başlangıç Ortaya koyma Ayrıntılandırma Müzakere Şartname Doğrulama Gereksinim yönetimi

5 Gereksinim pratikleri ile ilgili sorunlarımız Müşteriden aldığımız gereksinimleri anlamakta sorunlar yaşarız Gereksinimleri genelllikle organize olmayan bir şekilde kaydederiz. Neyi kaydetmiş olduğumuzu doğrulamak için çok az zaman harcarız Değişimi kontrol edecek mekanizmaları kurup işletmek yerine değişimin bizi kontrol etmesine izin veririz En önemlisi, kullanıcının kurmak istediği sistem için sağlam bir temel oluşturmak konusunda başarısız oluruz. (daha fazlası diğer slaytta)

6 Gereksinim pratikleri ile ilgili sorunlarımız (devamı) Birçok yüklenici genelde şunları ileri sürer –İşin yapımı o kadar zorlayıcı bir süreçtir ki, doğrudan işe girişmek isteriz (tam olarak neye gereksinim duyulduğunu açık olarak anlamadan) – İşi tamamlamaya yaklaştıkça, her şey daha açık hale geleektir. –Proje paydaşları, neye gereksinim duyduklarını işin ilk sonuçlarını irdeledikten sonra daha iyi ortaya koyabileceklerdir. –Her şey o kadar hızlı değişmektedir ki, Gereksinim Mühendisliği sdece zaman kaybıdır. –Gerçek sonuç, çalışan bir işey yapmaktır ve diğer herşey ikinci derecede önemlidir. Tüm bu argümanlar kısımi gerçekler içermektedir, özellikler ufak projelerin tamamlanması gerçekten de kısa süre alır. Bununla birlikte, işin boyutu ve karmaşıklığı büyüdükçe yukarıdaki argümanlar zayıflamakta ve başarısızlıkla sonuçlanacak bir sürece yol açabilmektedir.

7 Bir çözüm: GM İletişim ile başlar ve modelleme ile devam eder İşin nasıl yapılacağının tasarımı ve geliştirilmesi arasında bir köprü kurar. GM’nin şunları incelemesine olanak sağlar –İcra edilecek işlerin kapsamı –Tasarım ve geliştirme süreçlerinin sağlaması gereken gereksinimler –Tamamlanacak işlerin önceliklendirilmesi için gözetilmesi gereken sıra –Sonuçta ortaya çıkacak tasarım üzerinde derin etkisi olacak bilgi, işlev ve davranışlar

8 GM Görevleri 7 ayrı görev 1.Başlangıç 2.Ortaya koyma 3.Detaylandırma 4.Müzakere 5.Şartname 6.Doğrulama 7.GereksinimYönetimi Bu görevlerin bir ksımı paralel olarak yapılabilir ve proje gereksinimlerine göre uyarlanabilir. Tümü, müşterinin ne istediğini tanımlamaya uğraşır Tümü, işin tasarım ve yapısı için sağlam bir temel ortaya koyma amacına hizmet eder

9 gereksinim Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

10 Başlangıç Görevi Başlangıç sırasında, GM, aşağıdakileri ortaya çıkartmak için bir dizi soru sorar… –Sorunun temel olarak anlaşılması –Bir çözüm isteyen insanlar kimler? –İstenilen çözümün doğası –Müşteri ve gelişitirici arasındaki ilk iletişim ve işbirliğinin etkinliği Bu sorular yoluyla, GM aşağıdakileri hedefler... –Paydaşları ortaya çıkartmak –Farklı bakış açılarını tanımak –İş birliği ortamını sağlamak –Çekingenliği sona erdirerek iletişimi başlatmak

11 Birinci Soru Kümesi Bu iş talebinin arkasında kim var? Çözümü kim kullanacak? Başarılı bir çözümün ekonomik faydası ne olacaktır? Gerek duyduğunuz çözümü sağlayabilecek başka kaynak var mı? Bu sorular müşteri, diğer paydaşlar, genel hedefler ve faydalar üzerinde odaklanır

12 İkinci Soru Kümesi Başarılı bir çözüm tarafında üretilecek 'iyi' bir çıktıyı, nasıl karakterize edersiniz? Bu çözüm, hangi sorun(ları) hedefleyecek? Bana bu sorunun kullanılacağı iş ortamını gösterebilir ya da tarif edebilir misiniz? Çözüme yaklaşma yolunu etkileyebilecek özel performans konuları ya da kısıtları var mıdır? Bu sorular, GM’nin sorunu daha iyi anlamasına ve müşterinin sorun hakkındaki kendi algılamalarını seslendirmesine izin vermesini sağlar.

13 Nihai Sorular Kümesi Siz, bu soruları yanıtlamak için doğru kişi misiniz? Yanıtlarınız 'resmi' midir? Sorduğum sorular, sahip olduğunuz sorun ile ilgili midir? Çok fazla soru mu soruyorum? Başka birisi daha fazla bilgi sağlayabilir mi? Size, başka sorular da sormalı mıyım? Bu sorular, doğrudan iletişimin etkinliğine odaklanır

14 gereksinimler Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

15 Ortaya Koyma Görevi Gereksinimlerin ortaya koyulması şu nedenler dolasıyla zordur: Sistemin sınırlarını belirleme veya genel sistem hedefleri yerine çok fazla teknik detay belirteren kapsam sorunlarından, Ne istenildigini anlamanin problemli kapsaminin ne oldugu ve işlem ortamınin neyle başa çıkabilecegi (” bariz " olduğuna inanılan bilgiler genellikle ihmal edilir ) Gereksinimlerin zamanla değişmesinden doğan kaybolabilirlikler Gereksinimlerin ortaya çıkartılması şu iki yolla başarılabilir: İşbirliği halinde gerçekleşebilecek gereksinimleri toplama Kalite fonksiyonun yerine göre uygulanması

16 İşbirliği Gerektiren Gereksinimleri Biraraya Toplama Temel Kuralları Toplantılar, mühendisler, müşteriler ve diğer ilgili paydaşlar katılımıyla yürütülür. Hazırlık ve katılım için gerekli kurallar oluşturulur. Tüm önemli noktaları kapsayan kadar resmi ama fikirlerin özgür akımını destekleyecek kadar esnek bir gündem önerilir. Bir " moderatör" (müşteri, geliştirici veya dışarıdan ) toplantıyı yönetir. Not kağıtları, flip-chartlar, duvar çıkartmaları, elektronik bülten tahtası, sohbet odası, ya da başka bir sanal forum bir " tanım mekanizması ” olarak kullanılır. Amaç, sorunu tanımlamak çözümün unsurları önermek, farklı yaklaşımları müzakere etmek ve ön dizi çözüm gereksinimlerini belirtmektir.

17 Kalite Fonksiyonu Müşterinin ihtiyaçlarını, teknik gereksinimler yazılmına çeviren bir tekniktir. Bu, müşteriye neyin değerli olduğunu anlayışını vurgulamaktadır ve ardından mühendislik süreci yoluyla işlev, bilgi ve görevler yoluyla bu değerleri dağıtır. 3 çeşit gerekisinim tanımlar: –Normal gereksinimler: Bu şartlar, müşteri ile toplantılar sırasında bir ürün veya sistem için belirtilen amaç ve hedeflerdir. –Beklenilen gereksinimler: Bu gereksinimler, ürün veya sisteme örtülüdür ve de o kadar temel olabilirlerki müşteri onları açıkça ifade edemez. –Heyecan verici gereksinimler: Bu gereksinimler müşterinin beklentilerinin ötesine giden türdendir ve gercekleştiği zaman müşteriyi çok tatmin eder.

18 Ortaya Çıkarma Çalışması Ürünleri İhtiyaç ve fizibilitenin ortaya koyulması Sistem veya ürünün sınırlarının (kapsam) ortaya koyulması. gereksinimlerin ortaya çıkarılmasına katılan müşteriler, kullanıcılar ve diğer paydaşların bir listesi. Sistemin teknik ortamının bir açıklaması. Her biri için geçerli gereksinimler ve iş çevresinin kısıtlamaları listesi. Farklı çalışma koşulları altında sistemin veya ürünün kullanımı hakkında içgörü sağlayan (kullanım durumları şeklinde) bir dizi ön kullanım senaryoları gereksinimleri daha iyi tanımlamak için geliştirilen herhangi bir prototip. İş ürünleri, sisteme bağlı olarak değişebilir, ancak aşağıdaki öğelerden birini veya daha fazlasını içermelidir :

19 gereksinim Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

20 Detaylandırma Görevi Detaylandırılması sırasında, yazılım mühendisi başlangıç ​​ ve ortaya çıkarma sırasında elde edilen bilgileri alır ve genişletmeye ve iyileştirmeye başlar. Detaylandırma, yazılım fonksiyonlarının, özelliklerinin ve kısıtlamalarının rafine teknik bir modelini geliştirmeye odaklanmaktadır. Bu bir analiz modelleme görevdir. –Kullanım senaryoları geliştirilir. –Alan dersleri kendi nitelikleri ve ilişkileri ile birlikte tespit edilir. –Durum makine diyagramları bir nesne üzerinde hayatı yakalamak için kullanılır. –Sonuç, sorunun fonksiyonel, bilgilendirici ve davranışsal boyutlarını tanımlayan bir analiz modelidir.

21 Kullanım Senaryoları Geliştirme Adım 1- Senaryoda yer alacak aktörler kümesini tanımla. –Aktörler, insanlar, cihazlar veya tarif edilecek fonksiyon ve davranışlar bağlamında sistem veya ürün kullanan diğer sistemlerdir. –Aktörler sistem veya ürün ile iletişim içinde bulunmaktadırlar ve sistemin kendisi dışında bulunmaktadır. Adım 2- Her biri bir grup soruyu cevaplayan kullanım senaryoları geliştir. (Devamı bir sonraki slaytta)

22 Bir Kullanım Senaryosunca Cevaplanacak Yaygın Sorular Birincil aktör(ler) kimdir, ikincil aktör(ler) kimdir? Aktörün görevleri nelerdir? Senaryo başlamadan önce hangi koşullar bulunmalıdır? Aktör tarafından hangi asıl işler ve işlevler yerine getirilmelidir? Seneryo tanımlandıkça hangi istisnalar düşünülebilir? Aktörün etkileşiminde hangi çeşitlemeler mümkündür? Aktör hangi sistem bilgilerini elde edecek, üretecek ya da değiştirecektir? Aktör dış çevredeki değişiklikleri sisteme bildirmeli midir? Aktör sistemden ne çeşit bir bilgi istemektedir? Aktör, beklenilmeyen değşikliklerden haberdar edilmek ister mi?

23 Analiz Modelinin Elemanları Senaryo tabanlı elemanlar –Kullanım durumları ve aktivite diyagramları tasvir eden senaryolar kullanarak, kullanıcının bakış açısından sistemini tanımla. Sınıf tabanlı elemanlar –Aktörler, bu sınıfların nitelikleri ve birbirleriyle etkileşimleri tarafından manipüle edilen nesne alanların sınıflarını belirle. Bunlari yapmak için şemalar kullanılır. Davranışsal elemanlar –Sistemlerin durumunu, sistemin durumunu değişiren olayları ve belli bir olayın sonucunda atılan adımları gösteren durum şemaları kullan. Akış odaklı elemanlar –Bir sisteme gelen verileri, giriş verileri transformasyonu için hangi işlemlerin uygulandığını ve sonuçta hangi çıkış verilerinin üretildiğini göşteren veri akış şemaları kullan.

24 gereksinimler Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

25 Müzakere Görevi Müzakere sırasında, müşterinin istekleri ve iş kaynakları açısıdan olabilirlikler arasındaki uyuşmazlıklar çözülür. gereksinimler, müşteriler, kullanıcılar ve diğer paydaşlara göre sıralanıp önceliklendirilir. Her gereksinim ile ilgili riskler tanımlanır ve analiz edilir. Proje maliyeti ve teslim süresinin her gereksinim üzerindeki etkisini değerlendirmek için, geliştirme çabalarının kaba bir tahmini yapılır ve kullanılır. Iteratif bir yaklaşım kullanarak, her grubun memnuniyete ulaşabilmesi için belli bazı gereksinimler ortada kaldırılır, birleştirilir ya da modifiye edilir.

26 Müzakere Sanatı Bunun bir yarışma olmadığını farket. Stratejinin haritasını yap Aktif olarak dinle. Diğer grupların isteklerini dikkate al.. Konuyu kişiselleştirme. Yaratıcı ol. Görev üstlenmeye hazır ol.

27 gereksinim Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

28 Şartname (specs) Görevi Bir şartname, GM tarafından üretilen nihai üründür. Şartname, bundan sonra yapılacak mühendislik faaliyetleri için bir temel görevi yapar. Yapılacak işin bilgilendirme, fonksiyon ve diğer ihtiyaçlarını hem grafik hem de yazı formatında resmiyete döker.

29 Bir İhtiyaç Şartnamesinin Tipik İçeriği İhtiyaçlar –İstenilen durumlar ve modeller –İhtiyaçların gruplanmış yetenekleri (yani fonksiyonlar, nesneler gibi) –Yüklenici dışındakilerle bağlantılar –Yüklenici ile ilişki ihtiyaçları –Bilgi ihtiyaçları –Diğer ihtiyaçlar (güvenilirlik, güvenlik, gizlilik, çevre, donanım, yazılım, iletişim, kalite, işgücü, eğitim, lojistik vd) –Tasarım ve uygulamadaki olası sınırlamalar Her bir ihtiyacın karşılandığından emin olmak –Demo, test, analiz, kontrol, vbg. Gereksinimlerin izlenebilirliği –Sistemin bütünü ya da alt sistemlerde her bir gereksinimin yerine geldiğinin geriye doğru izlenebilirliği

30 gereksinim Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

31 Doğrulama Görevi Doğrulama sırasında, GM’nin bir sonucu olarak ortaya çıkan ürünler kalite açısından değerlendirilir. Şartnamenin şunları yerine getirdiğinden emin olunur: –Tüm gereksinimler hiçbir belirsizlik içermeyecek şekilde belirtilmiştir, –Tutarsızlıklar, ihmaller veya hatalar tesbit edilip düzeltilmiştir, –Süreç. Proje ve ürünler standartlara uymaktadır, Resmi bir teknik gözden geçirme, doğrulama mekanizmasının birincil yöntemidir. –Gözden geçirme ekibinde mühendisler, müşteriler ve diğer paydaşlar bulunur.

32 Doğrulama İhtiyaçları için Sorulacak Sorular Her bir gereksinim, sistem veya ürün’ün bütüncül amaçları ile tutarlı mı? Tüm gereksinimler uygun bir soyutlama düzeyi ile belirtilmiş mi? Yani, bir düzeydeki bir gereksinim bir başka teknik detay ile çelişiyor mu? Bir gereksinim gerçekten gerekli mi yoksa sistemin temel amaçlarına hizmet etmeyen optional bir eklenti mi? Her bir talebin çerçevesi belli ve belirsizliklerden arınmış mı? Herhangi bir gereksinim bir diğeri ile çelişiyor mu? Her bir gereksinim teknik olarak gerçekleştirilebilir mi? Her bir gereksinim yerine getirildikten sonra test edilebilir mi?

33 gereksinim Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname

34 Gereksinimlerin Yönetimi Görevi Gereksinim yönetimi sırasında proje takımı, gereksinimlerin tanımlanması, kontrolu ve izlenmesi; proje ilerledikçe de gereksinimlerde olabilecek değişiklikler için bir dizi eylem gerçekleştirir. Her ihtiyaca özgün bir tanımlama kodu atanır. Sonra her gereksinim bir veya birden fazla izleme tablosuna yerleştirilir. Bu tablolar bir veri tabarı olarak kullanılabilir. Bir ihtiyaç izleme tablosu, ihtiyaç şartnamesinin sonuna eklenir.

35 gereksinim Yönetimi Doğrulama Başlangıç Ortaya koyma Detaylandırma Müzakere Şartname Özet