EXERCISE WORKBOOK

MI1042-2012#12,13 Nama MK : Rekayasa Perangkat Lunak Disampaikan pada minggu ke-12, 13

Program Studi Manajemen Informatika Politeknik Telkom Bandung Jl. Telekomunikasi Terusan Buah Batu, Bandung, 40257

IDENTITAS Kajian 3 Dokumen SKPL Topik Dokumen SKPL Referensi [1] DeMarco, Tom., Structured Analysis and System Specifications, Prentice Hall, New York, 1979. [2] Roger Pressman, Software Engineering A Practitioners Approach, 6th Edition, Mc GrawHill. [3] Yourdon, Edward, Modern Structured Analysis, Prentice-Hall International Inc., Englewood Cliffs, New Jersey, 1989 Kompetensi Utama Indikator Kompetensi
Kajian Kategori K. Dasar (1) Mengetahui tujuan pembuatan SKPL 3 Dokumen SKPL Mengetahui atribut penulisan SKPL yang baik Mengetahui syarat pembentukan SKPL K. Menengah (2) Menunjukkan dan mendemonstrasikan penulisan kebutuhan rekayasa PL pada dokumen SKPL walaupun belum lengkap K. Mahir (3) Bobot

30 Menghasilkan dokumen SKPL secara lengkap

30

40 100

Pencapaian (Nilai Akhir) Kajian 3 Lama Pengerjaan 2 x 50 menit Jenis Pengerjaan *(bisa dipilih lebih dari 1) Individu Kelompok Mandiri

Terbimbing

PERTANYAAN PENDAHULUAN

Pertanyaan berikut dapat digunakan sebagai Pre-test. a. Apa yang dimaksud dengan Spesifikasi Kebutuhan Perangkat Lunak (SKPL)? b. Apa tujuan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) dan bagaimana cara menuliskan kebutuhan perangkat lunak kedalam SKPL?

3
3.1

RINGKASAN TEORI
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK (SKPL)

Spesifikasi Kebutuhan Perangkat Lunak atau Software Requirements Specification (SRS) adalah sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak. Suatu SKPL harus mencantumkan tentang deskripsi lengkap dari semua antarmuka yang ada dalam sistem yang dapat menghubungkan sistem dengan lingkungannya, mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai.

Versi: RPL/EWD/2012-2/18022013

EXERCISE WORKBOOK
MI1042-2012#12,13 Nama MK : Rekayasa Perangkat Lunak Disampaikan pada minggu ke-12, 13
Program Studi Manajemen Informatika Politeknik Telkom Bandung Jl. Telekomunikasi Terusan Buah Batu, Bandung, 40257

SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi. Suatu SKPL harus dapat menguraikan definisi masalah, dan menguraikan masalah dengan tepat dengan cara yang tepat pula. 3.1.1 Tujuan Pembuatan SKPL Ada beberapa tujuan pembuatan SKPL, dan itu tergantung kepada siapa yang menulisnya. Pertama, SKPL dapat ditulis oleh pemakai potensial (pelanggan) dari sistem, dan kedua oleh pengembang sistem. Untuk kasus pertama, tujuan penulisan SKPL adalah untuk mendefinisikan keinginan yang biasanya dinyatakan dalam bentuk penjelasan umum. Untuk yang kedua, tujuan pembuatan SKPL adalah: a. Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang perangkat lunak. b. Dasar untuk merencanakan dan melaksanakan aktivitas pengujian sistem. c. Acuan untuk melakukan perbaikan dan perubahan perangkat lunak. Sedangkan manfaat dan kegunaan SKPL menurut Witarto[WIT04] dari IEEE, adalah a. Memastikan kesamaan antara kebutuhan untuk pengembangan dengan kebutuhan yang ditulis didalam dokumen. b. Mendefinisikan kerangka kerja bersama untuk proses-proses pengembangan perangkat lunak. c. Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam proses pengembangan perangkat lunak. d. Memperjelas jenis dan isi dokumen. e. Mengenali tugas, tahapan, baseline, aktivitas kaji ulang, dan dokumentasinya. f. Belajar pendekatan praktis yang diterapkan di dunia industri. g. Menghilangkan persoalan-persoalan seperti yang pernah dialami masa lalu. 3.1.2 Syarat Pembentukan SKPL Ada empat syarat yang harus diperhatikan saat pembentukan SKPL, yaitu: a. Mudah diidentifikasi b. Diuraikan dengan jelas, simple, sederhana, dan concise (jelas, tidak ambiguous) c. Bisa divalidasi dan bisa dites (test reliable, test accessable) d. Mampu untuk ditelusuri kembali (tracebility) Hindari hal-hal berikut saat pembentukan SKPL: a. Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas) b. Tindakan unconcistency (seperti menggunakan istilah yang tidak konsisten) c. Ambiguity dalam kata atau kalimat seperti menyatakan keterukuran kebutuhan secara tidak jelas misalkan menggunakan kata-kata :minimal, maksimal, optimal, cepat, user friendly, efisien, fleksible dan lainnya. d. Menuliskan mimpi-mimpi, yaitu hal-hal yang tidak bisa dilakukan Dalam suatu SKPL ada 2 aspek yang harus bisa dilihat: a. Fungsi Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa), sifat perangkat lunak, dan datanya. b. Non-fungsi 1. Dependability 2. Ergonomic 3. Performance 4. Constraint 3.1.3 Atribut Penulisan SKPL Dokumen SKPL yang baik (sempurna) akan ditulis secara: a. Benar (correct)

Versi: RPL/EWD/2012-2/18022013

EXERCISE WORKBOOK
MI1042-2012#12,13 Nama MK : Rekayasa Perangkat Lunak Disampaikan pada minggu ke-12, 13
Program Studi Manajemen Informatika Politeknik Telkom Bandung Jl. Telekomunikasi Terusan Buah Batu, Bandung, 40257

Suatu dokumen SKPL disebut benar jika dan hanya jika setiap kebutuhan yang dinyatakan dalam dokumen merepresentasikan sesuatu yang disyaratkan dari sistem yang akan dibangun. b. Tepat (precise) Berpengaruh pada hasil perancangan dan pembuatan Software Requirements Design (SRD). c. Unambiguouity Setiap permintaan harus punya satu intepretasi, atau hanya ada satu arti dalam satu kalimat. d. Lengkap (complete) Lengkap jika dilihat dari dua sudut pandang: 1. dokumen memuat tabel isi, nomor halaman, nomor gambar, nomor tabel, dan sebagainya. 2. tidak ada bagian yang hilang (to be define) yaitu tulisan yang akan didefinisikan kemudian. e. Bisa diverifikasi (verifiable) Bisa diperiksa dan dicek kebenarannya. Setiap kebutuhan selalu dimulai dengan dokumen yang bisa diperiksa. f. Konsisten Nilai-nilai kebutuhan harus tetap sama baik dalam karakteristik maupun spesifikasi, misalnya diminta A tetap ditulis A. g. Understandable Dapat dimengerti oleh pemrogram, analis sistem atau system engineer. h. Bisa dimodifikasi (modifiedable) Bisa diubah-ubah dan pengubahannya sangat sederhana tetapi tetap konsisten dan lengkap. i. Dapat ditelusuri (traceable) Jika ditelusuri, harus tahu mana bagian yang diubah. j. Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menyelesaikan what tadi). k. Dapat mencakup dan melingkupi seluruh sistem l. Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional. m. Bisa menggambarkan sistem seperti yang dilihat oleh pemakai. n. Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan ketidakkonsistenan. o. Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat. Ada 9 macam orang yang terlibat dalam pembuatan SKPL: a. Pemakai (user) Kelompok orang yang mengoperasikan/menggunakan produk final dari perangkat lunak yang dibuat. b. Client Orang atau perusahaan yang mau membuat sistem (yang menentukan). c. System analyst (system engineer) Kelompok orang yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement. d. Software engineer Kelompok orang yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan system engineer saat mendefinisikan kebutuhan perangkat lunak dam membuat deskripsi perancangannya). e. Programmer Kelompok orang yang menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul. f. Test integration group Kelompok orang yang melakukan tes dan mengintegrasi modul. g. Maintenance group Kelompok orang yang memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan). Versi: RPL/EWD/2012-2/18022013

EXERCISE WORKBOOK
MI1042-2012#12,13 Nama MK : Rekayasa Perangkat Lunak Disampaikan pada minggu ke-12, 13
Program Studi Manajemen Informatika Politeknik Telkom Bandung Jl. Telekomunikasi Terusan Buah Batu, Bandung, 40257

h.

i.

Technical Support Orang-orang yang mengelola (manage) pengembang perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi. Staff dan Clerical Work Kelompok orang yang bertugas mengetik, memasukkan data, membuat dokumen.

Keberhasilan pengembangan perangkat lunak bisa dilihat dari 10 aspek atau titik pandang: a. Ketelitian dari pembuatnya b. Kualitas dari spesifikasi perangkat lunak yang dihasilkan (baik, jika ada sedikit kesalahan) c. Integritas d. Ketelitian e. Proses pembuatan yang mantap f. Mudah dikembangkan g. Jumlah versi tidak banyak h. Ketelitian dari model pengembangan yang digunakan untuk meramal atribut perangkat lunak i. Efektivitas rencana tes dan integrasi j. Tingkat persiapan untuk sistem perawatan (mempersiapkan pencarian bugs) 3.1.4 Tata Letak DOkumen SKPL Tata letak atau format dokumen SKPL baku menurut ANSI/IEEE std 830 1984 dapat dilihat pada Gambar 1.
1. PENDAHULUAN 1.1 Tujuan 1.2 Ruang Lingkup 1.3 Definisi 1.4 Referensi 1.5 Sistematika DESKRIPSI UMUM 2.1 Perspektif 2.2 Kegunaan 2.3 Karakteristik Pengguna 2.4 Batasan-batasan 2.5 Asumsi dan Ketergantungan SPESIFIKASI KEBUTUHAN 3.1 Kebutuhan Fungsional 3.1.1 Pendahuluan 3.1.2 Input 3.1.3 Proses 3.1.4 Output 3.2 Kebutuhan Antarmuka Eksternal 3.2.1 Antarmuka Pengguna 3.2.2 Antarmuka Perangkat Keras 3.2.3 Antarmuka Perangkat Lunak 3.2.4 Antarmuka Komunikasi 3.3 Kebutuhan Performansi 3.4 Kendala Disain 3.4.1 Standard Compliance 3.4.2 Perangkat Keras 3.5 Atribut 3.5.1 Keamanan Sistem 3.5.2 Pemeliharaan 3.6 Kebutuhan Lain 3.6.1 Database 3.6.2 Pengoperasian 3.6.3 Penyesuaian Tempat

2.

3.

Gambar 1 Tata letak dokumen SKPL

Versi: RPL/EWD/2012-2/18022013

EXERCISE WORKBOOK
MI1042-2012#12,13 Nama MK : Rekayasa Perangkat Lunak Disampaikan pada minggu ke-12, 13
Program Studi Manajemen Informatika Politeknik Telkom Bandung Jl. Telekomunikasi Terusan Buah Batu, Bandung, 40257

4
4.1

STUDI KASUS
BAGIAN B (KELOMPOK)
Studi Kasus Tuliskan Spesifikasi Kebutuhan Perangkat Lunak (SKPL) sesuai dengan topik dan studi kasus yang telah disetujui dalam sebuah dokumen SKPL.

No 1

Versi: RPL/EWD/2012-2/18022013