SPESIFIKASI KEBUTUHAN

Presentasi berjudul: "SPESIFIKASI KEBUTUHAN"— Transcript presentasi:

1 SPESIFIKASI KEBUTUHAN

2 Bab ini membahas hal-hal berikut :
Apakah itu spesifikasi kebutuhan ? Teknik dan metode spesifikasi kebutuhan? Komponen dalam spesifikasi kebutuhan? Aspek yang menjadi perhatian dalam spesifikasi. Templat dokumen spesifikasi kebutuhan. Perkakas bantu untuk spesifikasi kebutuhan

3 Apakah spesifikasi kebutuhan ??
Spesifikasi kebutuhan merupakan salah satu aktivitas yang dilakukan ketika merekayasa kebutuhan. Spesifikasi kebutuhan merupakan suatu proses memformalisasikan sekumpulan kebutuhan baik fungsional maupun non-fungsional. Ada sebuah standart yang dapat digunakan ketika mengembangkan dokumen spesifikasi, missal (IEEE, 1998), ISO 9126 (ISO, 2008), PSS-05-0 (ESA, 1991) Setiap standart juga mengajukan aspek-aspek kualitas yang harus terpenuhi antara lain : Kemudahan pemeliharaan (maintainability) Kemudahan verifikasi (verifiability) Kelengkapan (completness) Kebenaran (correctness) Konsistensi (consistency) Kejelasan (clarity) Kemudahan pelacakan (traceability) Kemudahan perubahan (modifiability) Kemudahan membaca (readability) Kemudahan penggunaan (ease of use) The Power of PowerPoint

4 IEEE 830 (1998) Tentang Dokumen Spesifikasi Kebutuhan
Manfaat dari dokumentasi kebutuhan adalah sebagai berikut : Dokumen spesifikasi dapat digunakan sebagai dasar persetujuan antara konsumen dan supplier Dokumen spesifikasi dapat mengurangi usaha yang harus dikeluarkan dalam pembangunan perangkat lunak Dokumen spesifikasi dapat digunakan sebagai dasar untuk perkiraan biaya dan jadwal Dokumen spesifikasi dapat digunakan sebagai panduan untuk proses validasi dan verifikasi Dokumen spesifikasi dapat memfasilitasi pergantian/peralihan Dokumen spesifikasi dapat digunakan sebagai dasar untuk pengembangan lebih lanjut The Power of PowerPoint

5 Langkah-langkah membuat dokumen spesifikasi yang baik :
SLIDE 5 Langkah-langkah membuat dokumen spesifikasi yang baik : Sebaiknya gunakanlah template SKPL yang tersedia Berikut ini adalah hal-hal yang harus dipertimbangkan saat memilih template yang akan digunakan : Penjelasan untuk fungsi dari entitas yang dispesifikasikan Penjelasan masukan dan darimana masukan berasal Penjelasan luaran dan kemana luaran pergi Indikasi entity luar yang mungkin digunakan Jika pendekatan fungsional digunakan, informasi tentang precondition harus didefinisikan dengan benar. Dan, post condition juga harus dispesifikasikan setelah fungsi dipanggil Mengidentifikasi sumber dari kebutuhan perangkat lunak Memberikan label yang unik untuk setiap kebutuhan Merekam alur bisnis Menspesifikasikan kualitas yang unik untuk setiap kebutuhan

6 Menyediakan umpan balik kepada konsumen
Masih menurut Sommerville (2007), dokumen spesifikasi yang baik harus memiliki 4 tujuan utama : Menyediakan umpan balik kepada konsumen Memecah permasalahan ke dalam komponen-komponen yang lebih kecil Merupakan masukan untuk tahap spesifikasi rancangan Bisa melakukan pengecekan validasi pendek The Power of PowerPoint

7 Metode pembuatan spesifikasi perangkat lunak
Bahasa Alamiah (Natural Language) Bahasa yang sehari-hari digunakan oleh manusia. Biasanya digunakan untuk berkomunikasi. Structured Natural Language Bahasa alamiah dengan struktur dan batasan tertentu. Digunakan dengan tujuan untuk mendeskripsikan masukan, luaran, dan kebutuhan fungsional system yang akan dibangun. Semi Formal Language The Power of PowerPoint Pendekatan yang menggunakan diagram untuk mendeskripsikan spesifikasi kebutuhan perangkat lunak. Misalnya, diagram Use Case

8 The Power of PowerPoint
Use Case SI Akademik Use Case ATM The Power of PowerPoint

9 Deskripsi setiap kasus penggunaan hendaklah mengandung informasi-informasi berikut ini :
Deskripsi singkat tentang kasus penggunaa tersebut Memberikan gambaran ruang lingkup, masukan, dan luaran yang diharapkan dari kasus penggunaan tersebut. 2. Mendefinisikan alur normal kejadian dari kasus penggunaan Mendifinisikan bagaimana dan kapan suatu kasus penggunaan dimulai dan berakhir (termasuk actor mana yang menginialisasi kasus penggunaan tersebut) 3. Kejadian exsepsional Mendefinisikan setiap kejadian eksepsional yang dapat terjadi yang dapat menyebabkan tujuan dari actor tidak tercapai. 4. Pra-kondisi (Pre-condition) Mendefinisikan kondisi awal yang harus terpenuhi sebelum kasus penggunaa dimulai. 5. Post-kondisi Mendefinisikan kondisi akhir yang harus tercapai setelah kasus penggunaan ini berakhir

10 Dokumen tersebut tersusun seperti berikut :
RUP menyediakan suatu template untuk pendokumentasian deskripsi dari setiap kasus penggunaan Dokumen tersebut tersusun seperti berikut : 1. Deskripsi singkat 2. Alur kejadian 2.1 Alur Dasar 2.2 Alur Alternatif 2.3 Alur Eksepsional 3. Kebutuhan khusus [kebutuhan non-fungsional] <kebutuhan khusus pertama> 4. Pra-Kondisi <Pra-kondisi Pertama> Pasca-kondisi <Pasca-kondisi Pertama> Titik Ekstensi <Nama Titik Ekstensi>

11 Contoh deskripsi alur dasar kasus Pindah Lantai pada Sistem Lift
1. Penumpang menekan tombol permintaan lift 2. Lift sampai ke lantai k, sampai mendekati 2.1 Lift berhenti 2.2 Terdengar bunyi dan lampu berkedip tanda lift sudah sampai 2.3 Pintu lift terbuka 3. Penumpang memasuki lift, kemudian menekan tombol lantai yang dituju 4. Lift bergerak menuju lantai yang dituju 4.1 setelah bebrapa detik pintu tertutup 4.2 lift bergerak menuju lantai yang dituju 5. Lift sampai ke lantai yang dituju Penumpang keluar

12 Identifikasi dan deskripsi sub-kasus yang memiliki relasi ekstensi dengan sub-kasus penggunaan sampai ke lantai Pada sub-kasus penggunaan sampai ke lantai: 2.3a Sepanjang pintu lift terbuka, penumpang dapat menekan tombol tutup pintu 2.3a. 1 Penumpang menekan tombol untuk meminta pintu ditutup 2.3a. 2 Pintu mulai tertutup

13 Identifikasi dan deskripsi eksepsi yang bisa muncul dari kasus penggunaan pindah lantai pada system lift Pada sub-kasus penggunaan bergerak menuju, jika lift sudah kelebihan beban : 4.1a Sistem akan mengeluarkan bunyi tanda lift penuh a. 1 sistem mengeluarkan bunyi a. 2 penumpang keluar dari lift The Power of PowerPoint

14 Metode Formal Ada beberapa alasan mengapa perekekayasa kebutuhan menggunakan metode formal dalamsfesifikasi perangkat lunak : Untuk menghilangkan krancuan dan meningkatkan presisi Untuk menyediakan dasar untuk memprevikasi bahwa suatu spesifikasi kebutuhan sudah terpenuhi Untuk memungkinkan perekayasa melakukan reasoning. Untuk memungkinkan perekayasa menganimasi/mengeksekusi kebutuhan Pada akhirnya kebutuhan harus diformalisasi Terminologi metode formal digunakan untuk merujuk kepada berbagai aktivitas yang berbasis pada representasi matematis dari perangkat lunak yang meliputi : Spesifikasi system formal (Formal System Spesification) Analisis dan pembuktian spesifikasi (Spesification Analysis and Proof) Pengembangan tranformasional (Transformational Development) Verifikasi program (Program Verification) The Power of PowerPoint

15 Spesifikasi formal dalam proses perangkat lunak
Jika dibuat spesifikasi formal dari sebuah perangkat lunak, maka biasanya dilakukan sesudah pengidentifikasian kebutuhan system, sebelum perincian rancangan system. Ada sebuah feedback loop antara perincian spesifikasi kebutuhan dan spesidfikasi formal. Salah satu keuntungan utama dari spesifikasi formal adalah kemampuannya untuk menghindari masalah dan kerancuan dalam kebutuhan system. The Power of PowerPoint

16 Gambar Spesifikasi dan Perancangan
Gambar disamping menunjukkan aktivitas spesifikasi dan perancangan yang bisa dilakukan secara pararel. The Power of PowerPoint

17 Spesifikasi Formal dalam sebuah proses perangkat lunak
Hubungan dari keseluruhan proses pengembangan perangkat lunak yang menggunakan spesifikasi formal, seperti ditunjukkan pada gambar disamping The Power of PowerPoint

18 Spesifikasi bebrbasis model
Ada dua pendekatan mendasar untuk spesifikasi formal yang digunakan untuk menulis spesifikasi rinci untuk indistri system perangkat lunak yaitu : Pendekatan aljabar Sistem dispesifikasikan dalam bentuk operasi-operasi dan hubungan-hubungannya Spesifikasi bebrbasis model Sistem dispesifikasikan dalam bentuk state model yang dibagun dalam konstruksi matematika seperti himpunan dan urutan. Operasi didefinisikan dengan modifikasi terhadap state dari sistem The Power of PowerPoint

19 MAYER’S SEVEN SINS Mayer(1985) menunjukkan sejumlah area spesifikasi kebutuhan dimana seseorang spesifikator cendrung akan melakukan kesalahan. mayer mendiskripsikan secara mendalam kesalahan-kesalahan tersebut dengan cara mengklasifikasikannya kedalam tujuh kategori yang dikenal dengan nama “seven sin” atau “tujuh dosa” The Power of PowerPoint

20 “seven sins” Dosa Deskripsi Noise
Keberadaan suatu elemen dalam sfesifikasi yang mengandung informasi yang tidak relevan dari permasalahan Silence Keberadaan suatu fitur dari permasalahan yang tidak dijelaskan oleh elemen apapun dalam dikumen spesifikasi Overspesification Keberadaan suatu elemen dari permasalahan yang tidak berkorespondensi dengan fitur apapun dalam permasalahan tetapi kepada fitur dari solusi yang mungkin Contradiction Keberadaan dua atau lebih elemn dalam spesifikasi yang mendefinisikan suatu fitur dalam system yang bertentangan satu dengan yang lain Ambiguity Keberadaan suatu elemen dalam spesifikasi yang memungkinkan lebih dari satu interpretasi. Forward reference Keberadaan suatu elemen dalam spesifikasi yang merujuk kepada fitur dari permasalahan yang didefinisikan kemudian dalam spesifikasi. Wishful thinking Keberadaan suatu elemen dalam spesifikasi yang mendefinisikan fitur dari permasalahan yang tidak realistis untuk diimplementasikan. The Power of PowerPoint

21 Kerancuan dalam spesifikasi kebutuhan
Menurut Husain et al (2007), Kerancuan dalam spesifikasi kebutuhan dapat terjadi dalam dua bentuk : Pengertian permukaan ( surface understanding) merupakan karakteristik yang didapat dari fitur-fitur leksikal maupun sintaktikal. Pengertian konseptual (conceptual understanding) merupakan karakteristik yang diturunkan dari semua aspek “seven in” (Mayer, 1985) The Power of PowerPoint

22 IEEE Std SKPL merupakan spesifikasi produk perangkat lunak,program,atau sekumpulan program tertentu yang menampilakan fungsi-fungsi tertentu pada lingkungan yang spesifik. Menurut IEEE Std , sebuah SKPL yang baik harus mengandung informasi-informasi yang tertera pada gambar berikut : The Power of PowerPoint

23 Karakteristik SKPL yang baik
Beberapa karakteristik yang harus dimiliki oleh dokumen skpl, yaitu : Correct. Sebuah SKPL dikatakan benar jika, dan hanya jika, setiap kebutuhan yang dinyatakan di dalamnya adalah kebutuhan yang harus dimiliki oleh perangkat lunak. Unambiguous. Sebuah SKPL tidak rancu jika,dan hanya jika setiap kebutuhan yang dinyatakan di dalamnya hanya memiliki satu penafsiran. Complete. Sebuah SKPL dinyatakan lengkap jika, dan hanya jika, memiliki elemen-elemen sebagai berikut : Semua kebutuhan penting yang berkaitan dengan fungsionalitas, unjuk kerja, batasan rancangan ,atribut,atau antarmuka eksternal. Definisi reaksi-reaksi perangkat lunak terhadap masukan data pada semua situasi yang mungkin terjadi. Label dan acuan terhadap semua gambar ,table, dan diagaram pada SKPL dan definisi dari semua istilah dan satuan ukuran yang digunakan. Semua SKPL yang menggunakan frase ‘ditentukan kemudian’bukanlah skpl yang lengkap Consistent. Sebuah SKPL dinyatakan konsisten jika, dan hanya jika, tidak ada konflik antar kebutuhan yang dinyatakan didalamnya. The Power of PowerPoint

24 Ranked for importance and/or stability
Ranked for importance and/or stability. Sebuah SKPL diperingkatkan berdasarkan kepentingan danstabilitas jika tiap kebutuhan di dalamnya memiliki identifier yang mengindikasikan seberapa penting dan stabil kebutuhan tersebut. Vertifiable. Sebuah kebutuhan tidak dapat diverifikasi bila mengandung pernyataan seperti ‘dapat bekerja dengan baik,’antarmuka yang baik’,’biasanya sering muncul’, dan lain-lain. Modifiable. Sebuah SKPL dapat dimodifikasi jika, dan hanya jika, bila terjadi perubahan maka dapat dilakukan dengan mudah, lengkap dan konsisten tanpa harus mengubah struktur dan gaya tulisan. Traceable. Sebuah SKPL dapat ditelusuri jika dapat diketahui dengan jelas rujukan dari tiap-tiap kebutuhan. The Power of PowerPoint

25 Rational unified process
Rational unified process (RUP) adalah salah satu kerangka kerja untuk melakukan proses rekayasa kebutuhan. Tujuan utama standar RUP untuk memastikan perangkat lunak yang sampai pada pengguna adalah perangkat lunak yang berkualitas baik. The Power of PowerPoint

26 RUP menggambarkan bagaimana cara membangun perangkat lunak dengan efisien, atau biasa disebut dengan pendekatan best practices. Hal-hal yang diatur dalam standar RUP: Mengembangkan perangkat lunak secara iterative Mengelola kebutuhan Menggunakan arsitektur berbasis komponen Memodelkan perangkat lunak secara visual Memverifikasi kualitas dari perangkat lunak dan Mengontrol perubahan dari perangkat lunak. The Power of PowerPoint Fase pada RUP(IBM, 2007)

27 Menangkap user requerment
ESA PSS-05-0, mendiskripsikan standar RPL untuk diaplikasikan pada seluruh perangkat lunak yang diimplementasikan oleh European Space Agency(ESA), baik untuk masyarakat maupun industry pengguna perangkat lunak. Menangkap user requerment Menangkap kebutuhan pengguna adalah sebuah proses untuk mendapatkan informasi tentang kebutuhan pengguna. ESA-05-0 merekomendasikan sebagai berikut : Kebutuhan pengguna harus diklarifikasi melalui pengkritisan dan pengalaman dari perangkat lunak dan prototype terkini. Kesepakatan yang luas harus dibuat melalui wawancara dan survey. Pengetahuan dan Pengalaman dari potential development organitations harus digunakan untuk memebantu memutuskan kelayakan implementasi dan untuk memebuat prototype. The Power of PowerPoint

28 Model kualitas pernyataan kebutuhan (Husain et al,2007)
The Power of PowerPoint

29 Contoh template SKPL The Power of PowerPoint

30 That’s all. Thank you! 