LAPORAN TUGAS PERKULIAHAN

REKAYASA DAN PROYEK PERANGKAT LUNAK 14620164

Kelas : B
DAFTAR KELOMPOK 1

Dyaspasa Alam Pangestu 1462000165

Vegi Burhanudin 1462000258
Aiman 1462100166
Dymas Adi Saputra 1462100242

Dosen Pengampu

Agus Hermanto, S.Kom., M.MT., ITIL, COBIT, SFC

PROGRAM STUDI TEKNIK INFORMATIKA

MARET 2023
 DAFTAR ISI

DAFTAR ISI 2
2.15 Grocery Inventory Management Using RFID 3
a. Tulis semua ringkasan kasus penggunaan yang dapat diturunkan dari persyaratan
REQ1–REQ7. 3
b. Gambarkan diagram use case untuk use case yang dijelaskan pada item (a) 5
c. Diskusikan persyaratan tambahan dan kasus penggunaan yang dapat ditambahkan ke
sistem ini. 5
2.16 Tulis spesifikasi terperinci untuk kasus penggunaan 6
2.19 Pertimbangkan variasi dari sistem kontrol akses rumah yang akan melakukan
identifikasi pengguna berdasarkan pengenalan wajah. 9
2.20 Pertimbangkan mesin bank otomatis, yang dikenal sebagai ATM 12
2.21. Turunkan model domain dengan konsep, asosiasi, dan atribut untuk lab mitosis
virtual. 15
2.22. Jelaskan hubungan antara kasus penggunaan dan objek model domain dan
ilustrasikan dengan contoh. 16
Referensi 18
2.15 Grocery Inventory Management Using RFID

a. Tulis semua ringkasan kasus penggunaan yang dapat diturunkan dari

persyaratan REQ1–REQ7. Untuk setiap kasus penggunaan, tunjukkan
persyaratan terkait. Perhatikan bahwa satu use case mungkin terkait dengan
beberapa persyaratan dan sebaliknya, satu persyaratan mungkin terkait
dengan beberapa use case.

Pertama-tama, kita perlu mengidentifikasi aktor untuk perangkat lunak yang akan
dikembangkan. Untuk yang pertama yaitu aktor manusia, Store Manager dan Store
Associate. Mungkin ada beberapa Store Manager atau Store Associate, untuk setiap
aktor mewakili peran, yang bukan individu.

Manager Store memiliki tiga jenis interaksi dengan perangkat lunak yaitu :

1. diberitahukan tentang status stok habis

2. menetapkan tugas pengisian rak
3. diberi tahu tentang tugas"Pengisian kembali telah selesai ".

Associate Store memiliki tiga jenis interaksi dengan perangkat lunak :

1. diberi tahu tentang suatu tugas pengisian rak yang ditugaskan

2. menambahkan item ke rak
3. Memberitahu tentang "Pengisian ulang rak". Selain itu, akan ada
database informasi yang menyimpan persediaan dan informasi
tugas.

Masalah utama adalah apakah pelanggan adalah seorang aktor. Pelanggan

menghapus item (tetapi mungkin juga mengembalikan item jika pelanggan berubah
pikiran). Store Associate menambahkan item ke rak, tapi juga dapat menghapus
item, misalnya jika telah mencapai tanggal kedaluwarsa. Namun, aktor manusia
tidak secara langsung berinteraksi dengan perangkat lunak. Sebaliknya, itu adalah
RFID pembaca yang memberi tahu perangkat lunak tentang item yang di
tambahkan atau dihapus. Sistem akan secara otomatis mengirim pengingat berkala
sebagai berikut:
 ● kepada Manager Store, jika tugas pengisian tidak diberikan dalam waktu
yang ditentukan setelahnya memberikan status "stok rendah" atau "stok
habis" terdeteksi, kepada Associate Store, jika tugas tidak diselesaikan
dalam waktu yang ditentukan setelah ditugaskan.

Ringkasan kasus penggunaan adalah sebagai berikut:

Gambar Hubungan aktor manusia dengan perangkat lunak yang akan di

kembangkan dimediasi oleh sistem RFID. Ini membenarkan memilih pembaca
RFID sebagai inisiasi aktor untuk kasus penggunaan RemoveItem dan AddItem,
bukan aktor manusia.

● UC-1: RemoveItem-RFID Reader memberi tahu sistem bahwa item produk

dihapus dari rak. Sistem ini juga mendeteksi status "stok rendah" dan "stok habis"
untuk suatu produk dengan memeriksa Item produk menghitung dan memberi tahu
Store Manager. (Requirements : REQ1 - REQ4)
● UC-2: Additem-RFID Reader memberi tahu sistem bahwa item produk
ditempatkan di rak.(REQ6)
● UC-3: AssignreplenishTask-Store Manager Menugaskan Store Associate dengan
tugas untuk mengisi kembali rak tertentu dengan produk tertentu. Store Associate
diberitahu tentang detail dari tugas yang ditugaskan. (REQ5)
● UC-4: Viewpendingwork-Store Manager atau Store Associate Melihat pekerjaan
mereka sendiri yang dibutuhkan Untuk dilakukan: Store Manager memberikan
tugas-tugas pengisian ulang dan Store Associate melakukan tugas-tugas tersebut.
Store Manager juga dapat melihat tugas yang tertunda yang ditugaskan untuk Store
Associate.
● UC-5: Sendreminder-Timeout Timer mengirimkan pengingat ke Store Manager
(jika Tugas pengisian ulang tidak ditetapkan dalam waktu tertentu) atau ke Store
Associate (jika penyelesaian pengisian tidak dilaporkan dalam waktu tertentu).
● UC-6: ReplenishCompleted-Store Associate Inputs ke Dalam Sistem Tugas
Pengisian lengkap. Sistem memperbarui database dan memberi tahu manajer toko.
(REQ7)

b. Gambarkan diagram use case untuk use case yang dijelaskan pada item (a)

c. Diskusikan persyaratan tambahan dan kasus penggunaan yang dapat

ditambahkan ke sistem ini.

UC-1: RemoveItem, sistem saat ini sedang memeriksa dua ambang batas: "stok
rendah" atau "out-stok.” Manajemen mungkin memutuskan untuk memeriksa
beberapa ambang batas, misalnya, untuk melacak tingkat penjualan untuk produk
yang berbeda (tidak hanya jumlah item), atau untuk menerima peringatan dini
untuk menghubungi pemasok jika tidak ada lagi produk ini di gudang. Selain itu,
ambang berbeda nilai dapat digunakan untuk produk yang berbeda.
 UC-3: AssignReplenishTask, Store Manager mungkin ingin melihat karyawan yang
mana sedang dalam shift, serta berbagai statistik, seperti jumlah total tugas yang
saat ini ditugaskan untuk setiap karyawan, atau jumlah total tugas yang
diselesaikan oleh setiap karyawan selama masa lalu tertentu selang. Selain itu,
UC-3 harus menyertakan opsi untuk menetapkan kembali tugas, jika manajer
berubah pikiran (sebelum tugas menjadi terlambat). Ini tidak eksplisit dalam
persyaratan, tetapi dapat diasumsikan sesuai kebutuhan.

UC-8: StartReplenishing, sehingga Store Associate dapat memberi tahu sistem

bahwa dia ada saat ini mengisi ulang rak. Tujuan dari use case ini adalah untuk
menghindari pesan about yang tidak perlu penipisan produk kepada Store Manager.
Misalnya, jika rekanan toko meletakkan satu barang di sebuah rak kosong dan
pelanggan segera menghapus item ini, sistem akan menghasilkan pesan "stok
habis" yang tidak perlu untuk Store Manager.

UC-9: VolunteerHelp, Rekan seperti itu akan dapat melihat semuanya tugas
penambahan yang tertunda, sambil menjaga anonimitas penerima tugas. Pilihan
lain adalah untuk izinkan karyawan untuk membentuk "Friendship Network",
sehingga anggota dapat melihat satu sama lain tertunda tugas dan menawarkan
bantuan. Opsi sukarela akan memungkinkan penyetokan ulang yang lebih cepat,
mengurangi downtime karyawan, dan dan meningkatkan moral dari kerja sama tim.

2.16 Tulis spesifikasi terperinci untuk kasus penggunaan

Use Case 1 (UC-1): Pemantau Barang

Persyaratan yang berhubungan: REQ1-REQ4
Aktor: Pembaca RFID
Tujuan aktor: Untuk memperbarui penghitung item produk di database
setelah produk dihapus dan memberi tahu manajer toko
jika produk kehabisan stok.
Aktor yang berpartisipasi: Basis Data, Manajer Toko, Timeout timer
Prasyarat: ● Dalam database, hitungan produk > 0
● Ambang batas > 0 ditentukan untuk deteksi “stok
habis”.
Kondisi akhir: ● Di database, jumlah produk yang diperbarui ≥ 0
● Jika jumlah produk yang diperbarui < ambang batas,
 maka:
○ Tugas "out-of-stock" dicatat dalam database yang
perlu ditetapkan (saat ini ditandai sebagai “belum
ditetapkan”)
○ Pemberitahuan dikirim ke manajer toko
○ Timeout timer dimulai
Skenario utama:
1. Pembaca RFID melaporkan bahwa tag tertentu keluar dari jangkauan.
2. Sistem (a) menggunakan tag-ID mengambil nama produk dan jumlah produk dari basis
data, menguranginya dengan 1.
3. Sistem menyimpan jumlah produk yang diperbarui ke database dan keluar dari kasus
penggunaan ini.

Skenario alternatif:
1. Pesan dari Pembaca RFID rusak/tidak dapat dikenal:
1.1. Sistem membuang pesan, mencatat kejadian di Database, dan keluar dari kasus
penggunaan ini.
2. Hasil query untuk tag-ID yang dikembalikan oleh Database adalah nihil
2.1. Sistem membuang pesan, mencatat kejadian di Database, dan keluar dari kasus
penggunaan ini.
3. Jumlah produk yang diperbarui 0
3.1. Sistem menyimpan semua parameter yang relevan tetapi tidak memperbarui
jumlah produk di database.
3.2. Kesalahan sinyal sistem ke Manajer Penyimpanan dan keluar dari kasus
penggunaan ini.
4. Jumlah produk yang diperbarui Ambang batas (tetapi jumlah produk ≥ 0!)
4.1. Sistem mengirimkan notifikasi “out-of-stock” ke Store Manager
4.2. Sistem memulai Timeout timer.
4.3. Sistem menyimpan jumlah produk yang diperbarui ke database dan keluar dari
kasus penggunaan ini.

Use Case 5 (UC-5): Pengirim Pengingat

Persyaratan yang berhubungan: REQ4 dan REQ5

Aktor: Timeout timer

Tujuan Aktor: Untuk mengingatkan manajer toko bahwa tugas
penambahan harus diberikan untuk produk yang
kehabisan stok

Aktor yang Berpartisipasi: Manajer toko

Prasyarat: ● Timeout terjadi untuk tugas "stok habis" yang belum

ditetapkan

Kondisi akhir: ● Jumlah upaya pemberitahuan untuk tugas yang

ditambahkan di database
● Jika percobaan-hitungan percobaan-maksimum,
maka pemberitahuan "out-of-stock" dikirim kembali
ke manajer toko. Jika tidak, notifikasi dikirim ke
seluruh sistem.
● Timeout timer dimulai kembali.

Skenario sukses:
1. Sistem mengirimkan notifikasi “out-of-stock” ke manajer toko.
2. Sistem memulai Timeout timer dan keluar dari kasus penggunaan ini.

Skenario alternatif:
1. Sistem mengirimkan notifikasi “out-of-stock” ke Store Manager
1.1. Sistem mengirimkan pemberitahuan "stok habis" ke seluruh toko
1.2. Sistem memulai Timeout timer dan keluar dari kasus penggunaan ini.
2.19 Pertimbangkan variasi dari sistem kontrol akses rumah yang akan melakukan
identifikasi pengguna berdasarkan pengenalan wajah, seperti yang dijelaskan dalam
Bagian 2.4.2. Tulis deskripsi kasus penggunaan terperinci tentang penggunaan.

cases UC3: Tambah Pengguna dan UC4: Hapus Pengguna untuk kedua kasus yang
diberikan pada Gambar 2-16, yaitu secara lokal
menerapkan pengenalan wajah (Kasus (a)) dan pengenalan wajah yang disediakan dari
jarak jauh (Kasus (b)).

Kasus (a) implementasi pengenalan wajah secara lokal

1. Kasus penggunaan UC-3: tambah pengguna

● Persyaratan terkait : REQ6, Sistem harus mengizinkan penambahan orang yang
berwenang baru saat runtime atau menghapus yang sudah ada.
● Aktor inisiai : Tuan rumah
● Tujuan aktor : Untuk mendaftarkan penduduk baru dan mencatat informasi
demografisnya.
● Aktor yang berpartisipasi : Penyewa
● Prasyarat : Pemilik telah diautentikasi dengan benar
● Kondisi akhir : Sistem pengenalan wajah dilatihkan pada wajah penduduk baru.
● Skenario Sukses Utama :
○ Tuan tanah meminta sistem untuk membuat catatan pengguna baru
○ Sistem (a) membuat rekaman pengguna baru, dan (b) meminta data (file
nama penduduk baru, alamat, telepon, dll.)
○ Tuan tanah mengisi formulir dengan informasi dan sinyal demografis
penyewa penyelesaian
○ Sistem (a) menyimpan nilai di bidang catatan, dan (b) meminta Penyewa
“kata sandi”, yang dalam hal ini adalah satu atau lebih gambar wajah
Penyewa
○ Penyewa berpose di depan kamera untuk "bidikan mug" dan sinyal untuk
pengambilan gambar
○ Sistem (a) melakukan dan menegaskan pengambilan gambar, (b)
menjalankan pelatihan pengenalan
○ algoritme hingga wajah baru "dipelajari", (c) menandakan penyelesaian
pelatihan, dan (d) menandakan bahwa penyewa baru berhasil ditambahkan
dan proses selesai
 2. Kasus penggunaan UC-4: hapus pengguna
● Persyaratan terkait : REQ6, Sistem harus mengizinkan penambahan orang yang
berwenang baru saat runtime atau menghapus yang sudah ada.
● Aktor inisiai : Tuan rumah
● Tujuan aktor : Untuk menghapus data penduduk
● Aktor yang berpartisipasi : Penyewa
● Prasyarat : Pemilik telah diautentikasi dengan benar
● Kondisi akhir : Sistem pengenalan wajah tidak mengenali wajah pengguna yang
telah dihapus.
● Skenario Sukses Utama :
○ Tuan tanah meminta sistem untuk menghapus catatan pengguna
○ Sistem mencari dan menghapus rekaman pengguna

Kasus (b) di mana pengenalan wajah disediakan oleh perusahaan jarak jauh

1. Kasus penggunaan UC-3: tambah pengguna

● Persyaratan terkait : REQ6, Sistem harus mengizinkan penambahan orang yang
berwenang baru saat runtime atau menghapus yang sudah ada.
● Aktor inisiai : Tuan rumah
● Tujuan aktor : Untuk mendaftarkan penduduk baru dan mencatat informasi
demografisnya.
● Aktor yang berpartisipasi : Penyewa, FaceReco
● Kondisi akhir : Sistem pengenalan wajah dilatihkan pada wajah penduduk baru.
● Skenario Sukses Utama :
○ tanah meminta sistem untuk membuat catatan pengguna baru
○ Sistem (a) membuat rekaman pengguna baru, dan (b) meminta data (file
nama penduduk baru, alamat, telepon, dll.)
○ Tuan tanah mengisi formulir dengan informasi dan sinyal demografis
penyewa penyelesaian
○ Sistem (a) menyimpan nilai di bidang catatan, dan (b) meminta Penyewa
“kata sandi”, yang dalam hal ini adalah satu atau lebih gambar wajah
Penyewa
○ Penyewa berpose di depan kamera untuk "bidikan mug" dan sinyal untuk
pengambilan gambar
 ○ Sistem (a) melakukan dan menegaskan pengambilan gambar, (b)
menjalankan pelatihan pengenalan
○ Sistem (a) melakukan pengambilan gambar, (b) mengirimkan gambar ke
FaceReco untuk pelatihan algoritma pengenalan wajah, dan (c) memberi
sinyal kepada Pemilik bahwa pelatihan sedang berlangsung kemajuan
○ FaceReco (a) menjalankan algoritme pelatihan pengenalan hingga wajah
baru “dipelajari”, dan (b) menandai penyelesaian pelatihan ke Sistem
○ Sistem memberi sinyal kepada Pemilik bahwa penyewa baru berhasil
ditambahkan dan proses selesai
2. Kasus penggunaan UC-4: hapus pengguna
● Persyaratan terkait : REQ6, Sistem harus mengizinkan penambahan orang yang
berwenang baru saat runtime atau menghapus yang sudah ada.
● Aktor inisiai : Tuan rumah
● Tujuan aktor : Untuk menghapus data penduduk
● Aktor yang berpartisipasi : Penyewa, FaceReco
● Prasyarat : Pemilik telah diautentikasi dengan benar
● Kondisi akhir : Sistem tidak mengenali wajah pengguna yang telah dihapus.
● Skenario Sukses Utama :
○ Tuan tanah meminta sistem untuk menghapus catatan pengguna
○ Sistem mencari dan menghapus rekaman pengguna
2.20 Pertimbangkan mesin bank otomatis, yang dikenal sebagai Anjungan Tunai
Mandiri (ATM), dan pelanggan yang ingin menarik sejumlah uang tunai dari
rekening perbankannya. Menggambar UML diagram aktivitas untuk mewakili kasus
penggunaan ini.
2.21. Turunkan model domain dengan konsep, asosiasi, dan atribut untuk lab mitosis
virtual.

Model domain untuk laboratorium virtual pembelahan sel.

Konsep:

● Lab Mitosis Virtual: Aplikasi yang memungkinkan pengguna untuk mempelajari

dan mengamati proses mitosis sel melalui simulasi.
● Sel: Unit dasar kehidupan, terdiri dari nukleus, sitoplasma, dan membran sel.
● Tahap Mitosis: Fase dalam siklus sel ketika sel membelah menjadi dua sel anak.
● Proses Mitosis: Proses pembelahan sel menjadi dua sel anak yang identik.

Asosiasi:

● Sel memiliki tahap mitosis: Setiap sel akan mengalami tahap-tahap mitosis tertentu
dalam proses pembelahan sel.
● Proses Mitosis terdiri dari tahap-tahap mitosis: Proses mitosis terdiri dari
serangkaian tahap-tahap mitosis yang harus diikuti secara berurutan.
Atribut:

1. Sel:
1.1. Jenis sel: menunjukkan jenis sel yang diamati oleh pengguna (misalnya, sel
tumbuhan atau sel hewan).
1.2. Ukuran: menunjukkan ukuran sel dalam mikrometer.
1.3. Kondisi: menunjukkan kondisi sel (misalnya, normal atau abnormal).
2. Tahap Mitosis:
2.1. Nama tahap: menunjukkan nama tahap mitosis (misalnya, profase,
metafase, anafase, atau telofase).
2.2. Durasi: menunjukkan durasi tahap dalam hitungan waktu.
3. Proses Mitosis:
3.1. Durasi: menunjukkan durasi proses mitosis dalam hitungan waktu.
3.2. Keterangan: menunjukkan deskripsi proses mitosis dan tujuan pembelahan
sel.

2.22. Jelaskan hubungan antara kasus penggunaan dan objek model domain dan
ilustrasikan dengan contoh.

● Kasus penggunaan mewakili persyaratan fungsional dari suatu sistem,

menggambarkan interaksi antara sistem dan penggunanya. Mereka menangkap
tujuan yang ingin dicapai pengguna saat menggunakan sistem dan bagaimana
sistem harus merespons tindakan mereka. Kasus penggunaan biasanya melibatkan
beberapa objek model domain yang bekerja sama untuk mencapai fungsionalitas
yang diinginkan.

● Di sisi lain, objek model domain adalah konsep kunci dan entitas yang membentuk
domain masalah dari sistem. Mereka adalah kata benda dalam domain masalah,
mewakili objek atau konsep dunia nyata yang perlu ditangani oleh sistem. Objek
model domain menangkap properti dan perilaku penting dari domain sistem dan
menyediakan dasar untuk fungsionalitas sistem.

● Hubungan antara kasus penggunaan dan objek model domain adalah bahwa kasus
penggunaan mendorong desain dan implementasi objek model domain. Kasus
penggunaan menentukan fungsionalitas yang perlu disediakan oleh sistem, dan
 objek model domain mewakili konsep dan entitas yang perlu dimanipulasi oleh
sistem untuk menyediakan fungsionalitas tersebut.

● Sebagai contoh, sistem belanja online. Kasus penggunaan untuk sistem mungkin
adalah "Pemesanan". Kasus penggunaan ini melibatkan beberapa objek model
domain, seperti Pelanggan, Keranjang Belanja, Pesanan, dan Pembayaran.
Pelanggan memilih item untuk dibeli dan menambahkannya ke Keranjang Belanja,
yang direpresentasikan sebagai objek model domain. Sistem kemudian membuat
objek Pesanan untuk menangkap detail pesanan, termasuk item yang dipilih dan
informasi pengiriman dan penagihan Pelanggan. Terakhir, sistem menggunakan
objek Pembayaran untuk memproses pembayaran dan menyelesaikan pesanan.

● Kasus penggunaan "Pemesanan" mengarahkan desain objek model domain yang

mewakili konsep kunci yang terlibat dalam proses. Objek model domain, pada
gilirannya, memberikan dasar untuk mengimplementasikan fungsionalitas yang
diperlukan oleh use case.
 Referensi

1. Ebook-Software-Engineering-Ivan-Marsic