Bölüm 9
İhtiyaçları Anlama
(Understanding Requirements)

Modified from
Software Engineering: A Practitioner’s Approach
by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student
use.
1
İhtiyaç Mühendisliği-I

Başlangıç—aşağıdakilerin anlaşılması için soruların sorulması
problemin temel olarak anlaşılması
 çözüm isteyen kişi
 istenen çözümün yapısı
 müşteri ve geliştirici arasında etkili iletişimin ve işbirliğinin
sağlanması




Ortaya çıkarma/ öğreme—bütün paydaşlardan ihtiyaçları al/öğren
Detaylandırma—veri, fonksiyonel ve davranışlar ihtiyaçları ortaya
koyan bir analiz modeli oluştur.
Müzakere /Görüşme Negotiation—müşteri ve geliştirici için
gerçekçi olan teslim edilebilir sistem üzerinde anlaş.
2
İhtiyaç Mühendisliği-II

Tanımlama /Şartname hazırlama—aşağıdakilerden
herhangi birisi olabilir






Doğrulama / Onaylama—aşağıdakileri gözden geçirme
mekanizması






yazılı bir doküman
çeşitli modeller
matematiksel ifade
çeşitli kullanıcı senaryoları (use cases)
prototip
kapsam veya yorumlamadaki hatalar
açıklığa kavuşturulması gereken alanlar
eksik bilgi
tutarsızlıklar
çatışan veya gerçekçi olmayan ihtiyaçlar
İhtiyaç Yönetimi
3
Başlangıç

Paydaşları belirler
 “başka



kimle konuşmalıyım?”
Farklı görişleri belirle
İşbirliğini oluşturmaya çalış
İlk sorular
 Bu
işin olmasını isteyen kim?
 Çözümü kim kullanacak?
 Başarılı bir çözümün ekonomik faydası ne olacak?
 İhtiyacınız olan başka bir çözüm kaynağı var?
4
İhtiyaçların Ortaya Çıkarılması






yazılım mühendisleri ve müşterilerin katıldığı ve toplantılar
yapılır
hazırlık ve katılım kuralları belirlenir
bir ajanda önerilir
bir “hakem” veya yönetici toplantıyı yönlendirir. Bu kişi
müşteri, geliştirici veya dışarıdan birisi olabilir.
bir tanımlama mekanizması kullanılır (çalışma tabloları,
post it, elektronik ilan tablosu, chat odası veya sanal forum
gibi)
Amaç
problemi tanımlamak
 çözüm parçalarını sunmak
 farklı yaklaşımları tartışmak
 ön çözüm ihtiyaçlarının belirlenmesi

5
İhtiyaçların Ortaya Çıkarılması
Co n d u c t F A ST
m e e t in g s
M a k e lis t s o f
f u n c t io n s , c la s s e s
M a k e lis t s o f
c o n s t r a in t s , e t c .
f o r m a l p r io r it iz a t io n ?
E l i c i t re q u i re m e n t s
no
y es
Us e Q F D t o
in f o r m a lly
p r io r it iz e
p r io r it iz e
r e q u ir e m e n t s
r e q u ir e m e n t s
d e f in e a c t o r s
draw us e-c as e
d ia g r a m
w r it e s c e n a r io
Cr e a t e Us e - c a s e s
c o m p le t e t e m p la t e
6
Kalite Fonksiyon Konuşlandırılma




Fonksiyon konuşlandırma; sistem için gereken
herbir fonksiyonun değerinin (müşteri
tarafından algılanan) belirlenmesi
Bilgi konuşlandırma veri nesne ve olaylarını
tanımlar
Görev konuşlandırma sistemin davranışını
inceler
Değer analizi ihtiyaçların bağıl önceliğini belirler
7
İş Ürünlerini Ortaya Çıkarma







fizibilite ve ihtiyacın ifade edilmesi.
sistem veya ürün için kasamın sınırlarının ifade edilmesi
ihtiyaçların belirlenmesine katılım sağlayacak müşterilerin,
kullanıcıların ve paydaşların listesi
sistemin teknik ortamının tanımlanması
ihtiyaç listesi ve her bir ihtiyaca uygulanacak alan şartları
farklı yönetim şartlarında sistemin veya ürünün kullanımı
hakkında fikir verebilecek kullanım senaryoları
ihtiyaçların daha iyi tanımlanması için bir prototipin
geliştirilmesi.
8
Analiz Modelinin İnşa Edilmesi

Analiz modelinin elemanları
 Senaryo-tabanlı


Fonksiyonel—yazılım fonksiyonlarının gelişen açıklaması
Kullanım-durumları (Use-case)—bir aktör ve sistem arasındaki
etkileşimin tanımlanması
 Sınıf-tabanlı

elemanlar
Senaryolar tarafından ima edilen /kastedilen
 Davranışsal

elemanlar
Durum diyagramları
 Akış-yönelimli

elemanlar
elemanlar
Veri akış diyagramı
9
Kullanım Durumları (Use-Cases)



sistemin parçalarını tanımlayan kullanıcı senaryolarının
toplamıdır.
Herbir senaryo bir aktörün (kullanıcı veya aygıt)
Herbir senaryo aşağıdaki sorulara cevap verir:










Ana aktör, ikinci aktör kimdir?
Aktörün amacı nedir?
Hikaye başlamadan önce hangi önşartlar belli olmalıdır?
Aktör tarafından hangi ana görev ve fonksiyonlar işlenir?
Hikaye tanımlanıyorken hangi eklentiler düşünülmelidir?
Aktörün etkileşiminin türevleri nelerdir?
Aktör hangi sistem bilgisini alacak, üretecek veya değiştirecek?
Aktör, dış ortamdaki değişiklikleri sisteme bildirmek
zorundamıdır?
Aktör sistemden hangi bilgileri beklemektedir.
Aktör beklenmeyen değişikliler hakkında bilgi sahibi olacak mı?
10
Kullanım-Durumu Diyagramı
A r m s / dis ar m s
s y s t em
A c c es s es s y s t em
s ens or s
v i a In t e r n e t
hom eow ner
Re s p o n d s t o
alar m ev ent
En c o u n t e r s a n
er r or c ondit ion
s y s t em
adm inis t r at or
Re c o n f i g u r e s
s ens or s
and r elat ed
s y s t em f eat ur es
11
Sınıf Diyagramı
SafeHome sistemi için …
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure
()
12
Durum Diyagramı
Reading
Commands
System status = “ready”
Display msg = “enter cmd”
Display status = steady
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State name
State variables
State activities
13
Analiz Örüntüleri
Pattern name: A descriptor that captures the essence of the
pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used
to address the problem.
Forces and context: A description of external issues (forces) that
can affect how the pattern is used and also the external issues that
will be resolved when the pattern is applied.
Solution: A description of how the pattern is applied to solve the
problem with an emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is
applied and what trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved
through the use of known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related
to the named pattern because (1) it is commonly used with the
named pattern; (2) it is structurally similar to the named pattern;
(3) it is a variation of the named pattern.
14
Tartışma / Müzakere İhtiyaçları

Ana paydaşları belirle
 Tartışmaya

Herbir paydaşın “kazandığı durumları” belirle
 Bazen

dahil olacak kişiler bu kişilerdir
açık olmayabilir
Müzakere et /Tartış
 “kazan-kazan”
“win-win” durumuna yol açacak
ihtiyaçları belirlemek için çalış.
15
İhtiyaçları Onaylama - I






Herbir ihtiyaç sistemin amaçlarıyla tutarlı mı?
Bütün ihtiyaçlar uygun bir soyutlama seviyesinde
belirtildimi? Yani, Bu aşamada uygun olmayan derecede
teknik detay sağlıyormu?
İhtiyaç gerçekten tereklimi veya sistemin amacına uygun
olmayan eklenebilir bir yapıyı mı içeriyor.
Herbir ihtiyacın sınırları bellimi ve kesin mi?
Herbir ihtiyacın özellikleri var mı? Yani, her bir ihtiyacın
özellikleri, kaynağı kaydedildi mi?
Herhangi bir ihtiyaç diğer bir ihtiyaçla çatışıyormu?
16
İhtiyaçları Onaylama - II






Herbir ihtiyaç sistemin çalışacağı teknik ortam için temin edilebilir
mi?
Herbir ihtiyaç test edilebilir mi , daha önce uygulandıvmı?
İhtiyaçlar, inşa edilecek sistemin bilgi, fonksiyon ve davranışlarını
uygun bir şekilde yansıtıyor mu?
Herbir ihtiyaç sistemin detaylı bir şekilde bölmelendi mi?
Is each requirement achievable in the technical environment that will
house the system or product?
İhtiyaç örüntüleri ihtiyaç modelini basitleştirmek için kullanıldımı
Heribr örüntü onandımı? Bütün örüntüler müşteri ihtiyaçlarıyla
tutarlımı?
17
Download

İhtiyaçları Anlama