Kebutuhan yang SMART.

Presentasi berjudul: "Kebutuhan yang SMART."— Transcript presentasi:

1 Kebutuhan yang SMART

2 Apa yang di bahas dalam bab ini ?
Apa itu kebutuhan SMART? Kebutuhan yang spesifik Kebutuhan yang terukur Kebutuhan yang dapat di capai Kebutuhan yang dapat direalisasikan Pelacakan kebutuhan Masa kadaluarsa suatu kebutuhan Proritas kebutuhan Pihak-pihak yang berkepentingan

3 Masalah dalam Representasi Kebutuhan
Disebutkan bahwa proses rekayasa kebutuhan merupakan salah satu proses penting dalam daur hidup pengembangan perangkat lunak yang menyita waktu parah analisis sistem. Proses ini merupakan fase yang kritis dalam rangkaian daur hidup pengembangan perangkat lunak, karena pada fase inilah pelanggan dan pengembang menyatukan pemahaman tentang kebutuhan yang dibutuhkan pelanggan dan yang akan dibangun pengembang. Proses rekayasa kebutuhan dikenal sebagai proses yang bersifat iterative dan seringkali dianggap sulit untuk dilakukan dengan baik karena sangat bergantung kepada kemampuan pihak pelanggan dan pengembang dalam mengkomunikasikan (baik lisan maupun tulisan) kebutuhan tersebut.

4 Komunikasi yang baik itu antara lain
Mendengarkan secara selektif Mendeskripsika dan menjelaskan Menangkap konsep-konsep baru dan abstrak dengan cepat dan Menunjukan ketertarikan dan antusias yang murni untuk menyelesaikan permasalahan orang lain

5 Atribut kualitas dari sebuah spesifikasi kebutuhan
Mudah di kelola Dapat diverifikasi Lengkap Benar/Tepat Konsisten Jelas Dapat di lacak Dapat di modifikasi Mudah di baca Mudah di gunakan

6 Specific, Measurable, Attainable, Realizable, and Time-bounded/Tracable (SMART)
SMART pada dasarnya dimaksudkan untuk mengarahkan kita untuk dapat menetapkan tujuan-tujuan yang baik. Yang dimaksud tujuan yang baik adalah spesifik (Specific), terukur (Measurable), dapat di capai (Attaianable), dapat direalisasikan (Realizable), dan memiliki dimensi waktu (Traceable). Tujuan utama membangun kebutuhan SMART bukanlah untuk membuktikan bahwa spesifikasi kebutuhan yang telah ditetapkan sudah benar secara teknis(yaitu bahwa kebutuhan yang dinyatakan adalah benar-benar yang dibutuhkan), tetapi lebih kepada agar spesifikasi kebutuhan tersebut dapat dicek dan diverifikasi kebenarannya dari aspek ekspresi (bukan isi).

7 Spesifik (SPECIFIC) Kriteria ini dasarnya menekankan bahwa setiap kebutuhan haruslah menyebutkan tepat seperti yang dibutuhkan. Penggunaan asumsi dalam mengintepretasikan arti sebuah kalimat kebutuhan hendaklah dihindari.

8 Kriteria Spesifik Jelas Konsisten Sederhana
Sampai pada tingkat rinci yang diperlukan Jika kebutuhan dinyatakan dengan sebuah prototipe program Untuk istilah-istilah yang artinya tidak umum atau memiliki arti yang khusus dalam ruang lingkup sistem yang dikembangkan Hindari penggunaan “akan didefinisikan kemudian” Hendaklah menggunakan kata “rinci”, “informasi”, dan “data” dalam suatu kebutuhan Hendaklah menempatkan kebutuhan individual dalam suatu paragraph tepisah dan tandailah secara individual pula

9 Terukur (MEASURABLE) Dalam konteks rekayasa kebutuhan, karakter measurable atau dapat diukur ini maksudnya adalah apakah suatu kebutuhan mungkin untuk diuji ketika sistem bersangkutan selesai dibangun, suatu cara pembuktian bahwa kebutuhan tersebut telah terpenuhi. Untuk itu, terkadang dalam dokumen spesifikasi kebutuhan kita temui pula mekanisme pengujian untuk setiap kebutuhan yang dispesifikasikan.

10 Dapat di capai (ATTAINABLE)
Suatu kebutuhan dapat dicapai apabila secara fisik sistem tersebut mungkin mencapai kebutuhan bersangkutan dalam kondisi-kondisi yang telah di tetapkan. Ada kebutuhan-kebutuhan yang masih dapat dilakukan karena masih dalam batas-batas kekuatan dan pengetahuan manusia. Akan tetapi, ada kebutuhan-kebutuhan yang mungkin secara teori terdapat solusinya, namun pada prakteknya belum dapat dicapai.

11 Dapat direalisasikan (REALIZABLE)
Dalam konteks rekayasa kebutuhan, suatu kebutuhan dianggap dapat di realisasikan apabila kebutuhan tersebut dapat dicapai atau dibuat berdasarkan pengetahuan kita tentang batasan yang diberlakukan dalam pengembangan sistem maupun proyeksi. Menentukan apakah suatu kebutuhan benar-benar dapat direalisasikan merupakan salah satu hal tersulit dalam membuat kebutuhan yang SMART.

12 Memiliki dimensi waktu/Dapat dilacak (TIME BOUNDED/TRACEABLE)
Suatu kebutuhan hendaklah diselesaikan atau direalisasikan dalam waktu yang telah ditentukan. Dalam hal ini, waktu yang dimaksud adalah waktu yang ditetapkan di dalam Rencana Proyek (Project Plan). Rencana Proyek memang biasanya tidak di buat oleh penulis yang sama dari dokumen SKPL. Rencana Proyek juga seringkali memiliki deviasi disbanding dengan kenyataannya. Untuk itu atribut ini tidak dimaksudkan untuk sesorang analis sistem, dalam hal ini perekayasa kebutuhan, untuk menetapkan tengkat waktu untuk masing-masing kebutuhan dalam spesifikasi kebutuhan. Biasanya, tenggat waktu ini direpresentasikan ke dalam sejumlah tonggak waktu atau milestone, dimana ditetapkan rencana capaian-capain yang merepresentasikan kemajuan dari proyek pengembangan perangkat lunak secara keseluruhan. Jadi pelacak kebutunan hendakalh memungkinkan pelacakan (ke depan dan ke belakang) suatu kebutuhan mulai dari proses konsepsinya terus kepada spesifikasi, perencanaan, implementasi , pengujian dan seterusnya.

13 PRIORITAS Para iterasi awal dari proses rekayasa kebutuhan, mungkin kita dihadapkan kepada sejumlah besar kebutuhan yang berasal dari pemangku kepentingan yang berbeda-beda. Kebutuha-kebutuhan tersebut mungkin memiliki konflik satu dengan yang lain. Selain itu, seperti telah disebutkan sebelumnya, sumbur daya yang tersedia terbatas. Sehingga seringkali tidaklah mungkin semua kebutuhan tersebut direalisasikan. Untuk itu perlu dipilah-pilah kebutuhan mana yang haru d implementasikan, mana yang boleh di implementasikan, dan mana yang tidak perlu diimplementasikan.

14 Spesifikasi kebutuhan yang di kategori kan sebagai Prioritas
Essential Kebutuhan yang esensial (essential) merupakan kebutuhan yang sifatnya harus direalisasikan oleh pengembang. Jikalau kebutuhan ini tidak direalisasikan, maka sistem tidak dapat menjalankan fungsionalitasnya secara utuh. Kebutuhan yang diturunkan langsung dari kasus penggunaan maupun kebutuhan yang muncul untuk merealisasikan suatu kasus penggunaan merupakan kebutuhan yang tergolong essential. Desirable Kebutuhan yang diinginkan (desirable) merupakan kebutuhan yang sifatnya boleh direalisasikan oleh pengembang. Jikalau kebutuhan ini tidak direalisasikan, maka sistem tetap dapat menjalankan fungsionalitasnya secara utuh. Akan tetapi, jika kebutuhan ini direalisasikan, maka sistem akan memiliki nilai tambah (added value). Valueless Jika kebutuhan dengan prioritas ini tidak direalisasikan, maka sistem tetap dapat menjalankan fungsionalitasnya secara utuh. Akan tetapi, jika kebutuhan dengan prioritas ini direalisasikan, maka tetap tidak ada nilai tambah yang diberikan.

15 Pemeringkatan berbasis Nilai dan Resiko
Untuk sistem perangkat lunak yang berskala kecil, dimana kompleksitas (misalnya jumlah kelas pengguna, jumlah komponen atau subsistem, dan jumlah kebutuhan) dari spesifikasi kebutuhan tidaklah besar, seringkali diskuis dengan pemangku kebutuhan berjalan lebih singkat dalam menetapkan peringkat kebutuhan. Akan tetapi, tidak demikian untuk sistem perangkat lunak yang berskala besar dan kompleks. Banyak kepentingan dari kelas-kelas pengguna yang berbeda mendorong munculnya konflik dalam menentukkan kebutuhan mana yang hendak didahulukan disbanding kebutuhan lain, mengingat keterbatasan sumber daya dari perusahanan.

16 Metode untuk membantu perekayasa kebutuhan melakukan pemeringkatan
Metode pertama -> Total Quality Management (TQM) Memberi nilai bagi setiap kebutuhan relative terhadap masing-masing kriteria kesuksesan proyek yang telah diberi bobot. Sekumpulan nilai ini kemudian dikalkulasi untuk menetapkan peringkat prioritas dari masing-masing kebutuhan. Metode kedua -> Quality Function Deployment (QFD) Menghubungkan nilai pelanggan dengan fitur dari produk yang hendak dibangun. Nilai pelanggan mempresentasikan kuantifikasi keuntungan yang didapatkan pelanggan ketika suatu fitur tersebut berhasil di implementasikan. Fitur dari produk merepresentasikan relative biaya yang harus di keluarkan dan relative resiko yang harus di hadapi untuk membangun fitur tersebut.

17 Total Quality Management (TQM)
Konsep Total Quality Management berasal dari tiga kata yaitu total, quality, dan management. Fokus utama dari TQM adalah quality. Quality atau mutu sebagai tercukupinya kebutuhan (conformance to requirement). Kata selanjutnya adalah total, yang dalam bahasa Indonesia sering dipakai kata menyeluruh atau terpadu. Kata total (terpadu) dalam Total Quality Management menegaskan bahwa setiap orang yang berada dalam organisasi harus terlibat dalam upaya peningkatan secara terus menerus. Unsur ketiga dari Total Quality Management, adalah kata management, yang merupakan konsep awal dari TQM itu sendiri. Secara etimologis, kata manajemen berasal dari bahasa Inggris yaitu management yang berarti ketatalaksanaan, tata pimpinan, dan pengelolaan. Hal-hal yang diperhatikan untuk melaksanakan TQM adalah manajemen harian, manajemen kebijakan, manajemen cross-functional, gugus kendali mutu, dan manajemen keselamatan kerja. Filosofi dasar dari TQM adalah “sebagai efek dari kepuasan konsumen, sebuah organisasi dapat mengalami kesuksesan”.

18 Quality Function Deployment (QFD)
QFD adalah sebagai yang sangat baik untuk memastikan bahwa “Voice of the Customer” langsung setiap tahap pengembangan produk dan produksi proses, serta untuk mengintegritasikan semua upaya yang organisasi ke dalam mendapatkan solusi yang baik. Tujuan dari QFD adalah membangun dalam kepuasaan pelanggan pada tahap desain produk yang menarik banyak dari perhatian di beberapa industry. Penerapan metode Quality Function Deployment dalam proses perancangan produk dan jasa diawali dengan pembentukan matriks perencanaan produk atau sering disebut sebagai House of Quality (rumah kualitas) House of Quality (HOQ)

19 Elemen - elemen HOQ WHATS adalah awal masukan bagi HOQ yang di peroleh dari informasi usaha penelitian dan analisis HOWS menandakan cara untuk WHATS Hubungan matrix menunjukkan hubungan antara WHATS dan HOWS, yang menyatakan jumlah setiap CARA mempengaruh setiap APA, dimana mitra dapat disajikan oleh nomor atau symbol-symbol. Dari matrix korelasi WHATS batin menujukkan ketergantungan diantara setiap APA biasanya dinilai dengan 5, 7 atau 9 titik skala Matriks korelasi yang menunjukkan HOWS batin ketergantungan di antara HOWS, dimana interaksi mei ada di dalam HOWS Prioritas dari keseluruhan HOWS menunjukkan pentingnya sintesis dari HOWS.

20 Pihak yang berkepentingan
Ketika membaca dokumen spesifikasi kebutuhan, tidak semua pemangku kepentingan memiliki ketertarikan yang sama terhadap semua aspek dari kebutuhan yang SMART. Di tabel nanti akan di tunjukkan matriks yang memetakan setiap pemangku kepentingan dalam daur hidup pengembangan perangkat lunak dengan setiap aspek dari kebutuhan yang SMART.

21 Tabel Pemetaan antara Pemangku Kepentingan dan kebutuhan yang SMART
Pemilik Sistem  Pengguna Manajer Proyek Staf Kualitas Sistem Analis Perancang Programmer Penguji Penyelia Regulator