what is requirement analysis
Bu Öğretici, SDLC'de Gereksinim Analizi, Gereksinim Analizi Adımları, Örnekleri ve Gereksinim Toplama Hedeflerinin Ne Olduğunu Açıklar:
Yazılım geliştirme, çalışan bir yazılım ürünü oluşturan muazzam bir görevdir.
Yazılım ürünü, müşterinin ihtiyacına göre oluşturulmuştur. Çoğunlukla, bu yazılım ürünü son müşterinin / kullanıcının beklediği şeyle uyumludur, bazen bu ürün müşterinin / son kullanıcının beklediklerine tam olarak uymaz.
Ne öğreneceksin:
- Gereksinim Analizi Nedir?
- Sonuç
Gereksinim Analizi Nedir?
Bir örnek yardımıyla Gereksinim Analizini anlayalım.
Müşteri / Son kullanıcı beklentisi:
Müşteri / Son kullanıcı şunları alır:
Yukarıdaki görüntülerden analiz edebileceğiniz gibi, son üründe müşteri beklentisi ile bir uyumsuzluk olduğunu. Bu sayısız nedenden dolayı olabilir, yani. müşteri gereksinimlerinin yanlış uygulanması, hatalı tasarım, müşteri gereksinimlerinin programcılar ve kalite ekibi tarafından yanlış anlaşılması vb.
Ancak, gördüğünüz gibi, yanlış ürün teslimatının herhangi bir nedeni olsa da, birincil neden gereksinime gider. Bu nedenle, gereksinimlerin doğru anlaşılması, yakalanması, uygulanması ve test edilmesi durumunda, müşteriye / son kullanıcıya hatalı ve eksik ürün teslimatının azaltılmasına yardımcı olacaktı.
İyi bir ürün teslimi, ön koşul olarak doğru gereksinim toplama, toplanan gereksinimlerin verimli bir şekilde incelenmesi ve son olarak açık gereksinim dokümantasyonu gerektirir. Tüm bu süreç aynı zamanda Yazılım Geliştirme Yaşam Döngüsünde (SDLC) Gereksinim Analizi
Gereksinim Analizi Aşamaları / Adımları
Gördüğünüz gibi, Gereksinim Analizi, SDLC'deki ilk etkinliktir, ardından İşlevsel Spesifikasyon vb. Gereksinim analizi, müşteriler tarafından ürün kabulü için kritik olan kabul testi ile rezonansa girdiğinden SDLC'de hayati bir adımdır.
Bu eğitimde, SDLC'de ihtiyaç analizinin nasıl yapıldığını açıklayacağız. İhtiyaç analizinde yer alan çeşitli adımları, sonuçları, zorlukları ve düzeltici önlemleri de göreceğiz.
Gereksinim analizi şunlarla başlar:
- Şartlı toplantı bu aynı zamanda ortaya çıkarma olarak da adlandırılır.
- Bunu takip eden analiz Bu gereksinimleri olası bir ürüne dönüştürmenin doğruluğunu ve uygulanabilirliğini anlamak için toplanan gereksinimler.
- Ve sonunda, belgeleme toplanan gereksinimler.
# 1) İhtiyaç Toplama
Yukarıda belirtilen tüm adımların uygun şekilde yürütüldüğünden emin olmak için, açık, özlü ve doğru gereksinimler müşteriden alınmalıdır. Müşteri, gereksinimlerini doğru bir şekilde tanımlayabilmeli ve iş analisti bunu, müşterinin iletmeyi planladığı şekilde toplayabilmelidir.
Çoğu zaman, müşterinin iş analistleri tarafından ihtiyaç toplama işleminin verimli bir şekilde yapılması mümkün değildir. Bunun nedeni, beklenen son ürün, araçlar, çevre, vb. İle ilgili birçok kişiye bağımlılık olabilir. Bu nedenle, nihai ürünü etkileyebilecek veya ondan etkilenebilecek tüm paydaşları dahil etmek her zaman iyi bir fikirdir.
Olası paydaş grubu, Yazılım Kalitesi mühendisleri (hem QC hem de QA), projede destek sağlayabilecek herhangi bir üçüncü taraf satıcı, ürünün amaçlandığı son kullanıcı, yazılım programcıları, organizasyon içinde sağlayabilecek başka bir ekip olabilir. ürün geliştirme için bir modül veya yazılım platformu, yazılım kitaplıkları vb.
Misal: Bir organizasyonda, ihtiyaç duyulan bir ADAS ürünü (prestijli bir OEM için çevresel görüş kamerası sistemi) geliştirirler. Autosar yığını ve Önyükleyici başka bir tedarikçiden alınan ikili dosyalar.
İhtiyaç toplama aşamasına çeşitli paydaşları dahil etmek, birbirlerine olan çeşitli bağımlılıkları anlamaya yardımcı olur ve gelecekteki olası çatışmalar önlenebilir.
Bazen planlanan ürünün prototip modelini oluşturmak ve müşteriye göstermek iyi bir fikirdir. Bu, müşterilere hangi ürünü beklediklerini ve daha sonra nasıl görünebileceğini iletmenin mükemmel bir yoludur. Bu, müşterinin beklediği ürünü görselleştirmesine ve net gereksinimler bulmasına yardımcı olur.
Bu prototip oluşturma iki tür ürüne bağlıdır:
- Müşterilerin amaçladığı benzer bir ürün organizasyon içinde mevcuttur.
- Geliştirilecek yeni ürün.
(ben) İlk durumda, müşteriye son ürünün nasıl görüneceğini ve nasıl geliştirileceğini göstermek daha kolaydır. Otomotiv ADAS'ında müşterilere, halihazırda piyasada bulunan ve organizasyon içinde geliştirilmiş başka bir ürünü göstermek mümkündür.
Örneğin, Bir OEM (GM, Volkswagen, BMW, vb.) İçin geliştirilen ve başka bir OEM'e sergilenebilen bir çevre görüş kamerası sistemi.
lütfen aklınızda bulundurun geliştirilmekte olan müşteriye ürün / proto ürün göstermek, o ürünün geliştirilmekte olduğu başka bir müşteri ile imzalanan Gizlilik Sözleşmesi'ni ihlal edebileceğinden akıllıca değildir. Ayrıca gereksiz bir yasal mücadeleye neden olabilir.
Başka bir örnek organizasyon tarafından geliştirilen bilgi-eğlence sistemi olabilir ve zaten piyasada. Bir organizasyon içindeki iş analistleri ve diğer paydaşlar, müşteri için somut HMI, cihaz bağlantı portları, sandbox vb. İçeren bilgi-eğlence sistemlerini görüntüleyerek bir atölye demosu planlayabilir.
Bu, müşterinin son ürünün nasıl görüneceğini anlamasına ve gereksinimlerini çok daha net bir şekilde karşılamasına yardımcı olacaktır.
(ii) İkinci durum, basit kodlama ve montaj yapılarak (çoğunlukla buradaki özellikler yazılım programlarında kodlanmıştır) temel bir çalışma modeli oluşturarak veya müşteriyi ürünün nasıl görüneceğine ikna edebilecek bir akış şeması veya diyagram oluşturarak gerçekleştirilebilir.
Her durumda, müşteri artık ne istediğini bildiği için ihtiyaç toplama süreci için bir soluk olacaktır.
İş analisti artık, tüm paydaşların davet edilebileceği ve böylece müşteri tarafından sağlanan çeşitli gereksinimleri not alabileceği resmi gereksinim belirleme toplantıları düzenleyebilir (bazı durumlarda, paydaşların sayısı daha fazlaysa, müşteriyi not etmek için ayrı bir yazı yazabilir) iş analistinin toplantıyı yönetmeye konsantre olabilmesi için gereksinimler veya kullanıcı hikayeleri).
Toplanan gereksinimler şu şekilde olabilir: Kullanıcı hikayeleri (çevik geliştirmede), kullanım senaryoları, müşteri doğal dil belgeleri, diyagramlar, akış şemaları, vb. Kullanıcı hikayeleri, günümüz yazılım geliştirme yaşam döngüsünde popüler hale geliyor. Kullanıcı hikayeleri, temelde kendi doğal dillerinde bir dizi müşteri girdisidir.
Gereksinim Toplama Örneği: ADAS çevre görüş kamerası sisteminde, olası bir kullanıcı hikayesi şöyle olabilir: 'Bir kullanıcı olarak, arabamın arka görüşünde ne olduğunu görebilmeliyim'.
Çok olabilir 'neden,' her kullanıcı öyküsünde sorulan ve müşterinin gereksinimle ilgili daha ayrıntılı bilgi sağlamasına yardımcı olacak sorular.
Yukarıdaki kullanıcı öyküsünde, bir müşteri 'Bir kullanıcı olarak arabamın arka görüşünde ne olduğunu görebilmeliyim' diyor ve bir soru soruyorsa 'neden 'Bir kullanıcı olarak arabamın arka görüşünde ne olduğunu görebilmeliyim, böylece arabamı güvenle park edebilirim ”.
Soruyu sormak 'neden' ayrıca müşteri tarafından verilen muazzam doğal dil ifadelerinden nesnel ve atomik gereklilikler oluşturmaya yardımcı olur. Bu, daha sonra kodda kolayca uygulanabilir.
web hizmetleri mülakat soruları .net
Gereksinimi toplamanın bir başka yolu da şu şekildedir: kullanım durumları . Kullanım senaryosu, belirli bir sonuca ulaşmak için adım adım bir yaklaşımdır. Bu, yazılımın kullanıcı girdisi üzerinde nasıl çalışacağını söylemiyor, kullanıcı girdilerinden ne beklendiğini söylüyor.
Misal:
# 2) Toplanan Gereksinimlerin Analizi
Gereksinim toplama sonrası ihtiyaç analizi başlar. Bu aşamada, çeşitli paydaşlar oturur ve bir beyin fırtınası oturumu yapar. Toplanan gereksinimleri analiz ederler ve bunları uygulamak için fizibilite ararlar. Birbirleriyle tartışırlar ve herhangi bir belirsizlik çözülür.
Bu adım, aşağıdaki ana nedenlerden dolayı ihtiyaç analizi sürecinde önemlidir:
(ben) Müşteri, çeşitli bağımlılıklar nedeniyle uygulanması imkansız olabilecek bazı gereksinimler sağlayabilir.
Misal: Müşterileryardımcı olacak bir dikiz kamera özelliği ile kamera sistemini çevreleyen görüntülemeyi isteyebilir. otopark araba. Müşteri ayrıca şunları da isteyebilir: tanıtım videosu Çalışmak için arka kamerayı da kullanan bağlantı özelliği.
Müşteri, arka görüş kamerası için bir gereklilik belirtirse, otopark yardım her zaman istisnasız çalışmalıdır, sonra tanıtım videosu özellik asla çalışmaz ve bunun tersi de geçerlidir.
(ii) Bir iş analisti, gerekliliği, müşteri nasıl bir programcı yorumlanırdı.
Programcılar teknik uzmanlar olarak düşündükleri için, müşteri gereksinimlerinin hatalı bir şekilde işlevsel şartnamelere dönüştürülmesi her zaman mümkündür, bu daha sonra mimari ve tasarım belgelerine ve ardından koda yanlış bir şekilde yapılacaktır. Etki üsteldir ve bu nedenle kontrol edilmelidir.
Olası bir iyileştirici önlem, çevik bir yazılım geliştirme yöntemini takip ederek, müşterinin sağladığı kullanım durumlarını takip ederek vb. Olabilir.
# 3) Analiz Edilen Gereksinimlerin Belgelenmesi
Gereksinim analizi yapıldıktan sonra gereksinim dokümantasyonu başlar. İhtiyaçların analizinden çeşitli ihtiyaç türleri ortaya çıkar.
Bunlardan bazıları:
(ben) Müşteri Gereksinimi özellikleri.
(ii) Yazılım Mimarisi gereksinimi.
Misal:
(iii) Yazılım Tasarım gereksinimi.
Misal:
(iv) Fonksiyonel Gereksinim spesifikasyonu (doğrudan müşteri spesifikasyonlarından türetilmiştir.)
Misal: 'Kullanıcı Bilgi ve Eğlence HMI üzerindeki Bluetooth simgesine dokunduğunda, Bluetooth ekranı görüntülenmelidir'
(v) İşlevsel olmayan Gereksinim özellikleri (yani performans, stres, yük vb.).
Misal: 'Sistem performansında herhangi bir bozulma olmadan 15 Bluetooth cihazını bilgi-eğlence sistemi ile eşleştirmek mümkün olmalı'.
(Biz) Kullanıcı Arayüzü gereksinimleri.
Misal: 'Tuner FM ekranında, farklı istasyonları seçmek için bir düğme sağlanmalıdır'
Yukarıdaki gereksinimler, IBM DOORS, HP QC gibi gereksinim yönetimi araçlarında kaydedilir ve belgelenir. Bazen kuruluşların maliyeti düşürmek için kendi özel yapım gereksinim yönetimi araçları vardır.
Şimdi dönüştürme sürecine bakalım İş gereksinimleri -e yazılım gereksinimleri (işlevsel ve işlevsel olmayan).
İşletme Gereksinimlerini Yazılım Gereksinimlerine Dönüştürme
Yukarıda tartışıldığı gibi, iş gereksinimleri, son kullanıcının yazılım sistemi üzerinde tanımlanmış bir eylemden ne istediğinden bahseden üst düzey gereksinimlerdir. Yazılım sisteminin veya bileşeninin nasıl uygulanacağına dair ayrıntılı bir açıklama yapılmadığından, tüm yazılım sisteminin bu gereksinimlere göre geliştirilmesi mümkün değildir.
Bu nedenle, İş gereksinimleri, işlevsel ve işlevsel olmayan gereksinimlere göre daha ayrıntılı olarak açıklanacak olan daha ayrıntılı yazılım gereksinimlerine bölünmelidir.
Bunu yapmak için aşağıdaki adımlar takip edilebilir:
- Üst düzey iş gereksinimlerini ayrıntılı kullanıcı hikayelerine ayırın.
- Faaliyetlerin akışını tanımlamak için bir akış şeması türetme.
- Türetilmiş kullanıcı hikayelerini doğrulayan koşulu sağlamak.
- Nesnelerin iş akışını açıklamak için tel kafes diyagramları.
- İş gereksinimlerinden işlevsel olmayan gereksinimleri tanımlama.
Bir örnek Otomotiv Bilgi-Eğlence sistemi ile başlayalım.
İş gereksinimi, 'Son kullanıcı Bilgi ve Eğlence sistemi HMI'dan Navigasyon pencere öğesine erişebilmeli ve hedef adresi ayarlayabilmelidir' diyor.
Dolayısıyla, yukarıda listelenen adımlar şu şekilde uygulanabilir:
# 1) Üst düzey iş gereksinimlerini ayrıntılı kullanıcı hikayelerine ayırın.
Bu iş gereksinimini üst düzey bir kullanıcı öyküsüne dönüştürelim, ' Bir kullanıcı olarak, hedef adresini girebilmem için Gezinme pencere öğesi kutusuna erişebilmeliyim ”. Bu kullanıcı hikayesi, son kullanıcının neye ihtiyaç duyduğunu anlatıyor. Bu gereksinimin nasıl uygulanacağını tanımlamaya çalışacağız.
Bu kullanıcı hikayesine olası sorular sorarak başlayalım.
- Kullanıcılar kimler?
- Navigasyona, yerleşik (SD karttan) veya SmartPhone'dan nasıl erişebilirim?
- Ne tür hedef girişleri girebilirim?
- Araba Park Halindeyken bile varış noktasına girmeme izin verilmeli mi?
Bunlar, üst düzey kullanıcı öykülerinden türetilen daha ayrıntılı düzey kullanıcı öyküleridir ve İş gereksinimlerimiz hakkında daha fazla bilgi edinmemize yardımcı olur.
Bu noktada kullanıcı alt hikayelerinden birini alıp sorgulamaya başlayabiliriz. (No. 3) alalım:
- Coğrafi Koordinatlar, Posta Adresi, Konuşma Tanıma vb. Gibi hedef girişleri girebilir miyim?
- Coğrafi Koordinatları girmek için GPS'e ihtiyacım var mı?
- Adres geçmişinden arayarak mevcut hedef adresini girebilir miyim?
# 2) Faaliyetlerin akışını tanımlamak için bir akış şeması türetmek.
Şimdi, iş gereksiniminin, akış şemasında aşağıdaki gibi işaretlenebilecek çok ayrıntılı kullanım durumlarına bölündüğünü görebiliriz:
# 3) Türetilmiş kullanıcı hikayelerini doğrulayan koşullar sağlamak.
Üst düzey iş gereksiniminin ayrıntılı düşük düzey kullanıcı öykülerine ve akış şemasına ayrıştırılması nedeniyle daha ayrıntılı bilgilerin ortaya çıktığını görebiliriz. Bu akış şemasından, uygulama için gerekli olan teknik ayrıntıları alabiliriz.
- Hedef girişi görüntülemek için ekran yükleme süresi 1 saniye olmalıdır.
- Hedef giriş klavyesi alfanümerik karakterlere ve özel sembollere sahip olmalıdır.
- Navigasyon hedefi giriş ekranında GPS etkinleştirme / devre dışı bırakma geçiş düğmesi bulunmalıdır.
Yukarıdaki bilgiler, kullanıcı hikayelerini tatmin eder ve gereksinimin, özellikler olarak uygulanırken gereksinimle herhangi bir karışıklıktan kaçınarak ayrı ve ölçülebilir şekilde test edilmesini mümkün kılar.
# 4) Nesnelerin iş akışını açıklamak için tel kafes diyagramları.
Yukarıdaki kullanım durumundan, kullanıcı arayüzünü daha net hale getirecek bir tel kafes diyagramı çıkaracağız.
# 5) İşlevsel olmayan gereksinimleri İş gereksinimleri dışında tanımlama.
örnekler ve sözdizimi içeren unix komutları
Ayrıntılı yazılım gereksinimlerinin üst düzey iş gereksinimlerinden türetilmesi zorunludur, ancak çoğu zaman yalnızca bir sistemin belirli bir kullanıcı girdisine / eylemine nasıl davranacağını belirten işlevsel gereksinimler tanımlanır.
Bununla birlikte, işlevsel gereksinimler, sistem performansını ve kullanılabilirlik, güvenilirlik gibi diğer nitel parametreleri netleştirmez.
Örnekler:
a) Yukarıdaki otomotiv bilgi-eğlence sistemi örneğini alacağız.
Aracın sürücüsü (son kullanıcı) USB'den müzik çalıyorsa ve Navigasyon rehberliği devam ediyorsa, Eller Serbest modunda Bluetooth aracılığıyla gelen bir çağrı da alırsa, birden fazla işlem olduğu için CPU ve RAM tüketimi maksimum seviyeye çıkar. arka planda çalışıyor.
Bu noktada, sürücü bir bilgi-eğlence sistemi dokunmatik ekran arayüzüne dokunarak gelen aramayı otomatik cevaplı SMS yoluyla reddederse (cep telefonlarımızda yaptığımız gibi), sistem bu görevi yerine getirebilmeli ve kilitlenmemeli veya çökmemelidir. Yük yüksek olduğunda sistemin performansı budur ve kullanılabilirliği ve güvenilirliği test ederiz.
b) Diğer bir durum Stres senaryosudur.
Örneğin, bilgi-eğlence sistemi bağlı Bluetooth telefon üzerinden SMS'leri (belki 10 saniye içinde 20 SMS) arka arkaya alıyor. Bilgi-eğlence sistemi gelen tüm SMS'leri idare edebilmeli ve Infotainment HMI üzerinden gelen SMS bildirimlerini hiçbir noktada kaçırmamalıdır.
Yukarıdaki örnekler, yalnızca işlevsel gereksinimler yoluyla test edilemeyen işlevsel olmayan gereksinim durumlarıdır. Bazen müşteriler bu işlevsel olmayan gereksinimleri karşılamayı kaçırır. Müşteriye bir ürün teslim edildiğinde bu bilgileri onlara sağlamak kuruluşun sorumluluğundadır.
İşlevsel Olmayan Gereksinim Durumlarını Anlama
Aşağıdaki tablo işlevsel olmayan gereksinimleri açıklamaktadır:
Sl. Yok hayır | Özellik / kullanım durumu | CPU yükü (maks.) | RAM kullanımı (512MB'den maksimum) | Performans parametreleri |
---|---|---|---|---|
1 | Maks. Hayır. Bilgi ve Eğlence sistemiyle eşleştirilebilen Bluetooth cihazlarının | % 75 | 300 MB | 10 Bluetooth cihazı |
iki | Bluetooth eşleştirmesi ve bağlantısından sonra Bilgi ve Eğlence sistemine 2000 Telefon kişisini indirme zamanı | % 90 | 315 MB | 120 saniye |
3 | Bilgi-eğlence sistemindeki Tuner'daki tüm mevcut FM istasyonlarını tarama zamanı | elli% | 200 MB | 30 saniye |
İşlevsel olmayan gereksinimler, işlevsel gereksinimlerden farklı olarak, ilgili Çevik Sprintlerde veya farklı yinelemelerde aşamalı olarak uygulandıklarından, uygulanmaları için bir projenin tüm yaşam döngüsünü alır.
Dolayısıyla, Yazılım Gereksinimlerini İş Gereksinimlerinden bu şekilde elde ederiz.
İşletme Gereksinimleri ve Yazılım Gereksinimleri Arasındaki Fark
Yukarıda, Yazılım gereksinimlerinin üst düzey İş gereksinimlerinden nasıl elde edileceğini gördük. Yazılım gereksinimleri, programcı ve test mühendisinin sistemi geliştirmesine ve verimli bir şekilde test etmesine olanak tanır. Bu nedenle, artık iş gereksinimlerinin müşterinin üst düzey doğal dil gereksinimleri olduğunu, yazılım gereksinimlerinin ise yazılım sisteminin uygulanmasına yardımcı olan ayrıntılı düşük düzey gereksinimler olduğunu biliyoruz.
İki gereksinim türü arasındaki ayrıntılı farkı inceleyelim.
İş gereksinimleri | yazılım gereksinimleri |
---|---|
Sistemin “ne yapması gerektiğini” söyleyen bir müşterinin üst düzey gereksinimleridir. Bu gereksinimler, gereksinimlerin 'nasıl' işlemesi gerektiğini söylemez. | Müşteri gereksinimlerinin 'nasıl' yönüne odaklanırlar. Bu gereksinimler, sistemin nasıl çalışacağını / uygulayacağını açıklar. |
Bu gereksinimler, bir kuruluşun iş hedefiyle ilgilidir. Misal: Kullanıcı Navigasyon hedefini ayarlayabilmelidir. | Bu gereksinimler, gereksinimlerin teknik bilgi birikimini açıklar. Misal: Kullanıcı Navigasyon hedefi simgesine tıkladığında, veritabanı kullanıcının girmesi için hedef ayrıntılarını yüklemelidir. |
İş gereksinimleri, kuruluşun faydasına odaklanır. Misal: Sistemde Navigasyon yoksa ve kullanıcı Navigasyon simgesine tıklarsa, Bilgi-Eğlence sistemindeki bayiden Navigasyon özelliğini yükseltmek için kullanıcıya bilgi verilmelidir. | Yazılım Gereksinimleri, sistemdeki iş gereksinimlerinin uygulama detaylarıyla ilgilenir. Misal: Kullanıcı Bilgi ve Eğlence sistemindeki Navigasyon simgesine tıkladığında, sistem yükseltmesi için kullanıcıya bir mesajın görüntülenmesi için bir API çağrısı başlatılmalıdır. |
İş gereksinimleri normalde Natural dilinde veya üst düzey kullanıcı hikayelerinde yazılır. | Yazılım gereksinimleri işlevseldir ve işlevsel değildir. Misal: İşlevsel olmayan gereksinimler arasında performans, stres, taşınabilirlik, kullanılabilirlik, bellek optimizasyonu, görünüm ve his vb. vardır. |
Sonuç
Gereksinim analizi, herhangi bir SDLC modelinin bel kemiğidir.
Gereksinim analizi sırasında gözden kaçan ve Birim testinde yakalanan bir sorun, bir kuruluşa on binlerce dolara mal olabilir ve bu maliyet, piyasadan geri arama olarak gelirse milyonlarca dolara yol açabilir (2017'de ABD hava yastığı üreticisi Takata a patlayan hava yastıkları nedeniyle 1 Milyar Dolar ceza).
Kuruluş, yazılım geliştirme ve kaliteye odaklanmak yerine kök neden analizi, 5 neden belgesi hazırlama, hata ağacı analizi, 8D belgesi vb. Gibi hasar kontrol görevlerini yerine getirecektir.
En kötü durumlarda, etkilenen özellik güvenlik erişimi, hava yastığı, ABS (Kilitlenmeyi Önleyici fren sistemi) vb. Gibi güvenlik / güvenlikle ilgili ise, kuruluş müşteri tarafından açılan yasal davalara sürüklenir.
Önerilen Kaynaklar
- SDLC (Yazılım Geliştirme Yaşam Döngüsü) Aşamaları, Metodolojileri, Süreçleri ve Modelleri
- İşlevsel Gereksinimlerin Özellikleri ve İşlevsel Olmayan Gereksinimler
- Yazılım Gereksinimleri Spesifikasyonu (SRS) Nasıl Test Edilir?
- Gereksinim Yönetiminde 5 Ölümcül Hata ve Bunların Üstesinden Gelme
- Gereksinimler Olmadan Bir Uygulama Nasıl Test Edilir?
- SSDLC için Önlemler (Güvenli Yazılım Geliştirme Yaşam Döngüsü)
- Spiral Model - SDLC Spiral Modeli nedir?
- SDLC Şelale Modeli nedir?