tib15 - analisis & desain berorientasi objek

advertisement
Pertemuan 2
Pengumpulan Persyaratan
(disadur dari Slide Software Engineering – Ian Sommerville Ch6 dan Ch7)
TIB15 - ANALISIS & DESAIN
BERORIENTASI OBJEK
Materi yang dibahas
• Requirements/Persyaratan
• Klasifikasi persyaratan
• Menentukan Persyaratan
– Requirements Engineering Process
– Teknik memunculkan Persyaratan (Elisitasi dan Analisa)
• Sumber Persyaratan
– Ethnography
• Mengelola persyaratan
– Dokumen Requirement
– Panduan Penulisan Requirement
Requirements/Persyaratan
• Requirement mengidentifikasi bagaimana
suatu sistem dapat membantu pemakai.
• Pengumpulan requirement berhubungan
dengan pengumpulan fitur-fitur dan aturanaturan dalam pengembangan sistem.
Klasifikasi Persyaratan
• Functional Requirements
Menentukan perilaku system beserta batasanbatasannya
• Non functional Requirements
Menentukan properti-properti nonbehavioral
system dan batasan-batasannya
Non Functional Requirement
Beberapa kategori non functional Requirement:
• Usability
• Reliability
• Performance
• Maintainability
• Security
Functional Requirements
• Pernyataan layanan yang harus diberikan
sistem
• Reaksi sistem terhadap input tertentu
• Situasi-situasi tertentu dimana sistem akan
berlaku
• Pernyataan secara eksplisit mengenai apa
yang boleh dilakukan sistem
Requirements Engineering Process
Feasibility studies
• Feasibility study memutuskan apakah sistem
yang diusulkan berharga atau tidak
• Studi terfokus singkat yang memeriksa
– Apakah sistem berkontribusi pada tujuan
organisasi
– Apakah sistem dapat direkayasa dengan teknologi
saat ini dan budget yang ada
– Apakah sistem dapat diintegarasikan dengan
sistem lain yang digunakan
Penerapan Feasibility study
• Berdasarkan penilaian informasi (apa yang diperlukan),
pengumpulan informasi dan penulisan laporan
• Pertanyaan untuk orang-orang pada organisasi
–
–
–
–
–
–
Bagaimana jika sistem tidak diimplementasikan?
Apakah masalah proses yang ada saat ini?
Bagaimana sistem yang diusulkan dapat membantu?
Apakah masalah yang akan terjadi pada integrasinya?
Apakah teknologi baru dibutuhkan? Bagaimana dengan skill nya?
Apakah fasilitas yang harus di dukung dengan usulan sistem?
Elisitasi dan Analisa
• Seringkali disebut requirements elicitation atau
requirements discovery.
• Melibatkan pekerjaan technical staff dengan
customer untuk menemukan domain aplikasi,
layanan yang harus disediakan sistem dan
batasan operasional sistem
• Dapat melibatkan stakeholders seperti end-users,
managers, engineers involved in maintenance,
domain experts, trade unions, dsb
Viewpoints (sudut pandang)
• Viewpoints adalah sebuah cara untuk menata
persyaratan untuk merepresentasikan
perspektif dari stakeholders yang berbeda.
Stakeholders dapat digolongkan dengan sudut
pandang yang berbeda.
Teknik elisitasi dan analisis
persyaratan
(berdasarkan VORD – Viewpoint-Oriented Requirements Definition)
• Elisitasi berorientasi sudut pandang
• Skenario
• Etnografi
Tahap-tahap sudut pandang
• Identifikasi sudut pandang
– Pencarian sudut pandang yang menerima layanan sistem dan
pengidentifikasian layanan-layanan khusus yang diberikan bagi
setiap sudut pandang
• Penstrukturan sudut pandang
– Pengelompokan sudut pandang yang berhubungan menjadi
hierarki.
• Dokumentasi sudut pandang
– Melakukan dekripsi sudut pandang dan layanan yang
teridentifikasi
• Pemetaan sistem sudut pandang
– Pengidentifikasian obyek pada desain berorientasi obyek
dengan menggunakan informasi layanan yang dicakup pada
sudut pandang
Sudut pandang dapat dianggap
sebagai:
• Sumber ataupun tempat masuknya data
– Sudut pandang bertanggung jawab untuk menghasilkan atau memakai
data
– Analisis mencakup pengenalan semua sudut pandang seperti ini
– Mengidentifikasi data ap yang dihasilkan ataupun dipalai, serta pross
apa saja yang dikerjakan
• Kerangka kerja representasi
– Sudut pandang dianggap sebagai jenis khusus model sistem
– Catatan: Dalam hal ini setiap pendekatan analisis menemukan hal-hal
yang berbeda engenai sistem yang dianalisis
• Penerima layanan
– Dalam hal ini sudut pandang bersifat eksternal terhadap sistem dan
menerima layanan dari sistem
– Analisis melibatkan pemeriksaan layanan yang diterima oleh sudut
pandang yang berbeda, pengumpulannya dan penyelesaian konflik
Contoh: LIBSYS viewpoint hierarchy
All VP s
I ndir ect
Libr ar y
m anager
I nt era ctor
Art ic le
Fina nc e
St udents
providers
St aff
Users
Ext ernal
Doma in
Libr ar y
staf f
S yst em
m anager s
UI
standar ds
Ca taloguer s
Classif icat ion
system
Wawancara
• Pada wawancara formal atau informal
interviewing, RE team memberi pertanyaan
pada stakeholders mengenai sistem yang
pakai dan sistem yang akan dibangun.
• Dua tipe interview
– Interview tertutup dimana sekumpulan
pertanyaan pre-defined dijawab
– Open interviews dimana tidak ada agenda predefined dan cakupan isu dieksplorasi dengan
stakeholders.
Praktek Interview
• Secara normal, berupa gabungan closed and open-ended
interviewing.
• Interview baik untuk mendapatkan pengertian secara
menyeluruh dari apa yang stakeholders lakukan dan
bagaimana mereka berinteraksi dengan sistem.
• Interviews tidak baik untuk memahami domain requirements
– Requirements engineers tidak dapat memahami terminologi specific
domain
– Beberapa domain knowledge begitu familiar sehingga sulit untuk
dijelaskan ataupun juga mengira tidak perlu dijelaskan
Skenario
• Skenario adalah contoh nyata bagaimana
sistem dapat digunakan.
• Termasuk diantaranya
– Penjelasan situasi awal
– Penjelasan aliran normal dari kejadian
– Penjelasan apa yang dapat menjadi kesalahan
– Informasi tentang kegiatan yang bersamaan
– Penjelasan keadaan ketika skenario berakhir
Contoh LIBSYS scenario (1)
In itia l assu m p tion : The user h as lo gg ed on to the LI BS Y S sys te m a nd ha s lo cat e d the jo urna l co ntai n in g
th e c op y o f th e a rticle .
N orm a l: The user selec ts th e article to be co pi e d. He or sh e is th e n pr om pted by th e sys te m to ei the r
p ro vide su bsc ribe r inform at ion for the jour na l or to ind ic a te h ow the y w il l p ay fo r th e article . A lte rn at ive
p ay m en t me th o ds ar e by cred it ca rd or by q uo tin g an orga ni sa tio na l ac co u nt num be r.
T h e use r is the n ask ed to fill in a c op yrig ht for m th at ma in tai ns d eta ils of th e tra ns ac tio n an d th ey th e n
subm it th is t o th e L IB S Y S sys te m .
T h e co py righ t fo rm is c h ec k ed a nd , if OK , the PDF ve rsion of the artic le is d ow nl o ad ed to th e L IB SY S
w orking area o n th e use rÕs com pu te r an d th e u se r is inform ed th at it is av ai lab le. The user is aske d t o se lec t
a pr in ter an d a co py of the ar tic le is prin te d . If th e a rtic le h as be en flag g ed as Ōprin t-on ly Õ it i s d el e te d from
th e us erÕs sys te m o n ce the user h as c o nfirm ed t h at prin tin g is com plete .
Contoh LIBSYS scenario (2)
W h at can go w ro ng : The user m ay fai l to fil l in the co p yrig ht form co rrec tly . In th is ca se , th e fo rm sh ou ld
b e re- pr esen ted to the user for co rrec tio n. If the res ub m itted fo rm is s till in co rr ec t th en th e use rÕs req u est
for th e a rtic le i s re jec ted .
T h e p a ym en t ma y b e rej e cte d b y the s ystem . T h e us er Õs req ue st f or th e a rtic le i s re jec ted .
T h e a rticle do w n lo ad m ay fail. Re try un til su cce ssf ul o r th e user term in a te s t he s essio n.
It m ay n ot be poss ib le to prin t the ar tic le. If t h e a rtic le is no t fla g ge d as Ōpr in t-on ly Õ the n it is he ld in th e
L IB S Y S w o rks pa c e. O th erw is e, the artic le is d e le ted an d th e us erÕs acc o un t cred ited w ith th e cos t o f th e
article .
Ot he r ac tivities: Sim ulta n eo us d ow nloa ds o f o th er a rticle s.
S ystem sta te on co m p le tion : U ser is lo gg ed on . T h e d ow nloa d ed article ha s b ee n d ele ted fro m LI BS Y S
w orksp ace if it has be e n fla gg ed as p rint-o nly.
Use cases
• Use-cases adalah teknik scenario based pada
UML yang mengidentifikasi aktor pada sebuah
interaksi dan menjelaskan interaksi itu sendiri
• Sekumpulan use cases akan menjelaskan
semua kemungkinan interaksi dengan sistem
• Sequence diagrams dapat digunakan untuk
menambahkan detail ke use-cases dengan
menunjukkan sequence dari kejadian
pemrosesan pada sistem.
Contoh Article printing use-case
Contoh LIBSYS use cases
Contoh Print article sequence
Ethnography
• Ilmuwan Sosial melakukan observasi untuk
menganalisa bagaimana orang bekerja.
• Orang tidak menjelaskan ataupun mengutarakan
pekerjaan mereka.
• Faktor sosial dan organisational penting untuk
diamati
• Ethnographic studies menunjukkan bahwa
pekerjaan biasanya lebih luas dan lebih kompleks
daripada yang ditunjukkan oleh model sistem
yang sederhana
Scope of ethnography
• Requirements yang berasal dari cara orangorang bekerja bukan cara definisi proses yang
disarankan yang merupakan bagaimana cara
mereka seharusnya bekerja
• Requirements berasal dari kerjasama dan
kepedulian dari aktifitas orang lain
Ethnography and prototyping
Validasi Requirements
• Berpusat pada mendemonstrasikan bahwa
ketentuan requirement sesuai dengan yang
customer inginkan
• Harga kesalahan requirements besar, sehingga
validasi sangat penting
– Fixing a requirements error after delivery may cost
up to 100 times the cost of fixing an
implementation error.
Panduan Penulisan Requirement
• Menciptakan format standar dan
menggunakannya untuk semua kebutuhan.
• Menggunakan bahasa dengan cara yang
konsisten. Gunakan kata ‘harus’ untuk
persyaratan yang diharuskan, ‘sebaiknya’
untuk kebutuhan yang diinginkan
• Gunakan teks yang mencolok untuk
mengidentifikasi bagian kunci.
• Hindari pemakaian bahasa prokem.
Contoh Penulisan Requirement
Insu lin P u m p /C on trol S of tw ar e/ S RS /3. 3 .2
F un ction
C om pu te in su lin d ose : S afe su ga r lev e l
D escr iption
C om pu tes the dos e o f ins ul in to be de liv er e d wh en the cu rren t m ea sur ed su ga r le v el is i n
th e safe zo n e b etw ee n 3 a n d 7 u ni ts .
Inp uts
C ur re n t su ga r re a di n g (r2 ), th e p re v io us t w o r ea d in gs (r 0 a nd r 1)
S ou rc e C ur re n t su ga r re a di n g fro m s en so r. O the r re a di n gs fro m m em ory.
Ou tputs C om pD ose Š the dos e in insu lin to b e d elive re d
D estin atio n
M ain co ntro l loo p
A ct ion: C om pD ose is z er o if the sug ar le v el is stab le o r fa lling or if th e le ve l is inc re as in g b ut th e rate of
in crea se is d ec rea sin g. If the le v el is inc rea sing an d the rate of in crea se is in crea sing , th en C om pD ose is
com pu ted by d iv id ing th e d iff er e nc e be tw een th e cu rren t su ga r lev el a nd th e p re v io us le v el by 4 an d
rou nd in g the re su lt. If th e result, is rou nd ed to ze ro th en C o m pD ose is set to th e mi ni mum d ose tha t ca n
b e d e li v ered .
R eq uire s
T w o pr ev ious r ead ings s o th at the ra te of ch an g e o f s ug ar le v el can be co mp uted .
Pre -con dition
T h e i ns ulin r eservo ir co nt a in s at lea st th e m ax imum al low ed sin gle d ose of i ns ulin ..
P os t-co ndi tion
r0 is r ep lace d b y r1 th en r1 is re p la ced b y r 2
S id e-effe ct s
N on e
Dokumen requirements
• Dokumen requirements adalah pernyataan
resmi dari apa yang dibutuhkan pada
pengembangan sistem
• Harus berisi definisi user requirements dan
spesifikasi system requirements.
• BUKAN dokumen design. Sejauh yang
diijinkan, sebaiknya berisi sekumpulan APA
yang sistem seharusnya dapat lakukan
daripada BAGAIMANA sistem melakukannya.
IEEE requirements standard
• Defines a generic structure for a requirements
document that must be instantiated for each
specific system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
Struktur Dokumen Requirement
•
•
•
•
•
•
•
•
•
•
Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
Referensi
• Ian Sommerville, Software Engineering, 7th-ed,
2004, Prentice hall, USA
• N. Ashrafi, Object Oriented systems Analysis
and Design, Pearson International Edition,
2008, Pearson Education, USA
Download