Sistem Mühendisliğine Giriş - Tüm Dersler

Sistem Mühendisliğine Giriş
Emir SADE
emirsade@buyutech.com.tr
2023
Dersin Amacı
➢ Sistem Mühendisliği disiplinini anlamak ve temel kavramları öğrenmek

➢ Karmaşık sistemlerin yönetimi ve tasarımı hakkında bilgi edinmek
➢ Sistem Mühendisliği ilkelerini gerçek dünya uygulamalarıyla ilişkilendirmek
➢ Sistem Mühendisliği projelerine yönelik temel becerileri geliştirmek
1 Copyright © www.buyutech.com.tr
1. 2.
Hafta
İçerik
➢ Sistem Mühendisliğine Giriş

➢ Genel Tanım
➢ Sistem Mühendisliğinin Temel Kavramları
➢ Sistem Mühendisliğinin Tarihsel Gelişimi
➢ Sistem Mühendisliği ve Diğer Disiplinlerle İlişkisi
➢ Sistem Mühendisliği İlkeleri ve Süreç
Genel Tanım
Sistem Mühendisliği Tanımı
➢ Sistem Mühendisliği:
➢ Bir disiplin olarak karmaşık sistemlerin tasarımı, geliştirilmesi ve yönetimi ile ilgilenir.
➢ Çeşitli disiplinlerin (mühendislik, proje yönetimi,…) bir araya geldiği disiplinlerarası bir alandır.
Neden Sistem Mühendisliği?
➢ Sistem Mühendisliği:
➢ Karmaşık sistemleri anlamak ve yönetmek için bir yaklaşım sunar
➢ Verimlilik, güvenilirlik ve güvenlik sağlama potansiyeline sahiptir
➢ Karmaşık Sistemler:
➢ Günümüz dünyasında karmaşıklık artıyor
➢ Büyük ölçekli projeler ve sistemler daha fazla koordinasyon gerektiriyor
➢ Sistem Mühendisi alanları:

➢ Savunma Sanayi, Uzay ve Havacılık, Otomotiv gibi sektörlerde iş imkanları
➢ Yüksek talep ve rekabetçi maaşlar
Sistem Mühendiliğinin Avantajları
➢ Proje Başarısını Artırma

➢ Sistem mühendisliği, karmaşıklığı daha iyi yönetme ve projelerin başarılı bir şekilde
tamamlanmasını sağlama konusunda yardımcı olur.
➢ Maliyet Düşürme
➢ İyi bir sistem mühendisliği yaklaşımı, gereksiz harcamaları azaltabilir ve projelerin bütçesini korur.
Sistem Mühendisliğinin
Temel Kavramları
Sistem Nedir?
➢ Sistem Tanımı:
➢ Sistem, bir veya daha fazla bileşeni veya parçayı bir araya getiren ve belirli bir amacı veya
fonksiyonu gerçekleştirmek için çalışan bir organizasyondur.
➢ Parçalar ve İlişkiler:
➢ Bir sistem, alt sistemlere veya bileşenlere sahip olabilir ve bu parçalar arasında belirli ilişkiler
bulunabilir.
➢ Amaç ve Fonksiyonlar:
➢ Her sistem, belirli bir amaç veya fonksiyonu gerçekleştirmek için tasarlanmıştır.
Karmaşıklık
➢ Sistemlerin Karmaşıklığı:
➢ Karmaşıklık, bir sistemin içerdiği parçaların ve bu parçalar arasındaki ilişkilerin miktarı ve
karmaşıklığıdır.
➢ Modülerlik ve Entegrasyon:
➢ Sistemler, modüler bir yapıda olabilir, yani parçalara ayrılabilir ve daha sonra entegre edilebilir.
➢ Karmaşıklığı Yönetmek:
➢ Sistem mühendisliği, karmaşıklığı yönetme ve sistemi anlama sürecini sağlar.
Çok Disiplinli Yaklaşım
➢ Yaklaşım:
➢ Sistem mühendisliği, mühendislik alanında (yazılım, donanım, mekanik,…) çeşitli disiplinlerden
gelen bilgi ve yöntemleri birleştirir.
➢ Disiplinlerarası İşbirliği:
➢ Farklı disiplinlerden gelen uzmanlar, karmaşıklıkla başa çıkmak için işbirliği yaparlar.
➢ Farklı Bakış Açıları:

➢ Her disiplin, sistemi farklı bir bakış açısıyla ele alır ve bu farklılıkların avantajlarını kullanır.
Sistem Mühendisi
➢ Sistem Mühendisinin Rolü:
➢ Sistem mühendisi, karmaşık sistemlerin tasarımı, geliştirilmesi ve yönetimi süreçlerini koordine
eden kişidir.
➢ Sorumluluklar ve Görevler:
➢ Fizibilite analizi, gereksinim analizi, sistem tasarım, entegrasyon, test gibi süreçlerin yönetimi ve
denetimi
➢ Tümünün Ötesinde Düşünme:

➢ Sistem mühendisleri, tüm sistemi anlamak için parçaların ötesine geçer ve sistemin büyük
resmini görme yeteneğine sahiptir.
➢ İlişkili Süreçler ve Etkiler:

➢ Bir değişiklik veya kararın bir parçada nasıl etkiler yaratacağını anlarlar ve bu etkileri
değerlendirirler.
Sistem Mühendisliğinin
Tarihsel Gelişimi
Tarihsel Gelişimi
➢ Öncü Dönemler - (1940-1960)
➢ II. Dünya Savaşı Dönemi

➢ Örnek: Manhattan Projesi
➢ İkinci Dünya Savaşı sırasında geliştirilen atom bombası, sistem mühendisliği ilkelerinin uygulandığı
erken bir projeydi
➢ Soğuk Savaş Dönemi

➢ Örnek: RAN (Radar And Navigation) Projesi
➢ II. Dünya Savaşı ve soğuk savaş sırasında geliştirilen RAN projesi, sistem mühendisliği ilkelerinin
başarıyla uygulandığı bir örnektir.
Tarihsel Gelişimi
➢ Sistem Mühendisliği Disiplininin Doğuşu (1960-1980)
➢ Raporda Tanımlanan Sistem Mühendisliği
➢ 1960'ların ortalarında, Amerika'da yapılan bir dizi raporla sistem mühendisliği disiplini
tanımlandı. Bu raporlar, sistem mühendisliği ilkelerini ve süreçlerini tanımladı.
➢ Standartlar ve Süreçler
➢ Savunma Sanayi için sistem mühendisliği standartları olan DoD-STD-2167 ve Mil-STD-499, bu
dönemde oluşturuldu.
➢ Modern Sistem Mühendisliği (2000'lerden Günümüze)

➢ Bu dönemde, sistem mühendisliği için daha fazla standart ve yönergeler geliştirildi. Özellikle
savunma sanayi ve havacılık gibi sektörlerde standartlar sıkı bir şekilde uygulanır.
➢ CMMI (Capability Maturity Model Integration) gibi süreç iyileştirme modelleri, sistem
mühendisliği süreçlerinin olgunluğunu ve etkililiğini değerlendirmek için kullanılır.
Sistem Mühendisliği
ve
Diğer Disiplinlerle
İlişkisi
Sistem Mühendisliği ve Yazılım Mühendisliği
➢ Yazılım Mühendislerinin Rolü

➢ Yazılım mühendisleri, bir sistemin yazılım bileşenlerinin tasarımı, geliştirilmesi, test edilmesi ve
bakımı ile ilgilenirler.
➢ Yazılımın Karmaşıklığı
➢ Modern sistemlerde, yazılımın rolü ve karmaşıklığı büyüktür. İşletim sistemleri, gömülü yazılım,
uygulama yazılımı gibi birçok yazılım bileşeni bir araya getirilmelidir.
➢ Sistem Mühendisleri ile İşbirliği

➢ Yazılım mühendisleri, sistem mühendisleri ile yakın işbirliği yaparlar. Sistem mühendisleri,
yazılımın diğer sistem bileşenleri ile uyumlu olmasını ve sistemin bütününü başarıyla yönetmesini
sağlar.
➢ Yazılım ve Donanım Entegrasyonu

➢ Sistem mühendisleri, yazılımın donanım ile uyumlu bir şekilde çalışmasını sağlarlar. Bu, özellikle
karmaşık sistemlerde önemlidir (örneğin, bir otomobilin motor kontrol yazılımının donanım ile
entegrasyonu).
➢ Test ve Doğrulama
➢ Yazılım ve sistem bileşenlerinin doğru çalıştığından emin olmak için sistem testleri ve
doğrulamaları yapılır. Sistem mühendisleri, bu süreçleri koordine ederler.
➢ Yazılım ve Donanım Entegrasyonu

➢ Sistem mühendisleri, yazılımın donanım ile uyumlu bir şekilde çalışmasını sağlarlar. Bu, özellikle
karmaşık sistemlerde önemlidir (örneğin, bir otomobilin motor kontrol yazılımının donanım ile
entegrasyonu).
➢ Yazılım ve sistem bileşenlerinin doğru çalıştığından emin olmak için sistem testleri ve
doğrulamaları yapılır. Sistem mühendisleri, bu süreçleri koordine ederler.
Sistem Mühendisliği
İlkeleri ve Süreçleri
Sistem Mühendisliği Felsefesi
➢ Sistem Mühendisliği Felsefesi

➢ Sistem mühendisliği, sistemlerin gereksinimlere uygun olarak tasarlanması ve yönetilmesi
gerektiği felsefesini benimser.
➢ Sistem Düşünme Yaklaşımı

➢ Sistem mühendisleri, bir sistemi tüm bileşenleri ve ilişkileri ile birlikte ele alır ve bütünsel bir
yaklaşım benimserler.
Sistem Mühendisliği İlkeleri
➢ Entegrasyon İlkesi
➢ Sistem mühendisliği, farklı bileşenleri ve disiplinleri başarıyla entegre etmeyi gerektirir.
➢ Maliyet-Etki Analizi
➢ Proje maliyetleri ve getirileri dikkate alınarak kararlar verilir.
➢ Modülerlik ve Genişletilebilirlik
➢ Sistemler modüler olarak tasarlanır ve gelecekteki değişikliklere uyum sağlama yeteneği göz
önünde bulundurulur.
Sistem Mühendisliği Süreç Modeli
➢ Süreç Modeli Nedir?

➢ Sistem mühendisliği süreç modeli, bir projenin başlangıcından sonuna kadar izlenmesi gereken
adımları ve aşamaları tanımlayan bir planı ifade eder. Bu model, projenin organizasyon,
planlama, tasarım, geliştirme, test, dağıtım ve bakım gibi farklı evrelerini kapsar.
➢ Neden Süreç Modeli Kullanılır?

➢ Süreç modeli, projenin yönetimini kolaylaştırır, kaliteyi artırır, maliyetleri kontrol altında tutar ve
projenin başarılı bir şekilde tamamlanmasını sağlar.
Sistem Mühendisliği Süreç Aşamaları
➢ Gereksinim Analizi
➢ Proje gereksinimleri belirlenir, sistem hedefleri ve kısıtlamaları tanımlanır.
➢ Tasarım
➢ Sistem ve bileşenlerin tasarımı yapılır, mimari oluşturulur ve gereksinimlere uygunluğu sağlanır.
➢ Geliştirme
➢ Tasarlanan sistem ve bileşenler inşa edilir, yazılım kodlanır ve test edilir.
➢ Sistem, gereksinimlere uygunluğunu doğrulamak için kapsamlı testlere tabi tutulur.
Temel Sistem Mühendisliği Süreç Modelleri
➢ V-Model
➢ V-Model, sistem mühendisliği süreçlerini
açıklamak için sıklıkla kullanılan bir modeldir.
Bu model, her geliştirme aşamasının bir
doğrulama aşaması ile eşleştirildiği simetrik bir
yapı sunar.
➢ Çevik Sistem Geliştirme

➢ Çevik yöntemler, sistem mühendisliği süreçlerine esneklik ve müşteri odaklılık getirir.
İteratif bir yaklaşımı benimser ve gereksinimlerin sürekli olarak revize edilmesine izin verir.
➢ SPICE (Yazılım Süreç İyileştirme ve Yetkinlik Değerlendirme)
➢ SPICE, yazılım ve sistem mühendisliği süreçlerinin iyileştirilmesi ve değerlendirilmesi için kullanılan bir
modeldir. Süreç olgunluğunu ve yetkinliği ölçmek amacıyla kullanılır.
3. 4.
Hafta
İçerik
➢ Sistem Gereksinimlerinin Uygulanması

1. Paydaşları Tanımlamak ve İhtiyaçları Belirlemek
2. Sistem Kapsamını Belirlemek
3. Sistem Gereksinimlerini Belirlemek ve Analiz Etmek
4. Sistem Gereksinimlerini Tanımlamak ve Dağıtmak
5. Sistem Gereksinimlerini Doğrulama ve Geçerleme (V&V)
6. Sistem Gereksinimlerini Yönetme ve Kontrol Etme
Paydaşları Tanımlamak ve İhtiyaçları Belirlemek
➢ Paydaşları Tanımlama:
➢ Sistem mühendisliği, bir sistem veya proje üzerinde etkisi olan tüm paydaşları tanımlar. Bu
paydaşlar, sistemle doğrudan veya dolaylı olarak etkileşimde bulunan herkesi temsil eder.
➢ Sistem mühendisliği bakış açısıyla paydaşları ve ihtiyaçları tanımlamak, başarılı bir sistem
geliştirme süreci için temel bir adımdır. Bu süreç, paydaşlarla sürekli iletişim ve işbirliği gerektirir
ve gereksinimlerin net bir şekilde belirlenmesi ve yönetilmesi önemlidir.
➢ İçsel Paydaşlar:
➢ Çalışanlar
➢ Yöneticiler
➢ Şirket sahipleri
➢ Dışsal Paydaşlar:
➢ Müşteriler
➢ Tedarikçiler
➢ Rekabetçiler
➢ Paydaşların İhtiyaçlarını Belirleme:

➢ Sistem mühendisliği, paydaşların ihtiyaçlarını anlamak için gereken analitik yöntemleri kullanır.
Bu, gereksinimler mühendisliği sürecinin temelidir.
➢İşlevsel gereksinimler
➢Performans gereksinimleri
➢Güvenlik gereksinimleri
➢Yasal gereksinimler
➢ Öncelik Sırası Belirleme:
➢ Belirlenen gereksinimler arasında öncelik sırası belirlemek, kaynakların doğru şekilde tahsis
edilmesini ve önemli işlevselliğin öncelikli olarak geliştirilmesini sağlar.
➢ Öncelikler, paydaşların iş gereksinimleri ve risk faktörlerine dayalı olarak belirlenir.
➢ İhtiyaçlara Yanıt Verme:

➢ Sistem mühendisleri, belirlenen gereksinimlere uygun çözümler tasarlar ve bu çözümleri sistem
tasarımına entegre eder. İhtiyaçlara yanıt verme, sistem mimarisi, yazılım geliştirme ve test
aşamalarını içerir.
➢ İzleme ve Geri Bildirim:

➢ Sistemler zaman içinde değişebilir ve paydaşların ihtiyaçları da değişebilir. Bu nedenle, sistem
mühendisleri, sistemin performansını ve işlevselliğini izler ve paydaşlardan geri bildirim alır.
İhtiyaçlar ve sistem tasarımı, değişen gereksinimlere uyacak şekilde sürekli olarak
güncellenmelidir.
Sistem Kapsamını Belirlemek
➢ İkinci adım, sistemin kapsamını ve

bağlamını tanımlamaktır. Bu adım
sistemle çevresi arasındaki sınırları ve
etkileşimleri ifade eder.
➢ Sistem kapsamını ve bağlamını

açıklamak ve görselleştirmek için
kullanabileceğiniz teknikler arasında
kullanım senaryoları, senaryolar,
diyagramlar veya modeller
bulunabilir.
Sistem Kapsamını Belirlemek
➢ Kapsam (Scope):
➢ Sistem kapsamı, bir projesinin veya sisteminin hangi özellikleri, işlevleri ve sınırları içerdiğini
açıklayan bir kavramdır.
➢ Bu kavram, bir projenin veya sistemin hedeflerini, gereksinimlerini ve sınırlarını tanımlamak için
kullanılır.
➢ Bağlam (Context):
➢ Bağlam, bir projesinin veya sisteminin dış dünyayla olan ilişkilerini, etkileşimlerini ve konumunu
tanımlayan bir kavramdır.
➢ Sistem bağlamı, bir sistemin çevresini ve bu çevreyle nasıl etkileşimde bulunduğunu anlamamıza
yardımcı olur.
➢ Bu, sistem içindeki süreçlerin, alt sistemlerin ve dış sistemlerin nasıl birbirleriyle etkileşimde
bulunduğunu açıklar.
➢ Bağlam, sistem gereksinimlerinin, tasarımın ve testlerin oluşturulması sırasında kullanılır.
Sistem Gereksinimlerini Belirlemek ve Analiz Etmek
➢ Üçüncü adım, sistem gereksinimlerini belirlemek ve analiz etmektir. Bu gereksinimler, sistemin paydaş
ihtiyaçlarını karşılamak için ne yapması gerektiğini veya olması gerektiğini ifade eden açıklamalardır.
➢ Bu süreç, projenin başarılı bir şekilde planlanması ve tasarlanması için gereklidir.
➢Gereksinimleri belirleme: (Elicit)

➢ Bu gereksinimleri farklı kaynaklardan toplama ve dokümante etme sürecini içerir.
➢Gereksinimleri analiz etme: (Analyze)

➢ Sistem gereksinimlerini doğrulama ve iyileştirme sürecini ifade eder.
➢ Bu adımda gereksinimlerin açık, tutarlı, eksiksiz, uygulanabilir ve test edilebilir olduğundan emin
olmak önemlidir.
Sistem Gereksinimlerini Belirlemek ve Analiz Etmek
➢Değişiklikleri Yönetme: (Change Management)

➢ Gereksinimler, projenin ilerleyen aşamalarında değişebilir. Bu nedenle, değişiklik istekleri
kaydedilir, analiz edilir ve belgelendirilir. Değişiklikler, paydaşların onayı ve yönetim tarafından
onaylandıktan sonra uygulanır.
➢İzleme: (Monitoring)
➢ Gereksinimlerin sürekli olarak izlenmesi, takip edilmesi ve paydaşlarla düzenli iletişim kurulması
ve raporlanması gereklidir.
Sistem Gereksinimlerini Tanımlamak ve Dağıtmak
➢ Dörtüncü adım, sistem gereksinimlerini tanımlamak ve dağıtmaktır ve bu, sistem gereksinimlerini

tanımlamak ve alt sistem bileşenlerine kırmak anlamına gelir.
➢ Tanımlamak,
➢ Sistem gereksinimlerini iletebilmek ve sistem yaşam döngüsü boyunca izlenebilir hale
getirebilmek için resmi bir doküman veya veritabanında yazmak ve düzenlemek faaliyetini ifade
eder.
➢ Dağıtma,
➢ Sistem gereksinimlerini uygulayacak olan alt düzey bileşenlere veya alt sistemlere atama ve
ayrıştırma faaliyetini ifade eder.
➢ Gereksinimlerin Detaylandırılması:
➢ İlk olarak, yüksek düzeyde tanımlanmış olan sistem gereksinimleri daha ayrıntılı bir şekilde
incelenir ve detaylandırılır. Bu, gereksinimlerin daha kesin ve anlaşılır bir şekilde ifade edilmesini
sağlar.
➢ Gereksinimlerin Alt Sistemlere ve Bileşenlere Dağıtılması:

➢ Sistem gereksinimleri, sistemdeki alt sistemlere veya bileşenlere atama yapılacak şekilde dağıtılır.
Bu, her bir alt sistem veya bileşenin kendi görevlerini ve sorumluluklarını daha iyi anlamasına
olanak tanır.
➢ Sorunların Tanımlanması ve Çözülmesi:

➢ Bu aşamada, gereksinimlerin detaylandırılması ve dağıtılması sırasında ortaya çıkan sorunlar
tanımlanır ve çözülür. İhtilaflar, çakışmalar veya uyumsuzluklar giderilir.
➢ İzlenebilirlik Sağlama:
➢ Her gereksinimin, alt sistemler veya bileşenler tarafından nasıl karşılandığı ve uygulandığı
izlenebilir olmalıdır. Bu, gereksinimlerin test edilebilirliği ve doğrulanabilirliği için önemlidir.
Sistem Gereksinimlerini Doğrulama ve Geçerleme (V&V)
➢ Beşinci adım, sistem gereksinimlerini doğrulama (Validation) ve geçerleme (Varification) adımlarını

içerir. Bu adımlar, sistem gereksinimlerinin doğru ve eksiksiz olduğundan emin olmayı amaçlar.
➢ Doğrulama (Validation),
➢ Sistem gereksinimlerinin, paydaşların beklentilerini ve projenin amacını karşılayıp karşılamadığını
doğrulama işlemidir. Bu aşamada, gereksinimlerin işlevselliği ve performansı paydaşlarla
onaylanır.
➢ Geçerleme (Varification),
➢ Bu aşama gereksinimlerin yazılı olarak sistem tasarımı şartlarını karşılayıp karşılamadığını kontrol
etmeyi içerir. Bu, gereksinimlerin mantıklı, tutarlı ve eksiksiz olduğunu emin olma işlemidir.
Sistem Gereksinimlerini Doğrulama ve Geçerleme (V&V)
➢ Test Planlarının Hazırlanması:

➢ Doğrulama ve geçerleme işlemi için test planları hazırlanır. Bu planlar, gereksinimlerin nasıl test
edileceğini ve doğrulanacağını belirler.
➢ Testlerin Uygulanması:
➢ Hazırlanan test planlarına uygun olarak gereksinimler test edilir ve doğrulanır. Bu testler,
gereksinimlerin gerçek dünya koşullarında nasıl davranacağını değerlendirir.
➢ Değişikliklerin Yönetimi:
➢ Doğrulama ve geçerleme işlemi sırasında ortaya çıkan sorunlar ve uyumsuzluklar yönetilir.
Gereksinimlerin düzeltilmesi veya revize edilmesi gereken durumlar tespit edilir ve bu
değişiklikler belgelenir.
Sistem Gereksinimlerini Yönetme ve Kontrol Etme
➢ Altıncı adım, sistem gereksinimlerini yönetme ve kontrol etme adımlarını içerir. Bu adımlar, sistem
gereksinimlerini sistem yaşam döngüsü boyunca sürdürme ve güncelleme faaliyetlerini ifade eder.
➢Yönetim,
➢ sistem gereksinimleri faaliyetlerini ve kaynaklarını planlama, düzenleme ve izleme faaliyetidir.
➢Kontrol,
➢ yeni veya gelişen paydaş ihtiyaçları, sistem sorunları veya proje kısıtlamaları nedeniyle sistem
gereksinimlerine değişiklikler yapılmasını tanımlama, değerlendirme ve uygulama faaliyetidir.
➢ Sistem gereksinimlerini yönetme ve kontrol etme için görev yönetimi, değişiklik yönetimi veya
izlenebilirlik gibi aşamalar kullanılmaktadır.
5. 6. 7.
Hafta
İçerik
➢ Gereksinim Yönetim Planı

• Amaç, Kapsam, Tanım
• Sorumluluklar Ve Roller
• Platformlar ve Yönetim Sistemleri
• Gereksinim Yönetimi
i. İzlenebilirlik (Traceability)
ii. Gereksinim Kapsama ve Karşılama (Requirement Coverage)
iii. Gereksinim Durumu (Requirement Status)
iv. Gereksinim Şablonu (Template for Requirements)
v. Gereksinim Seti Referans Hattı (Requirements Set Baseline)
vi. Gereksinim Nitelikleri (Requirement Attributes)
Amaç, Kapsam, Tanım
➢ Gereksinim Yönetim Planın Amacı:
➢ Gereksinimlerin ortaya çıkarılması ve bunların yönetimi için planlama, dokümantasyon ve

sorumlu görevliler gibi ana hususları kapsar.
➢ Amaç, şirketin şirket içindeki köklü gereksinim mühendisliği süreçlerinin belirlemek ve bu ihtiyaça
kurumsal bir bakış açısı kazandırmaktır.
➢ Gereksinim Yönetim Planın Kapsamı:
➢ Gereksinim yönetimi planı, gereksinim yönetimi için kullanılan araçlar etrafında yapılandırılmıştır
ve sistem mühendisliğin asıl görevi olan Gereksinim Yönetimin süreçlerini kapsar.
➢ Bu prosedür, yeni geliştirmenin veya herhangi bir ürünün daha da geliştirilmesinin tüm yönleri
için uygulanmalıdır.
➢ Gereksinim Yönetim Planın Tanımı:
➢ Gereksinim Yönetimi:
➢ Gereksinim yönetimi, gereksinimlerin yönetimi, kontrolü ve idaresi için önlemleri içerir.
➢ İş birliği içinde üzerinde çalışılan karmaşık sistemlerin verimli ve hatasız geliştirilmesi için elzemdir.
➢ Gereksinim:
➢ Gereksinim, bir ürünün karşılaması gereken bir koşulu veya yararlığı tanımlayan bir isterdir.
Sorumluluklar Ve Roller
➢ Proje Yöneticisi:
➢ Projedeki iş paketlerinin uygun şekilde oluşturulup oluşturulmadığını, yönetilip yönetilmediğini

ve dağıtılıp dağıtılmadığını kontrol eder.
➢ İlgili organizasyon birimleri ile teknik faaliyetlerin planlanmasını koordine eder.
➢ Diğer proje grupları için bir arayüz görevi görür.
➢ Çözüm ve açıklama için sistem gereksinimlerine ilişkin açıklamaları veya yanlış anlamaları bildirir.
➢ Geliştirme disiplinleri ve dahili organizasyonlar arasında ve ayrıca müşteriler ve tedarikçilerle
harici olarak teknik konuları koordine eder.
➢ Her disiplin için Sistem Özellikleri Belgelerini tutar.
Sorumluluklar Ve Roller
➢ Sistem Mühendisi:
➢ Gereksinim yönetimi sürecini, prosedürlerini ve sistem tasarımını üstlenir.
➢ Sistem geliştirmeyi desteklemek için fonksiyonel güvenlik gereksinimleri de dahil olmak üzere
sistem gereksinimlerinin yönetiminden sorumludur.
➢ Birden fazla disiplini (HW, SW, MC) etkileyen tüm gereksinimleri gözden geçirir ve yayınlar.
➢ Birden fazla disiplini (HW, SW & Mekanik) etkileyen gereksinimlerin uygulama durumunu izler.
➢ Fonksiyonel Güvenlik Yöneticisi:

➢ Sistem geliştirmeyi desteklemek için fonksiyonel güvenlik gereksinimlerinden sorumludur.
➢ Fonksiyonel güvenlik gereksinimlerinin uygulama durumunu izler.
Platformlar ve Yönetim Sistemleri
➢ Farklı iş süreçlerini ve alanları yönetmek için kullanılan yazılım platformları ve yönetim sistemlerini ifade
eder.
➢ ALM (Application Lifecycle Management)
➢ PLM (Product Lifecycle Management)
➢ ERP (Enterprise Resource Planning)
➢ ALM (Application Lifecycle Management):
➢ ALM, yazılım geliştirme süreçlerini yönetmek ve denetlemek amacıyla kullanılır.

➢ Yazılım projelerini takip eder ve geliştirme aşamalarını yönetir.
➢ Geliştirme, test, sürüm kontrolü, hata takibi ve sürüm yönetimi gibi yazılım yaşam döngüsü
süreçlerini içerir.
➢ Özellikle yazılım geliştirme şirketleri için önemlidir.
➢ Örnek:
➢ Atlassian Jira Software
➢ Jama Software
➢ Codebeamer
➢ PLM (Product Lifecycle Management):
➢ PLM, bir ürünün yaşam döngüsünü, tasarımından son kullanıcıya ulaşana kadar olan süreçleri
yönetir.
➢ Ürün tasarımı, mühendislik, üretim, tedarik zinciri yönetimi ve servis süreçlerini içerir.
➢ Ürün geliştirme, iyileştirme ve ömrünün sonuna kadar izleme amaçlanır.
➢ İmalat, otomotiv, havacılık ve tıbbi cihazlar gibi sektörlerde kullanılır.
➢ Örnek:
➢ SIEMENS Teamcenter
➢ ANSYS Materials
➢ SAP PLM
➢ ERP (Enterprise Resource Planning):
➢ ERP, işletmelerin tüm iş süreçlerini ve kaynaklarını (finans, muhasebe, üretim, stok yönetimi,
insan kaynakları, vb.) tek bir entegre platformda yönetmeyi amaçlar.
➢ İşletme yönetimi için kullanılır ve finansal verilerin entegre edilmesi gibi iş süreçlerini izler.
➢ Tüm iş süreçlerinin tek bir veri tabanı üzerinden koordinasyonunu sağlar.
➢ Üretim planlaması, sipariş yönetimi, envanter kontrolü ve finansal raporlama gibi iş
fonksiyonlarına odaklanır.
➢ Örnek:
➢ Workcube
➢ Acumatica
➢ SAP ERP
➢ Farklar:
➢ ALM, yazılım geliştirme süreçlerini yönetirken, PLM ürün yaşam döngüsünü ve üretimini yönetir.
ERP ise genel iş süreçlerini yönetir.
➢ ALM ve PLM, daha özelleştirilmiş endüstriye özgü çözümler sunabilirken, ERP genellikle
işletmelerin tüm sektörlerdeki ihtiyaçlarını karşılamak için kullanılır.
➢ ALM, genellikle yazılım geliştirme süreçlerine odaklanırken, PLM ve ERP daha geniş bir iş alanını
kapsar.
➢ ALM'nin Gereksinim Yönetim süreçlerine uygulama faydaları:
➢ Gereksinim yönetiminin çoğunu otomatikleştirir.

➢ Farklı gereksinim türleri arasındaki izlenebilirliği kaydeder ve sürdürür.
➢ Kapsam belirleme, etki analizi ve gereksinim yönetiminin tüm yönlerini etkinleştirir.
➢ Gereksinimlerin ortaya çıkarılması sırasında (referans hattı) zaman içinde farklı noktalarda
gereksinimlerin sürüm kontrolünü korur.
➢ Değişiklik yönetim süreçlerini ve izlenebilirliği etkinleştiri.
Gereksinim Yönetimi: İzlenebilirlik
➢ İzlenebilirlik (Traceability)
➢ Gereksinimlerle ilgili önemli bir faktör, tam izlenebilirliktir. Bu şekilde geliştirme süreci her zaman
eksiksiz ve şeffaftır.
➢ İzlenebilirlik, bir gereksinimi ve özellikleri kökenlerine (V-modeli, paydaşlar, belgeler, gerekçe
vb.), mimari tasarıma ve bu gereksinimin bağlı olduğu diğer gereksinimlere kadar izleme
yeteneğidir.
➢ Gereksinimler özelliklerle ilgili olmalı ve oradan alt sistemlere bağlantı kurulmalıdır.
Gereksinim Yönetimi: İzlenebilirlik
Gereksinim Yönetimi: Gereksinim Kapsama ve Karşılama
➢ Gereksinim Kapsama ve Karşılama (Requirement Coverage)
➢ Projenin veya ürünün belirtilen gereksinimlere ne kadar iyi cevap verdiğini ve bu gereksinimlerin
ne derece test edildiğini ve onaylandığını ölçer.
➢ Her sistem seviyesi gereksinimi veya özelliği, bir alt sisteme referansa ihtiyaç duyar, ancak her alt
sistem veya bileşenin sistemle ilgili olması gerekmez.
➢ Gereksinim kapsamının amacı, gereksinimlerin gözden kaçırılma veya yanlış yorumlanma riskini
en aza indirmektir, bu da eksik veya yanlış uygulamalara yol açabilir.
➢ Doğru gereksinim kapsamı, müşteri ve paydaş ihtiyaçlarını karşılayan yüksek kaliteli bir son
ürünün sağlanması için önemlidir.
Gereksinim Yönetimi: Gereksinim Durumu
➢ Gereksinim Durumu (Requirement Status)
➢ Herhangi bir gereksinim için belirlenebilecek durumlar:

➢ Draft
➢ Waiting for Approval
➢ Accepted
➢ Rejected
➢ Implemented
➢ Verified
➢ Taslak (Draft):
➢ Bir gereksinim, yazıldığı anda Taslak durumundadır. Ancak, gereksinimler kontrol listesi ile henüz
kontrol edilmemiştir.
➢ Herkes bir gereksinim yazıp taslak durumuna getirebilir, ancak bu sistem mühendisi veya takım
liderleri ile tartışılmalıdır.
➢ Onay İçin Beklemede (Waiting for Approval) :
➢ Onay Bekleniyor durumu, gereksinim kontrol listesiyle gereksinim kontrol edilir edilmez
ayarlanabilir. Onay bekliyor durumu, gereksinimin gözden geçirilmeye hazır olduğu anlamına
gelir.
➢ Sistem mühendisi veya takım lideri, gereksinimlerin gereksinim kontrol listesinin kriterlerini
karşılayıp karşılamadığını kontrol etmelidir.
➢ Kabul Edildi (Accepted) :
➢ Başarılı bir incelemeden sonra gereksinimler Kabul Edildi durumuna ayarlanabilir. İncelemedeki
tüm katılımcılar karar üzerinde anlaşmaya varmalıdır.
➢ Yalnızca sistem mühendisi veya takım lideri gereksinimlerin durumunu Kabul Edildi durumuna
getirebilir.
➢ Reddedildi (Rejected) :
➢ Uygulanamazsa veya tamamen revize edilmesi gerekiyorsa, bir gereksinim Reddedildi durumuna
ayarlanır. Bir gereksinimin revize edildiği sonucuna varılırsa, yeniden kaleme alınmalı ve
gereksinim kontrol listesinden geçilmelidir.
➢ Yalnızca sistem mühendisi veya takım lideri gereksinimlerin durumunu Reddedildi durumuna
getirebilir.
➢ Uygulandı (Implemented) :
➢ Uygulandı durumu, tam bir izlenebilirlik sağlanır sağlanmaz ve gereksinim bir test senaryosuna
bağlanır bağlanmaz ayarlanabilir. Sistem gereksinimlerin bir test durumuna başvurması
gerekmez.
➢ Yalnızca sistem mühendisi veya takım lideri, gereksinimlerin durumunu Uygulandı durumuna
getirebilir.
➢ Doğrulandı (Verified) :
➢ Bir gereksinim, yalnızca başarılı bir testten sonra Doğrulandı durumuna ayarlanabilir. Sistem
gereksinimleri, uygulanan durumdan doğrulanmış duruma doğrudan ayarlanabilir.
➢ Yalnızca sistem test ve entegrasyon mühendisi veya takım lideri, gereksinimlerin durumunu
Doğrulandı durumuna getirebilir.
Gereksinim Yönetimi: Gereksinim Şablonu
➢ Gereksinim Şablonu (Template for Requirements):
➢ Cümle şablonu, bir gereksinim oluştururken doğru şekilde oluşturulması için bir yönlendirme
görevi görür.
Sample:
➢Self-Activated Function
➢ If the user presses the power button and the system is powered down, the Büyütech system
SHALL power on the battery.
➢User Interaction
➢ The vehicle SHALL provide the rider with the ability to switch off the light.
➢Interface
➢ The vehicle SHALL BE ABLE TO receive software updates.
Örnek:
➢Kendiliğinden Etkinleşen İşlev

➢ Kullanıcı açma düğmesine basarsa ve sistem kapanırsa, Büyütech sistemi pili AÇACAKTIR.
➢Kullanıcı etkileşimi
➢ Araç, sürücüye ışığı kapatma olanağını SAĞLAYACAKTIR.
➢Arayüz
➢ Araç, yazılım güncellemelerini ALABİLMELİDİR.
Gereksinim Yönetimi: Gereksinim Seti Referans Hattı
➢ Gereksinim Seti Referans Hattı (Requirements Set Baseline)
➢ Gereksinim referans hattı, bir ürün için (örneğin, belirli bir ürün sürümü için) kesin olarak
tanımlanmış bir geliştirme ve teslimat durumunu yansıtan seçilmiş ve yayınlanmış gereksinimler
veya özelliklerdir. Referans Hattı, donmuş bir sürümü temsil eder.
➢ Her ürün sürümünden önce tüm gereksinimlerin ve özelliklerin bir referans hattı oluşturulmalıdır.
➢ Gereksinimler veya özellikler bir tedarikçiye iletilirse, bir temel oluşturmaktan sistem mühendisi
veya konfigürasyon mühendisi sorumludur.
Gereksinim Yönetimi: Gereksinim Nitelikleri
➢ Gereksinim Nitelikleri (Requirement Attributes):
➢ Nitelikler, gereksinimlerin belirli özelliklerini tanımlar. Amaç, atıf kullanarak gereksinimleri

sınıflandırmak ve böylece gereksinimlerin yönetimini ve değerlendirilmesini kolaylaştırmaktır.
➢ ID
➢ Requirement Type
➢ Verification Method
➢ Version
➢ Submitted by
➢ Suspected
➢ Special Requirement Type
➢ ASIL (ISO 26262)
➢ ID:
➢ Her gereksinime otomatik olarak eşsiz bir numara verilir.
➢ Requirement Type:
➢ Bu nitelikler gereksinimin türünü tanımlamak için seçilir.
➢ Functional
➢ Non-Functional
➢ Customer Requirement
➢ Software Requirement Spesification
➢ Hardware Requirement Spesification
➢ Mechanical Requirement Spesification
➢ Verification Method:
➢ Gereksinimlerin ya da özelliklerin nasıl doğrulanacağı belirtilmelidir.
➢ Test Case
➢ Review
➢ Assessment
➢ Version:
➢ Ürün özelliği, hangi ürün sürümü olduğunu seçmek için kullanılır. Baseline bilgisi bu alan için
kullanılabilir.
➢ Submitted by:
➢ Gönderen niteliği, bu gereksinimleri veya özellikleri kimin oluşturduğunu gösterir.
➢ Suspected:
➢ Bu nitelik, başka bir gereksinim ile bağlı bir gereksinimin veya bir özelliğin değiştirilip
değiştirilmediğini belirtmek için ayarlanır. Gereksinimler veya özellikler birbirini etkiliyorsa bu
önemlidir.
➢ Special Requirement Type:

➢ Gereksinimler yasal bir düzeneleme/gereklilikten veya bir güvenlik gereksinimden kaynaklı
olduğu durumlar bu alana bilgi girilmesi gerekmektedir. Bu alan Safety Requirement seçildiğinde
de ise ASIL seviyesi de girilmelidir.
➢ Legal Requirement
➢ Safety Requirement
➢ ASIL: QM-A-B-C-D
8. 9. 10. 11. 12.
Hafta
İçerik
➢ Sistem Mühendisliğinde Süreç Yönetimi

➢ Değişiklik Yönetimi (Change Request Management)
➢ RCR
➢ S/H/M-CR
➢ TCR
➢ Gereksinim Yönetimi (Requirement Management)

➢ Gereksinim Türleri
Değişiklik Yönetimi (Change Request Management)
➢ "Change Request”, bir projenin veya sürecin akışında meydana gelecek olan değişiklikleri veya
iyileştirmeleri resmi olarak talep eden bir belgedir.
➢ Genellikle Change Request projeler, iş süreçleri veya yazılım geliştirme gibi faaliyetler sırasında kullanılır.
➢ Change Request, bu değişikliklerin nedenini, kapsamını, etkilerini ve gereksinimlerini ayrıntılı bir şekilde
açıklar. Ayrıca, değişikliği talep eden kişinin kimliğini ve talebin onaylanması veya reddedilmesi için
gereken adımları içerebilir.
➢ Change Request, projenin yönetim sürecini düzenlemeye ve değişikliklerin izlenmesini sağlamaya

yardımcı olur. Aynı zamanda, projenin daha iyi bir şekilde yönetilmesine ve gereksinimlerin doğru bir
şekilde takip edilmesine katkıda bulunur.
➢ Bir değişiklik talebinin kabul edilmesi durumunda, bu talep proje planına veya süreç akışına dahil edilir.
Değişiklik Yönetimi (Change Request Management)
➢ Projelerin iş yapısında Change Request, sistem seviyesi ve alt seviye (yazılım, donanım, mekanik
geliştirmeler) gereksinimlerin güncellenmesi, oluşturulması ve iyileştirmesi için kullanılmaktadır.
➢ Bu kapsam her bir gereksinim türü ve seviyesi için ve de bu gereksinimlere ait testler için farklı Change
Request tipleri tanımlanabilir.
➢ Requirement Change Request (RCR)

➢ Software Change Request (SCR)
➢ Hardware Change Request (HCR)
➢ Mechanical Change Request (MCR)
➢ Test Change Request (TCR)
Değişiklik Yönetimi (Change Request Management) - RCR
➢ Requirement Change Request (RCR)
➢ Requirement Change Request, sistem seviyesindeki fonksiyonel ve fonksiyonel olmayan
gereksinimlerin değiştirilmesi veya iyileştirilmesi için kullanılmaktadır.
➢ RCR hiyerarşik olarak tüm diğer türlerinin en üstündedir ve RCR iş akışı ile diğer Change Request
tipleri tetiklenmektedir.
➢ SCR – Software Change Request
➢ HCR – Hardware Change Request
➢ MCR – Mechanical Change Request
➢ RCR döngüsü her ne kadar ayrık bir döngü olarak görünse de bir alt hiyerarşideki SCR, MCR ve
HCR döngülerinden gelen geri dönüş ile tetiklenerek ilerlemektedir. Bu iş akışındaki amaç ASPICE
ve V Modeldeki yapıyı pratik bir şekilde uygulamaya dökmektir.
➢ Requirement Change Request (RCR) - Workflow

➢ Requirement Change Request (RCR)’a ait iş akışında ilk olarak Sistem Mühendisi ihtiyaç dahilinde
bir RCR açmaktadır.
➢ RCR içinde aşağıda tanımlı alanları doldurduktan sonra “Send to Approval” butonuna basarak
Sistem Mühendisliği Lider’inin onayına göndermektedir.
➢ Burada Sistem Mühendisi Lideri eğer RCR üzerinden eksik/hatalı veya değiştirilmesi gereken bir
durum görürse “Reopen” butonuna basarak tekrar ilgili Sistem Mühendisine RCR’ı gönderir.
➢ Eğer inceleme sonunda herhangi bir düzeltme ihtiyacı görmezse “Send To CCB” butonuna basarak
görüşülmek üzere Configuration Control Board’a gönderir.
➢ Configuration Control Board, bir organizasyonun veya projenin konfigürasyon yönetimi

süreçlerini denetleyen ve değişiklikleri yönlendiren bir kurul veya komitedir.
➢ CCB, özellikle karmaşık sistemlerin, yazılım projelerinin veya ürünlerin konfigürasyon yönetimi
süreçlerini etkin bir şekilde yönetmek için kullanılır.
➢ CCB’de çıkan karara göre Konfigürasyon Mühendisi rolündeki kişi “Reopen” butonuna basarak
yine bir düzenleme ihtiyacından dolayı RCR’ı döngünün en başına çekebilir, “Cancel” butonuna
basarak toplantıda alınan karar doğrultusunda değişikliği reddedip iptal edebilir veya herhangi
bir düzenleme ihtiyacı görmeyip RCR’ın uygun olduğu kararına göre “Accept” butonuna basarak
değişikliğin gerçekleşmesi için ilgili Sistem Mühendisine gönderir.
➢ Eğer CCB’de bir RCR iptal edilirse “Cancel” butonuna tıklandıktan sonra bununla ilgili bir yorum
girilmesi gerekmektedir.
➢ Accepted durumuna geçen RCR’a gerekli implementasyonlar Sistem Mühendisi tarafından yapılır
ve “Implement” butonuna basılarak gözden geçirme için Sistem Mühendisi Lideri’ne gönderilir.
➢ Accept butonuna basıldıktan sonra Sistem Mühendisinden son konfigürasyon versiyonu ve

yapılan geliştirme/implementasyona dair bilgi için yorum girmesi istenir.
➢ Bu aşamadan sonra Sistem Mühendisi Lideri, yapılan işlemleri gözden geçirir eğer bir
düzeltme/değişiklik vs. ihtiyacı varsa “Revise” butonuna tıklayarak tekrar Sistem Mühendisine
atar.
➢ Yapılan değişikliği uygun görürse de “Review” butonuna basarak “Reviewed” duruma geçirir.
➢ RCR Alanları ve Nitelikleri (Field and Attributes)
➢ Component
➢ RCR için kullanılan Component alanı ilgili RCR’ın hangi sistemler ve/veya alt sistemleri etkilediği
bilgisinin girilmesi için kullanılmaktadır.
➢ Bu alanı ilgili sistem mühendisi RCR’ı oluştururken en başta girmek zorundadır.
➢ Assigned Team Leaders

➢ Bu alan doldurulurken sistem mühendisi ekip lideri, RCR’ı ve etkilenen alt sistemleri değerlendirir ve
ona göre SCR, HCR ve MCR açılması için teknik ekipleri tetikler.
➢ Linked Requirement
➢ Bu alan, RCR’ın etkilediği R4J tarafında tanımlı gereksinimi ifade etmektedir, JIRA Link Issue yeteneğiyle
RCR açılırken ilgili sistem mühendisi tarafından gereksinime bağlanmalıdır.
➢ Change Reason
➢ RCR’ın türünü belirtmek için kullanılır. Sistem mühendisi RCR’ı açarken bu isteğin yeni bir istek, bir
güncelleme veya bir hata düzeltmeden kaynaklanıp kaynaklanmadığını girer.
➢ New
➢ Update
➢ Bugfix

➢ Priority
➢ Bu alana 1 ile 5 arasında bir öncelik atanır. Bu öncelik bilgisine göre RCR’ın sürecinin önceliklendirilmesi
değerlendirilir.
➢ Initial Configuration Item Version (CI Version) & Final Configuration Item Version (CI Version)
➢ RCR açılmadan önceki versiyonu ve RCR’ın işlendikten sonra alınan versiyonu ifade eder. Son versiyon
bilgisi RCR “Accepted” statüsünden “Implemented” statüsüne geçerken girilmelidir.
➢ Summary – Description - Comment

➢ Bu bölümü JIRA’da açılan RCR’ın özet/başlık görünümünü, Description bölümü ise RCR’ın detaylı olarak
içeriğini ifade eder. Ayrıca tüm iş akışı boyunca Comment alanları sayesinde ilgili roller RCR sürecinde
yorumlarını girebilir.
Değişiklik Yönetimi (Change Request Management) - S/H/M-CR
➢ Software/Hardware/Mechanical Change Request (S/H/M-CR)

➢ Software/Hardware/Mechanical Change Request, bir üst seviyedeki RCR’dan gelen değişiklik
kaynaklı alt seviyede yazılım donanım ve mekanik gereksinimlerinin (S/H/M-RS) veya tasarımın
değiştirilmesi veya iyileştirilmesi için kullanılmaktadır.
➢ S/H/M-CR’lar hiyerarşik olarak RCR’ın altındadır ve RCR iş akışı ile tetiklenmektedir.
➢ Bir RCR’a bağlı olarak minimum bir S/H/M-CR gereksinim değişimi için ve bir S/H/M-CR tasarım
güncellenmesi için açılması gerekiyor.
➢ S/H/M-CR’lar hiyerarşisinde eğer üst seviye sistem gereksinimi Fonksiyonel ise S/H/M-CR’lar
tasarım/Gereksinim ve eğer üst seviye sistem gereksinim Fonksiyonel değilse S/H/M-CR’lar
dokümanları güncellemek/değiştirmek veya oluşturma işlemleri için kullanılmaktadır.
➢ Software/Hardware/Mechanical Change Request (S/H/M-CR)
➢ Yazılım Değişiklik Talebi (SCR), Donanım Değişiklik Talebi (HCR) ve Mekanik Değişiklik Talebi
(MCR), genelde aynı iş akışını takip eder ve aynı süreçlerle yönetilir.
➢ Farklı uzmanlık alanlarının dahil olduğu bu farklı talepler, V Modeli ve ASPICE'da aynı seviyede
kabul edildiği için bu yapılar için aynı döngü ve iş akışını kullanmak uygundur.
➢ Software/Hardware/Mechanical Change Request (S/H/M-CR) - Workflow
➢ İlk olarak ilgili geliştirmeci CR’ını açar daha sonra içeriği tamamlayıp “Send To Approval”
butonuna basarak Geliştirme Takım Liderine gönderir.
➢ Takım lideri CR’ı inceledikten sonra herhangi bir düzeltme/değiştirme istersen “Reopen”
butonuna basarak geri gönderir veya CR’ı uygun görmezse “Cancel” butonuna basar ve
gerekçesini yorum olarak girerek iptal eder. Eğer herhangi bir düzeltme, değişiklik veya iptal
gereği yoksa “Accept” butonuna basarak tekrar geliştirmeciye işlemlerini yapması için atar.
➢ Bu aşamada geliştirici CR’ın içeriğine göre (gereksinim, kod, tasarım, doküman) yapması gereken
işleri yapar ve tamamlayınca son versiyon bilgisini de girerek “Implement” butonuyla gözden
geçirmesi için ekip liderine gönderir.

➢ Ekip lideri yapılan işlemleri gözden geçirir eğer bir düzeltme, değişiklik ihtiyacı varsa “Revise”
butonuna basarak geri gönderir veya herhangi bir sorun görmezse “Review” butonuna basarak
Test Change Requestlerinin hazırlanması için Test Mühendisliği Liderine gönderir.
➢ Takım lideri CR’ı inceledikten sonra herhangi bir düzeltme/değiştirme istersen “Reopen”
butonuna basarak geri gönderir veya CR’ı uygun görmezse “Cancel” butonuna basar ve
gerekçesini yorum olarak girerek iptal eder. Eğer herhangi bir düzeltme, değişiklik veya iptal
gereği yoksa “Accept” butonuna basarak tekrar geliştirmeciye işlemlerini yapması için atar.
➢ Bu aşamada geliştirici CR’ın içeriğine göre (gereksinim, kod, tasarım, doküman) yapması gereken
işleri yapar ve tamamlayınca son versiyon bilgisini de girerek “Implement” butonuyla gözden
geçirmesi için ekip liderine gönderir.
➢ CR bu aşamada üst seviyedeki RCR’a bağlı tüm S/H/MCRların kapanması için bekler. RCR’ın
System Validation aşamasında bir hatayla karşılaşması durumunda alt CRlar incelenir ve ilgili
hataya sebep olan CR “Repone” butonuna basılarak tekrar açılır.
➢ Eğer herhangi bir hata görülmezse Sistem Mühendisi “Close” butonuna basarak CR’ı kapatır.

➢ S/H/M-CR Alanları ve Nitelikleri (Field and Attributes)

➢ Linked CR
➢ Bu alan, CR’ın bağlı olduğu RCR’ı ifade etmektedir, JIRA Link Issue yeteneğiyle CR açılırken ilgili
geliştirme mühendisi tarafından gereksinime bağlanmalıdır.
➢ CR Type
➢ CR’ın türünü belirtmek için kullanılır. Geliştirme mühendisi CR’ı açarken bu isteğin bir tasarım, bir
gereksinim veya bir doküman olup olmadığını girer.
➢ Design
➢ Requirement
➢ Document


➢ Priority
➢ Bu alanın 1 ile 5 arasında bir öncelik atılmalıdır. Bu öncelik bilgisine göre CR’ın sürecinin
önceliklendirilmesi değerlendirilir.
➢ Initial Configuration Item Version (CI Version) & Final Configuration Item Version (CI Version)
➢ RCR açılmadan önceki versiyonu ve RCR’ın işlendikten sonra alınan versiyonu ifade eder. Son versiyon
bilgisi RCR “Accepted” statüsünden “Implemented” statüsüne geçerken girilmelidir.
➢ Summary – Description - Comment

➢ Bu bölümü JIRA’da açılan RCR’ın özet/başlık görünümünü, Description bölümü ise RCR’ın detaylı olarak
içeriğini ifade eder. Ayrıca tüm iş akışı boyunca Comment alanları sayesinde ilgili roller RCR sürecinde
yorumlarını girebilir.

Gereksinim Türleri
System
Requirement
Technical
Requirement

Gereksinim Türleri
➢ Müşteri Gereksinimleri (Customer Requirement)
➢ Müşteri gereksinimi, bir ürün veya hizmetten beklenen özellik, fonksiyon veya performans
kriteridir.
➢ Müşteri gereksinimleri, bir organizasyonun taleplerini ve beklentilerini belirlemek için kullanılır.
➢ Bu gereksinimler, ürünün veya hizmetin müşteri memnuniyetini sağlamak amacıyla karşılaması

gereken temel özellikleri ifade eder.

Gereksinim Türleri
➢ Sistem Gereksinimleri (System Requirement)
➢ İşlevsel gereksinimler (functional requirements)

➢ ürünün veya sistemin işlevselliği ile ilgili detayları ifade eder
➢ İşlevsel olmayan gereksinimler (non-functional requirements)

➢ genel performans, güvenlik, kullanılabilirlik gibi genel özellikleri tanımlar
➢ İşlevsel gereksinimler, "ne yapılmalıdır"ı tanımlarken, işlevsel olmayan gereksinimler "nasıl

yapılmalıdır" veya "ne kadar iyi yapılmalıdır"ı belirler.

Gereksinim Türleri
➢ Örnek
➢ bir e-ticaret platformu için bir işlevsel gereksinim "Kullanıcıların ürünleri sepete
ekleyebilmesi" iken, bir işlevsel olmayan gereksinim "Web sitesinin yüksek trafikle başa
çıkabilmesi için yanıt süresi 3 saniyenin altında olmalıdır" olabilir.

Gereksinim Türleri
➢ Teknik Gereksinimleri (Technical Requirement)
➢ Teknik gereksinimler, bir sistem veya ürünün tasarımı, geliştirilmesi, uygulanması ve sürdürülmesi
için belirlenen spesifik özellikler ve teknik detayları ifade eder.
➢ Bu gereksinimler, genellikle mühendislik ekibi tarafından anlaşılabilir ve uygulanabilir teknik
spesifikasyonlar içerir.
➢ Yazılım Spesifikasyon Gereksinimleri (SRS)
➢ Donanım Spesifikasyon Gereksinimleri (HRS)
➢ Mekanik Spesifikasyon Gereksinimleri (MRS)

www.buyutech.com.tr
buyutech@buyutech.com.tr

Sistem Mühendisliğine Giriş - Tüm Dersler

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistem Mühendisliğine Giriş - Tüm Dersler

Uploaded by

Copyright:

Available Formats

Sistem Mühendisliğine Giriş

➢ Sistem Mühendisliği disiplinini anlamak ve temel kavramları öğrenmek

➢ Sistem Mühendisliğine Giriş

➢ Sistem Mühendisi alanları:

➢ Proje Başarısını Artırma

➢ Farklı Bakış Açıları:

➢ Tümünün Ötesinde Düşünme:

➢ İlişkili Süreçler ve Etkiler:

➢ Öncü Dönemler - (1940-1960)

➢ II. Dünya Savaşı Dönemi

➢ Soğuk Savaş Dönemi

➢ Modern Sistem Mühendisliği (2000'lerden Günümüze)

➢ Yazılım Mühendislerinin Rolü

➢ Sistem Mühendisleri ile İşbirliği

➢ Yazılım ve Donanım Entegrasyonu

➢ Yazılım ve Donanım Entegrasyonu

➢ Sistem Mühendisliği Felsefesi

➢ Sistem Düşünme Yaklaşımı

➢ Süreç Modeli Nedir?

➢ Neden Süreç Modeli Kullanılır?

➢ Çevik Sistem Geliştirme

➢ Sistem Gereksinimlerinin Uygulanması

➢ Paydaşların İhtiyaçlarını Belirleme:

➢ Öncelik Sırası Belirleme:

➢ Öncelikler, paydaşların iş gereksinimleri ve risk faktörlerine dayalı olarak belirlenir.

➢ İhtiyaçlara Yanıt Verme:

➢ İzleme ve Geri Bildirim:

➢ İkinci adım, sistemin kapsamını ve

➢ Sistem kapsamını ve bağlamını

➢ Bu süreç, projenin başarılı bir şekilde planlanması ve tasarlanması için gereklidir.

➢Gereksinimleri belirleme: (Elicit)

➢Gereksinimleri analiz etme: (Analyze)

➢Değişiklikleri Yönetme: (Change Management)

➢ Dörtüncü adım, sistem gereksinimlerini tanımlamak ve dağıtmaktır ve bu, sistem gereksinimlerini

➢ Gereksinimlerin Alt Sistemlere ve Bileşenlere Dağıtılması:

➢ Sorunların Tanımlanması ve Çözülmesi:

➢ Beşinci adım, sistem gereksinimlerini doğrulama (Validation) ve geçerleme (Varification) adımlarını

➢ Test Planlarının Hazırlanması:

➢ Gereksinim Yönetim Planı

ii. Gereksinim Kapsama ve Karşılama (Requirement Coverage)

iii. Gereksinim Durumu (Requirement Status)

iv. Gereksinim Şablonu (Template for Requirements)

v. Gereksinim Seti Referans Hattı (Requirements Set Baseline)

vi. Gereksinim Nitelikleri (Requirement Attributes)

➢ Gereksinim Yönetim Planın Amacı:

➢ Gereksinimlerin ortaya çıkarılması ve bunların yönetimi için planlama, dokümantasyon ve

➢ Gereksinim Yönetim Planın Kapsamı:

➢ Gereksinim Yönetim Planın Tanımı:

➢ Projedeki iş paketlerinin uygun şekilde oluşturulup oluşturulmadığını, yönetilip yönetilmediğini

➢ Fonksiyonel Güvenlik Yöneticisi:

➢ ALM (Application Lifecycle Management)

➢ PLM (Product Lifecycle Management)

➢ ERP (Enterprise Resource Planning)

➢ ALM (Application Lifecycle Management):

➢ ALM, yazılım geliştirme süreçlerini yönetmek ve denetlemek amacıyla kullanılır.

➢ PLM (Product Lifecycle Management):

➢ ERP (Enterprise Resource Planning):

➢ ALM'nin Gereksinim Yönetim süreçlerine uygulama faydaları:

➢ Gereksinim yönetiminin çoğunu otomatikleştirir.

➢ Gereksinim Kapsama ve Karşılama (Requirement Coverage)

➢ Gereksinim Durumu (Requirement Status)

➢ Herhangi bir gereksinim için belirlenebilecek durumlar:

➢ Waiting for Approval

➢ Onay İçin Beklemede (Waiting for Approval) :