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
"kebutuhan mengidentifikasi.“.
Tujuan kedua adalah menghasilkan, dari
kebutuhan yang teridentifikasi, satu set stabil
membutuhkan dokumen yang membentuk dasar
yang kuat untuk maju ke dalam pemikiran tentang
desain.
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
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 /Questionnairesadalah 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
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 .
Task
description
•
Scenarios
•
Use
cases
Deskripsi Tugas
Deskripsi tugas bisnis telah digunakan dalam pengembangan perangkat lunak untuk bertahun-tahun. Selama tahun 1970-an d1970-an 1980-1970-an, "skenario bisnis" y1970-ang umum digunak1970-an 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. go 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.
A graphical representation
Tugas
Untuk tugas ini, anda harus:
(1) mengidentifikasikan kebutuhan para pemakai untuk situs
web ini. Anda bisa mengamati orang menggunakan agen tiket,
memikirkan pengalaman milik anda sendiri dari tiket
pembelian, memperhatikan situs‐situs dengan berbicara dengan
teman dan keluarga tentang pengalaman mereka
(2) berdasarkan pada kebutuhan pemakai, pilihan dua profil pemakai berbeda dan menghasilkan satu skenario utama untuk saling berhubungan dengan sistem.
