006 uml modelleri gereksinimler [120 slides]

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

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

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

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

• 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

• 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

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

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ı

Use Case Şemaları

[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

[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

“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)

• 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

• 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

[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

“+”

• İç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

[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

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

Gereksinim Yönetimi Planı 1“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

İlham Kaynakları

Ellen Gottesdiener Alistair Cockburn

James Bielak

006 uml modelleri gereksinimler [120 slides]

Documents

gelinlik modelleri , nişanlık modelleri , abiye modelleri

otoregsesif tahmin modelleri

2007 gelinlik modelleri

kocluk modelleri - clear

mobilya modelleri

şebeke modelleri

saklı markov modelleri

tÜketİcİ davraniŞ modellerİ

kocluk modelleri - gains

2006 gelinlik modelleri

deneysel hayvan modelleri · • peritoneal adezyon...

ofis mobilyasi modelleri

taşıma-aktarma modelleri

sinif yÖnetİmİ modellerİ

4. durum deĞİŞkeni modellerİ

ankos f İyatlandirma modellerİ

konsorsiyum modelleri

ekonometrİk sİmulasyon modellerİ

ulaŞtirma modellerİ

abiye modelleri ve nişanlık modelleri 3