Memperjelas Requirements Dalam Pengembangan Aplikasi
Project requirements are conditions or tasks that must be completed to ensure the success or completion of the project. They provide a clear picture of the work that needs to be done.
Requirement
Jika merujuk pada makna kata, requirement merupakan sesuatu yang dibutuhkan; sesuatu yang wajib ada; kondisi yang dibutuhkan. Tapi yang akan kita bahas adalah suatu kondisi yang harus diselesaikan untuk memastikan keberhasilan sebuah proyek (software). Requirement ini harus menggambarkan secara jelas apa yang dibutuhkan dalam proyek.
Requirement project merupakan hal penting yang harus dilakukan sebelum proyek mulai dikerjakan(coding). Kita ambil contoh, ada seseorang yang meminta kita untuk membuatkan rumah, sebagai seorang developer rumah yang sudah berpengalaman kita berasumsi bahwa rumah itu akan ditempati oleh manusia, tapi dalam kenyataannya rumah yang diinginkan adalah rumah (sangkar) burung. Begitupun dalam bisnis pengembangan aplikasi, hal ini dapat terjadi ketika ada client yang tidak bisa mendefinisikan dengan jelas apa yang mereka butuhkan.
Kerugian yang akan kita dapatkan apabila project sudah terlanjur dikerjakan tetapi requirement masih belum jelas yaitu waktu, tenaga yang sudah kita gunakan untuk development, uang yang sudah terpakai dan segala yang sudah kita lakukan untuk membangun proyek tersebut.
Requirement Gathering
Ada beberapa metode yang dapat kita lakukan untuk memperjelas requirement seperti apa yang dibutuhkan oleh client, antara lain:
Research
Kita bisa melakukan research berdasarkan dokumen yang sudah ada sebelumnya atau bisa juga mengacu pada proyek sejenis yang sudah ada. Dengan mempelajari proyek yang sudah ada, bisa jadi acuan untuk kita menerjemahkan apa yang client inginkan.
Interview
Setelah mengumpulkan bahan untuk divalidasi ke client, kita bisa melakukan interview. Di bagian interview ini kita bisa pakai rumus ask, listen, listen, listen. Disini ditekankan untuk banyak mendengarkan daripada bertanya.
Interview: Ask, Listen, Listen, Listen
Workshop
Workshop dapat berupa brainstorming, focus Group Discussion, Delphi Method, Design Sprint.
Survey
Survey bisa dilakukan kepada siapapun yang punya pengetahuan tentang proyek yang akan dikerjakan. Survey tidak harus dilakukan kepada client tapi bisa kepada siapapun yang ada disekitar kita asalkan memenuhi syarat.
Buat Dokumentasi
Dari beberapa hal yang sudah dilakukan tadi jangan lupa untuk mendokumentasikannya, dokumentasi ini bisa dalam bentuk Mindmap, Flowchart, ataupun System Overview.
Validasi
Jangan lupa untuk memvalidasi catatan yang dibuat tadi ke client atau product owner, untuk memastikan apa yang kita catat sudah sesuai.
Mengukur ketepatan requirement
Salah satu yang bisa dijadikan ukuran dalam menentukan ketepatan requirement adalah metode S.M.A.R.T yang disusun oleh George T. Doran yang didalamnya terdapat:
Specific
Menekankan pentingnya menetapkan target yang spesifik; benar-benar spesifik. Hindari target yang terlalu umum atau kurang mendetail. Target tidak boleh ambigu, harus jelas.
Measurable
Kriteria yang digunakan untuk mengukur besarnya kemajuan yang dibuat dalam mencapai target.
Assignable
Harus jelas siapa yang akan mengerjakan.
Realistic
Target harus realistis dan dapat dicapai. Target tidak boleh dibuat terlalu mudah (untuk performa standar tim), tapi juga tidak boleh terlalu sulit sehingga terasa mustahil untuk dicapai.
Time Based
Pentingnya menepatkan target dengan kerangka waktu, yaitu memberikan deadline pencapaian target. Komitmen kepada deadline akan membantu tim untuk tetap fokus menjalankan pekerjaan untuk memenuhi target tepat waktu, atau bahkan lebih cepat.
Peranan Quality Assurance
Lalu apa kaitannya apa yang sudah dipaparkan di atas dengan seorang Quality Assurance(QA) ? Salah satu peran seorang QA adalah melakukan validasi apakah aplikasi yang dikerjakan oleh engineer sudah sesuai dengan yang diinginkan oleh client atau belum. Tentunya hal ini akan dilakukan setelah development telah selesai (jika dalam sprint, test akan dilakukan jika ada fitur yang sudah selesai). Namun perlu diingat bahwa QA tidak sekedar melakukan pengujian aplikasi secara bebas terus menerus tapi harus mengacu pada apa yang diinginkan client. Untuk mendukung hal itu seorang QA haruslah membuat Acceptance Criteria dan harus mampu memikirkan seperti apa output yang akan dihasilkan nantinya.
Begin with the end in mind
Q&A
Q: Jika mendapat project turunan dan ada fitur yg tidak jelas dan tidak masuk contract harusnya bagaimana ? sedangkan fitur itu jadi stopper di flow yang dikerjakan
A: Ada dua solusi, pertama bikin kontrak baru, kalau itu stopper harus dikomunikasikan dengan client. Kedua, kita bisa ngasih dummy data jika itu berkaitan dengan teknis, sambil di proses secara legalnya, tetapi proses development harus tetep lanjut
Q: Mas saya mau tanya. Apa bedanya system analyst dengan UX Researcher?Kan kalau di UX juga melakukan riset, penentuan fitur, dll yang membentuk sebuah requirement
A: Bedanya System Analyst mendefinisikan yg akan d bangun keseluruhan, UX lebih ke fell aplikasi nya, bisa UI, atau interaksi yang oke seperti apa, UX lebih diangkat dan lebih dalam lagi, lebih detail, mengarah ke interaksi
Q: Jikalau requirement diawal sudah sesuai dengan PO tetapi ditengah jalan PO ternyata tidak sesuai atau meminta ganti dengan yang baru solusinya apa?
A: Melakukan preventif, kembali lagi ke kontrak, jadi di awal harus sudah jelas apa yang mau dikerjain, apalagi kalau project kita sudah ada deadline nya, beda lagi kalau produk, karena kebutuhan dari produk itu dinamis. Tapi goal harus tetap di definisikan, jika terpaksa tidak dilakukan maka harus jelas alasannya kenapa
Q: Cara untuk menjadi system analis pemula, apa yang harus dipelajari?
A: Kemampuan analisa. Mendefinisikan requierement yang jelas, next belajar stack development (berkaitan dengan teknologi) yang bisa di gunakan, technical writing juga akan mendukung untuk menyampaikan analisa yang kita hasilkan. Analisis perancangan System, memang kelihatan tidak berguna, tapi itu sangat dibutuhkan ketika kita menganalisa sebuah project, jadi baik-baik lah kuliah nya. Bersikap critical thinking, sering tanya kenapa memakai metode itu, kemudian analisis cari yg terbaik
Q: Bagaimana cara terbaik pada saat mentukan Requirement? Apakah harus meeting tiap hari. Kalau client sibuk? Soalnya pernah client sering merasa tidak puas
A: Client yg super sibuk, tadi ada beberapa metode, pertama tanya, jika client bingung maka bisa buat form atau kuisioner yg berhubungan dengan project tersebut, sehingga kita bisa dapat feedback kemudian bikin analisis kasar dan validasi ke client lagi.
Q: Requirement reviews yg ideal bagi seorang sistem analis itu seperti apa? Apakah ada chalecklist tablenya sendiri? Atau terpaku dengan document system requirement yang telah dibuat si client?
A: Dokumen FSD, BRD, technical specification, belum ada format yang pakem, bisa berbeda, yang penting bisa menjelaskan kebutuhan, kalau ada desain DB lebih bagus.
Keep in touch:
