Requirements Engineering
Requirements Engineering
Syarifuddin (14000049)
A. PENDAHLUAN
Setiap proyek sebuah organisasi telah melaksanakan requirements. Tidak peduli apakah itu membangun solusi hardware, mengembangkan solusi perangkat lunak, instalasi jaringan, melindungi data, atau pelatihan para pengguna – untuk proyek untuk sukses, maka mengetahui apa requirements adalah suatu keharusan. requirements ada hampir semua komponen dari suatu proyek atau tugas. Sebagai contoh, sebuah proyek tertentu mungkin memerlukan metode, tingkat keahlian personil, atau format penyampaian.
Proses requirements engineering bukanlah merupakan hal yang mudah. Seorang system analyst, project manager, atau siapapun yang memegang peran project champion harus mengumpulkan berbagai requirement dari para stakeholder, menganalisa requirement tersebut, mengkomunikasikasikannya dengan para programmer, serta menyelesaikan konflik yang terjadi antar berbagai requirement yang ada. Seringkali project champion ini harus bekerja di luar kantor untuk bertemu dengan para stakeholder. Hal ini terutama terjadi pada kasus proyek software development di mana organisasi pengembang berbeda dengan organisasi yang pada akhirnya akan menggunakan perangkat lunak tersebut.
Requirement tidak hanya sebagai syarat untuk klien, tetapi akan diberikan kepada klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim yang mengurus permintaan. Saat sudah ada persetujuan maka tim yang mengurus requirement pun menuliskan kemampuan sistem yang bisa dipahami oleh klien.
Dengan ada nya perkembangan software requirement akan dibentuk suatu nilai yang memberikan timbal balik, antar kebutuhan klien dengan sistem, dimana dari kebutuhan pelanggan akan diproses dan dipastikan akan memberikan keuntungan yang tinggi, dan memberikan pemahaman yang lebih baik kepada pengembang system tentang kebutuhan system.
Pada kenyataannya untuk memahami tentang kebutuhan awal dari pengguna tidaklah mudah karena dalam perjalanan proses pembuatan suatu aplikasi biasanya di tengah perjalanan ternyata mengalami perubahan, padahal mereka sudah mengetujui di awal pembuatan.
B. PEMBAHASAN
1. Arti Requirement
Defini Requirement Menurut (Dorf, 1990) yaitu : Sebuah requirement adalah sebuah kemampuan yang harus dimiliki dari suatu software. Kemampuan ini dapat ditujukan untuk memecahkan suatu permasalahan ataupun diperlukan untuk memenuhi ketentuan-ketentuan tertentu (seperti standar tertentu, keputusan manajemen, ataupun alasan-alasan politis).
Definisi dari requirement (Zave, 1997) adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan tersebut disebut Requirement Engineering.
2. Jenis Requirement
Requirement dapat dibedakan menjadi tiga jenis, yaitu :
- User requirement (kebutuhan pengguna)Pernyataan tentang layanan yang disediakan sistem dan tentang batasanbatasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.
- System requirement (kebutuhan sistem) Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
- Software design specification (spesifikasi rancangan PL) Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.
Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena masing-masing memberi pengertian ke pihak yang berbeda kepentingan.
Secara umum Requirements diklasifikasikan sebagainberikut (IEEE Std 830-1.998):
- Fungsional: Sebuah persyaratan yang menentukan suatu tindakan bahwa suatu sistem harus dapat melakukan, tanpa mempertimbangkan kendala fisik; satu persyaratan yang menentukan input / output perilaku dari sebuah sistem.
- Non-fungsional: Suatu persyaratan bahwa sistem menentukan sifat-sifat, seperti lingkungan dan kendala pelaksanaan, kinerja, platform dependensi, Kemampu-rawatan, diperpanjang, dan kehandalan. Non-fungsional sering diklasifikasikan menjadi beberapa kategori berikut:
- Performance persyaratan. Sebuah persyaratan yang menetapkan karakteristik kinerja bahwa sistem atau komponen sistem harus memiliki, misalnya, maks. CPU-penggunaan, max. footprint memori.
- External interface persyaratan. Sebuah persyaratan yang menentukan perangkat keras, perangkat lunak, atau database elemen dengan mana sistem atau komponen sistem harus antarmuka, atau yang memaparkan kendala di format, waktu atau disebabkan oleh faktor-faktor lain seperti interface.
- Desain kendala. Sebuah persyaratan yang mempengaruhi atau membatasi desain sistem atau komponen sistem, misalnya, persyaratan bahasa, fisik persyaratan perangkat keras, pengembangan perangkat lunak standar, dan standar jaminan kualitas perangkat lunak.
- Kualitas atribut. Sebuah persyaratan yang menentukan sejauh mana suatu sistem memiliki atribut yang mempengaruhi kualitas, misalnya, ketepatan, kehandalan, portabilitas.
Requirements teknik berisi serangkaian kegiatan untuk menemukan, menganalisis, mendokumentasikan, mengesahkan dan memelihara satu set persyaratan untuk suatu sistem (Sommerville & Sawyer, 1997). Requirements teknik ini dibagi menjadi dua kelompok utama kegiatan, pembangunan dan persyaratan persyaratan manajemen. Kebutuhan mencakup pengembangan kegiatan yang berkaitan dengan menemukan, menganalisis, mendokumentasikan dan memvalidasi persyaratan, di mana sebagai persyaratan manajemen mencakup kegiatan yang berkaitan dengan pemeliharaan, yaitu identifikasi, pelacakan dan manajemen perubahan persyaratan.
Secara spesifik, Requirements yang baik harus berisi: Kemampuan, Kondisi (s), dan Kendala (s). Menurut American Oxford Dictionary:
Kemampuan sebagai kata benda didefinisikan sebagai kemampuan melakukan sesuatu; atau kekuasaan atau kemampuan, yaitu, kemampuan membawa yang terbaik dari pada orang-orang atau kemampuan untuk meningkatkan produktivitas; Namun, ketika digunakan dengan kata sifat, kemampuan menggambarkan sebuah fasilitas pada komputer untuk melakukan tugas tertentu, yaitu, “memiliki computer kemampuan grafis.
Kondisi sebagai kata benda didefinisikan sebagai keadaan sesuatu, terutama yang berkaitan dengan penampilan, kualitas, atau urutan kerja, yaitu, kabel-kabel dalam kondisi baik, atau jembatan dalam kondisi yang sangat berbahaya. Seorang kondisi dapat juga menjadi urusan yang harus ada atau dapat diwujudkan sebelum sesuatu yang lain adalah mungkin atau diizinkan, yakni, untuk anggota untuk meminjam uang, tiga kondisi yang harus dipenuhi, atau semua karyawan harus sesuai dengan kebijakan ini sebagai syarat kerja, “atau” Aku akan menerima tawaran Anda dengan satu syarat.
Kendala sebagai kata benda didefinisikan sebagai pembatasan atau pembatasan, yaitu, ketersediaan air adalah kendala utama produksi makanan “atau” kendala waktu tidak memungkinkan untuk melakukan semuanya.
Requirements Engineering membantu seorang Software Engineering untuk memberikan pengertian yang lebih baik terhadap masalah yang hendak di pecahkan, antara lain: pemahaman tentang bisnis yang berpengaruh pada aplikasi, kebutuhan pengguna, dan bagaimana pengguna akan berinteraksi dengan aplikasi.
3. Klasifikasi Requirements
Tujuan Bisnis, Keseluruhan tujuan bisnis dan pedoman untuk proyek disebut tujuan bisnis. Tujuan bisnis membantu menyediakan dasar untuk sebuah proyek dan biasanya diperoleh dari manajemen atau dari perusahaan yang ada dokumen.
Sebagai contoh: Perusahaan XYZ akan meningkatkan penjualan dalam negeri sebesar 50 persen dalam waktu dua tahun.
Kebutuhan Bisnis, Kebutuhan dari stakeholder disebut kebutuhan bisnis. Persyaratan tersebut dapat mencakup bisnis proses sistem harus mendukung; berbagai kendala seperti biaya, sumber daya, jadwal, dan banyak lagi.
Stakeholder Persyaratan, Sebuah stakeholder adalah siapa pun yang memiliki kepentingan vested atau substantif dalam proyek. Persyaratan stakeholder termasuk kebutuhan stakeholder baik internal dan eksternal organisasi. Tantangan dari setiap proyek adalah untuk akurat mengidentifikasi semua pemangku kepentingan, dan untuk memperoleh dan memahami kebutuhan mereka.
Akhir-User Requirements, Kebutuhan dari orang-orang yang akan langsung atau tidak langsung berinteraksi dengan sistem yang disebut kebutuhan pengguna akhir.
Ini mencakup persyaratan untuk dokumentasi dan user interface, yang dapat menjadi sangat rumit dan sering menjadi sumber kesalahan.
Persyaratan Sistem, Persyaratan sistem yang berasal dari menganalisis tujuan bisnis dan kebutuhan stakeholder. Sementara bisnis tujuan dan persyaratan stakeholder ditulis dalam istilah bisnis dan dari dunia nyata perspektif, persyaratan sistem yang lebih ketat, lebih formal, dan ditulis dalam sistem (teknis) terminologi.
Sebagai contoh, sebuah persyaratan pihak mungkin merujuk kepada “Perusahaan XYZ Laporan Penjualan Bulanan”, sedangkan sistem persyaratan mungkin merujuk pada hal yang sama sebagai “XYZMoSalesRept.doc.” Persyaratan sistem tingkat tinggi persyaratan untuk seluruh sistem. Sistem mungkin termasuk subsistem (untuk Misalnya, perangkat keras subsistem, subsistem operasi, subsistem perangkat lunak [atau subsistem], atau subsistem jaringan).
Persyaratan perangkat lunak, Persyaratan perangkat lunak, seperti fungsi yang diperlukan untuk bekerja dalam lingkungan fisik yang keras atau antarmuka pengguna grafis yang diperlukan antara pengguna dan mesin, yang rinci, persyaratan spesifik ditulis untuk sebuah sistem perangkat lunak (atau subsystem).
4. Persyaratan Teknik
Menurut IEEE Software Engineering Body of Knowledge ® (SWEBOK ®), persyaratan teknikmencakup empat proses: pendatangan, analisis, spesifikasi, dan validasi.
Pendatangan
Pendatangan persyaratan berkaitan dengan persyaratan proyek mana berasal dan bagaimana analis dapatmengumpulkan mereka. Ini adalah tahap pertama dalam membangun pemahaman masalah proyek diperlukan untuk memecahkan. Ini pada dasarnya aktivitas manusia, dan adalah di mana para pemangku kepentingan diidentifikasi dan hubungan didirikanantara tim proyek dan pelanggan. Ini adalah berbagai disebut “persyaratan menangkap,” “persyaratan penemuan,”dan “persyaratan akuisisi.”
Salah satu prinsip-prinsip dasar manajemen proyek yang baik adalah bahwa ada komunikasi yang baik antara pengguna dan para perekayasa. Sebelum pembangunan dimulai, persyaratan spesialis dapat membentuk saluran untuk komunikasi. Mereka harus menjadi penengah antara bisnis domain pengguna (dan stakeholder lainnya) dan
dunia teknis para perekayasa
5. Analisis
Analisis adalah proses:
- Mendeteksi dan menyelesaikan konflik antara persyaratan
- Menemukan batas proyek dan bagaimana ia harus berinteraksi dengan lingkungan
- sistem mengelaborasi persyaratan untuk memperoleh persyaratan perangkat lunak
Pandangan tradisional tentang analisis persyaratan bahwa itu telah direduksi menjadi model konseptual menggunakan salah satu sejumlah metode analisis seperti Analisis Terstruktur atau Desain Teknik (SADT). Sementara model konseptual yang penting, analisis meliputi klasifikasi persyaratan untuk membantu menginformasikan trade-off antara persyaratan (persyaratan klasifikasi) dan proses membentuk trade-off ini (persyaratan negosiasi).
Penting untuk menjelaskan dengan tepat persyaratan yang cukup untuk memungkinkan syarat untuk divalidasi, mereka pelaksanaan harus diverifikasi, dan biaya untuk diperkirakan.
Spesifikasi
Untuk sebagian besar teknik profesi, istilah spesifikasi tugas mengacu pada nilai-nilai numerik atau batas ke tujuan desain produk. Khas sistem fisik memiliki jumlah yang relatif kecil nilai-nilai tersebut.
Perangkat lunak khas memiliki banyak persyaratan, dan penekanan dibagi antara melakukan kuantifikasi numerik dan mengelola kompleksitas interaksi di antara banyaknya persyaratan.
Jadi, dalam rekayasa perangkat lunak jargon, “persyaratan perangkat lunak spesifikasi” biasanya mengacu pada produksi sebuah dokumen, atau setara elektronik, yang dapat secara sistematis ditinjau, dievaluasi, dan disetujui. Untuk sistem yang kompleks, terutama yang menyangkut substansial non-komponen perangkat lunak, sebanyak tiga
jenis dokumen yang dihasilkan: konsep operasi, persyaratan sistem, dan perangkat lunak persyaratan.
Validasi
Persyaratan dokumen dapat dikenakan prosedur validasi dan verifikasi. Persyaratan dapat divalidasi untuk memastikan bahwa perangkat lunak insinyur telah memahami persyaratan. Ini adalah juga penting untuk memverifikasi bahwa dokumen persyaratan sesuai dengan standar perusahaan, dan bahwa hal itu dapat dipahami, konsisten, dan lengkap.
Notasi formal menawarkan keuntungan penting perijinan dua sifat terakhir untuk dibuktikan (dalam sebuah Pembatasan akal, setidaknya). Berbagai pemangku kepentingan, termasuk perwakilan dari pelanggan dan pengembang, harus meninjau dokumen.
Dokumen persyaratan tunduk pada manajemen konfigurasi perangkat lunak yang sama dengan yang lain praktek kiriman dari proses siklus hidup perangkat lunak.
Adalah normal secara eksplisit jadwal satu atau lebih poin dalam persyaratan proses dimana persyaratan divalidasi. Tujuannya adalah untuk mengangkat masalah sumber daya sebelum berkomitmen untuk mengatasi persyaratan.
Persyaratan validasi berkaitan dengan proses pemeriksaan dokumen persyaratan untuk memastikanbahwa perangkat lunak mendefinisikan hak (yaitu, perangkat lunak yang mengharapkan para pengguna).
6. Mengapa begitu penting?
Mendesain dan mengembangkan suatu program komputer yang bagus tetapi hanya memecahkan permasalahan yang kurang tepat untuk kebutuhan pengguna tentunya akan percuma, oleh sebab itu pemahaman akan kebutuhan dari pengguna sebelum mendesain dan membuat suatu program komputer adalah penting.
Selain itu Mengapa Requirements Engineering, Untuk menangkap persyaratan tertentu yang harus dicapai untuk membangun perangkat lunak berkualitas tinggi.
Apa saja langkah-langkahnya?
Requirements engineering meliput tujuh langkah yaitu:
1.Inception, sebuah tugas untuk mendefinisikan ruang lingkup dan batasan masalah yang hendak di selesaikan. Pada langkah ini, diperlukan pemahaman dasar tentang masalah, orang yang membutuhkan suatu solusi, pemecahan masalah yang di kehendaki, dan adanya komunikasi yang efektif serta kerjasama antara pelanggan (customer) dan pengembang (developer).
2.Elicitation, merupakan langkah selanjutnya untuk membantu customer mendefinisikan apa yang dibutuhkan dalam pengembangan suatu aplikasi. Beberapa hal yang sering menghambat dalam memahami pendefinisian masalah antara lain:
- Cakupan masalah, batasan masalah yang tidak di definisikan dengan baik.
- Pemahaman masalah, pengguna tidak benar-benar yakin terhadap apa yang dibutuhkan dan memiliki pemahaman yang kurang terhadap kemampuan dan batasan dari lingkungan komputasi mereka.
- Volatilitas dari permasalahan, kebutuhan yang sering berubah-ubah sepanjang waktu.
Dalam rangka untuk mendukung proses kolaborasi, maka panduannya antara lain:
- Adanya pertemuan dan dihadiri dari software engineering dan customer.
- Peraturan untuk persiapan dan persiapan telah ada.
- Adanya agenda yang dibuat secara formal.
- Seorang fasilitator akan mengawasi meeting.
- adanya definisi masalah.
- Tujuan akhir adalah untuk mengidentifikasi masalah, tujuan dari setiap elemen solusi.
3.Elaboration, ketika kebutuhan dasar telah di definisikan dan di modifikasi pada tahapan Inception dan Elicitation, maka langkah berikutnya adalah fokus pada pengembangan suatu model teknis dari suatu fungsi aplikasi, fitur-fitur yang ada dan batasan dari aplikasi yang dikembangkan. Elaboration merupakan suatu model analisis yang terdiri dari beberpa model dan perbaikan tugas. Hasil akhir dari elaboration ini adalah suatu model analisa yang mendefinisikan suatu informasi yang fungsional dan memiliki wilayah perilaku suatu permasalahan.
4.Negotitation, ketika customer mendefinisikan suatu permasalahan, maka negoisasi akan dibutuhkan ketika terjadi perbedaan antar kebutuhan di antara sesama pengguna. Customer, pengguna, dan stakeholder harus mengurutkan prioritas kebutuhannya.
Negotitation merupakan aktifitas pada setiap permulaan iterasi proses piranti lunak.Yang perlu dilakukan antara lain:
1) Identifikasi stakeholder pada sistem ataupun pada sub sistems
2) Penentuan
3) Adanya negoisasi pada stakeholder untuk memenangkan suatu kondisi baik
5.Specification, apa yang menjadi prioritas? yang benar-benar dibutuhkan?, kapan hal tersebut dibutuhkan?, hal ini menyangkut kebutuhan untuk setiap customer akan berbeda-beda. Specification merupakan hasil akhir dari kegiatan requirements engineering.
6.Validation, semua hal tersebut akhirnya perlu di validasi kembali untuk memastikan bahwa developer mengerti permasalahannya dan customer memahami masalah dengan tepat.
7.Management, ini merupakan sekumpulan kegiatan yang membantu tim proyek untuk mengindentifikasi, pengawasan, dan melacak perubahan kebutuhan setiap saat pada tahapan proyek. Kebutuhan manajemen di mulai dengan identifikasi. Setiap kebutuhan memiliki nomor yang unik. Sekali kebutuhan tersebut di identifikasi, maka tabel pelacakan segera dibuatkan.
Persyaratan sebagai dasar dari setiap proyek pembangunan, tim perlu untuk
memahami sifat-sifat “baik” persyaratan. Persyaratan yang terbaik adalah:
• Koreksi (secara teknis dan hukum mungkin)
• Complete (mengekspresikan seluruh ide atau pernyataan)
• Clear (ambigu dan tidak membingungkan)
• Konsisten (tidak bertentangan dengan persyaratan lainnya)
• diverifikasi (dapat ditentukan bahwa sistem memenuhi persyaratan)
• dilacak (unik diidentifikasi dan dilacak)
• Feasible (dapat dicapai dalam biaya dan jadwal)
• Modular (dapat berubah tanpa berlebihan dampak)
• Design-mandiri (tidak menimbulkan solusi spesifik pada desain)
Setiap persyaratan harus terlebih dahulu membentuk kalimat lengkap, yang berisi subjek dan sebuah predikat. Kalimat-kalimat ini harus konsisten menggunakan kata kerja “akan”, “akan” atau “Harus” untuk menunjukkan sifat persyaratan yang wajib, dan “harus” atau “mungkin” untuk menunjukkan bahwa kebutuhan adalah opsional.
Mekanisme yang tepat untuk memahami apa yang diinginkan oleh pelanggan, analisis kebutuhan, menegosiasikan solusi yang masuk akal, memvalidasi spesifikasi dan mengelola perubahan dalam persyaratan.
Persyaratan manajemen:
Persyaratan kemampuan nyata dimana sistem harus memberikan. Ini
karena itu masuk akal untuk mencari tahu apa persyaratan, menulis mereka
bawah dan mengatur mereka, dan mengatur mereka dalam hal bahwa mereka
mengubah. Dengan kata lain kita akan mendefinisikan persyaratan manajemen sebagai sebuah pendekatan sistematis memunculkan, pengorganisasian, dan mengadministrasikan
persyaratan sistem.
7. Analisis Kebutuhan
Sebuah studi kelayakan dan analisis biaya-manfaat dari proses pengembangan produk dapat dilakukan dan ruang lingkup sistem ditentukan. Kebutuhan pelanggan dianalisis dan persyaratan konflik jika ada yang diselesaikan. Analisis persyaratan memastikan bahwa sistem akan memberikan layanan yang pelanggan membutuhkan. Hal ini juga membantu desainer untuk memahami kebutuhan pelanggan.
- Untuk pengembangan lini produk, tahap analisis persyaratan meliputi:
- Identifikasi kesamaan dan variabilities dalam domain
- Identifikasi potensi anggota dan fitur dan model mereka mereka untuk mendapatkan yang lebih baik pemahaman keluarga.
Setelah persyaratan umum dan variabel diidentifikasi, potensi produk dan mereka
fitur yang dipilih. Menggunakan rincian tersebut, kelayakan pengembangan produk tersebut sebagai keluarga dianalisis.
Aspek untuk memilih anggota produk dan fitur
- strategi Perusahaan
- Nasabah prioritas
- Pasar keuntungan
- Kontribusi ke domain dan
- Kompetisi
Analisis pasar adalah teknik yang baik yang dapat memberikan informasi yang berguna tentang arus Dan masa depan kecenderungan pasar dan informasi tentang produk-produk lain di pasar. Berdasarkan hasil analisis ini, produk dan fitur yang dapat dipilih. Setelah produk dan fitur dipilih, mereka harus model. Modeling meningkatkan understandability dan menyederhanakan desain. Tergantung pada lini produk yang sesuai model pendekatan yang digunakan teknik dapat digunakan.
Analisis Kebutuhan – Teknik
- Structured system analysis (SSA)
- Object oriented analysis (OOA)
- Joint application design (JAD)
- Quality function deployment (QFD)
- Participatory design
SSA:
Fungsi-persyaratan yang berorientasi analisis
- Data-flow diagram dapat digunakan untuk mewakili aliran data antara berbagai
tugas-tugas dalam domain sedangkan entitas-hubungan diagram dapat digunakan untuk
mewakili berbagai domain entitas dan hubungan mereka.
- Data kamus dan hubungan badan-model.
OOA:
- Gunakan diagram kasus yang cocok untuk kebutuhan model dari perspektif pengguna
dan tingkat tinggi diagram kelas dapat digunakan untuk kebutuhan model dari perancang
perspektif. Unified Modeling Language (UML) adalah digunakan secara luas berorientasi obyek bahasa pemodelan
- Aliran pesan antara objek dan evaluasi perubahan di negara mereka karena
untuk kejadian-kejadian atau rangsangan lainnya
JAD:
- JAD adalah grup persyaratan sesi analisis dan pendekatan desain yang dikembangkan olehIBM.
- JAD adalah sesi kelompok pendekatan yang melibatkan pengguna dalam sistem desain.
- Semua stakeholder dapat berpartisipasi dalam proses pengambilan keputusan. Kegiatan sepertimendefinisikan persyaratan tingkat tinggi dan melompat-lompat lingkup sistem dapat diperluas untukproduk mengidentifikasi persyaratan dan ciri produk individu dalam keluarga.
- JAD mendefinisikan peranan yang berbeda dari enam peserta yang harus berpartisipasi dalam sesi: sebuahsesi pemimpin atau fasilitator, analis sistem, spesialis, wakil pengguna, sebuahsistem informasi perwakilan dan eksekutif sponsor.
QFD:
QFD adalah suatu pendekatan yang dikembangkan di Jepang untuk menghasilkan produk yang berkualitas dalam industri otomotif di 1986.
• ini berfokus pada kebutuhan pelanggan menerjemahkan ke seluruh persyaratan teknis
proses pengembangan produk.
• Seluruh proses QFD rumah berfokus pada kualitas, yang memetakan kebutuhan pelanggan kefitur produk yang diusulkan.
• Masing-masing tahap pengembangan dapat menggunakan rumah sendiri kualitas. QFD untuk tahap perencanaan digunakan untukpersyaratan analisis.
• Para peserta diminta untuk menilai setiap persyaratan sesuai dengan relevansi fitur tertentu. Selain ini, korelasi antara berbagai fitur-fitur teknis, pelanggan pentingnya setiap persyaratan dan evaluasi pasar dari fitur kompetitif juga dipertimbangkan.
• Berdasarkan analisis subjektif faktor di atas, fitur produk akhir yang dipilih. Jadi
pendekatan yang QFD membantu untuk mengembangkan fitur kualitas yang penting bagi pelanggan
• QFD adalah pendekatan yang baik untuk memilih fitur produk dan untuk membuat desain tingkat tinggi keputusan. Ini mendorong organisasi untuk mempertimbangkan faktor-faktor seperti prioritas pelanggan dan persaingan untuk persyaratan analisis.
Desain partisipatif:
Pendekatan Desain Partisipatoris memungkinkan desainer dan pengguna untuk bekerja bersama. Beberapa teknik termasuk Future Lokakarya, Koperasi Prototyping, Desain mock-up dan Masa Depan Game digunakan dalam Desain Partisipatif Karena pendekatan ini melibatkan pengguna dalam desain sistem, masalah yang dapat terjadi karena kurangnya komunikasi dapat dihindari.
Semua pengguna dapat berpartisipasi dalam proses pengambilan keputusan. Desainer dapat mempelajari lebih lanjut tentang kebutuhan pengguna dengan benar-benar melakukan pekerjaan mereka. Pengguna dapat bekerja dengan desainer untuk belajar tentang desain dan untuk memverifikasi bahwa Desain akan memenuhi semua kebutuhan mereka.
C. KSIMPULAN
Kesuksesan software diukur berdasarkan tingkat kecocokan dengan tujuan awal dari pembuatan software itu sendiri. Software System Requirement Engineering (RE) adalah proses untuk mengetahui tujuan dengan cara mengidentifikasikan stakeholder dan kebutuhan mereka serta mendokumentasikannya ke dalam bentuk yang memungkinkan untuk dianalisis, dikomunikasikan serta diimplementasikan. Requirement engineering adalah cabang dari software engineering yang berfokus terhadap tujuan yang nyata terhadap fungsi serta batasan pada software engineering.
D. DAFTAR PUSTAKA
Frederick,Richard. Introduction to Requirements – The Critical Details That Make or Break a Project.2007. Global Knowledge Training LLC
Waseso, bayu.2008. Requirement Engineering. http://waseso.net/?p=266
Parviainen ,Päivi. Requirements Engineering: Dealing with the Complexity of Sociotechnical Systems Development. VTT Technical Research Centre of Finland, VTT Electronics
