27 Mei 2009
Rekayasa Kebutuhan (Requirement Engineering)
REQUIREMENT ENGINEERING
1. Definisi dan Pentingnya Rekayasa Kebutuhan.
Rekayasa Kebutuhan (Requirement Engineering) adalah bagian yang tak terpisahkan dari kegiatan rekayasa perangkat lunak. Rekayasa Kebutuhan mempunyai peran yang cukup penting, bahkan akan menentukan keberhasilan dari suatu proyek rekayasa perangkat lunak. Mengenai peran penting rekayasa kebutuhan tersebut telah banyak dikemukakan oleh para pakar.
Requirements engineering merupakan fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan) [Rom-01].
Juga beberapa definisi dan hukum yang dikemukakan pakar mengenai requirement engineering sebagai berikut :
1. Requirement Engineering adalah proses menentukan properti tertentu dari sistem yang harus ada, dengan kata lain, menentukan komponen-komponen sistem. Kebutuhan proses menghasilkan informasi tentang desain yang akan menjadi dasar. Untuk ini, harus mengetahui dimana sebuah sistem akan digunakan, oleh siapa, dan layanan apa yang harus disediakan. Juga penting untuk menentukan kompromi apa yang dapat dilakukan jika terjadi konflik kebutuhan. Kita berasumsi bahwa setiap sistem memiliki kumpulan fungsi yang berguna, yang penting untuk keberhasilan [Alb-2003].
2. Software requirements berisikan kebutuhan dan kendala yang ditempatkan pada produk perangkat lunak yang memberikan kontribusi pada solusi dari beberapa masalah dunia nyata [Kot-2000].
3. Rekayasa Kebutuhan membantu para ahli perangkat lunak untuk lebih memahami masalah dan menyelesaikannya. Ini meliputi kumpulan dari tugas-tugas yang mengarah ke pemahaman tentang apa yang akan menjadi dampak dari bisnis perangkat lunak, apa yang diinginkan oleh pelanggan, dan bagaimana pemakai akan berinteraksi dengan perangkat lunak [Pre-2005].
4. Beberapa hukum dalam requirement engineering yang tercantum dalam SWEBOK edisi 2004 adalah sebagai berikut:
a. Hukum Glass (Robert Glass)
Kekurangan kebutuhan (requirement deficiences) adalah sumber utama dari kegagalan proyek.
Kekurangan kebutuhan menimbulkan masalah di banyak proyek. Kebutuhan yang ditentukan mungkin salah, atau tidak cukup perhatian yang diberikan pada definisi kebutuhan. Menetapkan tujuan dengan benar untuk setiap proyek adalah persyaratan tugas. Meskipun ada proyek dipahami dengan baik, ditentukan, dan kebutuhan stabil, lebih sering bukan ini masalahnya. Lebih khusus tidak lengkap atau kesalahan definisi kebutuhan, definisi terutama jika dilakukan oleh pihak ketiga untuk pelanggan dan pengembang.
Teori: Menentukan kebutuhan yang tepat merupakan masalah berat. Alasan utama untuk ini adalah kebutuhan yang berbeda dari berbagai kelompok pengguna, konflik kepentingan antara orang atau kelompok yang terlibat, dan kesulitan dari konflik antara prioritas kebutuhan. Definisi kebutuhan adalah proses belajar dan negosiasi. Kedua para pengembang dan pengguna belajar sambil menerapkan atau menggunakan sistem. Pengetahuan dari setiap orang yang terlibat sangat terbatas. Orang tidak tahu semuanya dan banyak lupa. Berbagi pengetahuan tidak terjadi dengan sendirinya. Masalah-masalah yang melekat dan tidak akan hilang sebagai kelangsungan teknologi.
b. Hukum Boehm pertama
Kesalahan yang paling sering selama menentukan kebutuhan (requirements) adalah kegiatan desain yang lebih mahal.
Studi ini berkaitan dengan analisis kesalahan yang dibuat oleh pengembang. Ketika menganalisis kesalahan, pertanyaan pertama adalah: "Di mana dalam proses pembangunan kesalahan ini telah dibuat?" Ini mengarah ke salah satu pekerjaan dari kesalahan ke setiap tahapan atau kegiatan di Lifecycle. Hukum ini menggabungkan dua observasi yang erat kaitannya.
Gambar 1. Cost of problems per phase
Teori: Manusia biasanya mempunyai masalah jika banyak situasi perlu pemikiran pada saat yang bersamaan. Kita cenderung untuk berpikir baris utamanya saja, dan melupakan kasus khusus. Bahkan jika pikiran manusia mendukung pemrosesan paralel, ini tidak berarti bahwa perbedaan berbagai unit investigasi di berbagai penjuru. Kami memiliki arti yang tidak melekat atau mekanisme untuk mencari domain secara mendalam (kecuali dapat diwakili secara visual). Kesalahan dari kelalaian lebih sering daripada kesalah-pahaman.
a. Hukum Boehm kedua
Prototyping (secara signifikan) mengurangi kebutuhan dan kesalahan desain, terutama untuk user interface.
Hukum ini menempatkan penekanan pada pengurangan kesalahan. Pengurangan kesalahan membawa penurunan biaya juga. Jumlah pengurangan tidak terukur, namun, menjadi signifikan, setidaknya 20-30 persen harus terjadi. Hal ini berlaku untuk semua hukum, meskipun kata 'signifikan' akan diabaikan. Perubahan dalam kisaran 5-20 persen karena perbedaan pengukuran atau setup, atau dapat disebabkan oleh gangguan tak terkendalikan.
Gambar 2. Prototypes in the system lifecycle
Teori: Prototip memberikan pandangan dari sistem yang tampak nyata bagi pengguna. Berbeda dengan representasi desain lainnya, prototip tidak bergantung pada kekuatan imajinasi orang untuk memvisualisasikannya. Ini adalah perwujudan sebagian sistem yang sesungguhnya, bukan yang abstrak. Mungkin lebih menekankan detil dan dengan demikian tidak menyembunyikan atau merusak penampakan total dari sistem. Prototip perlu dibuat untuk sistem di bawah pengembangan saja, bukan untuk sistem yang ada.
a. Hukum Davis
Nilai dari sebuah model tergantung pada pandangan diambil, tetapi tidak ada yang terbaik untuk semua tujuan.
Model adalah bentuk yang sangat berguna untuk menjelaskan sistem. Hal ini berlaku sebelum, selama, dan sesudah pengembangan sistem. Contoh model yang digunakan dalam ilmu alam adalah model yang menggambarkan evolusi bintang, model atom atau pengoperasian sel. Model tersebut konsep intelektual yang pertama, namun dapat diwujudkan atau dinyatakan dalam sebuah representasi yang terlihat. Dalam ilmu komputer, kita dapat menggunakan model untuk mempelajari struktur statis objek sistem atau komponen, struktur logika data yang digunakan, atau struktur dinamis interaksi tugas dan proses.
Model view | Elements considered | Practical notations | Mathematical equivalent |
Data | Data structures, data relationships | Entity relationship, diagram (ERD) | Heterogeneous algebra |
Process | Processes, interconnections | Dataflow diagram (DFD) | Process graphs |
State transition | Events, states | State diagram, including hierarchically structured state chart (Harel) | Finite state machine |
Structure | Objects, classes, components | Class diagram, Component diagram | I/O functions |
Behavior | Interfaces, message histories | Message sequence chart | Dataflow graphs |
Tabel 1. Modeling views and notations
Teori: Sebuah model dari realitas membantu untuk menjelaskan pemahaman. Model merupakan penjelasan dari sistem. Model taklangsung terlihat atau abstrak, berangkat dari hal-hal yang tidak dianggap penting untuk sementara waktu. Abstraksi berguna untuk beberapa jenis pemahaman manusia saja. Abstraksi merupakan pengetahuan konseptual yang ditingkatkan. Tidak semua pengguna perlu, ingin atau bahkan akan mentolerir abstraksi ini. Dari sudut pandang sistem yang akan dibangun, abstraksi berangkat dari kenyataan yang tergantung pada notasi yang digunakan, yang sering menipu pengamat. Gerakan bintang dalam gugus bintang, atau orbit elektron dalam model atom, hanya ada satu persamaan kusam pada kenyataan. Namun demikian, model-model seperti itu sering digunakan untuk tujuan yang bermanfaat.
Dalam mendefiniskan kebutuhan, tentu melibatkan beberapa pihak. Pihak-pihak yang berpartisipasi dalam proses definisi kebutuhan secara kolektif disebut sebagai pihak yang berkepentingan (stakeholders). Jika sistem yang dibangun untuk diketahui pelanggan, kebutuhan mungkin merupakan dasar untuk pembuatan kontrak. Jika pelanggan tidak mengetahui awalnya, organisasi pemasaran dapat mengasumsikan fungsi ini. Pada awalnya, kebutuhan dibahas di tingkat aplikasi. Hal ini tidak selalu nampak jelas apakah kebutuhan tersebut akan diimplementasikan dalam perangkat keras atau perangkat lunak, atau dilakukan oleh manusia. Kebutuhan itu harus selalu dianggap sebagai kebutuhan sistem. Kebutuhan perangkat lunak hanya merupakan bagian dari keseluruhan. Kebutuhan perangkat lunak akan ditentukan setelah kebutuhan sistem, atau berasal dari keseluruhan.
Hasil dari fase requirements engineering terdokumentasi dalam requirements specification. Requirements specification berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan pelanggan, dan merupakan titik start menuju proses berikutnya yaitu software design. Sistemisasi proses negosiasi pengembang dan pelanggan dalam requirements engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions of Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer (user). [Rom-01].
Gambar 3, The three dimensions of requirement engineering
Kualitas produk biasanya ditetapkan sebagai derajat untuk memenuhi kebutuhan pelanggan. Pandangan ini menekankan satu sisi kualitas: perspektif pengguna. Yang lebih komprehensif dilihat juga termasuk sisi pengembang atau produsen.
Sudut Pandang | Kriteria | Definisi |
PENGGUNA | Ketersediaan | Derajat tingkat akses |
Keandalan | Kegagalan rendah | |
Efisiensi | Nilai konsumsi sumber daya Ekonomi | |
Penerapan | Mudah dan cepat penerapan di lingkungan pengguna | |
Kegunaan | Juga disesuaikan dengan kemampuan dan keinginan pengguna | |
Ketahanan | Reaksi aman pada kesalahan pengguna dan kegagalan hardware | |
Keselamatan/keamanan | Kerusakan rendah dalam hal kelalaian penggunaan | |
PENGEMBANG | Testability | Dokumentasi yang baik dan terstruktur |
Maintainability | Sangat mudah dibaca dan dapat dimodifikasi | |
Portabilitas | Ketergantungan rendah pada teknis lingkungan | |
Localizability | Adaptable untuk kebutuhan nasional dan regional | |
Reusability | Modularitas tinggi dan kelengkapan |
Tabel 2, Kriteria penting kualitas perangkat lunak [SWE-2004]
Kualitas produk perangkat lunak dari sudut pandang pengguna dapat dinyatakan sebagai pemenuhan dari beberapa properti: ketersediaan, keandalan, efisiensi, installability, kegunaan, ketahanan, dan keselamatan/keamanan. Selain itu, beberapa kriteria dapat ditambahkan jika pengembang berkeinginan. Kriteria ini adalah testability, maintainability, localizability, portability, dan reusability. Sebuah definisi singkat dari masing-masing kriteria diberikan dalam tabel 1. Properti ini, kehandalan (reliability) biasanya yang paling penting dan sering digunakan sebagai sinonim untuk kualitas. Dalam hal produk perangkat lunak, kehandalan (dan karena kehandalan jadi berkualitas) yang sering dinyatakan sebagai jumlah kesalahan atau cacat per seribu baris kode (cacat/KLOC). Masalahnya adalah bahwa ini adalah pengukuran berorientasi pengembang (developer-oriented). Pengukuran berorientasi pengguna untuk keandalan adalah jumlah masalah pengguna per bulan. Hubungan antara kedua pengukuran adalah rumit dan tergantung pada penggunaan sistem yang sebenarnya. Sistem ketersediaan adalah fungsi dari jumlah dan lama interupsi. Salah satu definisi yang populer adalah:
Availability = MTTF/(MTTF + MTTR)
dimana MTTF = waktu (lamanya) kegagalan dan MTTR = waktu untuk perbaikan. Satuan yang digunakan dalam persen (mis. 99,9%).
Software Requirement (Requirement Engineering) memiliki cakupan dan pendekatan pengetahuan yang cukup luas sehingga perlu dibagi-bagi dalam beberapa sub bidang. Pembagian KA yang kompatibel dengan bagian dari IEEE 12207 yang merujuk ke kebutuhan kegiatan. Risiko yang melekat dalam usulan pembagian adalah seperti sebuah proses air terjun (a waterfall-like process) yang dapat diduga/disimpulkan. Untuk menjaga hal ini, subarea 2 proses kebutuhan, dirancang untuk menyediakan gambaran tingkat tinggi proses kebutuhan dengan pengaturan sumber daya dan batasan dalam proses operasi dan yang bertindak untuk mengkonfigurasinya.
Kebutuhan Software KA terkait erat dengan Desain, Testing, Pemeliharaan, Manajemen Konfigurasi, Manajemen Rekayasa Perangkat Lunak, Proses Rekayasa Perangkat Lunak, dan Ranah Kualitas Perangkat Lunak.
Dalam SWEBOK edisi 2004, Ranah Pengetahuan Kebutuhan Perangkat Lunak (The Software Requirements Knowledge Area / KA) meliputi pengungkapan, analisis, spesifikasi, dan validasi kebutuhan perangkat lunak. Berikut adalah diagram pembagian software requirement [SWE-2004]:
Gambar 4. Breakdown of topics for the Software Requirements KA
1. Kegiatan Rekayasa Kebutuhan (Requirement Engineering Tasks)
Kegiatan dalam rekayasa kebutuhan memiliki aspek penting dalam menunjang kesuksesan proyek rekayasa perangkat lunak. Adapun kegiatan-kegiatan tersebut adalah sebagai berikut:
1) Pernyataan Visi (Vision statement)
Pernyataan visi dari sistem yang akan dibangun merupakan hal baik untuk memulai proses kebutuhan. Visi dituangkan dalam bentuk dokumen yang menguraikan keseluruhan tujuan yang harus dicapai dan disetujui oleh stakeholders, terutama di tingkat manajemen. Jika dalam proses ternyata visi tidak dapat dicapai, pernyataan visi harus direvisi dan dibahas kembali.
2) Pengungkapan Kebutuhan dan Prioritas (Requirements elicitation and prioritization)
Kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi. Kontribusi terutama dari calon pelanggan dan pengguna. Jika dana tidak datang langsung dari pelanggan, mungkin ada kelompok lain yang memiliki minat dan pengaruh. Selain itu, pihak ketiga ahli hukum yang berwenang, dan badan standar mungkin memiliki masukan. Namun, Kebutuhan yang diharapkan pengguna harus mendapatkan prioritas utama. Oleh karena itu, harus dipahami siapa pengguna, dan apa keterampilan mereka, motivasi dan lingkungan kerja [Alb-2003].
Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah [Pre-2005].
3) Pengetahuan akuisisi dan pengelolaan
Dalam banyak kasus, kebutuhan proses tergantung pada pendapat, klarifikasi, dan kumpulan masalah berorientasi pengetahuan. Hal ini terkait dengan aplikasi domain tertentu. Tanpa pengetahuan ini, kita tidak dapat menentukan fungsi apa yang harus ada pada sistem yang direncanakan. Jika ada pengetahuan, orang harus didorong untuk bersedia membuatnya [Alb-2003].
Kadang masalah yang muncul berakar dari perbedaan disiplin ilmu yang dimiliki. Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb. [Rom-01].
4) Studi Kelayakan atau analisis risiko
Untuk sistem yang lebih besar, studi kelayakan perlu dilakukan sebelum kebutuhan secara resmi diterima. Dalam proses ini, untuk mendapatkan jawaban atas pertanyaan berikut pada setiap item pada daftar kebutuhan harus diperoleh: "Apakah kebutuhan ini akan dipenuhi dengan pengetahuan dan teknologi yang tersedia saat ini?" Ini dapat diperluas melengkapi analisis risiko. Dalam hal ini, pembongkaran non-teknis akan diberikan juga. Ini dapat berhubungan dengan pertanyaan seperti: "Bisakah ini dikembangkan atau dibangun dalam waktu yang telah dialokasikan?" "Apakah anggaran memadai?” dan “Apakah ada pembongkaran yang kompetitif?" Untuk menjawab pertanyaan-pertanyaan ini, satu bentuk sebagian desain harus dilakukan.
5) Kebutuhan fungsional dan non-fungsional
a. Kebutuhan fungsional , adalah suatu kebutuhan yang menyatakan prilaku yang harus ada pada sistem. Contoh jika seorang pengusaha membeli mobil untuk membawa barang dari gudang ke toko, maka kebutuhan fungsional dari mobil tersebut adalah mobil harus dapat membawa barang dari gudang ke toko.
b. Kebutuhan non fungsional sederhananya adalah batasan yang harus ada pada sistem dan bagaimana dalam membentuk sistem tersebut. Batasan dapat dibagi menjadi dua sub katagori yakni:
- Performance constraint, batasan ini menunjukan spesifikasi bagaimana sistem bekerja ketika kebutuhan funsional telah bekerja. Contoh pada mobil yang mengangkut barang diatas adalah batasan bahwa minimal daya angkut pada mobil harus lebih dari satu ton.
- Development constraint, batasan ini menunjukan sebagai pelengkap dari performance constraint. Batasan ini lebih cenderung pada batasan pada level manajemen proyek . Contoh rincian dari waktu , resource, quality , dll.
6) Keselamatan dan Kebutuhan keamanan
Kekhususan bentuk kebutuhan non-fungsional menyangkut keselamatan dan keamanan sistem. Resiko keselamatan dapat menimbulkan bahaya untuk pengguna individu, kelompok, atau masyarakat luas. Keselamatan adalah penting, terutama jika komputer mengendalikan peralatan fisik atau pabrik, seperti rem mobil, pesawat, atau stasiun tenaga nuklir. Keamanan menjadi isu penting jika data yang disimpan, data harus dilindungi terhadap penyalahgunaan, serta terhadap serangan berbahaya oleh pesaing.
7) Dokumentasi Kebutuhan (Documentation of Requirements)
Kebutuhan setelah terkumpul dan teranalisa selanjutnya didokumentasikan dengan jelas dan baik dan tidak ambigu. Penulisan dokumentasi kebutuhan merupakan aspek yang “critical” sehingga memungkinkan suatu iterasi yang melibatkan seluruh ‘stakesholders’ sangatlah mungkin terjadi. Hal ini dapat disimpulkan dari peranan dokumentasi kebutuhan, yaitu :
a. Peran Dokumen Kebutuhan
- Digunakan sebagai dasar validasi jika terjadi konflik antar ‘stakesholders’
- Sebagai kontrak antara customer dan developer
- Dasar dari desain sistem bagi perancang
- Ukuran bagi manager proyek dalam pemantauan jalannya proyek
- Sumberdaya untuk manajemen kebutuhan dan pelacakan kebutuhan
- Sumber untuk memformulasikan test plan untuk QA dan pengujian tim
- Dasar untuk pengembangan perputaran proyek
b. Spesifikasi Kebutuhan
Ditinjau dari sisi pemakai dokumentasi requirement dapat dipisahkan menjadi dua bagian
- User requirement , lebih ke bahasa formal non teknis. Diperuntukkan untuk kepentingan pelanggan dan end-user
- System requirements, lebih ke bahasa formal teknis. Diperuntukan untuk kepentingan perancang dan perekayasa sistem.
Setiap notasi yang digunakan harus mudah dibaca dan diketahui. Jika pemeriksa dan pembaca dokumen tidak memiliki latar belakang ilmu komputer, teks biasa dan diagram sederhana merupakan media pilihan. Untuk menjelaskan sistem bagi pengembang, biasa disertakan kebutuhan model. Untuk keperluan pemodelan, dengan notasi UML diutamakan daripada notasi grafis lainnya. Notasi ini sebagian besar CASE tools, notasi UML Object Modeling Technique (OMT), Entity Relationship Diagrams (ERDs), State Chart, dan notasi Use Case serta Data Flow Diagrams (DFDs)
8) Penerimaan, Validasi dan Persetujuan Kebutuhan
Keberhasilan setiap proyek pembangunan terutama tergantung pada penerimaan dari produk akhir yang diinginkan oleh pengguna. Cara terbaik untuk mencapai ini adalah melalui partisipasi pengguna. Upaya bersama ini selalu dimulai dengan definisi kebutuhan. User harus menerima kebutuhan, yakni mempertimbangkan kebutuhan sebagai milik mereka.
Setelah didapat suatu kebutuhan yang teranalisa maka team rekayasa kebutuhan dan para stakeholdes memvalidasi kembali dan meperbaiki apa yang menjadi kekurangan. Meliputi proses identifikasi, menyakin kan kembali, menanggapi dan memperbaiki masalah dari requirements, dan menyatakan bahwa requirement telah dapat diterima.
9) Pelacakan Kebutuhan dan Perubahan kendali
Untuk sistem yang besar, perlu dipastikan bahwa tidak ada dokumentasi kebutuhan yang terlupakan. Kebutuhan dapat berubah, selama kehidupan sebuah proyek, baik sebelum atau setelah pengiriman. Oleh karena itu, diperlukan untuk membuat perubahan kendali prosedur guna kebutuhan. Prosedur ini harus menjamin bahwa semua pihak yang berkepentingan mengetahui tentang perubahan bila usulan, persetujuan untuk mengadopsi, dan tindak lanjut atas semua kegiatan yang dipicu oleh perubahan ini. Hal ini akan berlaku saat menambahkan atau menghapus kode, melakukan tes regresi, dokumentasi atau membuat perubahan.
2. Kesimpulan
Definisi Kebutuhan (Requirement Definitions) adalah pernyataan yang menidentifikasikan kebutuhan yang penting dalam sistem dan di dalamnya mencakup aspek kebenaran, realistis, dibutuhkan, tidak ambigu, dan terukur. Langkah yang paling penting dalam proses requirement adalah komunikasi yang akurat antara user yang memerlukan sistem dengan pengembang (developer).
RE yang baik adalah penting karena dampaknya mampu mengurangi biaya proyek, dan diterimanya sistem oleh stakeholder sehingga bisa mengarah kepada keuntungan yang tinggi. Namun juga harus diakui dibutuhkan tenaga dan waktu yang tidak sedikit untuk berinvestasi dalam pembuatan requirement yang benar-benar baik. Untuk mendapatkan requirement yang baik, ada banyak pekerjaan/tasks harus dilakukan, untuk itu tim Requirements Engineering tidak hanya bekerja pada awal dari proyek namun bekerja melalui tahap pengembangan sampai tahap delivery untuk memastikan requirement benar-benar sesuai.
Karena kompleksitas, ragam pengetahuan dan keahlian khusus serta bidang kerja yang banyak, maka Requirement Engineering telah menjadi cabang ilmu baru pada tahun 1990an.
Daftar Pustaka
[Rom-01] Romi Satria Wahono, “Menyegarkan Kembali Pemahaman tentang Requirement Engineering”,
http://romisatriawahono.net/2006/04/29/menyegarkan-kembali-pemahaman-tentang-requirement-engineering/
[Alb-2003] Albert Endres, Dieter Rombach, “A Handbook of Software and Systems Engineering : Empirical Observations, Laws and Theories”, Pearson Education Limited, England, 2003.
[SWE-2004] SWEBOK, “Chapter 2 : SOFTWARE REQUIREMENTS”, IEEE, 2004.
[Pre-2005] Pressman, Roger S., “Software Engineering: A Practitioner's Approach”, 6th Edition. McGraw-Hill. 2005.
[Kot-2000] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 2000.
1 komentar:
Terima kasih ilmunya pak..
Posting Komentar