Kebutuhan Fungsional & Kebutuhan Antarmuka

Slides:



Advertisements
Presentasi serupa
©Ayi Purbasari, S.T., /2008 Materi 3 Kuliah IT-505 PSBO ©Ayi Purbasari, S.T., /2008.
Advertisements

Analisis Kebutuhan Perangkat Lunak (software requirement analysis)
Rekayasa Perangkat Lunak dan Proses Software
Bab 6 PERANCANGAN PERANGKAT LUNAK
Perancangan Sistem Informasi Terstruktur (3 SKS)
Perancangan Sistem Informasi (2 SKS)
Analisis Kebutuhan Sistem Untuk Pengguna (User Requirement)
Perancangan Sistem Ana Kurniawati.
Dheni Setyawan ( ) Taufiq Yulyanto M ( ) Raka Januarsa ( )
PENGANTAR REKAYASA PERANGKAT LUNAK I
SKPL Spesifikasi Kebutuhan Perangkat Lunak STMIK AMIKOM PURWOKERTO.
Program Studi Manajemen Informatika Fakultas Ilmu Terapan
Program Studi Manajemen informatika
Program Studi Manajemen Informatika Fakultas Ilmu Terapan
Aktivitas Pengembangan Dan Pemeliharaan Sistem
KONSEP & DEFINISI KEBUTUHAN PL
C Diagram Aliran Data Program Studi Manajemen Informatika Fakultas Ilmu Terapan MI1042 – RPL | Genap : Hanya untuk kepentingan pengajaran di.
Konsep & Prinsip Analisis
Perangkat Pemodelan Terstruktur
Analisis Kebutuhan dan Spesifikasi Perangkat Lunak
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Pemrosesan Transaksi Kelompok 5 : Fitri Nur Kholila Gilang Wahyu W
Konteks Metode Analisis dan Desain Sistem
REKAYASA PERANGKAT LUNAK
Managing Software Requirement 1
PERANCANGAN BASIS DATA
Analisis Kebutuhan Software
REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
KONSEP & DEFINISI KEBUTUHAN PL
PERENCANAAN AKTIVITAS PROYEK
Spesifikasi Perangkat Lunak
Perancangan Sistem L. Erawan.
Perangkat Lunak 1.
PERANCANGAN SISTEM INFORMASI
Rekayasa Perangkat Lunak Model Proses PL
PERANCANGAN PERANGKAT LUNAK ( PL )
Rencana Pengembangan Perangkat Lunak (TIS 00)
Penggalian Kebutuhan; Modul Elisitasi
DOKUMENTASI.
Desain User Interface dan Input
DESAIN SISTEM Muhammad Taqiyyuddin Alawiy, ST., MT TEKNIK ELEKTRO
SE3414 RPL: Teknik Berorientasi Objek
Building the Requirements Model
Analisis Kebutuhan Perangkat Lunak
Membangun Model Kebutuhan
AKUNTANSI KOPERASI a JUNAIDI, SE
DATA FLOW DIAGRAM.
RPL & Analisis Sistem Oleh : Tim Pembina MK Rekayasa Perangkat Lunak
Rekayasa Kebutuhan Software
KONSEP & DEFINISI KEBUTUHAN PL
QUIS DPSIA Siapkan Kertas Selembar, pada kertas tersebut tuliskan:
Building the Requirements Model
REKAYASA PERANGKAT LUNAK
System analysis adalah sebuah teknik pemecahan masalah dengan menguraikan permasalahan/system menjadi komponen-komponen serta mengkaji hubungan antara.
DOKUMENTASI.
ANALISIS KEBUTUHAN PERANGKAT LUNAK
PENGANTAR REKAYASA PERANGKAT LUNAK
JURNAL EKONOMI DAN BISNIS PENGEMBANGAN SISTEM INFORMASI BERBASIS WEB MANAJEMEN PERJALANAN DINAS SATUAN KERJA PERANGKAT DAERAH (SKPD) Widyat Nurcahyo.
Pengembangan Sistem Informasi
Building the Requirements Model
DIAGRAM AKTIVITAS ACTIVITY DIAGRAM.
REKAYASA KEBUTUHAN PL.
Building the Requirements Model
SISTEM INFORMASI PERPUSTAKAAN PADA SMA PASUNDAN 3 BANDUNG
PENGENALAN PEMROSESAN TRANSAKSI
Teknik merancang Questioner dalam analisis kebutuhan PL
Pemrograman Terstruktur
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Tools System Dalam Desain Pengembangan Software SIA
Transcript presentasi:

Kebutuhan Fungsional & Kebutuhan Antarmuka Program Studi Manajemen Informatika Fakultas Ilmu Terapan MI1042 – RPL | Genap 2014-2015 .: Hanya untuk kepentingan pengajaran di lingkungan Fakultas Ilmu Terapan – Universitas Telkom :.

Disusun & divalidasi Eka Widhi Yunarso, S.T., M.MT. Hanung Nindito Prasetyo, S.Si., M.T

Indikator Kompetensi RPL Kajian Kategori Indikator Kompetensi Bobot K. Dasar (1) K. Menengah (2) K. Mahir (3) 2 Kebutuhan PL Menguraikan definisi kebutuhan PL Menjelaskan perbedaan antar jenis kebutuhan Merumuskan secara ringkas dan konsisten akan kebutuhan PL, Diagram Aliran Data, Kamus Data dan Spesifikasi Proses berdasarkan studi kasus 10 Menjelaskan secara singkat jenis-jenis kebutuhan PL Mengidentifikasi kebutuhan PL berdasarkan studi kasus Memberikan contoh tentang jenis-jenis kebutuhan PL Menjelaskan secara singkat teknik-teknik wawancara Diagram Aliran Data Menjelaskan secara singkat definisi Diagram Aliran Data Menggambarkan Diagram Aliran Data sederhana dengan lengkap berdasarkan studi kasus Menjelaskan secara singkat simbol-simbol Diagram Aliran Data Menjelaskan secara singkat aturan pembuatan Diagram Aliran Data Menguraikan kesalahan pada Diagram Aliran Data Kamus Data Menjelaskan secara singkat definisi Kamus Data Mengidentifikasi kamus data berdasarkan studi kasus Spesifikasi Proses Menjelaskan secara singkat definisi Spesifikasi Proses Mengidentifikasi spesifikasi proses berdasarkan studi kasus Pencapaian (Nilai Akhir) Kajian 2 100 Indikator Kompetensi RPL

Mendefiniskan Kebutuhan PL Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagai contoh, ungkapan kebutuhan pemakai di bagian akutansi. saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal. Informasi neraca keuangan bisa saya lihat kapan saja. Kebutuhan pemakai yang belum terstruktur tersebut akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka dan unjuk kerja perangkat lunak. Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat dimodelkan dengan menggunakan Data flow diagram, kamus data, dan spesifikasi proses jika menggunakan analisis tertsruktur Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek.

Mendefiniskan Kebutuhan PL Contoh, kebutuhan “data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal” setelah dianalisis, diklasifikasikan dan diterjemahkan, dapat menghasilkan pendefinisian kebutuhan sebagai berikut. Kebutuhan fungsional Entri dan rekam data transaksi penjualan. Retrieve data transaksi penjualan untuk periode tertentu (periode sesuai dengan inputan periode yang diinputkan pada keyboard). Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal umum berikut account pasangannya (kas). Kebutuhan antarmuka Antarmuka pemakai untuk memasukkan dan merekam data penjualan. Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi penjualan pada periode tertentu.

Mendefiniskan Kebutuhan PL Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian akutansi. Kebutuhan unjuk kerja proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan direkam. Adanya otoritas pemakaian perangkat lunak dan akses data sesuai dengan bagian pekerjaan masing-masing.

wawancara Hal pertama yang dilakukan dalam analisis sistem adalah melakukan pengumpulan data. Ada beberapa teknik pengumpulan data yang sering dilakukan di antaranya adalah teknik wawancara. Dalam mewawancara narasumber, gunakan pertanyaan yang jelas dan mudah dipahami. Hindari pertanyaan yang panjang dan kompleks. Cobalah untuk menggali mengenai kelebihan dan kekurangan sistem yang telah berjalan sebelumnya. Improvisasi dapat dilakukan dengan mencoba menggali bagian-bagian tertentu, misalnya pertanyaan- pertanyaan yang sudah dijawab di pertanyaan sebelumnya, atau dapat dihapus jika dianggap tidak relevan berdasarkan informasi yang sudah diketahui secara pasti selama wawancara. Catat hasil wawancara tersebut.

wawancara Pertanyaan Pembuka Apakah posisi Anda di bagian Perpustakaan ini? Sudah berapa lama Anda bekerja di bagian ini? Pertanyaan Isi Bisa Anda ceritakan mengenai Sistem Informasi Perpustakaan yang ada saat ini? Aktivitas apa saja yang ada pada perpustakaan dan khususnya pada sistem informasi perpustakaan ini? Bagaimana prosedur pendaftaran anggota? Data apa saja yang dicatat? Bagaimana prosedur peminjaman dan pengembalian buku? Data apa saja yang dicatat pada saat tsb? Sudah pernah ada pengembangan terhadap sistem tersebut? (Apabila tidak, mengapa?) Apakah ada nilai tambah setelah pengembangan? Apakah pernah mengalami kegagalan setelah pengembangan sistem? (Apabila ada, bisa memberikan contoh?) dst. Kesimpulan … (menyimpulkan hasil wawancara)

Keb. Antarmuka eksternal Antarmuka Pengguna Karakteristik logis dari setiap antarmuka antara produk perangkat lunak dan penggunanya. Hal ini akan melibatkan karakteristik konfigurasi (misalnya standar format layar, tata letak window, isi laporan/menu -bukan tata letak tiap layar/windownya sendiri- atau ketersediaan kunci khusus atau jenis mouse) untuk memenuhi kebutuhan sistem. Semua aspek optimisasi antarmuka dengan orang yang akan menggunakan sistem. Bagian ini mungkin hanya berisi daftar yang harus dan tidak boleh dilakukan oleh sistem dari sudut pandang pengguna. Misalnya kebutuhan untuk pemilihan pesan yang singkat atau panjang. Seperti kebutuhan lain, kebutuhan ini harus dapat diverifikasi. Misalnya kalimat “seorang pegawai berpengalaman dapat melakukan X dalam Z menit setelah 1 jam training” akan lebih baik daripada hanya mendefinisikan “Seorang pegawai berpengalaman dapat melakukan X”.

Keb. Antarmuka eksternal Antarmuka Pengguna No. Kode Deskripsi Kebutuhan 1. UI-100 Tampilan GUI dalam bentuk window dengan ukuran sesuai isi, fix, dan resolusi 1024 x 768 2. UI-200 Menu pulldown yang dilengkapi dengan toolbar untuk save, search, print preview dan print 3. UI-300 dst.

Keb. Antarmuka eksternal Antarmuka Perangkat Keras Bagian ini menjelaskan karakteristik logis dari setiap antarmuka antara produk perangkat lunak dan komponen perangkat keras dari sistem. Bagian ini akan melibatkan karakteristik konfigurasi (jumlah port, jumlah instruksi, dll). Antarmuka ini juga melibatkan hal-hal seperti perangkat pendukung, dan bagaimana peralatan tersebut menjadi pendukung, dan protokol. Bagian ini hanya diisi jika sistem perangkat lunak yang dispesifikasikan membutuhkan perangkat keras khusus, contoh: VideoGrabber Card, FM Tuner, Sound Card, dan lain-lain. No. Kode Deskripsi Kebutuhan 1. HW-100 Standard I/O devices untuk entry dan cetak 2. HW-200 Driver type xxx untuk mengakses data kode barang dari bar code reader

Keb. Antarmuka eksternal Antarmuka Perangkat Lunak Bagian ini menspesifikasikan penggunaan produk perangkat lunak lain (misalnya sistem manajemen basis data, sistem operasi atau paket matematik) dan antarmuka dengan sistem aplikasi lain (sebagai contoh hubungan antara sistem account receivable dan sistem General Ledger). Bagian ini hanya diisi jika perangkat lunak yang dispesifikasikan memakai antarmuka (berupa perangkat lunak lain atau mekanisme khusus), misalnya API Windows. Jadi jika perangkat lunak direncanakan hanya berjalan di atas Windows saja tanpa menggunakan layanan Windows misalnya, tidak perlu dituliskan. Untuk setiap perangkat lunak yang dibutuhkan atau terkait, harus disertai dengan: Nama, Mnemonic, Nomor spesifikasi, Nomor Versi, Sumber Tujuan menghubungkan perangkat lunak tersebut dengan perangkat lunak yang dispesifikasikan. Definisi dari antarmuka dalam bentuk isi pesan dan formatnya. Jika antarmuka yang sudah terdokumentasi dengan baik, maka tidak perlu diuraikan ulang tetapi cukup mengacu ke dokumen tersebut.

Keb. Antarmuka eksternal Antarmuka Komunikasi Bagian ini harus menspesifikasikan berbagai antarmuka untuk komunikasi, seperti protokol jaringan lokal. Bagian ini hanya diisi jika perangkat lunak yang dispesifikasikan beroperasi dengan memanfaatkan antarmuka tersebut. Contoh: RS232, TCP/IP, WinSock. Jadi, jika perangkat lunak yang dispesifikasi hanya sekedar dijalankan di atas Unix tanpa menggunakan protokol TCP atau IP, maka TCP/IP tidak perlu disebutkan.

Kebutuhan performansi Bagian ini harus menspesifikasikan baik kebutuhan numerik statik/dinamik yang terletak pada interaksi perangkat lunak atau pada interaksi manusia dengan perangkat lunak secara keseluruhan. Kebutuhan numerik statik sering diidentifikasi pada bagian terpisah yang disebut kapasitas. Kebutuhan numerik dinamik mungkin dapat melibatkan, sebagai contoh, jumlah transaksi dan tugas dan jumlah data yang akan diproses selama jangka waktu tertentu, baik kondisi normal atau kondisi beban puncak. Berikut ini merupakan contoh spesifikasi kebutuhan perfomansi: Perangkat lunak harus dapat dioperasikan maksimal sampai 5 pemakai. Sistem login untuk masing-masing pemakai di awal penggunaan perangkat lunak. Fasilitas backup data historis sesuai periode yang diinginkan. Fasilitas untuk load data historis yang sudah di-backup.

referensi [1] DeMarco, Tom., “Structured Analysis and System Specifications”, Prentice Hall, New York, 1979. [2] Roger Pressman, “Software Engineering A Practitioner’s Approach”, 6th Edition, Mc GrawHill. [3] Yourdon, Edward, “Modern Structured Analysis”, Prentice-Hall International Inc., Englewood Cliffs, New Jersey, 1989

DISKUSI ???