What Are Requirements? “Requirements didefinisikan : menilai secara seksama kebutuhan-kebutuhan yg harus dipenuhi oleh sebuah sistem……. Harus ditekankan mengapa sistem membutuhkan…didasarkan kondisi sekarang dan kondisi yg diharapkan, dapat berupa operasi-operasi internal dan eksteral…harus ditekankan juga pada fitur apa yg harus disediakan oleh sistem….juga harus dijawab bagaimana sistem dikonstruksi…” [Ross77] Requirements merepresentasikan spesifikasi dari sistem baru Kesepakatan kontrak antara pengembang dan client Harus dibedakan antara kebutuhan fungsional yg menggambarkan fungsi sistem baru dengan kebutuhan non fungsional (atau mutu) yg menentukan batasan global pada sistem

Requirements Functional Menggambarkan kebutuhan proses dari sistem baru; Menggambarkan input ke dalam sistem berupa formulir (kertas) dan dokumen, input dari interaksi dengan seseorang, seperti pesan email, atau dari sistem lainnya. Juga menggambarkan output yg diharapkan dari sistem dalam bentuk cetakan dokumen, layar display dan transfer data ke sistem yg lain Menggambarkan data yg harus ditangani serta dikelola oleh sistem

Non-Functional Requirements Menggambarkan aspek-aspek dari sistem dgn memperhatikan bagaimana memberikan dukungan pada kebutuhan fungsional atau disebut dengan quality requirements Yaitu : - kriteria kinerja seperti tingkat waktu respon updating data pada sistem atau pengambilan data dari sistem - kebutuhan kehandalan - Pertimbangan keamanan, akses yg benar bagi user - standar-standar kerja sistem - kemudahan dalam penggunaan sistem, user mampu menggunakan sistem setelah 2 hari training

Aktivitas dalam Fase Analisis Sistem Pengumpulan data Menentuan Kebutuhan Menyusun Kebutuhan Penilaian Alternatif Rekomendasi kepada Manajemen

deskripsi dari fungsi-fungsi yang akan dilakukan oleh sistem yang baru Kebutuhan Sistem deskripsi dari fungsi-fungsi yang akan dilakukan oleh sistem yang baru Perlu menentukan keperluan secara tepat untuk menghindari: Biaya yg meningkat Terlambat dlm penyelesaian Tidak terpenuhinya kebutuhan pengguna pada sistem yg baru

Jenis Kebutuhan Kebutuhan Fungsional Kebutuhannon Fungsional Kebutuhan Teknis

Teknik Pengumpulan Fakta Pemeriksaan Dokumen Pengamatan Penyelidikan Wawancara Joint Application Requirement – JRP Prototipe

Pemeriksaan Dokumen Sebuah cara di mana SA akan meneliti dan menganalisa dokumen2 tertentu dalam organisasi 3 komponen dokumen: Dokumen yang yg berkaitan dengan organisasi dan fungsi-fungsinya Dokumentasi2 sistem yang berjalan Dokumentasi tentang masalah sistem yg berjalan

Pengamatan (Observasi) Suatu cara di mana SA akan mengamati aktivitas2 yg dilakukan oleh seseorang/ petugas pada sistem yg berjalan Dapat membantu SA memahami operasi2 sistem berjalan Petunjuk: Objektif, sesuai standar operasi Dapatkan kebenaran Pengamatan dilakukan pada berbagai keadaan SA perlu memahami setiap langkah2 dalam aktivitis sistem berjalan

Kelebihan dan Kelemahan Teknik Pengamatan Kelebihan Kelemahan Lebih mudah memahami operasi Fakta-fakta dan informasi yg diamati lebih handal Informasi lain dpt dikumpulkan, seperti karakter pengguna Petugas merasa terganggu Oleh karena ada yg memperhatikan, maka petugas tidak dapat bekerja seperti biasa (gugup)

Penyelidikan Teknik menggunakan formulir atau dokumen tertentu untuk mendapatkan feedback dari responden Sesuai jika sumber informasi tersebar diberbagai tempat (bagian) Beberapa hal yang harus diperhatikan: Bentuk dan jenis persoalan Pengukuran Penyediaan formulir penyelidikan

Panduan Penyediaan Formulir Penyelidikan Penggunaan Bahasa dan Pemilihan kata-kata yg tepat Formulir jawaban Beberapa hal yang perlu dihindari dalam menyusun pertanyaan Pertanyaan yang memandu kepada jawaban Pertanyaan yang bermakna ganda (ambiguous)

Kelebihan dan Kelemahan Teknik Penyelidikan Kelebihan Kelemahan Biaya rendah apabila informasi yang didapatkan dari beberapa orang Responden dapat menjawab sesuai dengan pengetahuannya Informasi yang didapatkan dapat dijadualkan dengan mudah untuk dianalisa Ada responden yang tidak mengembalikan formulir Tidak ada informasi tambahan Harus sesuai dengan jadwal, sehingga tidak ada formulir susulan

Wawancara Teknik di mana SA mendapatkan Informasi dengan cara bertatap muka / interaksi dengan user Ada 2 Kategori : Terstruktur Wawancara dengan pertanyaan yg telah disediakan (disiapkan) Tidak terstruktur Pertanyaan spontan

Panduan Menjalankan Wawancara Menentukan tujuan dari wawancara Pemilihan responden Persiapan wawancara Menyediakan pertanyaan terbuka dan pertanyaan tertutup Menjalankan wawancara Mendokumentasian wawancara Penilaian wawancara

Kelebihan dan Kelemahan Pertanyaan Terbuka pada Teknik wawancara Kelebihan Kelemahan Memberi kebebasan sepenuhnya kepada responden Memberi jawaban yang lebih terperinci Memberi peluang untuk bertanya hal-hal lain untuk meningkatkan pemahaman Jawaban yang diberikan mungkin tidak relevan atau terlalu terperinci Cukup memakan waktu Topik pembicaraan sulit dikendalikan malah cenderung untuk menyimpang

Kelebihan dan Kelemahan Pertanyaan Tertutup dalam Teknik wawancara Kelebihan Kelemahan Wawancara dapat disempurnakan dalam waktu yang singkat Jawaban yang diperoleh tepat dan relevan kepada pertanyaan Topik pembicaraan dapat dikendalikan sehingga tidak menyimpang Mudah menyebabkan responden merasa bosan Membatasi kebebasan responden untuk menyatakan kebutuhannya Tidak ada interaksi di antara responden dengan Pewancara

Joint Application Requirement(JRP) Merupakan metoda terstruktur untuk : Mengumpulkan kebutuhan dan negosiasi Perancangan antar muka Partisipan : End users Eksekutif "Joint" = together participants design product concept. Developer Goal : - Spesifikasi sistem detil dari perspektif bisnis (bukan perspektif teknis)

Pihak yg terlibat dalam JRP Fasilitator Manajemen Pencatat Pemakai Sistem Staf Teknologi Informasi

Results: · Memperpendek waktu yg diperlukan untuk fase requirements American Airlines, Texas Instruments and IBM reported reductions of 15 to 35% in 1985 CNA Insurance Company cut requirement effot by almost 70%. [Ruth 1985]. Normal reduction in requirements efforts 20% to 60%, in total effort 20% to 60% [August 1991] Requirements gathering takes between 10% to 30% of elapsed time on typical project Can expect a total development time reduction of 5 to 15% [Boehm 1981] · Menangkap kebutuhan-kebutuhan lebih baik · Mereduksi perubahan kebutuhan, serta membantu dalam mendapatkan kebutuhan yg benar pada pertama kali · Untuk mendapatkan antarmuka user dgn benar, mutu tinggi (first time) · Komitment top manajemen untuk proses perencanaan PL, memperpendek siklus persetujuan produk · Mengeliminir fitur-fitur yg diragukan, mereduksi ukuran dari produk dan waktu pengembangan · Mereduksi konflik kebutuhan, dan politik yg dapat membuat proyek menjadi timpang

Spesifikasi Kebutuhan Sistem 1.PENDAHULUAN 1.1.Tujuan 1.2.Lingkup Masalah 1.3.Definisi, Akronim, dan Singkatan 1.4.Referensi 1.5.Deskripsi Umum Dokumen 2.DESKRIPSI GLOBAL PERANGKAT LUNAK 2.1. Perspektif Produk 2.2. Fungsi Produk 2.3. Karakteristik Pengguna 2.4. Batasan 2.5. Asumsi 3.DESKRIPSI RINCI KEBUTUHAN 3.1. Kebutuhan Antar Muka Eksternal 3.1.1 Antar Muka Pemakai 3.1.2 Antar Muka Perangkat Keras 3.1.3 Antar Muka Perangkat Lunak 3.2. Kebutuhan Fungsional 4.DESKRIPSI ARSITEKTURAL Lampiran