Requirement in UX Design

Seorang UX Designer harus mengetahui apa yang diinginkan oleh pengguna. Keinginan ini disebut sebagai requirement atau kebutuhan. Requirement ini merujuk kepada apa yang harus ditambahkan sehingga bisa memenuhi kebutuhan pengguna tadi. Untuk mengetahui requirement ini, UX Designer harus melakukan riset dan mengumpulkan informasi terkait kebutuhan dan saran dari pengguna, yang kemudian digunakan untuk mengembangkan sistem.

Ada beberapa penyebutan terkait aktivitas requirement ini, beberapa contohnya adalah:

– Requirement Gathering

Penyebutan ini merujuk kepada pemikiran bahwa requirement itu layaknya “buah” yang sudah tersebar dan tinggal kita “petik”. Maksudnya, seorang UX Designer harus mencari sendiri apa yang menjadi requirement ini.

– Requirement Enginering

Penyebutan ini merujuk kepada UX Designer berperan dalam menciptakan requirement tadi. Ini merupakan penyebutan yang biasa dipakai.

Setelah seorang UX Designer menentukan requirement, maka selanjutnya akan membuat penjelasan mengenai requirement yang sudah ditentukan agar nantinya pihak developer bisa mengerti apa yang harus dibuat.

Dalam menjelaskan requirement, kita harus menggunakan bahasa yang lugas dan tidak berbelit-belit untuk menghilangkan peluang terjadinya salah paham antara pihak UX Designer dengan Developer. Selain itu, sebisa mungkin kita juga menyertakan prototype, gambar, sketsa, atau media lainnya.

Requirement biasanya dibagi menjadi 2 bagian, yakni requirement yang functional dan non-functional:

– Functional requirement

Adalah requirement apa yang harus dilakukan oleh sistem kita. Singkatnya, functional requirement ini berupa fungsi yang bisa dilakukan oleh sistem kita. Misalnya saja “Mengirim e-mail kepada pelanggan yang baru daftar”, sehingga sistem kita bisa melakukan sesuatu, dalam hal ini mengiriman email, saat beberapa kondisi/syarat terpenuhi, dalam hal ini pelanggan baru medaftar. Contoh lainnya adalah “Sistem mati otomatis saat ada serangan cyber”, sehingga sistem kita akan melakukan shutdown secara otomatis saat kondisi terpenuhi, dalam hal ini adanya cyber attack.

– Non-functional requirement

Adalah kualitas yang harus dimiliki oleh sistem kita. Kualitas ini bisa berupa desain, gambar, estetika sistem, fungsi, performa, UX, dan keamanan. Secara sederhana, non-functional requirement ini mendefiniskan tentang bagaimana sistem memenuhi functional requirement. Contoh non-functional requirement ini adalah “Email harus terkirim tidak lebih dari 12 jam” atau “Setiap klik harus diproses <10 detik”.

Setelah menemukan beberapa requirement yang ingin kita implementasikan, terkadang sulit mewujudkannya sekaligus. Karena itu dilakukanlah semacam “rules” untuk menentukan mana requirement yang menjadi prioritas. Rules ini dinamakan “MoSCoW rules”. Dengan adanya prioritas, maka memudahkan kita untuk memanajemen, terutama waktu, dalam pengerjaan suatu proyek. Dengan melakukan prioritas, maka kita bisa mengerjakan requirement yang terpenting terlebih dahulu dan memikirkan requiremeny yang kurang penting nanti.

Kepanjangan dari MoSCoW ini adalah Must have, Should have, Could have, Want to have but Won’t have this time around. Adapun penjelasannya adalah:

– Must have

Adalah requirement yang penting dan mendesak karena jika tidak ada requirement ini, maka sistem tidak akan bekerja atau dengan kata lain, tidak berguna.

– Should have

Adalah requirement-requirement yang penting tapi tidak mendesak, sehingga tidak ada requirement ini pun sistem masih bisa berjalan. Requirement yang masuk kategori ini bisa ditambahkan jika masih ada waktu luang.

– Could have

Adalah requirement-requirement yang kurang penting, sehingga bisa ditinggalkan dalam development kali ini. Requirement ini tidak terlalu berdampak jika tidak ditambahkan jika dibandingkan dengan 2 kategori sebelumnya

– Want to have but won’t have this time around

Adalah requirement yang bisa ditunda hingga development-development nantinya. Requirement yang masuk ke kategori ini biasanya requirement yang membuat lingkup proyek menyebar kemana-mana. Untuk membuat lingkup tetap terfokus, maka dibuatlah kategori ini.

Dengan melakukan prioritas, maka kita bisa mengerjakan requirement yang terpenting terlebih dahulu dan memikirkan requirement yang kurang penting nanti. Hal ini membuat manajemen waktu kita menjadi lebih mudah dan bisa memastikan pekerjaan bisa selesai tepat waktu dan efisien.

Referensi:

Benyon, D. (2019). Designing User Experience: A guide to HCI, UX and interaction design (4th ed.). Pearson.

ReQtest. (5 April 2019). Why is the difference between functional and Non-functional requirements important. https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/

Volkerdon. What is MoSCow technique. https://www.volkerdon.com/pages/moscow-prioritisation