Mengidentifikasi kebutuhan dan Menetapkan persyaratan

Slides:



Advertisements
Presentasi serupa
MODEL PROTOTYPE.
Advertisements

Proses-proses Perangkat Lunak
ANALISIS SISTEM.
Manajemen Proyek Sistem Informasi DAY-4
PEMODELAN ANALISIS Kuliah - 5
PERENCANAAN USAHA Perencanaan dalam bahasa yang sederhana adalah berfikir ke depan. Dalam bisnis/usaha perencanaan adalah berfikir mengenai tujuan, strategi,
Use case Narrative Use case Narrative adalah deskripsi tertulis mengenai peristiwa-peristiwa bisnis dan bagaimana pengguna akan berinteraksi dengan sistem.
Seminar Metode Pembelajaran dan PTK
Perancangan sistem ( berbasis objek )
Konsep & Prinsip Analisis
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
PLANNING A SOFTWARE PROJECT Ir. Waniwatining Astuti, M.T.I.
Analisis Sistem Kuliah M-4.
THE REQUIREMENTS ANALYSIS PHASE
Tehnik Berbasis Relasi Entitas
Pendekatan Penelitian Kuantitatif dan Kualitatif
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
Lecture Note: Mulyati, SE., M.T.I Model Bisnis v [STMIK MDP] Mulyati, SE., M.T.I1.
Lecture Note: Trisnadi Wijaya, SE., S.Kom
Mengidentifikasi kebutuhan dan Menetapkan persyaratan
Proses Dari Desain Interaksi
Pengembangan Solusi Content Management Pertemuan 3.
KONSEP & DEFINISI KEBUTUHAN PL
APA ITU REKAYASA KEBUTUHAN ??
3 Pengembangan Sistem Informasi TINJAUAN UMUM
Skenario Diagram.
Memulai Sebuah Proyek WebApp Pressman 6ED
TRANSFORMASI SISTEM INFORMASI TRADISIONAL KE BASIS KOMPUTER
Perspektif Pemangku Kepentingan
Spesifikasi Perangkat Lunak
ANALISIS DAN PERANCANGAN SISTEM (APS)
ANALISIS KEBUTUHAN.
PriNciples That Guide Practice
REKAYASA PERANGKAT LUNAK
USABILITAS WEB (WEB USABILITY)
Chapter 7. Requirements Negotiation
Metode Penelitian Perkembangan Manusia
Pengumpulan Kebutuhan dan Dokumentasi
Tahap Proses PSSI.
4 Managing Software Requirement Analisis Kebutuhan
RISET & SISTEM INTELIJEN PEMASARAN A. DEFINISI : B. TUJUAN :
Sampling dan Investigasi Hard Data
PENGALAMAN PENGGUNA A. Ridwan Siregar.
FAKULTAS TEKNOLOGI INFORMASI
Jaminan Mutu dalam Kebutuhan Rekayasa
Persyaratan Rekayasa Proses
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Penelitian Survei Penelitian survei merupakan salah satu jenis metode penelitian yang banyak digunakan dalam praktek sehari-hari. Penelitian survei merupakan.
mEnyusun rencana manajemen CAKUPAN PROYEK
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Proses Dari Desain Interaksi
Rekayasa Kebutuhan Software
Analisis Kebutuhan.
Penelitian Kualitatif
Pengembangan Kebutuhan Bisnis
Teknik Mencari Fakta untuk Persyaratan Penemuan
Analisis dan Rancang Pekerjaan
Model problem based learning
PERSPEKTIF SOSIOLOGI DALAM PENELITIAN KUALITATIF
Chapter 05 DESAIN RISET 11/11/2018.
TEKNIK PENGUMPULAN DATA : WAWANCARA DAN OBSERVASI
Proses Rekayasa Kebutuhan
Bab 2 metodologi pengembangan sistem akuntansi
Analisis dan Desain Sistem
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
mEnyusun rencana manajemen CAKUPAN PROYEK
Fathiah, S.T.,M.Eng Universitas Ubudiyah Indonesia
DATA COLLECTION METHODS INTERVIEWS – OBSERVATION - QUESTIONNAIRES.
Transcript presentasi:

Mengidentifikasi kebutuhan dan Menetapkan persyaratan

Salah satu tujuannya adalah untuk memahami sebanyak mungkin tentang pengguna, mereka bekerja, dan konteks kerja itu, sehingga sistem yang sedang dikembangkan dapat mendukung mereka dalam mencapai tujuan, hal ini kita sebut "mengidentifikasi kebutuhan“. Tujuan kedua adalah menghasilkan, dari kebutuhan yang teridentifikasi, membutuhkan dokumen yang membentuk dasar yang kuat ke dalam pemikiran tentang desain.

Bagaimana kita mencapai hal ini Bagaimana kita mencapai hal ini? Pada awal kegiatan persyaratan, banyak mengetahui dan menjelaskan. Pada akhir kegiatan akan memiliki persyaratan yang stabil yang dapat bergerak maju ke dalam aktivitas desain. Di tengah, ada kegiatan yang bersangkutan dengan pengumpulan data, menafsirkan atau menganalisa data, dan kemudian ekstrak beberapa persyaratan dari itu dan kegiatan mempengaruhi satu sama lain sebagai proses iteratsi.

Mengapa mengganggu? Pentingnya mendapatkan suatu yang benar Sebuah artikel yang diterbitkan pada bulan Januari 2000 (Taylor, 2000) menyelidiki penyebab kegagalan proyek TI. Artikel tersebut mengakui bahwa "tidak ada penyebab tunggal kegagalan proyek TI.“ Penelitian yang terlibat mempertanyakan dari 38 profesional TI di Inggris secara rinci. Ketika ditanya tahapan proyek yang menyebabkan kegagalan, disebutkan resposden "definisi persyaratan“ lebih dari fase lainnya. Ketika ditanya tentang penyebab kegagalan, “tidak jelas tujuan dan persyaratannya” dan untuk sukses kritis faktor, "harus jelas persyaratannya”

What are requirements? Persyaratan adalah pernyataan tentang sebuah produk yang dimaksud untuk menentukan apa yang harus dilakukan atau bagaimana harus melakukan. Salah satu tujuan dari kegiatan persyaratan adalah membuat persyaratan yang spesifik, dan jelas. Misalnya, persyaratan untuk sebuah situs web mungkin butuh waktu untuk mendownload halaman selesai kurang dari 5 detik.

Apa yang dibutuhkan ? Berbagai jenis kebutuhan Dalam rekayasa perangkat lunak, ada dua macam persyaratan secara tradisional yang telah diidentifikasi: a. persyaratan fungsional, yang mengatakan sistem yang harus dilakukan, dan b. persyaratan non-fungsional , yang mengatakan kendala yang ada pada sistem dan perkembangannya.

Data gathering Bagaimana cara kita menentukan persyaratan? Pengumpulan data adalah bagian dari kegiatan persyaratan dan juga evaluasi. Tujuan pengumpulan data adalah mengumpulkan data yang cukup, relevan, dan tepat sehingga seperangkat persyaratan yang stabil dapat diproduksi. Pada dasarnya ada teknik dasar untuk mengumpulkan data, tetapi mereka fleksibel dan dapat dikombinasikan dan diperluas dalam berbagai cara; membuat kemungkinan untuk pengumpulan data sangat bervariasi. Teknik-teknik ini adalah kuesioner, wawancara, kelompok fokus dan lokakarya, observasi naturalistik, dan dokumentasi belajar.

Data-gathering techniques a. Kuesioner /Questionnaires adalah pertanyaan yang dirancang untuk memperoleh informasi khusus . Pertanyaan mungkin memerlukan berbagai jenis jawaban: beberapa memerlukan YES atau NO sederhana, yang lain meminta untuk memilih dari serangkaian jawaban atau komentar. Kadang-kadang kuesioner akan dikirim dalam bentuk elektronik dan melalui email atau diposting di situs Web, dan terkadang kuisioner diberikan di atas kertas.

b. Wawancara/ Interviews Wawancara melibatkan seseorang meminta sejumlah pertanyaan. Seringkali wawancara dilakukan dengan tatap muka, tapi tidak harus. Perusahaan menghabiskan dana yang besar untuk melakukan wawancara melalui telepon dengan pelanggan, mencari tahu apa yang mereka suka atau tidak suka tentang layanan mereka. Jika diwawancarai dalam pekerjaan mereka sendiri , orang mungkin akan lebih mudah untuk berbicara tentang kegiatan mereka dengan menunjukkan pada pewawancara apa yang mereka lakukan.

c. Focus groups and workshops Wawancara cenderung menjadi satu-satu, dan hanya memperoleh perspektif seseorang. Sebagai alternatif atau sebagai pembuktian, dapat sangat membuka pikiran untuk mendapatkan kelompok kepentingan bersama untuk mendiskusikan isu-isu dan kebutuhan.

d. Naturalistic observation Hal ini bisa sangat sulit bagi manusia untuk menjelaskan apa yang mereka lakukan atau bahkan menjelaskan secara akurat bagaimana mereka mencapai tugas. Jadi, sangat tidak mungkin bahwa seorang desainer akan mendapatkan cerita yang lengkap dan benar dari stakeholders dengan menggunakan salah satu teknik-teknik yang tercantum di atas. Skenario dan alat peraga lainnya yang digunakan dalam wawancara dan Workshop akan membantu orang meminta untuk lebih akurat dalam deskripsi mereka, tetapi pengamatan memberikan pandangan lebih kaya.

e. Studying documentation Prosedur dan aturan sering ditulis dalam buku pedoman, dan ini merupakan sumber yang baik dari data tentang langkah- langkah yang terlibat dalam suatu kegiatan dan peraturan yang mengatur tugas. Dokumentasi tersebut tidak harus digunakan sebagai sumber, namun, sebagai praktek sehari- hari dan mungkin telah dirancang oleh mereka yang peduli untuk membuat prosedur kerja yang praktis.

* Memilih teknik-teknik Olson dan Moran (1996) menyatakan bahwa memilih antara pengumpulan teknik data bersandar pada dua hal: sifat teknik pengumpulan data itu sendiri dan tugas untuk dikaji. Teknik pengumpulan data berbeda dalam dua hal utama: 1. Jumlah waktu yang mereka ambil dan tingkat detail dan risiko yang terkait dengan temuan. Misalnya, mereka mengklaim bahwa observasi naturalistik akan memakan waktu dua hari upaya dan tiga bulan pelatihan, sementara wawancara hanya memakan waktu satu hari satu bulan usaha dan pelatihan . 2. Pengetahuan analis harus memiliki dasar proses kognitif

Task description Scenarios Use cases Essential use cases

Deskripsi Tugas Deskripsi tugas bisnis telah digunakan dalam pengembangan perangkat lunak untuk bertahun-tahun. Selama tahun 1970-an dan 1980-an, "skenario bisnis" yang umum digunakan sebagai dasar untuk pengujian penerimaan, yaitu tahap pengujian terakhir sebelum pelanggan membayar cicilan biaya final dan "menerima" sistem. Dalam beberapa tahun terakhir lebih, karena dengan penekanan pada melibatkan pengguna awal dalam siklus pengembangan dan sejumlah besar perangkat interaksi baru sekarang sedang dikembangkan, deskripsi tugas digunakan di seluruh pengembangan, dari persyaratan awal kegiatan melalui prototyping, evaluasi, dan pengujian. Akibatnya, lebih banyak waktu dan usaha telah menempatkan ke dalam pemahaman bagaimana cara terbaik untuk struktur dan menggunakannya.

Skenario Skenario adalah "narasi deskripsi informal" (Carroll, 2000). Ini menggambarkan kegiatan manusia atau tugas yang memungkinkan eksplorasi dan diskusi dari konteks, kebutuhan, dan persyaratan. Ini tidak secara eksplisit menjelaskan penggunaan perangkat lunak atau dukungan teknologi lain untuk mencapai suatu tugas. Menggunakan kosa kata dan ungkapan pengguna berarti bahwa skenario yang dapat dipahami oleh stakeholders dan mereka mampu berpartisipasi penuh dalam proses pembangunan. Bahkan, pembangunan skenario oleh stakeholders sering kali merupakan langkah pertama dalam menetapkan persyaratan.

Menggunakan kasus Gunakan kasus dan juga fokus pada tujuan pengguna, namun penekanannya di sini adalah pada sistem interaksi pengguna bukan tugas user itu sendiri. Meskipun fokus secara khusus pada interaksi antara pengguna (disebut''aktor ") dan sistem perangkat lunak. Istilah "skenario" juga digunakan dalam konteks kasus digunakan. Kasus penggunaan dikaitkan dengan aktor, dan merupakan tujuan aktor dalam menggunakan sistem yang digunakan untuk mengungkap suatu kasus. Jadi, misalnya, jika melalui pengumpulan data , sebagian besar pengguna pergi ke perpustakaan mencari katalog untuk memeriksa lokasi buku sebelum pergi ke rak, maka normal untuk kasus penggunaan akan menyertakan urutan kejadian. mungkin urutan lain, yang disebut program alternatif.

Task analysis Hierarchical Task Analysis (HTA) Analisis tugas Hirarkis (HTA) pada mulanya dirancang untuk mengidentifikasikan kebutuhan pelatihan(Annett dan Duncan, 1967). Itu mencakup rincian satu tugas ke dalam sub tasks.

An HTA for borrowing a book from the library 0. In order to borrow a book from the library 1. o to the library 2. fnd the required book 2.1 access library catalog 2.2 access the search screen 2.3 enter search criteria 2.4 identify required book 2.5 note location 3. go to correct shelf and retrieve book 4. take book to checkout counter plan 0: do 1-3-4. If book isn't on the shelf expected, do 2-3-4. plan 2: do 2.1 -2.4-2.5. If book not identified do 2.2-2.3- 2.4-2.5.

A graphical representation of the task analysis for borrowing a book