Dalam perencanaan pengembangan perangkat lunak (software development) kita dituntut untuk mampu menyusun requirement dengan tepat dan detail. Tepat dalam menyelesaikan permasalahan pengguna dan detail dalam menyusun alur fitur dengan segala kasus yang terjadi. Dalam artikel ini akan dibahas lebih detail mengenai cara mendetailkan requirement software untuk keperluan bisnis Anda.

Pada sebuah website ecommerce, pengguna tentu membutuhkan “Fitur Login” untuk bisa mengakses menu di dalam website. Penjelasan “Fitur Login” ini saja masih bias jika tidak di detailkan. Login seperti apa? Menggunakan email atau nomor HP? Kalau nomor HP menggunakan teknologi OTP (One Time Password) atau bagaimana? Bisa login menggunakan sosial media kah, apa saja? dan seterusnya. Disitulah kenapa “Fitur Login” mungkin sudah bisa dibilang requirement yang tepat, namun masih belum detail.

Di beberapa perusahaan software hari ini, sudah cukup familiar dengan istilah User Story untuk mendefinisikan requirement. User story sendiri merupakan salah satu tool untuk mendeskripsikan hasil diskusi kita dengan stakeholder, atau dengan kata lain catatan tertulis dari percakapan kita dengan user. Secara teori user story adalah deskripsi singkat fungsionalitas suatu sistem dalam perspektif user (high-level definition).

Dalam format user story, kita dapat mem-breakdown sebuah fungsionalitas dengan kategori “as” (sebagai siapa); “I want” (saya ingin melakukan apa; dan “so that” (alasan melakukan pekerjaan tersebut, atau bisa juga kita berikan “notes” untuk lebih spesifik menjelaskan kolom “I want“. Sebagai contoh:

Teknik menulis dengan format user story ini diharapkan dapat “mengungkap” kebutuhan user dengan tepat dan detail, sehingga proses estimasi pekerjaan atau proyek IT bisa diperkirakan dengan lebih baik. Dengan requirement user story yang berkualitas, estimasi mandays bisa dilakukan lebih presisi termasuk nominal harga atau budget yang harus dikeluarkan untuk pengerjaan software tersebut. Story yang jelas sangat penting dalam mendetailkan requirement software di fase awal. Hal ini juga akan meringankan beban project manager (PM) dan developer untuk menyusun perencanaan development dengan lebih rapi dan terarah, filterisasi feedback dan memudahkan anggota tim untuk memahami proyek secara komprehensif. Disisi lain, bagi designer ataupun software tester, story ini juga akan membantu dalam meningkatkan kualitas aplikasi yang dihasilkan.

Sebelum membuat user story, ada beberapa hal yang dapat disiapkan untuk mendapatkan hasil terbaik, yaitu:

1. Banyak-banyak mencoba atau bereksperimen dengan aplikasi atau website yang ada saat ini. Sebagai contoh, ketika ingin membuat user story mengenai e-commerce, kita dapat melakukan benchmarking ke aplikasi atau website e-commerce lain yang ada saat ini.
2. Pastikan kita mengetahui siapa saja stakeholder yang terlibat dalam sistem dan role atau peran dari setiap user tersebut seperti apa.
3. Kita harus memahami atribut yang diinginkan user sifatnya statis atau dinamis. Statis dalam artian fitur yang dibuat tidak dapat dimodifikasi atau berubah, sedangkan dinamis maksudnya adalah konten yang ada dalam fitur yang ingin dikembangkan bersifat temporary dan sangat mudah berubah sesuai dengan kebutuhan user. Hal ini akan sangat berpengaruh ke penyusunan database, screen, dan tentunya mandays development.
4. Saat requirement dengan klien, tentukan dan pastikan untuk mengetahui aspek yang di-handle oleh sistem dan yang di-handle di luar sistem.

Bagaimana cara mendefinisikan user story ?

Umumnya, sebelum mem-breakdown user story, kita harus memiliki gambaran mengenai topik dan fitur besar yang ingin dibuat. Adapun penjelasannya dapat dilihat dalam gambar berikut:

Features/Topics adalah terminologi terkait sebuah modul fitur yang masih general dan besar. Term ini digunakan untuk mengetahui secara umum fitur-fitur besar yang ada di dalam aplikasi apa saja.

EPICS adalah terminologi terkait dengan definisi fitur yang lebih spesifik yang berfungsi untuk menjelaskan gambaran yang lebih detail dari sebuah topics. Topics terdiri dari beberapa EPICS.

User Stories mengacu pada satuan fitur terkecil yang paling spesifik, dan tidak bisa dibagi lagi. EPICS terdiri dari beberapa user story. User story menjelaskan fungsionalitas dalam level paling kecil dalam sebuah software.

Sebuah story bisa jadi memiliki informasi yang masih bias, sebagai contoh: fitur authentication. Jika kita hanya menuliskan ini saja, maka akan ada banyak sekali informasi yang terlewat dan membuat bingung PM atau developer. Sehingga user story ini pun perlu di detailkan lagi dengan lebih spesifik. Ada tiga cara bagaimana mendetailkan user story:

1. Saat requirement gathering atau brainstorming dengan user. Ingatlah bahwa konsep awal story merupakan catatan percakapan dengan user, oleh karena itu kita harus menggali lebih dalam setiap story dari fitur yang ingin dikembangkan. Kita bisa membuat coret-coretan sendiri di kertas untuk menanyakan apa yang user inginkan dalam satu fitur tertentu. Kita juga dapat mengkonfirmasi kriteria yang dibutuhkan dalam satu story sehingga user dapat memvalidasi story yang kita buat benar dan dapat diimplementasikan.
2. Saat perencanaan iterasi. Sebagai bagian dari proses estimasi, adalah hal yang biasa untuk membuat task list yang dibutuhkan untuk mengimplementasi user story.
3. Saat implementasi. Saat Anda membuat user story, Anda mungkin akan membuat semacam gambaran kasar atas apa yang ingin dikembangkan seperti flowchart atau activity diagram yang merepresentasikan kebutuhan bisnis user.  

Berikut ini adalah contoh list user story dengan beberapa elemen didalamnya: 

Adapun dalam satu story sekali lagi sebaiknya hanya memiliki satu fungsi tertentu saja, dan jika terdapat fungsi yang lain, bisa dimasukkan ke dalam story yang berbeda. Misalkan dalam story “CRUD Article” sebaiknya yang bisa dilakukan disini hanyalah fungsi CRUD (Create, Read, Update, Delete) saja, jangan sampai ada fungsi lain seperti fungsi share article atau comment article. Untuk fungsi share atau comment bisa masuk kedalam story berikutnya.

Kesimpulan

Sebagaimana penjelasan diawal tulisan, bahwa dalam proses mendetailkan requirement software, mendefinisikan story merupakan fase pertama yang menjadi kunci utama dalam proses development. Namun pada prakteknya pasca requirement gathering, umumnya terdapat beberapa penyesuaian atau perubahan story karena memang mendefinisikan story diawal dengan sangat detail dan presisi serta meng –cover seluruh kebutuhan requirement merupakan hal yang cukup sulit. Belum lagi jika terdapat perubahan requirement dari sisi user pada saat pertengahan development karena merasa ada story yang kurang relevan atau belum tercakup dalam requirement gathering. Oleh karena itu, sebaiknya di awal telah diinformasikan kepada user bahwa pertemuan pertama untuk mendetailkan requirement software hanya mampu memberikan gambaran besar dari proyek yang akan dikerjakan, namun dalam pelaksanaannya sangat mungkin terjadi perubahan sesuai dengan kebutuhan klien.