Daftar isi kursus
1.
2.
3.
4.
5.
6.
7. < —
8. - -
9.
—
Terkadang tampaknya tugas pengembang sudah jelas! Tapi jangan terlalu mengandalkan akal sehat dalam mengatur masalah. Untuk setiap, bahkan tugas yang paling sederhana, perbedaan mungkin terjadi, karena orang cenderung hidup di dunia ilusi mereka sendiri. Misalnya, di Republik Kuba, diyakini bahwa dinding harus cerah dan beraneka ragam, dan bahkan jika pelanggan meminta untuk mengecat dinding dengan warna putih, pekerja dapat menambahkan bintik-bintik warna, karena "cara ini lebih indah". Hal yang sama berlaku untuk pembangunan.
Dokumen seperti itu sebagai persyaratan membantu mengatasi “dinding kesalahpahaman”. Kehadiran persyaratan memungkinkan Anda untuk membuat ide yang sama tentang apa yang perlu dilakukan dalam produk, apa yang seharusnya menjadi fitur.
Bagaimana persyaratan dibangun
Saat merumuskan persyaratan pengembangan, Anda perlu memahami untuk pengguna mana kami mengembangkan produk. Di sinilah Persona Pengguna berguna (kami telah membicarakannya di sini ). Persona Pengguna adalah apa yang disebut Aktor dalam sistem, dan untuk setiap aktor kami menetapkan seperangkat aturan dan kemampuan.
Misalnya, aktor berikut dapat didefinisikan dalam aplikasi forum web:
- Administrator dapat melakukan segalanya, secara harfiah semuanya - termasuk menetapkan peran (orang) kepada pengguna lain.
- Pengguna biasa hanya dapat meninggalkan pesan.
- Moderator dapat meninggalkan pesan, menghapus pesan orang lain, mencekal pengguna biasa.
Dalam kasus aplikasi panggilan taksi, yang kami ingat secara berkala selama kursus kami, orang tersebut dapat menjadi penumpang, supir taksi, dan operator.
Untuk merumuskan kebutuhan yang memadai, Anda perlu menyusun dokumen yang kami namakan Deskripsi Fitur. Dan untuk ini, Anda perlu menjawab pertanyaan-pertanyaan berikut:
- Untuk apa? Apa tujuannya? Apa keuntungan bisnisnya?
- Mengapa? Apa resikonya? Apa yang akan hilang jika tidak? Apa yang terjadi jika kita melakukannya?
- Apa? Masalah apa yang ingin kita selesaikan? Untuk siapa?
- Bagaimana? Persyaratan fungsional dan kasus penggunaan (urutan tindakan).
Hal ini juga diperlukan untuk menyediakan kosakata istilah-istilah dalam bidang subjek. Ini terutama berlaku untuk akronim tertentu. Misalnya, pengembang mungkin tidak mengetahui semua nama proses dan spesifikasi industri baja atau memasak.
Akhirnya, dokumen perlu membuat bagian "Persetujuan", di mana, di satu sisi, pelanggan fitur (pemangku kepentingan, pelanggan, manajer produk) setuju bahwa deskripsi sesuai dengan apa yang mereka inginkan dari produk. Di sisi lain, pengembang (pemimpin tim, arsitek) akan memastikan bahwa deskripsi tugas dalam persyaratan sudah jelas dan lengkap. Oleh karena itu, semua partisipan dalam proses pengembangan harus mengatakan: “Ya, kami mengerti dokumennya, sekarang sudah bisa”.
Metrik bantu
Saat bekerja dengan persyaratan, metrik bantu membantu mencapai pelaksanaan tugas yang akurat, serta mengurangi waktu yang dihabiskan untuk memeriksa kepatuhan.
- Definisi Selesai adalah deskripsi singkat tentang cara mengetahui apakah suatu fitur berfungsi.
- Persyaratan non-fungsional - persyaratan untuk parameter teknis seperti daya tanggap UI, beban backend, batasan CPU dan RAM. Ini adalah poin yang sangat penting, karena jika Anda tidak menyuarakan persyaratannya, Anda bisa mendapatkan photoshop built-in daripada hanya memilih warna mobil.
- Persyaratan keamanan - enkripsi, penyimpanan data pribadi, dll.
- Kasus Sudut - menguji kasus tepi. Apa yang terjadi jika harga produk 0? Berapa banyak mobil taksi yang bisa dipesan seseorang pada waktu yang sama?
- — , . , , , , — Visa, MasterCard, , .
- . , , , , . , , . , .
- . , “ ”, “ ”.
Persyaratan fungsional dan non-fungsional, kasus penggunaan
Mari kita membahas sedikit tentang persyaratan fungsional dan non-fungsional.
Persyaratan fungsional menjelaskan apa yang perlu dilakukan, mereka mencantumkan tindakan aplikasi sebagai reaksi terhadap tindakan Aktor. Persyaratan ini diterapkan dalam Skenario Penggunaan yang terdaftar.
Persyaratan non-fungsional menangkap kondisi di mana solusi harus tetap efektif, atau kualitas yang harus dimiliki solusi tersebut. Contoh paling umum dari persyaratan non-fungsional adalah:
- skalabilitas,
- keandalan, waktu henti minimum,
- metode dukungan.
Kasus penggunaan juga digunakan untuk menjelaskan persyaratan. Ini adalah elemen utama dari dokumen kami, yang kami persiapkan saat membuat permintaan fitur. Skrip harus memberikan alur lengkap langkah demi langkah tentang apa yang dapat dilakukan pengguna dengan aplikasi Anda.
Skrip kustom biasanya berisi bagian berikut:
Bagian: Konteks
Menjawab pertanyaan: Komponen yang mana? Bagaimana kondisinya?
Contoh: Pengguna tidak diizinkan.
Bagian: Aktor
Menjawab pertanyaan: Siapa?
Contoh: Pengguna biasa.
Bagian: Prekondisi
Menjawab pertanyaan: Apa sajakah fiturnya?
Contoh: Ada undangan untuk menerima status VIP.
Bagian:Tujuan
Menjawab pertanyaan: Apa yang pengguna ingin lakukan / dapatkan?
Contoh: Masuk.
Bagian: Skenario utama
Menjawab pertanyaan: Tindakan apa yang perlu diambil untuk mencapai hasil?
Contoh: Masukkan username dan password Anda, tekan tombol "enter".
Bagian: Skrip Buruk
Menjawab pertanyaan: Apa yang bisa salah, daftar kesalahan, termasuk teks pesan kesalahan untuk pengguna.
Contoh: Tombol tidak ditekan, bahasa tidak berubah, koneksi tidak dapat dibuat melalui protokol https, dan seterusnya ...
Bagian: Layouts
Menjawab pertanyaan: Layout atau prototipe desain UI yang memungkinkan.
Contoh: Gambarlah Figma atau Sketch.
Dalam bentuk yang disederhanakan, skrip kustom mungkin terlihat seperti ini:
Untuk mengungkap
. ( e-mail) ( ). , , : « » « . »
Bagaimana cara membaca Deskripsi Fitur?
Setiap kategori pengguna dapat mengumpulkan informasi yang berguna untuk diri mereka sendiri dari persyaratan. Jadi, sangat penting untuk diingat bahwa persyaratan akan dibaca oleh orang yang berbeda:
- Pengembang - Penting bagi mereka untuk mengetahui mengapa fitur itu dibutuhkan, masalah apa yang dipecahkannya. Agar tidak membuang waktu untuk perbaikan nanti, pengembang perlu memberikan daftar lengkap semua skenario, serta memperhatikan kasus Corner. Jika Anda memberi tahu pengembang tepat waktu tentang apa yang akan kami tambahkan nanti, misalnya, pembayaran dengan kartu MIR, dia akan dapat memperkirakan kemungkinan ini di tingkat arsitektur. Dengan demikian, biaya dapat dikurangi secara signifikan dengan menghindari pengerjaan ulang.
- , QA — , . Corner Cases. , — , .. ( , , ) . , . .
- DevOps Datacenter Operations— , , , . DevOps , , , .
- — , , . , , .
Jika Anda menulis persyaratan pengembangan, pastikan untuk mengajukan pertanyaan - siapa pengguna Anda, apa yang dia lakukan (atau dapat lakukan), dalam kondisi apa dia. Buat diagram perilakunya, itu akan membantu menggambarkan semua aspek persyaratan.
Saat menyusun dokumen, Anda harus sesingkat mungkin dan tidak meninggalkan tempat yang tidak bisa dipahami. Persyaratan akan mencakup beberapa halaman. Ini perlu dibaca oleh banyak orang, dan harus dapat dibaca.
Ikuti aturan sederhana: mulai dengan hal utama dan baru kemudian tambahkan detail. Selain itu, Anda perlu mendapatkan umpan balik dari QA, Pengembang, DevOps, dan pemangku kepentingan lainnya. Kemungkinan besar, Deskripsi Fitur akan memperoleh detail baru setelah komunikasi dengan pemangku kepentingan.
Coba pikirkan skenario yang tidak jelas. Dianjurkan untuk segera menentukan apa yang harus dilakukan aplikasi Anda dalam situasi darurat. Pikirkan tentang komponen eksternal apa yang memengaruhi fitur Anda. Dan ketika semuanya sudah siap, sekali lagi ajukan pertanyaan: "Apa lagi yang dapat Anda uji selain langkah-langkah yang dijelaskan dalam skrip kustom?"
Kesimpulan
Di artikel selanjutnya, kita akan membahas tentang rencana bisnis dan harga untuk produk baru.
Sementara itu, bagikan dalam komentar pengalaman Anda bekerja dengan persyaratan, baik dari sisi manajer maupun pelaksana. Beritahu kami, apakah ada contoh dalam praktik Anda ketika pelanggan fungsional menginginkan satu hal, tetapi pada akhirnya ternyata sangat berbeda karena kesalahpahaman?
→ Rekaman video dari semua perkuliahan tersedia di YouTube
Lecture tentang peta jalan dan persyaratan untuk pengembangan: