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