Upload
erol-bozkurt
View
1.337
Download
0
Embed Size (px)
DESCRIPTION
Unified Process ve UML ile Yazılım Geliştirme - 6 - Gereksinim Yönetimi
Citation preview
UML/UP ile Yazılım Geliştirme
Bölüm 6/7
İçerik
• UML’in Sizin için Anlamı• UML Şemaları, Semboller ve Semantik İlişkileri• Şema ve Model Bazlı UML Çalışmaları
Arasındaki Farklar• Alternatif Yazılım Geliştirme Süreçlerinde
UML'in Yeri• UML ile Gereksinim Yönetimi• UML ile Nesne Yönelimli Tasarım
Neredeyiz?
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Proje Başarısızlığı Nedenleri
• En yaygın nedenler:– Kullanıcı fikirlerinin alınmaması (% 13)– Eksik gereksinimler (% 12)– Değişen gereksinimler (% 12)
• Dolayısıyla projelerin üçte biri gereksinimlerle ilgili nedenlerden başarısız oluyor
Proje Başarısı Nedenleri
• En yaygın nedenler :– Kullanıcı fikirlerinin alınması (% 16)– Üst yönetim desteği (% 14)– Gereksinimlerin açık olması (% 12)
Gereksinim Hataları
• Müşteriye taşınan hataların yaklaşık olarak üçte biri gereksinim hatalarıdır
• Gereksinim hataları bulundukları anda giderilmezlerse ilerideki düzeltilme maliyetleri 10 ila 100 katına çıkabilir
• İyi proje takımları hataları tespit edildikleri anda tahlil ederler
Gereksinim Yönetimi
• Öyleyse gereksinimleri denetlemeye ihtiyacımız var: – Gereksinimleri bulmak, organize etmek ve
dokümante etmek için bir sistem gerekli – Gereksinim değişikliklerini yöneterek müşteri ve
proje ekibinin anlaşmalarını sağlayabilmek için bir süreç gerekli
• Bu kavramlara Gereksinim Yönetimi diyoruz
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Gereksinim Nedir?
• Gereksinimleri tanımlayabilmek için onları gereksinim gibi algılanabilecek diğer bilgi türlerin ayrıştırabilmemiz gerekir
• Bir ihtiyaç (need) bir sistemi kullanan müşterinin işini yapabilmesi için gereken, sistemin sahip olmak zorunda olduğu bir özelliktir
Gereksinim Nedir?
• İşlev (feature) sistemin yerine getirmeyi taahhüt ettiği bir hizmettir
• Gereksinim (requirement) sistemin karakteristik bir özelliğidir
• Gerçekleştirme (realization) gereksinimlerin uygulanma şeklidir
Bir işlevden bir veya daha fazla gereksinim türetilebilir
Detay Seviyeleri
İhtiyaç
İşlev
Gereksinim
Gerçekleştirme
Müşterinin probleminin tanımı
Çözümün tanımı
Daha detaylı
Çözümün gerçekleştirilmesi
Gereksinim Nedir?
• Fırsat (opportunity) yeni bir işlev, yeni bir müşteri tipi veya ürüne eklenen yeni bir özellik olabilir
• Problem müşterinin işini yaparken karşılaştığı bir zorluktur
• Kısıtlama (constraint) oluşturulacak sistemin uymak zorunda olduğu bazı sınırlardır
Acaba Bu Bir Gereksinim Mi?
• Yoksa eksik bilgiyle tasarımıma mı başladık?• Gerçekte ihtiyaç duyulmayan gereksinimlere
ve aslında mevcut olmayan kısıtlara dikkat ediniz
• Yoksa birisi problemden ziyade çözümü mü tanımlamaya başladı?
• Bir gereksinim olmak için çok mu genel?
Öncelik• Gereksinimin önceliği veya aciliyeti nedir?
– Yüksek, Orta, Düşük– Zaruri, İstenen, Seçeneğe Tabii – Mutlaka olmalı, Olması arzulanan, Olsa iyi olacak olan– Gündelik terminolojide ‘olacak’, ‘olsa iyi olur’, ‘olmayabilir’
• Gereksinimlerin önem nedenleri nedir?– Sistem Mimarisine etki,– Teknolojik yenilik nedeniyle bir risk,– Zorluk nedeniyle bir risk,– Vs. vs.
Paydaş (Stakeholder)
• Müşteriden fikri değerli yegane grupmuş gibi bahsedebiliyoruz ama projeye yönelik çelişen düşüncelere sahip pek çok grup insan olabilir (paydaş)
Paydaş Türü Örnekleri
• Sponsor• İş Analisti, Sistem analisti, Tasarımcı, Programcı,
Veritabanı Analisti, vs.• Konu Uzmanları• Kullanıcı• Yöneticiler• Admin.’ler• Süreç Uzmanları, Kalite Sorumluları, vs.• 3rd Party
Paydaşların Çelişen İstekleri
• Bu paydaşların hepsinin farklı ve birbirleriyle çelişen istekleri olabilir
• Başarılı bir projenin sağlaması gereken en önemli şeylerden biri bu isteklerin sahipleri arasında bir mutabakat sağlamaktır
• Mutabakat farklı çıkarlara sahip rollerin çıkarlarını olabildiğince korumalarıyla mümkündür
Yazılım Ekibi
• Yazılım geliştirme sürecine iştirak eden herkes gereksinim yönetimi çalışmalarından farklı şekillerde etkilenirler
• Problem çoğu yazılımcının teknik odaklarından dolayı insan ilişkilerinde çok başarılı olmayışlarıdır
• Öte yandan modern sistemlerin karmaşıklıkları insan ilişkisini zaruri kılmaktadır
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Altı Ekip Yeteneği
1. Problem analizi2. Müşteri ihtiyaçlarını anlama3. Sistemi tanımlama4. Sistem kapsamını yönetme5. Sistem tanımının revize edilmesi6. Doğru sistemin geliştirilmesi
1. Problemi analizi
Bu konuya ileride, daha sonra değineceğiz.
2. Müşteri ihtiyaçlarını anlama
• En üst seviyedeki gereksinimler olası çözümün tanımlanmasından çıkar
• Müşteriden bu gereksinimleri alabilmek için hangi teknikleri kullanacağımıza nasıl karar vereceğiz?
• Tıpkı bir marangoz gibi iş için gereken alet edavatı kolayca tespit edebilmek
3. Sistemi tanımlama
• Bir dizi gereksinimi nasıl organize edecek ve oluşturulacak sistemin açık bir resmini görebileceğiz?
• Alakalı ürünler arasındaki ortak gereksinimler nasıl ilişkilendirilecekler?
• Ürünün vizyonunun dejenere olmaması için onu detay gereksinimlerden nasıl ayrıştıracağız?
4. Sistem kapsamını yönetme
• Gereksinimler nadiren statiktir. Üç yaşındaki çocukların ilgi alanı gibi her an değişirler
• Ürünün kapsamının kontrolden çıkmasını nasıl sağlayacağız?
• Yapılması gerekenleri geciktirirsek kapsamı nasıl kontrol edebiliriz?
5. Sistemin tanımının revizyonu
• Yazılım ekibinin işini yapmaya kalkışmadan onlar için gerekli detay seviyesindeki gereksinimleri nasıl oluşturabiliriz?
• Detaylı gereksinimler vizyondan kopmamalı ve sadece her küçük problem parçasının çözülebilir olmasını sağlamalı
6. Doğru sistemin geliştirilmesi
• Tasarımın gereksinimleri yerine getirdiğini nasıl anlayacağız?
• Tasarımın müşteri isteklerine uygunluğundan nasıl emin olacağız?
• Gereksinim değişikliklerini nasıl kontrol altına alacağız?
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Problemler ve Fırsatlar
• Sistemlerin en önemli iki nedeni:1. Problem çözmek; mevcut sistem müşteri
ihtiyaçlarını karşılamıyor demek 2. Fırsatları değerlendirmek; yeni ürün düşünceleri,
yeni işlevler, yeni pazarlar vs.
• Biz problem çözmeye odaklanacağız
Problem Analizi Aşamaları
• Problem beş aşamada tahlil edilebilir:1. Problem tanımı üzerinde anlaşmak2. Problemin temel nedenlerini anlamak3. Paydaş ve kullanıcıları tespit etmek 4. Sistemin sınırlarını tespit etmek5. Çözümü sınırlandıracak olan kısıtları bulmak
1Problem tanımı üzerinde anlaşmak
• Problem tanımı içeriği: – Problemi tarif ediniz – Etkilenen paydaşları belirtiniz – Problemin paydaşlar ve yaptıkları işler üzerindeki
etkilerini belirtiniz – Önerilen çözümü ve sağlayacağı faydaları ifade
ediniz • Kısaca, neden bu problemi çözmek için
vaktimizi harcamalıyız?
2Problemin nedenlerini anlamak
• Problemin mevcudiyetinden emin olunca bir çözüm oluşturmamız gerekiyor:
• Bir yol “temel neden” veya “nedensellik analizi”dir. Böylece problemin mevcudiyet nedenini anlayabiliriz
• Bunun için ‘kılçık şeması’ (fishbone) çizebiliriz– Düz bir çizgi çekerek problemi yazınız– Sonra problem nedenlerini yazınız– Daha sonra problem nedenlerinin nedenlerini yazınız– Tekrar ediniz
2Problemin nedenlerini anlamak
• ‘Akıl haritası’ (mindmap) çizebiliriz12 m.
Boeing Uçak A.H.
3Paydaşları ve kullanıcıları tespit
• Sistemi kullanacak ve mevcudiyetinden etkilenecek kişileri tespit edin
• Çoğu paydaş kullanıcıdır ama diğerleri değillerdir
4-5Sistemin sınırlarını tespit
• En basit tanımıyla her sistem bazı girdiler alır ve bazı çıktılar üretir
• Püf noktası bu girdi ve çıktıları kimin veya neyin üretip tükettiğidir
SystemInputs Outputs
4-5Sistemin sınırlarını tespit
• Neler sistemin kapsamındadır?– Paydaşların yerine kendimizi koyarsak,– Kullanıcıların yerine kendimizi koyarsak,– Yazılım ekibinin yerine kendimizi koyarsak,
• Dış sistemler hangileridir?– Bağımlı olduklarımız,– Bizim sistemimize bağımlı olanlar
4-5Sistemin sınırlarını tespit
• Sistem üzerine adı yazılı bir kutu ile gösterilir• Aktörler çöpten adamlardır• Dış sistemler ya adı üzerine yazılı bir kutu ya da daha yaygın olarak birer
aktör olarak gösterilirler• İlişki çizgilerinin yönü veri akış yönünü gösterir
StockTrackingSystemEnd User
StockExchanges
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Paydaş ve Kullanıcı İhtiyaçları“Stakeholder Requests”
• Gereksinimlerin bulunabilmeleri için yazılım ekibi dikkatli olmalıdır– Gereksinimleri açığa çıkarabilecek kavramları
değerlendiriniz – “Bunu bir gereksinim olarak eklemek ister misiniz”
diye sorunuz ve bahsedilen düşüncenin önemini saptayınız
• Çalışmalarınıza müşteri ihtiyaçlarını tespit ederek başlayınız
Paydaş ve Kullanıcı İhtiyaçları“Stakeholder Requests”
• En üst seviyedeki bilgi türümüz olan ihtiyaçlarla problem tahliline başlayabiliriz
• Genellikle ihtiyaçlar sistemin çözmesi beklenen temel bir problemle ifade edilirler (bu problemi nelerin ortadan kaldıracağıyla)
• Bazı kullanıcılar işlevlere değinebilirler – ihtiyaçların nasıl yerine getirilebilecekleri
İşlevler“Features”
• İşlevler müşteri ihtiyaçlarının hangi ürün kabiliyetlerine karşılık geleceğini ifade ederler – İşlev sistemin bir ihtiyacı gidermek için sunduğu bir
hizmettir• İşlevin faydası onun altında yatan ihtiyaçlara bakıldığında
kendisini gösterir • Bir ihtiyaç sisteme değinmez; bunu bir işlev yapar
Örneğin, Evden okula kayıt olabilmek istiyorum (ihtiyaç) -> Sistemin
internet erişimi olmalıdır (işlev)
Hangisi Hangisi?
• Kullanıcı görüşmesinde ihtiyaç ve işlev ayrımını hemen yapmak gerekmez
• Daha sonra edinilen bilgilerin düzenlenmesinde yardımcı olur (brainstorming)
• İşlev örneği arıyorsanız, yazılım ürünü reklamlarına bakınız!
İhtiyaç ve İşlev Sayıları
• İhtiyaçlar genellikle azdır – 10 veya daha az• İşlevler sistemin büyüklüğüne göre genellikle
25-100 arasında değişirler • Sistem kapsamı toplantıları için işlevler
kullanılırlar
İşlevler ve Gereksinimler
• İşlevlerin (feature) detayları ortaya dökülmeye başlandığında gereksinimler (requirement) ortaya çıkmaya başlarlar
• İşlev aşamasında geçici öncelikler verilebilir• İşlevleri ileride kolayca yönetebilmek için
açıklamalarını yazınız
İşlev/Gereksinim Değişkenleri (Attribute)
• İşlevleri yönetebilmek için kullanılan tipik değişkenler:– Statü, {önerildi, onaylandı, reddedildi}– Öncelik, {yüksek, orta, düşük}– Emek, {yüksek, orta, düşük}– Risk, {yüksek, orta, düşük}
İşlev/Gereksinim Değişkenleri (Attribute)
– Değişebilirlik (Stability), işlevin ve ileride implementasyonunun değişme olasılığı / derecesi
– Hedeflenen sürüm, Bu işlev hangi sürümde hazır olacak?
– Görevli, Bu işlevle ilgili atama kime yapıldı? Aşamasına göre farklı kişiler olabilir (gereksinim, analiz vs.)
– Neden veya Kaynak – Bu işlevin kaynağı nedir?
İşlevler ve Gereksinimler
Üst seviye gereksinimler: İşlevler“features”
Fonksiyonel gereksinimler“functional requirements”
Fonksiyonel olmayan gereksinimler“supplementary requirements”
Gereksinim Grupları
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Senaryo Odaklı Gereksinim YönetimiSenaryo Odaklı Gereksinim Yönetimi
Use-Case Modeli
İşlevler
Gereksinimler
İhtiyaçlar
=
Senaryo Odaklı Yol Geleneksel Yol
Geleneksel Software Requirements Specification (SRS) dokümanı Use Case Modeli ve Ek Gereksinimler Dokümanına (Supplementary Requirements) karşılık gelmektedir.
+
Gereksinim Ürünleri (Artifact)
Ek Gereksinimler(SupplementarySpecification)
Proje Sözlüğü(Glossary)
Use-Case Dokümanları
...
Use Case Modeli
AktörlerUse Case’ler
İlgili Roller
• Hazırlayan: İş Analisti, Sistem Analisti• Faydalanan: Tasarımcı, Kullanıcı Arayüzü
Tasarımcısı, Ürün Kullanım Kılavuzu Yazarı, Veritabanı Tasarımcısı
• Yardımcı: Müşteri, Müşteri Temsilcisi, Konu Uzmanı
Gereksinim Ürünleri (Artifact)
Use Case Şemaları
Gereksinim Ürünleri (Artifact)
[1]Vizyon
• Ürününüzün ilgili olduğu işi aklayan ve gerekli kabiliyetlerini ortaya koyan genel bir dokümandır
• Ne yapmak istiyorsunuz ve o iş neden yapılmaya değer?
• Vizyon dokümanı içeriği: – Giriş: ürününüzün karşılık olduğu temel ihtiyaçlara
değininiz
Vizyon
– Konumlandırma (Positioning): hitap ettiğiniz pazarın sizin açınızdan problemli yanlarını,
hedef kitlenizi ve rakiplerinizin ürünlerinin kabiliyetlerini (ne yapıp ne yapamadıkları) yazınız.
– Paydaş Tanımları: paydaşların demografik yapısını, ürününüzü kullanmak için
gereken kabiliyet seviyesini, paydaşlarınızın hedefleri ve yaşadıkları sorunları belirtiniz. Her paydaş türüne bir temsilci atayarak irtibat bilgilerini sağlayınız.
Vizyon
– Ürün işlevleri listesi: ürünün sağlaması gereken temel işlevleri ve
bunların paydaşlara ne fayda sağlayacağını birer ikişer cümle ile yazınız
Vizyon - Amaç
Vizyon – İş Fırsatı
Vizyon – Problem Tanımı
Vizyon - Paydaşlar
Paydaş Detayları
İşlevler
Gereksinim Ürünleri (Artifact)
[2]Use Case Dokümantasyonu
• Monolog değil Dialog olmalı.• Aktörleri ile Use Case arasındaki etkileşimleri
içermeli.• Müşteri ile Tasarımcılar, Veritabanı
Tasarımcıları ve Arayüz Tasarımcıları arasındaki köprü olmalı.
Use Case: Olayların Akışı• Bir tane olağan, en tipik akış: Temel Akış (“Happy
Path”)
• Birden fazla Alternatif Akış:– Başarılı alternatif akışlar– Başarısız Akışlar hata durumlarını tolere etmeye
yarar
“Happy Path”
Senaryo Nedir?Bir senaryo use case’in içerdiği akışların bir kombinasyonunun başlayıp
bitişidir: Use Case Instance.
Senaryolar
• Use Case akışlarının bir kombinasyonudur (use case instance)
• Bir senaryonun beklenen (başarılı) bir neticesi olabilir– Müşteri kitaplarını satın aldı
• Veya başarısız bir neticesi olabilir– Müşterinin kredi kartı kabul edilmedi
Senaryolar
• Her use case’in odağı başarılı Temel Akışı’dır• Ancak pek çok başarılı ve başarısız Alternatif
Akış olabilir– Alternatif senaryolar akış esnasında neler
olabileceğini tespit yollarıdır. Örneğin, farklı şekillerde ödeme, bir transaction’ın bitirilememesi gibi
Use Case Dokümanı Formatı
• Tek-sütun formatında her paragraf aktör veya sistemin bir faaliyetini anlatır. Daha yaygın bir kullanımdır.
• İki-sütun formatında sol sütun aktöre sağ sütun sisteme aittir ve faaliyetleri ona göre yer alırlar. Faydası dialoğun zigzag yapısını daha iyi göstermesidir.
Use Case DokümanıGelişim Süreci
Bulunma Tanımlanma
Konu Başlıkları + Kısa Tanımlar
Temel Akış Detaylanır Tüm Akışlar Detaylanır
Use Case Dokümanı İçeriği
• Dokümanın mutlaka içermesi gerekenler ‘*’ işaretlenmiştir.– Temel Aktör*– Paydaşlar ve UC’le ilgileri– Precondition*– Postcondition*– Temel Akış*– Alternatif Akışlar*
1. Use Case Tanımı
– İlişkili Use Case’ler– Ek Gereksinimler– İş Kuralları– Kullanım Yoğunluğu– Açık Konular
2. Temel Aktör
• Bir use case için temel aktör o UC’i kendine bir fayda sağlamak için çalıştıran aktördür.
• Dolayısıyla bu aktör UC’i için bir tetik mekanizmasıdır.
• Temel Aktör genellikle insandır. Ancak bazen sistemler otomatik olarak dış sistemlere erişirler.
3. Paydaşlar ve UC ile İlgileri
• Bu bölümde use case’in akışında bir parçası olan tüm aktörler ve kendilerine sağladıkları faydalar belirtilmelidir
• Genellikle aktör başına bir iki cümle kafidir
4. Temel Akış• Herşeyin yolunda gittiği varsayılarak use case akışının adım
adım ve aktörle sistem arasındaki dialoğu işaret edecek şekilde yazılmasıdır.
• Bu akış iş kurallarını, üretilecek ve tüketilecek veri yapılarını ve yapılacak kontrolleri içerir.
• Bu akış use case’in beklenen kullanım şeklini ifade eder.• Bütün adımlar aktör’ün perspektifiyle yazılır. Yalnızca onun
gördükleri ve yaptıkları ile sistemin bu davranışlara reaksiyonlarını içerir.
5. Alternatif Akışlar
• Temel akışın izlediği yolu değiştirebilecek koşulları ve bu durumlarda kullanılacak yeni akışları ifade eder
• Bu başarısızlık durumlarını içerdiği gibi (kredi kartının reddedilmesi), farklı seçeneklerin izlediği yolları da içerir (çekle, kredi kartıyla veya paypal’le ödeme)
5. Alternatif Akışlar
• Alternatif akışlar geçerli oldukları temel akış adımında yanlarına harf konarak işaretlenirler
• Temel Akış 3. Kasiyer ürün numarasını girer
• Alternatif Akış 3a. Geçersiz numara
• Daha sonra da alternatif akış adımları yazılır
5. Alternatif Akışlar
• Dolayısıyla alternatif akışların iki parçası olur:• Nedeni: Başlığı • Akışı: Kendine özel akışı• Nedeni: 3a. Geçersiz ürün numarası
Akışı: 1. Sistem bir hata mesajı vererek ürünün
girilmesini engeller.
6. Precondition
• Use Case’in çalışabilmesi için sistemin sahip olması gereken durumu ifade ederler
• Bu liste temel aktörün o ana kadar yaptıklarını ve yapmadıklarını, şu andaki use case’e yönelmesine yol açan eylemleri içerebilir
7. Postcondition
• Use case’in akışının tamamlanmasının sonucunda sahip olunması gereken durumları ifade eder
• Bu da precondition gibi temel akış referanslı bir listedir. Herşey yolunda giderse use case akışı sonunda elimize ne geçecek?
8. Ek Gereksinimler
• Fonksiyonel olmayan gereksinimler veya use case’e özel kısıtlamalar olabilir– Performans, Güvenilirlik, Kullanılabilirlik ve
Tasarım Kısıtlamaları bu bölümde belirtilebilir• Use Case’e özel olmayan bu tür gereksinimler
Ek Gereksinimler (Supplementary Specification) dokümanında yer alır
9. İş Kuralları
• Use Case akışı esnasında uyulması gereken işe özel kuralları ve yapılması gereken kontrolleri gösterir.
• Genellikle use case’e özel değil, proje genelinde bir doküman olarak oluşturulur.
10. Kullanım Yoğunluğu
• Use Case’in kullanım yoğunluğunun belirtildiği bölümdür:– Günde 1000 defa mı?– Ayda 1 defa mı?
• Use Case öncelikleri hakkında fikir verdiğinden tasarıma yardımcı olur
11. Açık Konular
• Bu kısımda emin olmadığımız varsayımları, muhtemel teknoloji değişikliklerini ve bunlar gibi kesinleşmemiş konuların unutulmamalarını sağlayabiliriz.
• Kesinleşmemiş hukuki, iş akışı ve interface konularını da burada belirtebiliriz.
Bid on Item - Use Case Dokümanı
İnternette Açık Artırma
UC Dokümanı - Tanım
UC Dokümanı - AkışUC Dokümanı - Akış
UC Dokümanı – Geriye KalanUC Dokümanı – Geriye Kalan
Gereksinim Ürünleri (Artifact)
[3]Ek Gereksinimler: FURPS+ Modeli
• Ek Gereksinimlerin kapsamı:• Fonksiyonel (Functional)• Kullanılabilirlik (Usability)• Güvenilirlik (Reliability)• Performans • Bakım (Supportability)• + = geriye kalan herşey
Fonksiyonel
• Tüm sisteme yönelik fonksiyonel gereksinimler.
• UC odaklı olmayan yazılım geliştirme yöntemlerini kullananlar için.
• Fonksiyonel gereksinimlerin tamamı aslında UML yaklaşımında UC Modeliyle kapsanıyor.
Kullanılabilirlik (Usability)
• Kullanılabilirlik:– İnsan faktörü; sisteminizi kullanmak nasıl
hoşnutluk verici olabilir? – Help; Kullanıcıya hangi help imkanı sağlanacaktır?
F1? Context sensitive? Online kullanım kılavuzu?– Dokümantasyon; Kullanıcıları eğitmek için ne tür
dokümantasyon üretilecektir?
Güvenilirlik (Reliability)
• Güvenilirlik ölçüm şekilleri: – Mean Time Between Failures (MTBF); İki sistem
göçmesi arasında geçen zaman – Mean Time To Repair (MTTR); Sistem göçtüğünde
çalışır hale getirilmesi için gereken zaman (Bu ‘bakım’ başlığı altında da olabilir)
– Sistemin kullanılabilir durumunu koruması (Availability) ‘performans’ başlığı altında yer alır
Performans
• Çoğu performans kriteri gereksinime dönüşür– Sorgu cevaplama süresi (ortalama, maksimum)– Throughput (Saat veya gün başına işlenen kayıt
sayısı, transactions per second (TPS))– Accuracy (scan veya veri giriş doğrululuğu)– Kaynak kullanımı (CPU, HDD kullanımı, network
trafiği)
Bakım (Supportability)
• İçeriği:– Bakım prosedürünü içerir. Sorunlar için kılavuz mu
sunacaksınız? – Sistemin bakımını yapmak ne kadar kolay? Yazılımı
ve Donanımı birlikte düşününüz. – Internationalization; sisteminiz farklı dillerde
kullanılabilecek mi?– Sisteminizin konfigürasyonu kolayca değiştirilebilir
mi?
“+”
• İçeriği:– İmplementasyon – Interface– Operasyonel– Paketleme– Kanuni konular– Ve aklınıza ne gelirse!
“+” - İmplementasyon
• İmplementasyon üzerindeki sınırlamaları ifade eder:– Kaynak sınırlamaları (maliyet, zamanlama,
eleman)– Dil ve ürünler (kullanılacak programlama ortamı)– Donanım (Dell)– Yazılım (MySQL)– Kullanıcı PC özellikleri (PIII 1000 MHz, 128 MB
RAM, Windows ME)
“+” - Interface
• Interface gereksinimleri dış sistemlerle haberleşme amaçlıdır: – Kurumuzdaki eski sistemler– Bileşenlerini satan şirketler– Başka proje ekipleri– Dış kurumlar (İMKB vs.)
“+” - Operasyonel
• Sisteminiz kullanım halindeyken yönetilebilmelidir
• Yöneticilere gereken kabiliyetler?– Kullanıcı ekleme– Kullanıcı erişim haklarını değiştirme– Kaynak kullanımını izleme (CPU, disk, network)– Fiziki ortamı izleme (ısı, nemlilik)
“+” - Paketleme
• Ürününüz nasıl paketlenecek?– Medya? CD-ROM? DVD?– Hangi dokümanlar basılacak? Hangileri elektronik
ortamdan sağlanacak?– Kullanıcılar için help desk kimlerden oluşacak?– Farklı ülkelere özel çalışmalar yapılacak mı?
“+” - Kanuni
• Ürününüz nasıl lisanslanacak?– Kullanıcı başına? Şirket başına?– PC başına?– CPU başına?
• Ürününüzün farklı versiyonları var mı? (akademik, profesyonel)
• Ürününüzün satılamayacağı yerler var mı? (ihracat kısıtlamaları)
FURPS + ve UML
Gereksinim Ürünleri (Artifact)
[4]Sözlük (Glossary)
• Proje terimlerini içerir:– Terim 1, Terim 2, … Terim N
• Kısaltmaları ve use case dokümanlarında ifade edilseler çok yer kaplayarak okunmayı zorlaştıracak veri yapısı tanımlarını içerir
• Tanımlar dokümanda olabilir veya başka bir dokümanı refere edebilir
• Sözlük hyperlink’ler içerebilir
İçerik
• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik
Gereksinimleri Önceliklendirme
• Tüm gereksinimler (özellikle use case modelindeki fonksiyonel gereksinimler) için öncelikler belirlemeli ve ona göre zaman planı yapmalıyız.
• Önceliklendirme gereksinim değişkenleri kullanılarak yapılmalıdır:– {Tür: Zaruri, İstenen, Seçeneğe Tabii}– {Sistem Mimarisine Etki: Var, Yok}– {Emek: Zor, Orta, Kolay}– Vs. vs.
Gereksinimlerin Takip Edilebilirliği
Önceliklendirme ve Takip Edilebilirlik Kriterleri
Önceliklendirme ve Takip Edilebilirlik Kriterleri
veya
Gereksinim Yönetimi Planı 1“Vizyon Kapsamında”
Gereksinim Yönetimi Planı 2“Vizyon Kapsamında”
Gereksinim Yönetimi Planı 3“Vizyon Kapsamında”
Gereksinim Yönetimi Planı 4“Vizyon Kapsamında”
Gereksinim Yönetimi PlanıRequirements Management Plan Configuration Management Plan
1. İterasyonların Belirlenmesiİnternet’te Açık Artırma Sistemi
2. İterasyonların Belirlenmesi
3. İterasyonların BelirlenmesiSistem Mimarisini Etkileyen UC’ler
İterasyon 1
İterasyon 2
İterasyon 2
İlham Kaynakları
Ellen Gottesdiener Alistair Cockburn
James Bielak