Use-case

ANALİZ
İçerik
 Yazılım İster (Gereksinim) Analizi
 İster Nedir?
 İster Türleri
 Alan
 İşlevsel, işlevsel olmayan
 Sistem, Kullanıcı
 Diğer
 İster Çözümleme Aşamaları
 İster Çözümleme Yöntemleri



Doğal Dil
Yapısal Doğal Dil
 Formlar, şablonlar aracılığı ile ifade
Grafiksel Gösterim
 Veri Akış Şemaları

UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi
 Geçerleme,Gözden Geçirme
 Sonuç: The software requirements document
(Yazılım İster (Gereksinim) Dökümanı)
Yazılım İsterleri Çözümlemesi
Bir bilgisayar programının başarısı öncelikle müşteri
isteklerini tam olarak karşılamasına bağlıdır.


Yazılım isterleri çözümleme aşaması
Müşterinin yazılımdan bekledikleri belirlenir
 Gereksinimler açıklığa kavuşturulur
 Yazılım isterleri modellenir ve tanımlanır
 Böylece de sonraki aşamalar için temel oluşturulur.

İster

İster nedir?

İster çeşitleri

Kullanıcı ve sistem isterleri nelerdir?
İşlevsel (functional) ve işlevsel-olmayan (non-functional)
isterler nelerdir?

İster nedir?

İster (gereksinim): gerekli olan, istenen veya ihtiyaç duyulan.*

IEEE 729
Kullanıcı tarafından bir problemi çözme ya da bir hedefi
gerçekleştirmek için ihtiyaç duyulan durum ya da yetenek

* http://www.webster.com
** Pressman, R. Software Engineering: A Practitioner’s approach
İster mühendisliği nedir?

Tüm bu hizmet ve kısıtlamaların
belirlenmesi
 çözümlenmesi
 belgelendirilmesi
 ve kontrol edilmesi

sürecine İster (Gereksinim) Mühendisliği denir
İsterler neden önemlidir?



İsterlerden kaynaklı hatalar
geç aşamalarda fark edilir
Genellikle yanlış bilgi, ihmal
ve tutarsızlık kaynaklıdır
Bu durumda da düzeltilme
maliyetleri yüksek olur
İster Türleri
 Görevlerine Göre
 İşlevsel (Functional)
 İşlevsel Olmayan (Nonfunctional)
 Detay Seviyesine Göre
 Kullanıcı
 Sistem
 Alan İsterleri
 Diğer İsterler??
 İsterleri farklı detay seviyelerinde yazmak gereklidir
çünkü farklı okuyucular onları farklı şekillerde
kullanacaklardır
Kullanıcı İsterleri
İşlevsel ve işlevsel olmayan gereksinimleri tanımlamalı,
böylece detaylı teknik bilgiye sahip olmayan sistemin
kullanıcıları tarafından da anlaşılabilmelidir.

Kullanıcı isterleri, doğal dil, basit tablo ve formlar ve
şemalar ile tanımlanır.

Sadece sistemin harici davranışlarını belirtmeli ve mümkün
olduğunca tasarım özelliklerine girmekten kaçınmalıdır.


Çoğunlukla, teknik-olmayan okuyucular tarafından okunurlar
Sistem İsterleri

Kullanıcı isterlerinin daha detaylı belirtimidir

Sistemi tasarlamak için temel oluşturur.
İdeal olarak, basitçe, harici davranış ve kısıtlamaları tanımlar.
Tasarım ve uygulama ile ilgilenmemelidir.


Fakat pratikte, tasarım bilgisi bulundurabilir.
İster belirtimine yardımcı olabilmek için bir başlangıç mimarisi
tasarlanabilir  tasarımda yeniden kullanılabilir
 Başka var olan sistemlerle arayüzü bulunabilir  tasarıma kısıt getirir
 İşlevsel olmayan isterlere özel bir mimariye karar verilebilir 
tasarıma kısıt getirir.

Uygulama Alanı isterleri
 İşlevsel veya işlevsel olmayan??
 Her ikisi de olabilir.
 Alana özel gereksinimler, sistemin çalışacağı ortam.
 Kullanım ortamında gözlem yapılarak nelere
gereksinim duyulduğu ve işin kapsamı belirlenir.
 Benzer ürünler incelenir, onlardan temel isterler
çıkarılır.
 Gerekirse bu bilgiler bir kapsam tanımlama belgesinde
toplanır
Uygulama Alanı isterleri
 Mevcut gereksinimleri yeni fonksiyonel gereksinimleri,
kısıtlamalar ekleyebilir
Bu gereksinimler yerine getirilmezse sistem çalışamaz.

Kütüphane sistemi uygulama alanı isterleri:

Z39.50 standardı esas alınacaktır tüm veritabanları için standart bir
kullanıcı arayüzü olacaktır.

Telif kısıtlamalarıdan dolayı, bazı belgeleri ulaştığında hemen
silinmelidir.Kullanıcı gereksinimlerine bağlı olarak, bu belgeler ya elle
kullanıcıya yönlendirme veya bir ağ yazıcısı yönlendirilirilerek sistem
sunucusu üzerinde yerel olarak basılacaktır.

Tren sinyalizasyon sistemi

Trenin yavaşlama gibi hesaplanacaktır:
Dtrain = Dcontrol + Dgradient
İşlevsel isterler
İşlevsel-olmayan isterler
İşlevsel-olmayan ister çeşitleri
İşlevselolmayan
İsterler
Kurum
isterleri
Ürün
isterleri
Kullanıla
bilirlik
Verim
lilik
Güven
ilirlik
Taşına
bilirlik
Teslim Gerçek
leştirim
Harici
isterler
Standart Birlikte
lar
işlerlik
Etik
İsterler
Yasal
isterler
Performans
isterleri
Gizlilik
isterleri
Alan
isterleri
Güvenlik
isterleri
İşlevsel-olmayan ister örnekleri
İşlevsel olmayan isterler diğer işlevsel olmayan ya da
işlevsel isterler ile çakışabilir ya da etkileşebilir.


Örn.
Sistem tarafından kullanılacak maksimum hafiza 4 MB den fazla
olmayacak.
 Sistem ADA kullanılarak yazılacak.

Ada programını istenen 4MB den düşük hafıza isteri ile
derlemek mümkün olmayabilir.
Başka bir geliştirme dili seçimi
 Hafızayı arttırma

İşlevsel-olmayan isterlerin ölçümü
Doğruluğunu sınamak zordur: Kullanılabilecek olası
ölçüm yolları (metric) vardır.


Ama bazılarını belirlemek zordur: bakım gibi
Mümkün olduğunca doğruluğu sınanabilecek işlevselolmayan ister yazmaya çalışmalısınız

İşlevsel-olmayan ister ölçütleri (metrics)




Hız:
 İşlenen işlem/saniye
 Ekran yenileme
Boyut:
 K bytes
 Ram miktarı
Kullanım kolaylığı

Gerekli eğitim süresi
 Yardım ekranlarının sayısı
Taşınabilirlik
 Hedef sistem sayısı
 Hedefe bağımlı anlatım yüzdesi


Güvenilirlik
 Ortalama hata sayısı zamanı
(MTF-Mean Time to failure)
 Kullanımda olmama olasılığı
Sağlamlık
 Hata sonrası yeniden başlatma
zamanı
 Hataya neden olan olay yüzdesi
İşlevsel-olmayan ister örnekleri
Sistem, deneyimli bir kontrolör tarafından kolayca
kullanılmalı ve kullanıcı hataları en aza indirilecek
şekilde organize edilmelidir.


Doğruluğu sınanabilecek şekilde yeniden yaz:
Deneyimli kontrolörler sistem fonksiyonlarını 2 saatlik bir
eğitim sonrasında kolaylıkla kullanabileceklerdir. Bu
eğitimden sonra, deneyimli kullanıcıların ortalama hata
yapma oranı günde 2 defayı geçmeyecektir.

İşlevsel ve işlevsel-olmayan isterlerin ilgisi
Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isterleri
bir takım işlevsel isterlerin oluşmasına neden olabilir
 Kimlik denetleme özelliği: oturum yönetimi, cookie, vb

Kimlik denetleme işlevi hem işlevsel hem işlevsel-olmayan
istere örnektir.
 Her iki çeşit ister arasında net bir ayrım yoktur.

Diğer İsterler
 Davranış şeklinde ifade edilemeyen isterlerdir. (non-
behavioral requirements)
 Arayüz İsterleri (Interface Requirements)
 Kullanıcı Arayüzleri
 Yazılım Arayüzleri
 Donanınım Arayüzleri
 İletişim Arayüzleri
Kullanıcı Arayüzü
 Yazılım ürünü ile kullanıcısı arasındaki her bir
arayüzün mantıksal özellikleri açıklanmalıdır.
 Bu özellikler, yazılım ihtiyaçlarının giderilmesine
yönelik olan ekranformatları, pencere görünümleri,
menü ya da rapor içerikleri, programlanabilir
fonksiyon tusları gibi konfigürasyon özellikleridir.
 Ayrıca arayüzler ile sistemin kendisini kullananlara
nasıl görünmesi gerektigi de tarif edilmelidir.
Yazılım Arayüzleri
 Diger gerekli yazılım ürünlerinin kullanımı ve ürünün
yazılımlar ile olan arayüzleri burada ortaya konmalıdır.
 Gerekli her bir yazılım ürünü için, isim, spesifikasyon
numarası, versiyon ve kaynak belirtilmelidir.
 Tanımlanan her bir arayüz, mesaj içerigi ve format
yönünden açıklanmalıdır.
Donanım Arayüzleri
 Burada yazılım ürünü ile donanım bilesenleri
arasındaki her bir arayüzün mantıksal özellikleri
verilmelidir.
 Bunun yanında örnek olarak; hangi cihazların
desteklenecegi, nasıl ve hangi protokollerle
desteklenecegi gibi noktalar da belirtilmelidir.
 İletişim Arayüzleri
 Yerel ag protokolleri..vs gibi iletisim arayüzleri burada
açıklanmalıdır.
İçerik
 Yazılım İster (Gereksinim) Analizi
 İster Nedir?
 İster Türleri
 Alan
 İşlevsel, işlevsel olmayan
 Sistem, Kullanıcı
 Diğer
 İster Çözümleme Aşamaları
 İster Çözümleme Yöntemleri

Doğal Dil

Doğal Dil

Yapısal Doğal Dil
 Formlar, şablonlar aracılığı ile ifade

Grafiksel Gösterim
 Veri Akış Şemaları

UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi
 Geçerleme,Gözden Geçirme
 Sonuç: The software requirements document
(Yazılım İster (Gereksinim) Dökümanı)
İster çözümleme aşamaları
Çözümleyici (Analyst): Yeterli deneyime sahip yazılım
isteri çözümlemesi yapan kişi

Çözümleme çalışmaları beş başlık altında
incelenebilir:

Problemin anlaşılması
 Problemin çözümlenmesi
 Modelleme
 Belirtim
 Gözden geçirme

İsterlerin değişmesi
İsterlerin çözümlenmesi ne kadar iyi yapılırsa yapılsın, süreç
sırasında da isterlerde değişiklik meydana gelebilir:


Müşteri ve geliştirici arasındaki iletişimin yeterli olmaması
Bu aşamaya çabuk geçebilmek için bazı varsayım ya da
kabullenmeler yapılmış olması


Müşterinin ne istediğini tam bilememesi ve sık sık fikir değiştirmesi

Geliştiricinin deneyim eksikliği

Ayrıntılı tasarıma geçilince yeni isterlerin gerekliliğinin ortaya çıkması
İsterlerin Belirlenmesi
Sistemin başarısı, sistemden ne istendiğinin doğru
olarak algılanmasına bağlıdır

Bunun için düzeylere ayrılmış sistem isterlerinden
Yazılım İsterleri belirtimi (SRS) çıkartılmalıdır.


İçerik
 Yazılım İster (Gereksinim) Analizi
 İster Nedir?
 İster Türleri
 Alan
 İşlevsel, işlevsel olmayan
 Sistem, Kullanıcı
 Diğer
 İster Çözümleme Aşamaları
 İster Çözümleme Yöntemleri



Doğal Dil
Yapısal Doğal Dil
 Formlar, şablonlar aracılığı ile ifade
Grafiksel Gösterim
 Veri Akış Şemaları

UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi
 Geçerleme,Gözden Geçirme
 Sonuç: The software requirements document
(Yazılım İster (Gereksinim) Dökümanı)
Gereksinim Çıkarma ve Analizi –
Zorluklar
 Yazılım gelistirme çalısmalarının ön asamaları
 Kimse birbirini tanımıyor, sistemi bilmiyor
 Yöntem, teknoloji, vb. yeni olabilir
 Kullanıcı odaklı problemler yasanabilir.
 Kullanıcılar ne istediklerini bilmeyebilir.
 Kullanıcılar isteklerini kendi terimleriyle ifade edebilir.
 Farklı kullanıcıların çelisen istekleri olabilir.
 Farklı grupların beraber çalısmasını gerektiriyor.
 Kullanıcı grupları, analiz uzmanları, mimari/tasarım uzmanları
 Kurumsal ve politik etkenler sistem gereksinimlerini
etkileyebilir.
 Analiz boyunca gereksinimler degisebilir; yeni kullanıcılar
çıkabilir ve is ortamı degisebilir.
Gereksinim Geçerleme
 Gereksinimlerin müsterinin istedigi sistemi tanımladıgını
güvence altına almayı hedefler.
 Gereksinimlerden kaynaklanan bir hatayı sonradan
düzeltmenin maliyeti yüksek oldugundan, geçerleme
büyük önem tasır.
 Gereksinim geçerleme teknikleri:
 Gözden geçirme – gereksinimlerin sistematik ve paydaslara
dayalı analizi
 Prototip olusturma – sistemin çalısan bir taslagı üzerinden
kontrol
 Test durumu gelistirme – sistemin test edilebilirligini kontrol
amacıya
 gereksinimler için test durumu gelistirme
Gözden Geçirme
 Gözden geçirme çalısmalarında hedefimiz, yazılım





gereksinimlerinin asagıdaki özellikleri tasıdıgından
emin olmaktır:
Tam ve dogru
Anlasılabilir
Tutarlı
Test edilebilir
Diger belgelerde tanımlanan is/kullanıcı/sistem
gereksinimlerine izlenebilir
Gereksinimler ve Tasarım
 Gereksinimler, sistemin “ne” yapacagını tanımlar.
 Tasarım,




sistemin tanımlanan gereksinimlerinin
“nasıl” gerçeklestirilecegini belirtir.
Pratikte, gereksinimler ve tasarım her zaman net
olarak ayrılamayabilir.
Sistem mimarisi, gereksinimleri yapısallastırmak için
tasarlanır.
Sistem islevleri, tasarımı kısıtlayan diger sistemlerle
iliski içinde gerçeklestiriliyor olabilir.
Müsteri tarafından, sistemin özel bir tasarıma uyması
isteniyor olabilir.
 Gereksinimlerin türlerine göre ayrı baslıklar altında tanımlanması, bu karısıklıgı
azaltacaktır.
Doğal Dil İle İlgili Problemler
 Muglaklık (“Ambiguity”)
 Gereksinimler, okuyan herkes tarafından aynı yorumlanacak
sekilde yazılmalıdır. Dogal dil muglak ifadelere açıktır.
 Asırı esneklik (“Over-flexibility”)
 Bir gereksinim, dogal dil ile çok farklı sekillerde ifade
edilebilir.
 Modülerligin olmayısı (“Lack of modularisation”)
 Dogal dilin ögeleri, sistem gereksinimlerini yapısallastırmak
için yetersiz kalmaktadır.
 Bu problemlere ragmen dogal dilin kullanılması, müsteri ve
gelistirici arasındaki iletisim açısında önem tasımaktadır.
Doğal Dile Alternatifler
 Yapısal Doğal Dil
 Formlar, şablonlar aracılığı ile ifade
 Grafiksel Gösterim
 VAD
 UML diyagramları (Kullanım senaryoları-Use Case
Sıralı-sequential ) diyagram gibi
Yapısal Dogal Dil –
Örnek: Form Esaslı Tanımlama
Çizelge şeklinde gösterim
Analysis Model - UML
Function
Class diagram
Object diagram
Use case diagram
Activity diagram
Data
Object
Behavior
State-chart diagram
Interaction diagram
Software Engineering Lab., FCU
39
Unified Modeling Language (UML)
 Yazılım sistemlerinin modellemesi için geliştirilmiş




standart bir dildir
Yazılım is ürünlerinin; tanımlanması, görsel hale
getirilmesi, belgelendirilmesi
Açık standarttır; birçok araç tarafından desteklenir
Tüm yazılım geliştirme sürecini destekler
Çıkış hedefleri:
 Kullanımı kolay, görsel bir modelleme dili sunmak
 Programlama dillerinden ve geliştirme sürecinden
bağımsız olmak
 En iyi yöntemleri bütünleştirmek
40
Unified Modeling Language (UML)
 Sundukları:
 Yazılım ürünlerinin gösterimi için yapı tasları ve ilişkiler
 Sunmadıkları:
 Sisteminin nasıl gelistirilmesi gerektigini tanımlamaz
 Nesne yönelimli yazılım modellemesi için yapılar sunar, ancak;
Bu yapıların hangi sıra ile kullanılması gerektigini tanımlamaz
 Yapıların gelistirme sürecinin hangi asamalarında kullanılması
 gerektigini tanımlamaz
41
UML Türleri
UML Türleri
 Use case diyagramı:
Aktörler ve use case’ler
arasındaki ilişkiyi gösterir.
 Etkinlik (Activity) diyagram:
Çoğu durumun eylem
durumu olduğu ve geçişlerin bir durumdaki eylemin
sonuçlanması ile tetiklendiği özel bir durum diyagramı
türüdür. Bu diyagram daha çok iç işlemler esnasındaki
akışı gösterir.
43
Sıralı Diyagramlar (Sequence
diagrams)
Use Case Elemanları
 Aktör: Sistemin kullanıcıları
 Use-case: Sistemin destekleyeceği isler
45
Use Case Elemanları
.
 "uses" ilişkisi ana use case in bir alt kümesidir,
“extends" ilişkisi ise ana use case den farklı
özellikleri (alternatif seçenekleri) olan bir use case
ile ilişkilendirilir.
46
47
48
Gereksinim Analizinde Use Case
 Bakıs açısı: Sistem, kullanıcısı için “ne” yapacak ?
 Sistem kapalı bir kutu (“black-box”)
 Sistem-kullanıcı etkilesimi
 Sistemin dısarıdan görünen davranısı
 Ilgilenmediklerimiz:
 Sistemin iç yapısı
 Sistem belirlenen davranısı “nasıl” yapacak ?
 Belirlenen davranıs “nasıl” kodlanacak ?
 Bu bakıs açısı, sistemdeki tüm islevselligi degil,
kullanıcılar için artı deger olusturacak islemleri
düsünmemizi saglar
52
Gereksinim Analizinde Use Case
 Kullanıcının gereksinimi olmayan özellikleri






53
tanımlamamızı engeller
Kullanıcının da anlayabilecegi sekilde sistemin
davranıslarını ve sorumluluklarını tanımlar
Kullanıcı ile iletisimi kolaylastırır
Kullanıcı arayüzlerinin tasarlanmasını kolaylastırır
Kullanıcı kılavuzlarını yazarken baslangıç noktasını
olusturur
Gelistirme sürecini baslatır ve tüm temel is adımlarını
birbirine baglar
Tasarlanacak test durumlarına esas olusturur
Aktivite Diyagramları
 Genel olarak bir akısı veya islemi göstermek için
kullanılırlar. (“flowchart” benzeri bir yapı)
 Activity diyagramın içerisinde
 Etkinlik (“activity”)
 Sistem ve aktörler tarafından yapılan isleri ifade etmek
için kullanılır
 Geçis (“transition”)
 Etkinlikler arasındaki geçisleri ifade etmek için
kullanılır
54
ATM Aktivite Diyagramı
55