Buku ini menjelaskan salah satu metode penulisan bagian rumusan masalah, yaitu metode use case.
Apa itu? Ini adalah deskripsi skenario interaksi pengguna dengan sistem (atau dengan bisnis). Dalam hal ini, sistem bertindak sebagai kotak hitam (dan ini memungkinkan untuk membagi tugas desain yang kompleks menjadi merancang interaksi dan memastikan interaksi ini). Pada saat yang sama, standar notasi diperkenalkan, yang menjamin kemudahan membaca, termasuk bagi non-peserta, dan memungkinkan dilakukannya beberapa pemeriksaan kelengkapan dan kepatuhan terhadap tujuan pemangku kepentingan.
Contoh kasus penggunaan
Seperti apa skenarionya, menggunakan contoh otorisasi di situs melalui email:
(Sistem) Masuk ke situs web untuk mengakses akun pribadi Anda. ~~ (permukaan laut)
Konteks: Klien yang tidak sah masuk ke situs sehingga situs mengenalinya dan menampilkan informasi pribadinya: riwayat penelusuran, riwayat pembelian, jumlah poin bonus saat ini, dll., menggunakan email sebagai login.
Tingkat: tujuan pengguna
Karakter utama: klien (pengunjung toko online kami)
Cakupan: Interaksi klien dengan website toko online
Pemangku kepentingan dan kepentingan:
- pemasar ingin jumlah maksimum pengunjung situs diidentifikasi untuk cakupan surat pribadi yang lebih luas,
- pakar keamanan ingin memastikan bahwa tidak ada kasus akses tidak sah ke data pribadi pengunjung, termasuk upaya menebak kata sandi untuk satu akun atau mencari akun dengan kata sandi yang lemah,
- penyerang ingin mendapatkan akses ke bonus korban,
- pesaing ingin meninggalkan ulasan negatif pada produk,
- Botnet ingin mendapatkan basis pelanggan toko dan menggunakan serangan untuk membuat situs tersebut tidak dapat dioperasikan.
Prasyarat: pengunjung tidak boleh diberi izin.
Jaminan minimal: pengunjung akan mengetahui apakah upaya otorisasi berhasil atau tidak.
Jaminan kesuksesan: pengunjung diberi wewenang.
Skenario utama:
- Klien memulai otorisasi.
- Sistem mengonfirmasi bahwa klien tidak diotorisasi dan tidak melebihi jumlah upaya otorisasi yang gagal dari sesi tertentu (mencari kata sandi yang lemah untuk beberapa akun) sesuai dengan “Peraturan Keamanan No. 23”.
- Sistem meningkatkan penghitung jumlah upaya otorisasi.
- Sistem menampilkan formulir otorisasi kepada klien.
- Klien memasukkan email dan kata sandinya.
- Sistem mengonfirmasi keberadaan klien dengan email tersebut di sistem dan bahwa kata sandinya cocok serta jumlah upaya masuk ke akun ini tidak terlampaui sesuai dengan “Peraturan Keamanan No. 24”.
- Sistem mengotorisasi klien, menambahkan riwayat penelusuran dan keranjang sesi ini dengan sesi terakhir akun klien ini.
- Sistem menampilkan pesan otorisasi berhasil dan berpindah ke langkah skrip yang kliennya dihentikan untuk otorisasi. Dalam hal ini, data pada halaman dimuat ulang dengan mempertimbangkan data akun pribadi.
Ekstensi:
2.a. Klien sudah diotorisasi:
2.a.1. Sistem memberi tahu klien tentang fakta otorisasi yang dilakukan sebelumnya dan menawarkan untuk menghentikan skrip atau melanjutkan ke langkah 4, dan jika langkah 6 berhasil diselesaikan, maka langkah 7 dilakukan dengan klarifikasi:
2.a.7. Sistem menonaktifkan klien dengan akun lama, mengotorisasi klien dengan akun baru, sedangkan riwayat penelusuran dan keranjang sesi interaksi ini tetap berada di akun lama dan tidak ditransfer ke akun baru. Selanjutnya, lanjutkan ke langkah 8.
2.b Jumlah upaya otorisasi telah melampaui ambang batas menurut “Peraturan Keamanan No. 23”:
2.b.1 Lanjutkan ke langkah 4, captcha juga ditampilkan pada formulir otorisasi
2.b.6 Sistem mengkonfirmasi entri captcha yang benar
2.b.6.1 Captcha yang dimasukkan salah:
2.b.6.1.1. sistem juga meningkatkan jumlah upaya otorisasi yang gagal untuk akun ini
2.b.6.1.2. sistem menampilkan pesan kegagalan dan kembali ke langkah 2
6.a. Tidak ada akun dengan email ini yang ditemukan:
6.a.1 Sistem menampilkan pesan tentang kegagalan dan menawarkan pilihan untuk melanjutkan ke langkah 2 atau pergi ke skenario “Pendaftaran Pengguna” dan menyimpan email yang dimasukkan,
6.b. Kata sandi akun dengan email ini tidak sesuai dengan yang dimasukkan:
6.b.1 Sistem meningkatkan jumlah upaya login yang gagal ke akun ini.
6.b.2 Sistem menampilkan pesan tentang kegagalan dan menawarkan pilihan untuk masuk ke skenario “Pemulihan Kata Sandi” atau melanjutkan ke langkah 2.
6.c: Penghitung upaya login untuk akun ini telah melampaui ambang batas “Peraturan Keamanan No. 24.”
6.c.1 Sistem menampilkan pesan tentang pemblokiran login akun selama X menit dan melanjutkan ke langkah 2.
Apa yang hebat
Memeriksa kelengkapan dan kepatuhan terhadap tujuan, yaitu, Anda dapat memberikan persyaratan kepada analis lain untuk verifikasi, membuat lebih sedikit kesalahan pada tahap perumusan masalah.
Bekerja dengan sistem kotak hitam memungkinkan Anda memisahkan pengembangan dan koordinasi dengan pelanggan tentang apa yang akan diotomatisasi dari metode implementasi.
Ini adalah bagian dari jalur analis, salah satu bagian utama dari kegunaan. Skenario pengguna menentukan jalur utama pergerakannya, yang sangat mengurangi kebebasan memilih bagi desainer dan pelanggan serta membantu meningkatkan kecepatan pengembangan desain.
Saya sangat senang dengan tempat dalam deskripsi di mana pengecualian untuk setiap langkah interaksi diidentifikasi. Sistem TI yang lengkap harus menyediakan beberapa jenis penanganan pengecualian, ada yang manual, ada yang otomatis (seperti pada contoh di atas).
Pengalaman menunjukkan bahwa penanganan pengecualian yang tidak dipikirkan dengan matang dapat dengan mudah mengubah suatu sistem menjadi sistem yang sangat merepotkan. Saya ingat cerita ketika di masa Soviet, untuk mendapatkan keputusan, Anda harus mendapatkan beberapa persetujuan dari layanan yang berbeda, dan betapa menyakitkannya ketika layanan terakhir mengatakan - tetapi aplikasi Anda menggunakan nama yang salah atau kesalahan lain dalam tanda baca, ulangi semuanya dan koordinasikan ulang semuanya.
Saya sering menjumpai situasi di mana logika operasi suatu sistem, yang tidak memikirkan pengecualian, memerlukan pengerjaan ulang sistem yang signifikan. Oleh karena itu, sebagian besar pekerjaan analis dihabiskan untuk penanganan pengecualian.
Notasi teks, dibandingkan dengan diagram, memungkinkan lebih banyak pengecualian untuk diidentifikasi dan dibahas.
Selain metode dari latihan
Kasus penggunaan bukanlah bagian pernyataan yang diprioritaskan secara independen, tidak seperti cerita pengguna.
Dalam skenario di atas, pertimbangkan pengecualian “6.a. Tidak ada akun dengan email ini yang ditemukan.” dan langkah selanjutnya “6.a.1 Sistem menampilkan pesan kegagalan dan melanjutkan ke langkah 2.” Hal negatif apa yang tertinggal di balik layar? Bagi klien, pengembalian apa pun sama dengan fakta bahwa semua pekerjaan yang dia lakukan dalam memasukkan data dibuang ke tempat pembuangan sampah. (Hanya saja tidak terlihat di skrip!) Apa yang bisa dilakukan? Bangun kembali skrip agar hal ini tidak terjadi. Apakah mungkin melakukan ini? Anda dapat - sebagai contoh, melihat skrip otorisasi Google.
Pengoptimalan skenario
Buku ini membahas tentang formalisasi, tetapi tidak banyak membahas tentang metode untuk mengoptimalkan skenario tersebut.
Namun metode ini dapat diperkuat dengan mengoptimalkan skenario, dan metode formalisasi kasus penggunaan memungkinkan hal ini dilakukan. Secara khusus, Anda perlu memikirkan setiap pengecualian yang terjadi, menentukan penyebabnya, dan membangun kembali skrip untuk menghilangkan pengecualian atau meminimalkan perjalanan pelanggan.
Saat melakukan pemesanan dari toko online, Anda harus memasukkan kota pengiriman. Bisa jadi toko tersebut tidak dapat mengirimkan barang ke kota yang dipilih klien karena tidak mengirimkannya ke sana, karena batasan ukuran, atau karena kurangnya barang di gudang terkait.
Jika kita hanya menggambarkan skenario interaksi pada tahap pendaftaran, kita dapat menulis “beri tahu klien bahwa pengiriman tidak mungkin dan tawarkan untuk mengubah kota atau isi keranjang” (dan banyak analis pemula berhenti di situ). Namun jika kasus seperti itu banyak, maka skenarionya bisa dioptimalkan.
Hal pertama yang perlu Anda lakukan adalah membiarkan Anda memilih hanya kota tempat kami dapat mengirimkan. Kapan melakukan ini? Sebelum memilih produk di website (autodeteksi kota melalui IP dengan klarifikasi).
Kedua, kita hanya perlu memberikan pilihan pada barang yang bisa kita kirimkan ke klien. Kapan melakukan ini? Pada saat pemilihan - pada ubin produk dan kartu produk.
Kedua perubahan ini sangat membantu menghilangkan pengecualian ini.
Persyaratan untuk pengukuran dan metrik
Saat mempertimbangkan tugas meminimalkan penanganan pengecualian, Anda dapat menetapkan tugas pelaporan (kasus penggunaan tidak dijelaskan). Berapa banyak pengecualian yang ada, dalam kasus apa pengecualian tersebut terjadi, ditambah berapa banyak skenario masuk yang berhasil dilewati.
Namun sayang. Pengalaman menunjukkan bahwa persyaratan pelaporan untuk skenario dalam bentuk ini saja tidak cukup; perlu mempertimbangkan persyaratan pelaporan untuk proses yang dijelaskan terutama bukan dalam bentuk kasus penggunaan.
Akses ke Kegunaan
Dalam praktik kami, kami telah memperluas formulir deskripsi kasus penggunaan dengan deskripsi atribut spesifik entitas dan data agar klien dapat mengambil keputusan, yang meningkatkan kegunaan selanjutnya.
Untuk desain kegunaan, kami menambahkan bagian input - menampilkan data.
Dalam skenario dengan otorisasi, ini adalah fakta bahwa klien diberi otorisasi dalam sistem. Jika klien telah melakukan pra-otorisasi, maka tampilkan peringatan tentang pengalihan riwayat navigasi dan keranjang ke akun baru setelah otorisasi berhasil.
Secara umum, ini adalah tampilan informasi yang diperlukan klien sehingga ia dapat mengambil keputusan tentang tindakan selanjutnya sesuai skenario (Anda dapat menanyakan apakah data ini cukup untuk klien, apa lagi yang dibutuhkan, informasi apa yang diperlukan? klien perlu membuat keputusan).
Penting juga untuk membagi informasi yang dimasukkan ke dalam kolom input jika diproses secara terpisah dan dengan pembentukan pengecualian yang berbeda.
Dalam contoh otorisasi klien, jika Anda memisahkan informasi yang dimasukkan menjadi login dan kata sandi, maka ada baiknya mengubah skrip otorisasi untuk menyorot tahapan memasukkan login terpisah dan kata sandi terpisah (dan ini dilakukan di Yandex, Google, tetapi tidak dilakukan di sebagian besar toko online).
Mencapai transformasi data yang diperlukan
Anda juga dapat mengekstrak persyaratan algoritma konversi data dari skrip.
Примеры:
- Untuk mengambil keputusan membeli produk di toko online, klien perlu mengetahui di kartu produk kemungkinan, biaya, waktu pengiriman produk ini ke kotanya (yang dihitung dengan algoritma berdasarkan ketersediaan produk di parameter gudang dan rantai pasokan).
- Saat memasukkan frasa ke dalam baris pencarian, klien diperlihatkan saran pencarian sesuai dengan algoritma (yang dihasilkan oleh algoritma...).
Total
Secara umum, setelah membaca buku ini, sayangnya, tidak jelas bagaimana cara beralih dari seorang analis ke masalah bisnis hingga spesifikasi teknis formal untuk seorang pengembang. Buku ini hanya menceritakan sebagian prosesnya, dengan langkah-langkah masukan yang tidak jelas dan langkah selanjutnya yang tidak jelas. Kasus penggunaan itu sendiri sering kali bukan merupakan pernyataan lengkap bagi pengembang.
Meskipun demikian, ini adalah cara yang sangat baik untuk memformalkan dan memproses skenario interaksi antara objek dan subjek, ketika interaksi tersebut menyebabkan perubahan pada sesuatu pada subjek. Ini adalah salah satu dari sedikit metode penulisan yang memungkinkan persyaratan yang dapat diverifikasi dengan titik pencarian pengecualian eksplisit.
Buku ini wajib dibaca oleh para analis untuk mulai menulis drama yang dapat diuji.
Sumber: www.habr.com