Menulis Requirements dalam User Story

Saat awal mengembangkan software, kita pastinya menuliskan daftar kebutuhan yang ingin dihadirkan dalam software yang akan dibuat. Daftar kebutuhan ini bisa didapatkan dari klien, dari user yang akan menggunakan software, atau bisa juga dari riset pasar mengenai apa sih solusi yang pas untuk menjawab kebutuhan pengguna. Dari daftar kebutuhan tersebut, kita bisa mendetailkan lebih lanjut untuk mendapatkan gambaran mengenai fitur dan fungsi dari software yang akan dibuat. Dalam pengembangan software, deskripsi dari daftar kebutuhan ini disebut requirements.

Ada banyak cara untuk menuliskan requirements. Dalam pengembangan software menggunakan pendekatan Agile, user story adalah yang populer digunakan dalam menuliskan requirements karena kesederhanaannya. Kenapa sederhana? Karena kita tidak perlu menuliskan requirements begitu detail dan komprehensif dalam dokumen yang berlembar-lembar banyaknya dalam menggambarkan fitur dan fungsi dari software. User story memiliki format yang sederhana, mudah dimengerti oleh orang bisnis maupun orang teknis, dan menyenangkan. User story juga mudah dikelola secara efektif selama masa pengembangan software. Dan hal yang terpenting dari user story adalah user story mendorong kolaborasi orang-orang yang terlibat di pengembangan software, baik itu orang bisnis maupun orang teknis, untuk selalu berdiskusi melakukan percakapan mengenai fungsionalitas yang ingin dibuat.

Jadi apa itu user story?

User story adalah deskripsi singkat dan sederhana mengenai fitur atau fungsi dari software, dilihat dari sudut pandang pengguna. User story dituliskan dalam bahasa bisnis dari pengguna software. Deskripsi user story umumnya hanya satu atau dua kalimat. Dalam sehari-hari, user story bisa dituliskan di sticky notes lalu ditempelkan di suatu papan tulis atau dinding sehingga dapat dengan mudah dilihat dan didiskusikan oleh development team.

Ada tiga buah aspek yang menyusun user story, yaitu Card, Conversation, dan Confirmation. Saat menuliskan requirements dalam bentuk user story, kita perlu mengingat tiga aspek tersebut, tiga aspek penting yang tidak terpisahkan satu sama lain.

1. User Story sebagai Card
Sebagai Card, user story menggambarkan deskripsi tertulis mengenai fungsionalitas tertentu dari software. Deskripsinya singkat seolah-olah ditulis di sebuah kertas yang ukurannya relatif kecil, ya kira-kira sebesar kartu nama kita pada umumnya. Dengan tempat yang terbatas seperti itu, itu sudah lebih dari cukup untuk menuliskan requirement dalam bentuk user story.

Berikut ini contoh template dalam menuliskan user story.

Sebagai <jenis pengguna>, saya ingin <melakukan tindakan tertentu atau mendapatkan suatu fungsi tertentu> sehingga <mendapatkan manfaat atau nilai bisnis tertentu>

Untuk mendapatkan gambaran lebih jelas mengenai penggunaan user story, sekarang bayangkan kita sedang terlibat di suatu project untuk membangun sebuah Learning Management System yang menyediakan konten pembelajaran melalui kuliah online terbuka untuk publik. Berikut ini merupakan sedikit dari user story yang kita kumpulkan untuk sistem tersebut berdasarkan template di atas.

ID: 01
Sebagai peserta, saya ingin melihat daftar mata kuliah terbaru yang tersedia sehingga saya bisa mengetahui daftar mata kuliah apa saja yang ditawarkan

ID: 02
Sebagai peserta, saya ingin mencari mata kuliah dengan memasukkan judul atau topik tertentu sehingga saya bisa menemukan kuliah yang mungkin saya minati

ID: 03
Sebagai peserta, saya ingin mendaftarkan diri di suatu mata kuliah tertentu sehingga saya bisa mengikuti pembelajaran di mata kuliah tersebut

ID: 04
Sebagai pengajar, saya ingin mendapatkan daftar peserta kuliah di mata kuliah yang saya ajarkan sehingga saya bisa mengetahui berapa banyak orang yang berminat di topik perkuliahan saya

ID: 05
Sebagai pengajar, saya ingin meng-upload materi pembelajaran sehingga para peserta kuliah bisa belajar dari materi tersebut

Dari lima buah user story di atas, kita bisa menemukan dua jenis pengguna yang berinteraksi dengan sistem, yaitu peserta kuliah dan pengajar. Ketika kita mendalami dan mengumpulkan requirements lebih lanjut, kita bisa menemukan jenis pengguna yang lain dengan karakteristik berbeda yang akan menggunakan sistem yang akan dibuat ini. Setiap jenis pengguna memiliki tindakan-tindakan tertentu dalam mencapai tujuannya saat menggunakan sistem.

Sebagai tambahan, saya menambahkan nomor unik ID pada suatu user story seperti contoh di atas untuk memudahkan pengelolaan user story sekaligus membedakan satu user story dengan yang lainnya. Kita bisa menambahkan informasi lainnya yang umumnya dibutuhkan seperti estimasi ukuran pengerjaan user story dan kategori user story. Untuk estimasi ukuran pengerjaan user story, insya Allah akan dibuat di tulisan yang lain.

2. User Story sebagai Conversation
Jika melihat aspek Card pada user story, kita hanya akan menemukan deskripsi singkat yang bersifat umum mengenai fungsionalitas yang ingin dibuat. Kita tidak mendapatkan banyak detail mengenai fungsionalitas tersebut. Development team pun tidak dapat bekerja hanya dengan mengandalkan deskripsi singkat dari suatu user story.

Melalui aspek Conversation, user story berperan sebagai reminder untuk mengadakan diskusi melakukan percakapan lebih lanjut antara development team dengan klien. Banyak hal detail terkait suatu user story akan didapatkan setelah melakukan percakapan. Kolaborasi intensif antara development team dengan klien melalui percakapan ini dapat memperjelas requirements yang masih samar dan menangkap maksud yang masih tersembunyi.

Untuk lebih jelasnya, saya akan memilih user story dengan ID 02 sebagai contoh.

ID: 02
Sebagai peserta, saya ingin mencari mata kuliah dengan memasukkan judul atau topik tertentu sehingga saya bisa menemukan kuliah yang mungkin saya minati

Saat membaca user story tersebut, kemungkinan akan banyak pertanyaan yang terlintas di pikiran developer seperti:

• Apakah pengguna harus dalam keadaan login terlebih dahulu untuk melakukan pencarian mata kuliah?
• Bedanya judul dan topik itu apa ya?
• Apakah mata kuliah lain dengan topik yang terkait juga ditampilkan dalam hasil pencarian?
• Seberapa banyak hasil pencarian yang ingin ditampilkan?
• Apakah hasil pencarian menampilkan semua kuliah yang pernah ada termasuk yang sudah berlalu, atau yang sedang aktif atau berlangsung saja?
• Hasil pencarian ingin diurutkan berdasarkan apa? Populer, terbaru, atau gimana?
• Informasi apa saja yang ingin ditampilkan di hasil pencarian?

Dengan munculnya banyak pertanyaan tersebut, development team perlu banget berkolaborasi dengan klien melakukan percakapan untuk menjawab pertanyaan-pertanyaan yang muncul dari para developer, dan developer pun akhirnya bisa mendapatkan detail yang cukup untuk implementasi dari hasil percakapan tersebut.

3. User Story sebagai Confirmation
Melalui diskusi dengan klien, development team mendapatkan banyak detail dari suatu user story. Nah, selanjutnya detail tersebut perlu dituliskan secara sederhana untuk melengkapi deskripsi fungsionalitas yang juga sederhana. 🙂

User story sebagai Confirmation menuangkan detail dalam bentuk acceptance test atau sering disebut juga sebagai acceptance criteria. Acceptance test tersebut akan mengkonfirmasikan apa yang sebenarnya dimaksud dengan klien. Beberapa asumsi dan ekspektasi terkait suatu user story dapat dikomunikasikan melalui acceptance test.

Sebagai contoh, mari kita lihat kembali user story di atas dengan ID 02. Saya menuliskan beberapa kemungkinan acceptance test untuk user story tersebut.

ID: 02
Sebagai peserta, saya ingin mencari mata kuliah dengan memasukkan judul atau topik tertentu sehingga saya bisa menemukan kuliah yang mungkin saya minati

Acceptance Test:

• Coba suatu nilai yang cocok dengan judul mata kuliah
• Coba suatu nilai yang cocok dengan topik mata kuliah
• Coba suatu nilai yang cocok dengan judul dan topik mata kuliah
• Coba suatu nilai yang tidak cocok dengan mata kuliah manapun

Acceptance test di atas hanyalah awalan. Development team atau klien bisa menambah test yang baru atau mengurangi test yang sudah ada seiring perjalanan implementasi user story. Penambahan atau pengurangan ini dimungkinkan jika terdapat ekspektasi baru yang hadir karena sebelumnya tidak terpikirkan, atau karena ekspektasi yang sudah dituliskan sebelumnya sudah tidak relevan lagi saat ini.

Dengan acceptance test, masalah komunikasi antara development team dengan klien bisa diminimalisir. Acceptance test menangkap ekspektasi klien lalu menyampaikan ekspektasi tersebut ke developer. Acceptance test ini selanjutnya digunakan oleh developer sebagai panduan dan pengingat dalam implementasi suatu user story yang dipilih. Acceptance test ini pun digunakan oleh developer sebagai kriteria untuk menentukan apakah suatu user story sudah selesai diimplementasikan.

—

Ya, itulah sedikit tentang user story. Saat kamu mau menuliskan requirements ke dalam bentuk user story, jangan lupa tiga buah aspek penting dalam user story, yaitu Card, Conversation, dan Confirmation. Meskipun kita sudah menuliskan deskripsi fitur atau fungsi plus acceptance test-nya, jangan lupa hal terpenting dari user story, yaitu mendorong kolaborasi orang-orang yang terlibat di pengembangan software untuk selalu berdiskusi melakukan percakapan mengenai fungsionalitas yang ingin dibuat.

Tertarik menggunakan user story untuk project kamu? Atau kamu sudah punya pengalaman dengan user story atau ingin bertanya dan diskusi lebih lanjut? Let’s discuss. 😀

Happy learning!

 

Referensi:

1. Cohn, Mike. User Stories Applied: For Agile Software Development. Boston: Pearson Education, 2004. Print.
2. Ambler, Scott W., and Matthew Holitza. Agile for Dummies, IBM Limited Edition. Hoboken: John Wiley & Sons, 2012.