The Requirements Discipline Requirement Discipline membicarakan tentang pembuatan model dan lebih terpusat pada fase elaborasi.

Requirement Discipline Lebih Detail Dalam Requirement Discipline fokusnya pada detail internal system, dari apa objektif bisnis menjadi bagaimana objektif dapat tercapai. Dalam Requirement Discipline, analis mendefinisikan detail dari system informasi yang dibutuhkan untuk memberikan organisasi keuntungan yang diharapkan. Berikut adalah prosesnya : A. Mengumpulkan detil informasi Sistem analis memperoleh informasi dari orang yang akan menggunakan system baik dari interview atau memperhatikan mereka bekerja. Mereka dapat memperoleh informasi dengan review dokumen perencanaan dan kebijakan. Analis harus berbicara dengan semuanya, pengguna system dan penggunan system serupa. Analis juga harus mengoleksi infomasi teknis seperti penggunaan computer, tempat kerja, interface system, dan software yang digunakan.

B. Mendefinisikan Persyaratan Setelah semua informasi dikumpulkan, penting untuk mencatatnya.Kebanyakan dari infomasi menjelaskan dibangun persyaratan dari fungsional, system beberapa menjelaskan persyaratan nonfungsional.Permodelan berlanjut ketika informasi sedang dikumpulkan.Spesifik model berdasarkan yang dikembangkan.UP menyediakan beberapa kemungkinan tipe model tapi analis tidak butuh menggunakan semuanya.Analis memilih model yang cocok dengan projek dan skill nya.

C. Memprioritaskan Persyaratan

Setelah persyaratan telah dimengerti dan detail model dari persyaratan telah selesai, penting untuk mengetahui persyaratan mana yang krusial untuk system. Kenapa harus diprioritaskan fungsi yang diminta oleh user?Karena sumber daya selalu terbatas. Jika analis tidak berhatihati dalam evaluasi prioritas, kebutuhan system akan terus bertambah dengan adanya pengguna yang meminta (scope creep) menyebabkan biaya lebih mahal dan keterlambatan implementasi.

D. Mengembangkan Dialog User Interface Dalam banyak kasus banyak pengguna yang cenderung tidak pasti dalam persyaratan system. Dengan adanya dialog interface pengguna dapat melihat system dan merasakanya. Dialog interface merupakan model yang memunculkan dan memvalidasi kebutuhan interface. Dialog interface bisa berupa storyboard atau prototype.

E. Evaluasi Persyaratan dengan Pengguna Analis biasanya menggunakan proses berulang dimana mereka memperoleh input pengguna, bekerja sendiri untuk memodelkan persyaratan, kembali ke pengguna untuk ditambahkan input atau validasi, kemudian bekerja sendiri lagi untuk menambahkan dan memperhalus model. Banyak alternative yang ada untuk design terakhir dan implementasi system. Model alternative terus dikembangkan dan diperbaiki terus menerus.

Persyaratan Sistem Persyaratan system adalah spesifikasi yang mendefinisikan fungsi yang akan diberikan system, menyangkut semua kemampuan dan kendala yang terjadi dalam system. Persyaratan system dibagi menjadi 2 : A. Persyaratan fungsional Persyaratan system yang mendeskripsikan sebuah aktivitas atau proses dari kerja system. Berhubungan langsung dengan use case dan disajikan dalam model grafis dan teks.

B. Persyaratan non-fungsional Persyaratan system selain dari yang harus dijalankan, sebagai support. Banyak jenis dari persyaratan non fungsional : Persayaratan teknis Persyaratan tampilan Persyaratan kegunaan Persyaratan andalan Persyaratan keamanan

Model dan Permodelan Model adalah representasi dari beberapa aspek system yang sedang dibangun.Model adalah komunikator yang baik untuk menyampaikan informasi serta mengurangi kerumitan.Model dikonfigurasi dalam hirerarki. UML diagram aktivitas salah satu model. A. Tujuan Model Proses membuat model membantu analis tuntuk mengklarifikasi dan memperjelas persyaratan dan detail design.Membuat model juga penting karena disebabkan kompleksitas dalam mendeskribsikan system informasi. Model membantu menyederhanakan kesalahan analis dan focus pada beberapa aspek system. Model membantu mengingatkan analis detail kerja sebelumnya yang sudah selesai.Model juga membantu komunikasi dengan pengguna dan perkembangan dalam mengerti. Berikut adalah beberapa alasan untuk membuat model : 1. Belajar dari proses permodelan 2. Mengurangi kompleksitas 3. Mengingat semua detail

4. Komunikasi dengan member tim pengembangan lainnya 5. Komunikasi dengan berbagai pengguna 6. Dokumentasi yang telah dipakai oleh perawatan ke depannya

B. Tipe-tipe model Analis menggunakan berbagai macam tipe model yang berbeda dalam mengembangkan sistem.Tipe model yang digunakan bergantung daripada informasi yang diwakili. Ada 3 tipe model : - Model Matematis Sebuah seri dari formula yang mendeskribsikan aspek teknis dari sistem.Dapat berupa rumus atau catatan matematis seperti persamaan dan fungsi respon waktu. - Model Deskriptif Catatan naratif, laporan atau daftar yang mendeskribsikan aspek dari sistem. Analis dapat interview beberapa pengguna untuk menulis proses sistem dalam bentuk naratif. Banyak model sistem informasi mengandung daftar-daftar seperti fitur, input, output, kejadian, dan pengguna. - Model Grafis Diagramdan representasiskematikbeberapa aspekdari suatu sistem. Mungkin

meupakan model yang paling berguna untuk analis.Model grafis mudah dimengerti hubungan yang kompleks yang susah diungkapkan secara verbal. UML menyediakan diagram standard untuk permodelan berorientasi objek.

UML Diagrams used for Modeling

Teknik Pengumpulan Informasi A. Tema Pertanyaan Pertanyaan seputar 3 dibawah ini : 1. Apa itu proses bisnis?

2. Bagaimana proses bisnis dilakukan? 3. Informasi apa saja yang dibutuhkan?

B. Review dari Laporan, Form, dan Deskripsi Prosedur Ada 2 sumber informasi untuk prosedur dan form yang ada. Satu dari external organisasi sedangkan satunya lagi dari laporan, form, dan prosedur dalam dokumen bisnis dan prosedurdalam organisasi. Untuk memulai proses, analis meminta pengguna untuk menyediakan salinan dari form dan laporan yang sedang digunakan. Mereka juga meminta salinan dari prosedur manual dan deskripsi kerja.

C. Melakukan Interview dan Diskusi dengan Pengguna Merupakan salah satu teknik paling efektif untuk mengerti fungsi dan aturan bisnis. Agar interview berjalan efektif maka analis harus mengorganisasi 3 area : (1) Menyiapkan interview, (2) Melakukan interview, dan (3) Follow Up interview.

D. Mengamati Dan Mendokumentasikan Proses Bisnis Selain interview, metode yang tidak kalah efektif adalah observasi pengguna langsung dan mendokumentasikan prosesnya. Caranya adalah : (1) Observasi dan (2) Dokumentasi dengan diagram aktivitas, contoh

E. Membangun Prototipe

Prototipe adalah awal, model kerja dengan entitas lebih kompleks. Ada beberapa macam prototype : throwaway prototype, discovery prototype, design prototype, dan evolving prototype. Karakteristik dari prototype yang efektif adalah operative, cepat, dan fokus. F. Mendistribusikan dan Mengoleksi Kuesioner G. Melakukan Design Aplikasi Bersama

USE CASE Events And Use Cases Use case adalah sebuah aktivitas sistem, biasanya di respon dari permintaan dari pengguna. Dalam fase inception suatu proyek, analis identifikasi banyak kunci use cases. Use case adalah titik awal dalam proses permodelan.

Ada beberapa cara untuk mengidentifikasi use case. Yang pertama adalah mendaftar semua pengguna dan berpikir apa yang mereka butuhkan dalam sistem untuk pekerjaan mereka. Pendekatan lainnya adalah memulai dari sistem yang sudah ada dan mendaftar semua fungsi sistem yang sedang berjalan kemudian menambah fungsi baru yang diminta pengguna. Pendekatan ketiga adalah berbicara dengan semua pengguna untuk mendeskripsikan tujuan mereka dengan sistem itu Dasar proses bisnis (EBPs) adalah tugas yang dijalankan oleh satu orang dalam satu tempat, dalam respon kejadian bisnis, yang menambahkan ukuran nilai bisnis dan meninggalkan sistem dan data dalam kondisi konsisten

Event Decomposition Event adalah sebuah kejadian yang terjadi pada waktu dan tempat yang spesifik kemudian dapat dijelaskan dan berharga untuk diingat. Event decomposition adalah teknik yang digunakan analis untuk identifikasi use case dengan fokus dahulu pada event sebuah sistem yang harus direspon dan melihat bagaimana sistem itu merespon. Analis didelegasikan peristiwa tertentu untuk menguraikan. Hasil dari event decomposition : daftar dari use case dipicu dari event bisnis dan use case yang benar.

Events Affecting a Charge Account Processing System that Lead to Use Cases Tipe-tipe Event Ada 3 macam tipe event : 1. External Events : Sebuah event yang terjadi di luar sistem, biasanya dilakukan oleh external agen atau actor. Yang termasuk external event : Agen luar ingin sebuah hasil dalam sebuah transaksi Agen luar ingin beberapa informasi

Pertukaran data harus diubah Manajemen butuh informasi

2. Temporal event : Event yang terjadi dalam suatu waktu yang telah ditentukan. Yang termasuk temporal event : Output internal dibutuhkan.Contoh : Laporan manajemen, Laporan operasional, Pernyataan internal dan dokumen. External output dibutuhkan. Contoh : Pernyataan, Laporan status, Bills, Pengingat

3. State event : Event yang terjadi ketika sesuatu terjadi didalam sistem yang memicu kebutuhan untuk memproses. Identifying Events 1. Event Versus Kondisi Sebelumnya dan Respon Membedakan event dari kondisi

2. Urutan Dari Event : Membuat Siklus Hidup Transaksi Melacak urutan kejadian diprakarsai oleh Mengisolasi peristiwa yang benar-benar menyentuh sistem 3. Kontrol Event dan Sistem yang Bergantung Pada Teknologi Melihat Setiap Event Dan Menghasilkan Usecase Masukkan use case dalam event table Event table ada baris dan kolom o Setiap baris adalah catatan menghubungkan ke sebuah use case o Kolom merepresentasikan informasi kunci Tabel acara RMO anatomizes sistem dukungan pelanggan agen eksternal

Information about each Event and the Resulting Use Case in an Event Table Use Cases dan Aktor Source : Orang atau benda yang melakukan business event dan harus berada diluar sistem. Actor : Orang atau benda yang bersentuhan dengan sistem dan berada diluar batas automatisasi. Mengidentifikasi aktor pada level detail yang benar: Asumsi aktor memiliki tangan. Use case adalah goal yang ingin dicapai oleh actor.

Diagram Use Case Notasi untuk use case diagram: figur simple tongkat mewakili sebuah actor, tangan-tangan actor langsung indikasi akses sistem, use case disimbolkan dengan sebuah oval, menghubungkan garis yang cocok antara actors dan use cases.

Ikatan Otomatis dan Organisasi Memperluas use case diagrams dengan actor lain dan use case. Garis penghubung: menghubungkan tiap aktor untuk berinteraksi dengan tiap use case. Automatisasi batas o Garis digambar disekitar set use case. o Mendefinisikan interfaces antara actors dan sistem komputer.

Figure - A Use Case Diagram of the Order-Entry Subsystem for RMO, Showing a System Boundary Deskripsi Detail Use Case 1. Brief Description. Ringkasan yang digabungkan dengan activity diagram. 2. Intermediate Description. Memperluas brief description dengan aliran aktivitas-aktivitas internal. 3. Fully Develop Ddescription. Memperluas intermediate description untuk tampilan yang lebih kaya.

Identifikasi Perilaku Objek Diagram Statechart

Pengenalan Kadang dalam sistem computer penting untuk menjaga informasi tentang status dari domain objek.Status kondisi dapat dijelaskan dalam statchart sebagai keadaan yang berbeda-beda dalam sebuah objek.Statechart dapat dibuat untuk kelas domain yang bermasalah yang mempunyai behavior kompleks atau status kondisi yang harus dicari. Sebuah statechart diagram terbuat dari oval yang menggambarkan status dari objekdan panah yang menggambarkan transisi. Contoh statechart : - Pseudostate = Titik hitam sebagai tanda permulaan statechart.

- State = Kondisi ketika sebuah objek memenuhi sebuah criteria, melakukan aksi, menunggu sebuah event. - Transisi = Pergerakan objek dari satu state ke state lainnya. - Destination State = State dimana objek bergerak menuju ketika transisi. - Origin State = State asal dari sebuah objek. - Message event = Pemicu transisi yang menyebabkan sebuah objek meninggalkan state aslinya. - Guard condition = Sebuah tes benar/salah agar transisi dapat berjalan. - Action expression = Sebuah deskripsi aktivitas untuk dijalankan. Nested States Dan Konkurensi Kondisi untuk berada lebih dari satu state pada satu waktu disebut konkurensi atau keadaan konkurensi. Satu cara intik menunjukan ini adalah dengan menggunakan synchronization bar dan konkuren path, seperti pada diagram aktivitas. Path adalah set yang berurutan dari state dan transisi yang berhubungan. Cara lain unutk menunjukan state konkuren adalah dengan menggunakan nested state didalam lainnya, state lebih tinggi. State yang levelnya lebih tinggi disebut composite state. Contoh :

Composite state dapat menunjukkan abstraksi level lebih tinggi dan dapat memuat nested state dan transisi. Sebagai contoh, dalam state printer kita ingin mengidentifikasi state on. Tapi ketika printer menyala, bisa idle atau bekerja. Untuk menunjukkan 2 state itu, kita menggambarkan statechart level rendah didalam state

On. Persegi untuk state on dibagi menjadi dua. Bagian atas mengandung nama dan bagian bawah mengandung nested states dan transition paths. Contoh concurrent path untuk state on:

Dalam

contoh

ini paths

ada

dua dalam atas

concurrent composite

state.Bagian

menunjukkan bagian paper tray dari printer. Dua path berdiri sendiri saling lepas dan printer berjalan melalui state dan transisi dalam setiap path sendiri. Ketika tombol off ditekanm maka printer meninggalkan state on.

Aturan Untuk Membuat Statechart Membuat statechart mengikuti beberapa aturan. Berikut adalah langkah yang akan membantu dalam mebuat statechart : 1. Pilihkelas yangakan membutuhkanstatecharts Biasanya kita hanya memasukan berbagai status kondisi yang penting dalam sistem.Kemudian mulai dengan kelas yang paling simple. 2. Daftarsemua kondisistatusuntuk setiap kelompok Dalam point ini, mudahnya melakukan brainstorm. Jika bekerja dengan kelompok, lakukan brainstorm dengan semua anggota tim. 3. Menentukantransisiyang menyebabkanobjekuntuk meninggalkanstatediidentifikasi Contoh, jika sebuah order dalam state siap di kirim, lalu ada transisi seperti memulai pengiriman akan menyebabkan order untuk meninggalkan state.

4. Urutkanstatetransisikombinasi dalamurutan yang benar Kemudian agregasi kombinasi mereka dalam fragmen lebih besar. 5. Identifikasiconcurrent paths Ketika item dapat berada dalam dua state bersamaan, ada dua kemungkinan.Dua kemungkinan dapat berdiri sendiri, spergi dalam printer bekerja dan penuh. 6. Mencaritransisitambahan Sering dalam iterasi pertama, beberapa kombinasi dari state-transisi-state hilang. Satu method untuk identifikasi mereka adalah mengambil setiap kombinasi dari state dan menanyakan apakah ada transisi yang valid antar state/ 7. Perbanyaksetiap transisiyang sesuai Masukkan setiap state action expression.Banyak dari inimungkin telahdilakukan sebagaifragmenStatechart yangsedangdibangun 8. Review danpengujianStatechartmasing-masing Review setiap statechart dengan melakukan hal sbb : 1. Pastikan state benar-benar state dari objek di kelas. 2. Ikuti siklus hidup objek dari datang keberadaan sampai dihapus dari sistem. 3. Pastikan diagram mengcover semua kondisi pengecualian serta alur normal dari behavior. 4. Lihat lagi tentang kejadian bersama dan kemungkinan nested paths.

Membuat Statechart RMO Langkah pertamaa adalah mereview domain class diagram dan memilih kelas yang mempunyai kondisi status yang harus dilacak. Dalam kasus ini kita memilih Order dan detail order. Kandidat kelas lainnya adalah InventoryItem, Shipment, Customer.

Membuat Statechart Detail Order Mengidentifikasikondisi statusyang mungkin : "Siap untuk dikirim "Pada urutan belakang" "Dikirimkan" Terus mengembangkanStatechartsesuai dengandelapan aturan

Membuat Statechart Order States mencerminkan siklus hidup dari order. Penerapanaturanmengarah kekompleksitas yang lebih besar: States bersama dan Transisi baru. ManfaatmengembangkanStatechartuntuk suatu benda : - Menangkap danmemperjelasaturan bisnis - Keuntunganpemahaman yang benar tentangpersyaratan sistem

Masalah Domain Kelas Tipe-tipe Things Things mempunyai representasi data dalam sistem. Things adalah objek yang berinteraksi dengan sistem. Analis dapat menanyakan beberapa tipe things untuk mengidentifikasi mereka.Banyak things yang terlihat lebih mudah diidentifikasi tapi beberapa tidak terlihat, harus dipisahkan. Tipe things yang beda penting untuk pengguna yang beda juga, jadi penting untuk mengambil inormasi dari semua pengguna.

Analis mengidentifikasikan tipe-tipe things ini dengan memikirkan setiap kejadian dalam tabel kejadian dan menanyakan pertanyaan. Prosedur Untuk Menemukan Daftar Awal Things

Analis dapat menggunakan banyak sumber informasi untuk menemukan daftar awal things yang sistem butuhkan untuk menyimpan informasi.Prosedurnya adalah dimulai dengan mencatat semua benda yang pengguna sebutkan ketika berbicara tentang sistem.Kemudia tambahkan benda tambahan ke dalam daftar yang muncul dalam informasi tentang sistem yang ada atau yang muncul ketika berbicara dengan stakeholder. Langkah pertama.Identifikasi semua benda dari tabel kejadian dan informasi dari setiap kejadian. Langkah kedua. Menggunakan informasi lain dari sistem yang ada, prosedur sekarang, dan laporan atau form sekarang tambahkakan benda atau informasi yang dibutuhkan. Langkah ketiga.Memperhalus daftar dan mencatat asumsi atau isu untuk menjelajah. Asosiasi Antara Things Setelah mencatat dan memperhalus daftar things, analis meneliti dan mencatat informasi tambahan.Banyak hubungan penting antara things penting untuk sistem.Asosiasi adalah relasi yang terjadi antara things secara spesifik.Contoh : ditempatkan pada dan bekerja di. Asosiasi berlaku pada 2 arah.Contoh : Pelanggan menempatkan pesanan dan Pesanan ditempatkan oleh pelanggan. Jumlah dari asosiasi yang terjadi disebut multiplicity. Multiplicity dibuat untuk setiap arah dari asosiasi. Asosiasi dilakukan dengan beberapa things dibedakan menjadi beberapa : Unary (antara things yang sejenis), binary (antara 2 things yang berbeda), ternary (3 things yang berbeda), dan n-ary (antara n (jumlah things) yang berbeda). Atribut Dari Things Kebanyakan dari informasi sistem menyimpan dan menggunakan potongan spesifik dari setiap informasi dari setiap things.Potongan spesifik informasi disebut atribut.Analis harus mengidentifikasi atribut dari things. Atribut yang secara unik mengidentifikasi things disebut indentifier (key) sedangkan atribut yang mengandung beberapa koleksi berhubungan dengan atribut yang sama disebut compound atribut. Analis mungkin memulai mendeskripsikan atribut yang paling penting tapi nanti pada akhirnya semua ditambahkan ke daftar.

Kelas dan Objek Object adalah suatu entitas yang memiliki identitas, state, dan behavior sedangkan Class adalah kumpulan dari object yang mempunyai structure, behavioral pattern, dan attributes yang bersamaan. Model domain kelas diagram adalah UML kelas diagram yang menunjukan things yang penting dalam pekerjaan pengguna, masalah domain kelas, asosiasi dan atribut mereka. Things dalam pekerjaan pengguna juga harus direpresentasikan dalam sistem, jadi yang harus dipikirkan adalah things sebagai software yang berinteraksi dengan sistem.Objek dalam pekerjaan pengguna seringkali mirip dengan objek software.Perbedaan utamanya adalah objek software bekerja dalam sistem, mereka tidak hanya menyimpan informasi. Dengan kata lain objek software juga mempunyai kelakuan begitu juga dengan atribut. Objek meng enkapsulasi atribut dan kelakuannya.

Kelas Diagram Domain Model Notasi Kelas Diagram Dalam kelas diagram, persegi panjang melambangkan kelas, dan garis yang menghubungkan persegi panjang menunjukkan asosiasi antara kelas. Persegi panjang dibagi menjadi 3 bagian, masing-masing merupakan nama, atribut, dan fungsi kelas. Fungsi tidak terdapat domain model kelas diagram.

Sebagai contoh dari gambar diatas kita dapat melihat 3 model domain kelas yang saling berhubungan. Dalam notasi diagram antara customer dengan order, kita dapat mlihat customer dapat membuat banyak oder sedangkan setiap order hanya bisa dibuat oleh satu customer. Multiplicitynya adalah one to many dan one to one di arah lainnya. Kemudian di paling kanan terdapat Order item (detail order), setiap pemesanan mempunyai minimum 1 barang yang dipesan dan maksimum banyak barang.

Hierarki dalam Notasi Kelas Diagram Hierarki Generalisasi dan Spesialisasi Generalisasi/spesialisasi berdasarkan kesamaan dan perbedaan orang mengklasifikasi benda.Generalisasi adalah menentukan grup dari things yang sejenis, contohnya banyak macam kendaraan bermotor seperti mobil, motor, truk dll.Maka dari itu kendaraan bermotor adalah kelas general.Spesialisasi adalah penilaian yang membedabedakan tipe dari things.Contoh : mobil balap, sedan, adalah spesialisasi dari kelas mobil. Generalisasi/spesialisasi digunakan untuk struktur atau peringkat things dari umum ke lebih special.Kelas yang lebih umum disebut superclass, sedangkan kelas yang lebih spesial disebut subclass.

UML kelas diagram untuk superclass dan subclass adalah segitiga kecil pada garus yang menunjuk pada superclass. Inheritance (penurunan sifat) membuat subclass mendapat karakteristik superclass. Hierarki Semua - Sebagian Whole part menangkap semua hubungan yang diidentifikasikan ketika orang mencoba membuat asosiasi antara objek dan komponennya. Whole adalah jumlah (kumpulan) dari bagian-bagian. Ada 2 tipe dalam hierarki whole-part: agregasi dan komposisi. Agregasi adalah asosiasi antara objek dengan bagian yang dapat dipisahkan, contoh : keyboard adalah bagian dari computer. Komposisi adalah hubungan bagian yang tidak dapat dipisahkan dari objek.Contoh : CRT dan monitor.

Mencari Pola Untuk Pattern Pola memberikan sumber inspirasi dan patokan untuk bagaimana memodel situasi Pola umum : Role pattern: object dengan multiple roles Relation pattern: relationship dengan attributes Hierarchy pattern: Item-descriptor pattern:

Kisi-kisi : 1. Jelaskan tahapan unified process! 2. Jelaskan 3 macam model yang dapat digunakan untuk menganalisis sistem informasi! 3. Apa perbedaan source dan actor? 4. Jelaskan notasi yang digunakan dalam membuat class dan class diagram. 5. Apakah perbedaan antara class dan object? 6. Berikan contoh penggunaan include dan extends dalam usecase diagram! 7. Apakah kegunaan dari usecase diagram? 8. Jelaskan mengenai compound attribute dalam class. 9. Bagaimana cara membuat statechart? 10. Apa saja aktivitas yang dilakukan sistem analis selama dalam requirement analys?

11. Jelaskan teknik yang dapat digunakan untuk mengumpulkan informasi kebutuhan user / identifikasi user requirement! 12. Sebutkan cara-cara untuk menentukan sebuah class 13. Jelaskan notasi yang digunakan dalam membuat statechart diagram. 14. Jelaskan 4 macam explore pattern yang digunakan dalam domain model class diagram! 15. Jelaskan notasi yang digunakan dalam membuat activity diagram. 16. Jelaskan yang ada ketahui tentang FACTOR dalam menentukan system definition! 17. Jelaskan Struktur Relationship yang dapat digunakan dalam membuat domain model class diagram 18. Jelaskan 3 macam usecase description menurut Satzinger beserta contoh! 19. Jelaskan apakah yang anda ketahui tentang event table. 20. Jelaskan macam-macam event description menurut Satzinger beserta contoh!

Kasus :

Customer yang datang akan didata dan dilayani oleh customer service BBCare Center. Setelah customer terdaftar, customer dapat langsung mengutarakan keluhannya seputar kerusakan smartphone tersebut.Customer service BB Care Centerakan langsung mengecek kondisi smartphone. Setelah dicek, customer service akan mencatat setiap keluhan tersebut dalam nota perbaikan. Berdasarkan keluhan tersebut, pihak customer service dapat memberikan estimasi biaya yang dibutuhkan untuk melakukan service tersebut.Customerakan diberikan garansi pasca service selama tiga bulan. Setelah customer menyetujui untuk melakukan service,maka customer service BB Care Center akan mencetak nota perbaikan sebanyak 3 (tiga) rangkap, di mana rangkap 1 (satu) akan diberikan kepada customer,
rangkap 2 (dua) akan diberikan kepada kepala teknisi, dan rangkap 3 (tiga) akan diarsip. Berdasarkan nota perbaikan tersebut, kepala teknisi akan membuatkan Surat Perintah Kerja. Pada Surat Perintah Kerja ini akan dicatat perintah perbaikan smartphone, beserta kode teknisi yang diperintahkan untuk memperbaiki smartphone tersebut. Setelah Surat Perintah Kerja ini selesai dibuat, maka pihak teknisi BB Care Center akan langsung memperbaiki smartphone tersebut berdasarkan Surat Perintah Kerja. Setelah perbaikan selesai dilakukan,

maka pihak teknisi akan membuat surat pengerjaan service. Pada surat pengerjaan service ini akan dicatat sparepart apa saja yang dibutuhkan untuk memperbaiki smartphone tersebut. Setelah smartphone selesai diperbaiki, maka pihak customer service BB Care Center akan menghubungi customer. Customer membayar biaya service kepada kasir berdasarkan surat pengerjaan service yang telah dilakukan tersebut, kemudian akan dicetak bukti pembayaran service.

1. Please explain what are the activities in Unified Process ! Whats the benefit of Unified Process 2. What are three types of models according to Satzinger ? 3. List and describe information-gathering techniques for identifying user requirements ! 4. There are three types of use case description. Fully developed use case description is one of them. Please explain each point on fully developed use case description ! 5. What is the purpose of an activity diagram ? 6. What is the <<includes>> and <<extends>> relationship used for? Give example! 7. Please explain three types of events according to Satzinger! 8. What is the difference between source and actor?-

9. You have set up an interview with Jason Nadold in the shipping department . Your objective is to determine how shipping works and what the information requirements for the new system will be. Make a list of questions, open-ended and close-ended, that you would use! 10.Develop an activity diagram based on the following system definition. If you need to make assumptions, also note them!The shipping department receives all shipments on outstanding purchase orders. When the clerk in the shipping department receives a shipment, he finds the outstanding purchase order for those items. The clerk then sends multiple copies of the shipment packing slip. One copy goes to purchasing and the department updates its records to indicate that the purchase order has been fulfilled. Another copy goes to accounting so that a payment can be made. A third copy goes to the requesting in-house customer so that he can receive the shipment. Once payment is made, the accounting department sends a notification to purchasing. Once the customer receives and accepts the goods, he or she sends notification to purchasing. When purchasing receives these other verifications, it closes the purchase order as fulfilled and paid. 11. Make an event table and draw use case diagram from auction house information

system below! Choose 1 (one) usecase from your usecase diagram and make fully developed use case description from that usecase ! You may make any assumptions and please write it on your answer sheet! The auction house has selling customers, who want to put up an item for sale, and buying customers, who buy an item at an auction. Selling customers ask the auction house to sell an item on their behalf. The auction house decides whether to accept the request and maintains a record for all accepted requests. Buying customers register with the auction house and participate in auctions. Auctions are conducted by giving buying customers information about an item, then taking bids. The auction determines a buying customer for each item put up for sale. The sale is completed when the buying customer pays for the item. The auction house sends a portion of the sale income to the selling customer who put up the item for sale in the first place. Of course, the auction house keeps track of all auctions (which are conducted every few weeks) and all sales at each auction. Answer :

1. Unified Process dirancang untuk digunakan pada pengembangan system informasi yang kompleks dan luas serta untuk menangani masalah pada UML. Keuntungannya adalah : 2. 3. Berikut adalah teknik untuk mengumpulkan informasi : A. Tema Pertanyaan Pertanyaan seputar 3 dibawah ini : 1. Apa itu proses bisnis? 2. Bagaimana proses bisnis dilakukan? 3. Informasi apa saja yang dibutuhkan? B. Review dari Laporan, Form, dan Deskripsi Prosedur Ada 2 sumber informasi untuk prosedur dan form yang ada. Satu dari external organisasi sedangkan satunya lagi dari laporan, form, dan prosedur dalam dokumen bisnis dan prosedurdalam organisasi. Untuk memulai proses, analis meminta pengguna untuk menyediakan salinan dari form dan laporan yang sedang digunakan. Mereka juga meminta salinan dari prosedur manual dan deskripsi kerja. C. Melakukan Interview dan Diskusi dengan Pengguna Merupakan salah satu teknik paling efektif untuk mengerti fungsi dan aturan bisnis. Agar interview berjalan efektif maka analis harus mengorganisasi 3 area : (1) Menyiapkan interview, (2) Melakukan interview, dan (3) Follow Up interview. D. Mengamati Dan Mendokumentasikan Proses Bisnis Menyediakan petunjuk untuk pengefisien pengembangan dari kualitas software Mengontrol semua proses dalam setiap tahapan Menghasilkan software yang berkualitas Mengurangi resiko

Selain interview, metode yang tidak kalah efektif adalah observasi pengguna langsung dan mendokumentasikan prosesnya. Caranya adalah : (1) Observasi dan (2) Dokumentasi dengan diagram aktivitas, contoh

E. Membangun Prototipe Prototipe adalah awal, model kerja dengan entitas lebih kompleks. Ada beberapa macam prototype : throwaway prototype, discovery prototype, design prototype, dan evolving prototype. Karakteristik dari prototype yang efektif adalah operative, cepat, dan fokus. F. Mendistribusikan dan Mengoleksi Kuesioner Walau kuesioneer mempunyai kegunaan terbatas dalam Keuntungan menggunakan kuesioner adalah dapat mengumpulkan informasi dari sejumlah besar pengguna. G. Melakukan Design Aplikasi Bersama 4. Fully developed adalah metode paling formal untuk mendokumentasikan sebuah use case. Contohnya sebagai berikut :

Bagian pertama (Use Case Name) dan kedua

(Scenario) digunakan untuk

mengidentifikasi nama use case dan scenario di dalam use case. Bagian ketiga (Triggering Event) mengidentifikasi pemicu yang menjalankan use case sama seperti yang terdapat dalam event table. Bagian keempat (Brief Description) menjelaskan deskripsi secara general tentang jalannya sistem. Bagian kelima (Actors) mengidentifikasi setiap aktor, pengguna sistem tersebut. Bagian keenam (Related Use Case) mengidentifikasikan use case lain yang berhubungan serta hubungan mereka. Bagian ketujuh (Stakeholders) mengidentifikasi kumpulan yang berhubungan tidak langsung dengan sistem (diluar aktor). Delapan dan Sembilan (Precondition dan Postcondition) menyajikan informasi penting tentang keadaan sistem sebelum dan sesudah use case berjalan. Postcondition adalah keadaan bersyarat yang harus dipenuhi untuk menjalankan use case. Precondition adalah keadaan yang harus terjadi setelah use case dijalankan.

Kesepuluh (Flow of Events) menceritakan alur aktivitas dalam use case. Dibagi menjadi 2 kolom, kerja yang dilakukan aktor dan respon dilakukan sistem. Yang terakhir adalah Exception Condition menuliskan kondisi yang terjadi terjadi pengecualian dalam aktivitasnya. 5. Activity Diagram adalah sebuah diagram alur kerja yang sederhana yang menjelaskan bermacam kegiatan dari user atau system, seseorang yang menjalankan beberapa aktivitas, dan alur kegiatan secara berurutan. Activity Diagram berguna untuk mendokumentasikan informasi proses kerja suatu sistem. Keuntungannya menggunakan activity diagram adalah kita dapat visualisasi lebih baik dan kita dapat mereview dengan pengguna untuk memastikan prosesnya sudah benar selain itu mudah dimengerti.

6. <<includes>> adalah penggunaan relationship antar use case jika salah satu use case digunakan lebih dari satu kali. Sebagai contoh, 2 subsistem memasukan order adalah membuat order dan mengupdate order. Masing-masinguse case memerlukan untuk memvalidasi akun pelanggan. Maka dari itu use case validasi akun pelanggan yang digunakan bersama dihubungkan dengan dengan tanda panah dan diberi <<includes>> sebagai indikasi dimana use case tersebut adalah bagian dari use case yang besar (major). Sebaliknya <<uses>> adalah penggunaan hubungan antar use case dimana ada satu use case parent yang berhubungan dengan satu atau banyak use case lainnya yang bersifat sebagai anaknya. Contoh : ketika ada barang dibeli dan pelanggan membayar maka dengan sendirinya stok akan terupdate. Use case update stok merupakan <<uses>> dari use case menerima pembayaran.

7. 3 macam event menurut Satzinger : External Events = Event yang terjadi diluar sistem, biasanya dilakukan oleh agen eksternal atau aktor. Agen eksternal adalah orang atau unit organisasi yang memberikan atau menerima data dari sistem. Contoh : Customer mengupdate informasi. Temporal Events = Event yang terjadi sebagai hasil dari mencapai batas waktu yang ditentukan. Dalam event ini tidak ada agen eksternal yang meminta, tapi

sistem mengeluarkan informasi dibutuhkan atau output lainnya ketika dibutuhkan. Contoh : Mencetak laporan penjualan tiap akhir bulan. State Events = Event yang terjadi ketika sesuatu terjadi dalam sistem yang memicu proses. Contoh : Titik memesan kembali barang yang sudah habis.

8. Source adalah sumber atau external agent yang menyuplai data ke sistem sedangkan actor adalah orang yang berinteraksi langsung dengan system.

11. Event table dan Use Case

Event Selling Customer mendaftarkan barang lelang Buying Customer mendaftar lelang

Trigger Adanya permintaan pelelangan Adanya pendaftaran

Source Selling Customer

Use Case mencatat permintaan lelang

Response mengikuti pelelangan -Record Customer baru -Kartu tanda peserta lelang

Destination Selling Customer

Menerima dan Surat

Buying Customer

Mendaftarkan buying customer

Buying Customer

Buying Customer mengikuti lelang

Adanya permintaan dan penawaran

Buying Customer

- Memberikan informasi brg Memasangkn tawaran

Informasi Buying Customer Harga

barang lelang terupdate

House Auction Adanya mengumumkan kesepakatan pemenang lelang Customer membayar memberikan bagian hasil penjualan Lelang berakhir

House Auction

Memasangkan buying customer dengan barang

Customer House Auction dari

Menerima pembayaran Memberikan hasil penjualan

Bukti bayar Bukti transfer

Customer Selling Customer

House Auction Hasil penjualan Selling Customer Mencatat hasil Setiap pelelangan beberapa minggu dari bagian

Mencatat hasil pelelangan

Catatan pelelangan