Contoh Dokumen Pendefinisian Kebutuhan

Contoh Dokumen Pendefinisian Kebutuhan 1. Daftar Kebutuhan Bisnis (Requirement List) Nama No REQI Kebutuha Deskripsi . D n 1 R-01 Menerima Sistem harus dapat menerima pesanan pesanan melalui SMS melalui SMS 2 R-02 Mencatat Sistem harus dapat mencatat waktu waktu antara pesanan diterima dengan terima barang diterima di tujuan. pesanan sampai waktu pengiriman 2. Use Case Diagram Contoh:

Lihat Menu Makanan

Mahasi swa Pesan M akanan

Manajer Kantin

Membuat Menu

Mengubah Menu

Gambar Use Case Sistem Pemesanan Makanan di Cafetaria Politeknik Telkom

a. Deskripsi Use Case Kumpulan Use Case Description yang mendeskripsikan Kebutuhan Bisnis. Satu UseCase Description menggambarkan satu atau lebih Kebutuhan Bisnis. Setiap Use CaseDescription harus diberi ID khusus yang membedakan Use Case Description satudengan Use Case Description lain. ID ini untuk selanjutnya disebut sebagai UCID.> Use case ID: 1 Nama Use Memesan Makanan case: Created By: Date Created:

Rachmat Gunawan 01/01/2009

Aktor: Mahasiswa Deskripsi: Mahasiswa mengaksis Sistem Pemesanan Makanan dari intranet Politeknik Telkom, melihat menu untuk tanggal tertentu, memilih makanan, dan melakukan pemesanan untuk makanan untuk diantarkan ke alamat tertentu dalam rentang waktu 30 menit. Preconditions 1. Mahasiswa Log In ke Sistem Pemesanan : Makanan. 2. Mahasiswa terdaftar di sistem pemesanan makanan untuk pembayaran Postcondition 1. Pesanan tersimpan di dalam sistem dengan s: status ‘Diterima’. 2. Data Keberadaan makanan dimutakhirkan sesuai dengan makanan yang dipesan. Normal 1.0 Pesan Satu Jenis Makanan Course/ 1. Mahasiswa melihat menu untuk tanggal Skenario tertentu Normal 2. Sistem menampilkan menu yang tersedia untuk tanggal tersebut dan penawaran khusus di hari itu. 3. Mahasiswa memilih satu atau lebih makanan dari menu. 4. Mahasiswa menyatakan bahwa pemesanan telah selesai dan lengkap. 5. Sistem menampilkan makanan yang dipesan, harga satuannya, dan harga keseluruhannya, termasuk pajak dan biaya pengantaran. 6. Mahasiswa menyetujui persetujuan tersebut, bila tidak setuju atau ingin merubah, kembali

ke nomor 3. 7. Mahasiswa memilih cara pembayaran 8. Sistem menerima cara pembayaran tersebut. 9. Sistem mengirim email ke mahasiswa tersebut untuk konfirmasi menyangkuit detail pemesanan, harga, dan cara pembayaran. 10. Sistem menyimpan pemesanan tersebut dalam database, mengirim email ke staf kafetaria, mengirimkan informasi stok makanan ke sistem inventory kafetaria. Alternative 1.1 Memesan banyak makanan (mencabang Courses/ setelah langkah ke 4) Skenario 1. Mahasiswa ditanya untuk memesan makanan Lain lain. 2. kembali ke langkah nomor 2. 1.2 Memesan banyak makanan sejenis (setelah langkah ke 3) 1. Mahasiswa diminta memasukkan jumlah makanan sejenis yang dipesan 2. kembali ke langkah 4. 1.3. Memesan pesanan khusus hari itu (setelah langkah ke 2) 1. Mahasiswa memesan makanan khusus hari itu. 2. Kembali ke langkah 5. Exceptions/ 1.0.E.1 Sekarang sudah lewat waktu Pengecualian pemesanan (di langkah 1) : 1. Sistem memberi tahu mahasiswa bahwa waktu pemesanan sudah habis untuk hari ini. 2a. Mahasiswa membatalkan pemesanan 2b. Sistem membatalkan Use case. 3a. Mahasiswa meminta tanggal yang lain 3b. Sistem mengulangi Use case. 1.2.E.1 Tidak dapat memenuhi pesanan banyak untuk makanan sejenis (langkah 1) 1. Sistem memberi tahu mahasiswa bahwa makanan sejenis yang dapat dipesan telah mencapai maksimum 2. Mahasiswa mengubah jumlah makanan sejenis yang dipesan atau membatalkan

pemesanan makanan. Includes: None Priority: High Frequency of Kira-kira 400 pelanggan, biasanya 1 kali pesan Use: per hati Aturan yang harus dipenuhi: Kebutuhan 1. Mahasiswa harus dapat membatalkan khusus: pemesanan makanan kapanpun sebelum mengkonfirmasi pemesanan. 2. Mahasiswa harus dapat melihat seluruh makanan yang dia pesan dalam 6 bulan ke belakang. (Prioritas = medium) Asumsi: Asumsi bahwa 30% mahasiswa akan memesan makanan tiap hari. Catatan:

b. Daftar Pemetaan Kebutuhan (Requirement Anaysis) Contoh: # 1 1.

UCID UC-1

ReqID R-01

Keterangan Menerima pesanan melalui SMS

Daftar Perubahan User Requirment (diisi jika ada perubahan requirement) Keterangan Approve No. REQID UCID Perubahan d By

2. Asumsi (Tahapan Analisis) Contoh: Asumsi yang digunakan dalam analisis ini adalah: 1. Aplikasi dibangun berbasis Web (Web-based) 2. Database yang digunakan menggunakan database relasional (RDBMS) 3. Metodologi pengkodean software menggunakan object oriented. 4. Authentication engine menggunakan LDAP server Politeknik Telkom 5. Email server menggunakan SMTP server Politeknik Telkom 6. SMS Gateway menggunakan SMS Gateway Telkom Flexy dan GSM Modem.

3. Pengguna/Kelompok Pengguna Contoh: Pengguna

Tanggung Jawab

Kewenangan

Administrator kantin

9 Memonitor pesanan 9 Memonitor menu 9 Mengadministrasi menu

9 Mendisposisi pesanan ke bagian delivery 9 Mengadministrasi menu

1. Model Struktural < Kumpulan Model Struktural yang secara logikal memberi solusi untuk Kebutuhan Bisnis yang ditangkap di Tahap Pengumpulan Kebutuhan. Setiap Model Struktural harus diberi ID khusus yang membedakan Model Struktural satu dengan Model Struktural lain. ID ini untuk selanjutnya disebut sebagai MSID. Salah satu bentuk model struktural adalan Class Diagram , akan dijelaskan lebih lengkap oleh Dosen>

2. Model Behavioral < Kumpulan Model Behavioral yang secara logikal memberi solusi untuk Kebutuhan Bisnis yang ditangkap di Tahap Pengumpulan Kebutuhan. Setiap Diagram Model Behavioral harus diberi ID khusus yang membedakan Diagram Model Behavioral satu dengan Diagram Model Behavioral lain. ID ini untuk selanjutnya disebut sebagai DMBID Salah satu bentuk model behavioral adalah Activity Diagram, Sequence Diagram, Collaboration Diagram, dan Work Flow atau Data Flow Diagram (untuk pendekatan prosedural. akan dijelaskan lebih lengkap oleh Dosen