Kebutuhan pengguna dan prototipe alur
INFO9-25
Mengubah kebutuhan menjadi tugas, alur, dan kriteria penerimaan yang dapat diuji.
Bekal awal: Memahami kontrak serta bukti pengguna.
Konteks bab
Revisi naskah pada PDF65 memberi konteks perbaikan berdasarkan pembaca. Prototipe berikut bukan gambaran sistem operasional pondok.
Bacaan dan kasus
7 · Hasil lama yang masih terlihat
Bacaan pendalaman
Kasus dan angka yang dibuat untuk latihan adalah simulasi/rekaan; fakta konsep dan sumber dibedakan dalam uraian.
Prototipe rekaan menampilkan total12, dipinjam5, dan hasil7. Pengguna mengganti total menjadi4 tetapi belum menekan tombol hitung. Hasil7 tetap terlihat tanpa penanda. Ia mengira angka itu sudah sesuai isian baru. Program menghitung benar pada perintah sebelumnya, tetapi tampilan keadaan membuat keputusan pengguna keliru.
Kelompok merancang dua pilihan: menghitung ulang setiap perubahan jika valid, atau menandai hasil lama belum berlaku sampai perintah berikutnya. Mereka membandingkan kejelasan, pesan invalid, dan cara akses. Label “jumlah” juga diganti menjadi “total alat” serta “sedang dipinjam” agar hubungan lebih jelas.
Uji berikut memakai tugas yang sama dan mencatat bantuan. Dua pemeran dapat memperbaiki isian sendiri; satu memerlukan penjelasan. Laporan menyebut perbedaan itu dan tidak mengubahnya menjadi tiga pengguna mandiri. Perbaikan antarmuka dibuktikan oleh alur yang dapat dipahami, bukan hanya warna baru.
Fokus pemeriksaan. Mengapa uji hitungan perlu dilengkapi uji keadaan tampilan?
Fitur perlu alasan
Produk digital dapat mempunyai banyak tombol tanpa membantu tugas utama. Mulai dari siapa pengguna model, apa yang ingin dilakukan, dan hambatan yang muncul. Dalam simulasi, pengguna ingin melihat sisa alat dan memahami mengapa masukan ditolak. Tujuan itu memerlukan label, aturan input, hasil, serta cara memperbaiki data; animasi atau akun baru belum tentu diperlukan.
Alur menjelaskan keadaan
Prototipe kertas dapat memuat layar awal, isian, kesalahan, hasil, dan pengulangan tugas. Gambar panah untuk tindakan pengguna serta keadaan sistem sesudahnya. Jelaskan apa yang terjadi ketika data kosong, valid, atau berubah setelah hasil dihitung. Hasil lama perlu dibedakan dari hasil yang sudah sesuai isian terbaru agar pengguna tidak membaca informasi kedaluwarsa.
Kriteria penerimaan berasal dari tugas
Contoh: pengguna dapat memasukkan12 dan5 lalu melihat7; masukan4 dan6 memberi pesan yang dapat diperbaiki; hasil tidak disebut tersimpan jika hanya ada di layar. Uji dengan tugas, bukan sekadar bertanya “bagus atau tidak?”. Prototipe ialah rancangan yang masih dapat berubah; belum membuktikan aplikasi aman atau siap digunakan nyata.
Telusuri contoh
Apa fitur minimum untuk kalkulator sisa?
- Label total dan dipinjam, validasi, tombol/proses hitung, hasil, serta pesan koreksi.
- Jelaskan status penyimpanan.
- Tambahkan fitur hanya jika kebutuhan serta uji mendukung.
Masukan berubah setelah hasil7 muncul. Apa yang perlu dilakukan tampilan?
- Hitung ulang jika perilaku itu dirancang atau tandai hasil lama belum berlaku.
- Jangan membiarkan pengguna mengira7 berasal dari isian baru.
- Uji transisi ini.
Fitur banyak tidak otomatis bermanfaat; hasil lama yang tidak ditandai dapat menyesatkan setelah masukan berubah.
Latihan mandiri
1 Apa beda kebutuhan dan fitur?
Petunjuk awal
Pisahkan informasi yang diketahui, alasan yang diperlukan, dan batas kesimpulan. Periksa kembali contoh sebelum membuka pembahasan.
Pembahasan · buka setelah mencoba
Kebutuhan tujuan/hambatan pengguna; fitur ialah cara yang dipilih untuk menjawabnya.
2 Sebutkan empat keadaan prototipe.
Petunjuk awal
Pisahkan informasi yang diketahui, alasan yang diperlukan, dan batas kesimpulan. Periksa kembali contoh sebelum membuka pembahasan.
Pembahasan · buka setelah mencoba
Awal, isian, kesalahan, hasil; dapat ditambah proses dan penyimpanan.
3 Mengapa tugas lebih berguna daripada pertanyaan suka?
Petunjuk awal
Pisahkan informasi yang diketahui, alasan yang diperlukan, dan batas kesimpulan. Periksa kembali contoh sebelum membuka pembahasan.
Pembahasan · buka setelah mencoba
Menunjukkan apakah tujuan dapat dikerjakan dan bagian yang menghambat.
4 Apa batas prototipe kertas?
Petunjuk awal
Pisahkan informasi yang diketahui, alasan yang diperlukan, dan batas kesimpulan. Periksa kembali contoh sebelum membuka pembahasan.
Pembahasan · buka setelah mencoba
Menilai alur serta pemahaman awal; belum membuktikan kode, keamanan, atau kinerja sistem nyata.
Perluas pemahamanmu
Hapus satu fitur yang tidak mendukung tugas utama. Jelaskan dampaknya terhadap kesederhanaan, akses, serta bukti yang perlu diuji.
Coba dengan umpan balik
Latihan otomatis membantu pemeriksaan; tuliskan alasan dan langkah untuk membuktikan pemahaman.
1 Kriteria penerimaan yang baik ialah…
Petunjuk awal
Tentukan informasi, konsep dan bukti yang dibutuhkan.
Pembahasan · buka setelah mencoba
D. masukan4 dan6 menghasilkan pesan koreksi yang jelas. Kriteria menyatakan perilaku yang dapat diuji terhadap kebutuhan.
Praktik dan refleksi
Gambar lima kartu layar dan jalankan tugas dengan teman sebagai pengguna model. Catat pilihan yang membingungkan sebelum menjelaskan.
Penanda pribadi di perangkat ini; bukan nilai atau bukti penguasaan.