Pembangungan Sistem Perubahan Kebutuhan Menggunakan Improved Framework

Transkripsi

1 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X Vol. 2, No. 5, Mei 2018, hlm Pembangungan Sistem Perubahan Kebutuhan Menggunakan Improved Framework Widya Bayu Wicaksono 1, Fajar Pradana 2, Bayu Priyambadha 3 Program Studi Teknik Informatika, 1 widyabayuwicaksono@gmail.com, 2 fajar.p@ub.ac.id, 3 bayu_priyambadha@ub.ac.id Abstrak Perubahan kebutuhan merupakan suatu hal yang tidak terelakkan pada lingkungan pengembangan perangkat lunak dalam proses rekayasa kebutuhan. Hal ini dapat terjadi karena adanya perubahan permintaan yang diajukan oleh pemangku kepentingan. Seiring berjalannya waktu perubahan kebutuhan menjadi suatu hal yang kompleks pada tahap pengembangan perangkat lunak. Kurangnya komunikasi antara pemangku kepentingan dan pengembang menjadikan perubahan kebutuhan susah untuk dipenuhi secara baik. Dampak yang terjadi karena adanya perubahan kebutuhan juga akan menyebabkan proses, harga, dan jadwal dari pengembangan perangkat lunak terganggu. Pada skripsi ini akan dijelaskan framework dan metode untuk memecahkan masalah tersebut. framework yang dipakai meliputi proses proses manajemen perubahan kebutuhan. framework tersebut dimulai dengan pengajuan perubahan kebutuhan oleh pemangku kepentingan, yang kemudian dianalisis dan dilakukan voting untuk menentukan apakah perubahan kebutuhan tersebut akan diimplementasikan atau tidak. Beberapa framework sebelumnya yang telah dipakai untuk memecahkan masalah perubahan kebutuhan juga akan dibahas pada skripsi ini. Terdapat juga sebuah metode untuk menghitung dampak yang terjadi apabila terjadi perubahan pada suatu kebutuhan. Metode tersebut menghitung waktu yang dibutuhkan untuk implementasi, harga dari perubahan kebutuhan, dan sisa waktu dari tenggat waktu proyek. Beberapa data juga diambil untuk menguatkan masalah yang terjadi pada tahap perubahan kebutuhan. Data-data tersebut diambil dari perusahaan pengembangan perangkat lunak Inagata Technosmith yang ada di kota Malang. Kata kunci: pengembangan perangkat lunak, rekayasa kebutuhan, manajemen perubahan kebutuhan Abstract Requirement change is an inevitable in software development activity. It can happen when stakeholders change their requirements. By the time requirements change becomes more complicated in software development. Requirements change are hardly achieved well because the lack of communication among stakeholders and software developer. Requirements change impact can affect process, cost, and schedule of software development. In this research a mehod and framework will be explained to resolve this problem. The framework includes all the process that required in requirement change management. The framework start with stakeholder write down what their needs, then analyzed, and finally some vote will be done to determine wether requirement change is worth to be implemented or not. Past research used to solve this problem will be explained too.there is also a method to count impact occurred when requirement change will be implemented. This method count time to implement, cost, and time left before the deadline come. Some data taken to support this problem in requirement change. The data is taken from Inagata Technosmith Software house in Malang city. Keywords: software development, requirement engineering, requirement change management 1. PENDAHULUAN Requirement Change Management (RCM) merupakan proses untuk menafsirkan, mengelola, menganalisis, melacak, dan mendokumentasi perubahan pada kebutuhan (Minhas, 2014). Hal ini dibutuhkan untuk memenuhi perubahan permintaan dari pemangku kepentingan agar perangkat lunak yang dibuat dapat memenuhi kebutuhan yang diminta. Apabila ada kebutuhan yang tidak Fakultas Ilmu Komputer Universitas Brawijaya 1947

2 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 1948 terpenuhi, maka pemangku kepentingan tidak akan mendapatkan perangkat lunak yang mereka butuhkan (Westfall, 2005). Perubahan kebutuhan merupakan salah satu faktor terbesar dalam kegagalan perangkat lunak karena mempengaruhi dana, kualitas, dan jadwal dari pengembangan perangkat lunak (Ali, 2015). RCM menjadi lebih susah untuk dilakukan pada lingkungan projek terdistribusi karena susahnya komunikasi antara pengembang dengan pemangku kepentingan (Minhas, 2014). Kurangnya manajemen terhadap perubahan kebutuhan membuat peluang kegagalan dalam pengembangan perangkat lunak semakin besar (Minhas, 2014). Pertemuan antara pengembang dengan pemangku kepentingan juga terkadang susah untuk dilakukan, padahal RCM merupakan proses kolaborasi yang intensif pada lingkungan terdistribusi (Minhas, 2014). RCM sangatlah penting untuk dapat sukses membangun perangkat lunak yang diinginkan oleh pemangku kepentingan (Minhas, 2014). Kesalahan analisis kebutuhan pada proses RCM dapat menghabiskan 70 sampai 85 persen dari biaya pengerjaan ulang proyek perangkat lunak (Wiegers, 2003). Beberapa penelitian telah dilakukan sebelumnya untuk memecahkan masalah pada RCM. Seperti pada penelitian Lai, dkk (2013) yang mengajukan pemecahan masalah kebutuhan dengan membuat repository untuk RCM pada lingkungan global. Penelitian lain dari Sultana, dkk (2012) mengajukan framework untuk RCM pada lingkup global. Framework tersebut menggunakan repository utama untuk berbagi informasi tentang kebutuhan, agar masalah RCM dapat terselesaikan. Khan, dkk (2012) mengajukan framework untuk mengatasi masalah komunikasi yang ada selama RCM pada lingkup global. Framework ini meliputi aktifitas perubahan inisiasi, evaluasi, dan implementasi. Penelitian-penelitian tersebut masih belum mencakup semua yang dibutuhkan untuk memecahkan masalah pada RCM. Semua elemen-elemen seperti komunikasi, koordinasi, dan kontrol belum dicakup semua oleh penelitian sebelumnya. Berdasarkan permasalahan dan penelitian sebelumnya maka penulis melakukan penelitian dengan judul Pembangunan Sistem Perubahan Kebutuhan Menggunakan Improved Framework. Metode improved framework diajukan oleh Minhas, dkk (2014) untuk membenahi framework manajemen perubahan kebutuhan yang sudah ada karena terdapat kekurangan pada sisi komunikasi, koordinasi, dan kontrol. Metode Improved Framework dipakai pada sistem ini karena metode ini yang mencakup semua elemen seperti komunikasi, koordinasi, dan kontrol yang dibutuhkan untuk RCM pada sisi rekayasa kebutuhan (Minhas, 2014). Sistem ini menerapkan seluruh alur yang ada pada metode improved framework. Sistem ini diharapkan dapat memecahkan masalah yang ada pada proses RCM dan membantu analis serta Change Control Board (CCB) dalam menganalisis maupun memutuskan perubahan kebutuhan yang diajukan oleh pemangku kepentingan. 2. LANDASAN KEPUSTAKAAN 2.1 Improved Framework Framework ini telah diajukan oleh (Minhas, 2014). untuk memecahkan masalah RCM pada lingkungan global. Seperti pada Gambar 1 fase inisiasi perubahan kebutuhan diambil dari beberapa pemangku kepentingan. Perubahan diterima pada Change Request Form (CRF). CRF berisikan tentang informasi berkaitan dengan permintaan pengubahan, detail kontak lengkap dari pencetus dan detail lengkap tentang permintaan pengubahan. Setelah CRF diisi, kemudian akan disimpan pada basis data RCM untuk kemudian diproses lebih lanjut. Langkah selanjutnya adalah analisis perubahan oleh analis yang dibantu dengan repositori kebutuhan berisikan informasi terkait kebutuhan sistem. Analisis dilakukan untuk menentukan harga, waktu, dan pemanfaatan sumber daya oleh analis kebutuhan. Hasil evaluasi kemudian disimpan pada basis data RCM.

3 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 1949 yang ditulis oleh pengembang akan diunggah ke dalam sistem untuk nantinya menjadi bahan analis menentukan jumlah baris kode per function point. Dokumen analisis juga akan diunggah untuk menentukan jumlah file, query, tabel pada basis data, masukan dari pengguna, dan dokumentasi. Gambar 1. Improved Framework untuk global software development Notifikasi diberikan pada semua member CCB, Untuk dilakukan voting pada hasil evaluasi. Batas waktu diberikan pada CCB melalui sistem secara otomatis. Hasil voting didapatkan dari semua member CCB, untuk menentukan setuju atau tidak setuju mengimplementasikan perubahan. Keputusan tentang persetujuan atau penolakan perubahan diputuskan dari hasil voting yang telah diberikan kepada semua member CCB. Jika semua member setuju pada hasil keputusan, perubahan dinyatakan diterima dan disetujui untuk kemudian diimplementasikan atau tidak. Hasil final dari keputusan CCB kemudian disimpan pada basis data RCM. Komunikasi pada framework ini dilakukan pada setiap kebutuhan yang ada. Setelah analis melakukan analisis terhadap sebuah kebutuhan, maka terdapat tombol untuk mengirim kepada CCB. Tombol tersebut akan mengirimkan kepada setiap CCB yang ada pada proyek dipilih. Koordinasi pada framework ini terletak pada penentuan jumlah pengembang yang akan mengerjakan perubahan kebutuhan. Saat analis menganalisis perubahan kebutuhan, maka terdapat kolom untuk menentukan jumlah pengembang yang akan mengerjakan perubahan kebutuhan tersebut. Kontrol pada framework ini terdapat pada sinkronisasi antara kode yang ditulis oleh pengembang dengan dampak dari perubahan kebutuhan yang akan ditulis oleh analis. Kode 2.2 Method of Requirement Change Management Metode yang diajukan oleh Ali (2015) dibagi menjadi 3 tahap yaitu: memahami perubahan, melakukan analisis terhadap perubahan, dan proses finalisasi. Namun yang dipakai pada penelitian ini hanyalah tahap analisis terhadap perubahan Ali (2015) memberikan persamaan untuk menghitung perkiraan waktu yang diperlukan untuk menyelesaikan pengembangan perangkat lunak. Berikut adalah persamaan yang di usulkan: factor FPs E Nw (1) n E = Perkiraan waktu pengembangan (jam) Nw = Waktu pengerjaan dalam sehari factors = Baris kode pada perangkat lunak per function point FP = Function Point n = Jumlah baris kode per hari E T R (2) Nw T R = Waktu untuk implementasi perubahan E = Perkiraan waktu pengembangan Nw = Waktu pengerjaan dalam sehari 2.3 Function Point Function points (FP) pertama kali diperkenalkan tahun 1970 an sebagai alternatif dalam menghitung jumlah baris yang sederhana berbasis metrik. Dasar dari FPs adalah dengan bertambah kuatnya suatu bahasa pemrograman di kembangkan, maka jumlah baris kode akan bertambah dan membuat fungsi-fungsinya kompleks (Raju, 2013). Bagaimanapun perhitungan harga per baris kode menunjukkan penurunan disisi produktivitas, karena harga pengembangan perangkat lunak tidak akan berubah. Pemecahannya adalah dengan menghitung fungsionalitas perangkat lunak menggunakan jumlah antarmuka antara modul dan sub sistem dalam program atau sistem. Keuntungan dari menggunakan FP metrik adalah dapat dihitung sebelum tahap implementasi dilakukan. Pada FP terdapat 5 karakteristik

4 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 1950 perangkat lunak setiap modul, yaitu: Number of inputs to the application (I), Number of outputs (O), Number of user inquiries (Q), Number of files used (F), Number of external interfaces (X). Tabel 1. Tabel Weighting Factor Parameter Simple Average Complex Number of inputs Number of outputs Number of user inquiries Number of files used Number of external interfaces METODOLOGI PENELITIAN Pada bab ini dijelaskan langkah langkah yang akan dilakukan dalam perancangan, implementasi, dan pengujian dari aplikasi perangkat lunak yang akan dibuat terlihat pada Gambar 2 secara diagram alur. Kesimpulan dan saran disertakan sebagai catatan atas aplikasi dan kemungkinan arah pengembangan aplikasi selanjutnya. Penghitungan FP menggunakan weighting factors yang setiap aspek merefleksikan kesulitan untuk diimplementasikan. Koefisien ini bervariasi bergantung pada kesulitan implementasinya. Untuk menghitung FP adalah sebagai berikut: FP ( I WF) ( O WF) ( Q WF) (3) ( F WF) ( X WF) I = Number of inputs O = Number of outputs Q = Number of user inquiries F = Number of files X = Number of external interfaces WF = Weighting Factor value 2.4 First Time Yield First Time Yield merupakan pembagian antara hasil jumlah unit yang bagus dengan jumlah unit yang masuk kedalam proses (Raju, 2013). FP dapat diaplikasikan kepada tahap kebutuhan dalam lingkup pengembangan perangkat lunak. Dalam perspektif pengembangan perangkat lunak, First Time Yield dapat didefinisikan sebagai jumlah FP yang sukses terpenuhi dibagi dengan jumlahfpyang direncanakan pada iterasi tersebut. Persamaan 4 adalah persamaan yang diajukan. FTY Y1... Y n (4) FTY = First Time Yield Yn = Nilai function point sesuai banyak iterasi Gambar 2. Diagram alir metode penelitian 4. ANALISIS KEBUTUHAN 4.1 Kebutuhan Fungsional Kebutuhan fungsional merupakan kebutuhan utama yang dibutuhkan dari sebuah sistem. Sistem perubahan kebutuhan menggunakan improved framework memiliki kebutuhan fungsional sebagai berikut: Tabel 2. Tabel kebutuhan fungsional ID Kebutuhan F.01 Sistem harus dapat memisahkan hak akses antar pengguna. F.02 Sistem harus dapat menyimpan kebutuhan yang didefinisikan oleh analis. F.03 Sistem harus dapat menampilkan semua kebutuhan yang sudah disimpan kedalam sistem. F.04 Sistem harus dapat menyediakan sarana untuk mengubah kebutuhan yang sudah F.05 Sistem harus dapat menyediakan sarana untuk menghapus kebutuhan yang sudah F.06 Sistem harus dapat menyimpan pengajuan perubahan kebutuhan yang diajukan pemangku kepentingan. F.07 Sistem harus dapat menampilkan semua perubahan yang diajukan oleh pemangku kepentingan. F.08 Sistem harus dapat menyediakan form analisis perubahan kebutuhan yang dapat

5 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 1951 menghitung hari dan harga dari perubahan. F.09 Sistem harus dapat melakukan otomatisasi penentuan jangka waktu bagi CCB untuk melakukan voting. F.10 Sistem harus dapat menampilkan daftar kebutuhan yang diubah bagi CCB. F.11 Sistem harus dapat menyediakan kolom pilihan untuk CCB melakukan voting perubahan kebutuhan. F.12 Sistem harus dapat menyimpan pengguna baru kedalam sistem. F.13 Sistem harus dapat menyediakan sarana untuk pengguna keluar dari sistem. F.14 Sistem harus dapat menampung dokumen yang diunggah oleh analis dan pengembang. F.15 Sistem harus dapat mengirimkan kepada CCB apabila ada perubahan kebutuhan baru yang sudah dikirim oleh analis. F.16 Sistem harus dapat menumpuk kebutuhan yang telah disetujui oleh semua CCB. F.17 Sistem harus dapat menyediakan halaman detil perubahan kebutuhan yang lengkap dengan dampak pada kebutuhan lainnya. F.18 Sistem harus dapat menyimpan konfigurasi proyek yang dibuat dan didefinisikan oleh analis. F.19 Sistem harus dapat menyimpan konfigurasi proyek apabila dilakukan perubahan oleh analis. F.20 Sistem harus dapat menghapus proyek yang F.21 Sistem harus dapat menyediakan sarana untuk admin mengubah pengguna yang F.22 Sistem harus dapat menyediakan sarana untuk admin menghapus pengguna yang F.23 Sistem harus dapat mengirimkan kepada pemangku kepentingan ketika keputusan perubahan kebutuhan telah dilakukan. 4.2 Kebutuhan Non Fungsional Tabel 3 merupakan kebutuhan non fungsional yang ada dalam sistem. Terdapat kebtuhan non fungsional portability dan security yang nantinya Kebutuhan non fungsional didapatkan dari pengumpulan data pada perusahaan Inagata Technosmith. Kebutuhan non fungsional dibutuhkan untuk menunjang sistem perubahan kebutuhan menggunakan improved framework, apabila kebutuhan non fungsional tidak didefinisikan maka sistem yang dibuat tidak akan berguna. Tabel 3. Tabel kebutuhan non fungsional ID Parameter Deskripsi NF.01 Compatibility Sistem dapat diakses diberbagai jenis browser seperti Mozilla firefox, Google chrome, dan Microsoft edge NF.02 Security Sistem menggunakan enkripsi md5 untuk mengenkripsi password yang ada didalam database 5. PERANCANGAN DAN IMPLEMENTASI 5.1 Perancangan Algoritme Pada bagian perancangan algoritme ini akan dijelaskan algoritme yang dipakai untuk membangun sistem perubahan kebutuhan menggunakan improved framework Tabel 4. Pseudocode menentukan dampak kebutuhan Int entry_screens, external files, reports, queries, database_tables, code_per_fp, es_wf, ef_wf, r_wf, q_wf, dt_wf, jumlah_pekerja, waktu_kerja_perhari, jumlah_kode_perhari, harga_perjam, deadline_proyek, functional_points, expected_hours, time_to_implement, time_acceptance, total_cost; functional_points = (entry_screens * es_wf) + (external_files * ef_wf) + (reports * r_wf) + (queries * q_wf) + (database_tables * dt_wf); expected_hours = waktu_kerja_perhari * (code_per_fp * functional_points / jumlah_kode_perhari); time_to_implement = (expected_hours / waktu_kerja_perhari) / jumlah_pekerja; time_acceptance = deadline_proyek - time_to_implement; total_cost = expected_hours * harga_perjam; Tabel 4 merupakan pseudocode untuk menentukan dampak perubahan kebutuhan. Pseudocode ini dimulai dengan menghitung function points dari kebutuhan yang akan diubah, kemudian menghitung perkiraan waktu yang dibutuhkan untuk mengimplementasi perubahan (dalam jam). Setelah itu akan dihitung waktu yang dibutuhkan dalam hari, waktu yang tersisa dan total harga perubahan kebutuhan.

6 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 1952 Tabel 5 merupakan pseudocode untuk menentukan jumlah rework yang dibutuhkan. Pseudocode ini menentukan jumlah First Time Yield yang dibutuhkan untuk perubahan kebutuhan serta menentukan jumlah rework yang dibutuhkan. Hasil dari perhitungan ini adalah dalam bentuk persen. Tabel 5. Pseudocode menentukan rework yang dibutuhkan 1 Fty = (function_points / planned_function_points) * 100 Rework = ((function_points / planned_function_points) * 100) 5.2 Implementasi Gambar 3 merupakan halaman fitur menganalisis perubahan kebutuhan. Pada halaman ini analis disediakan dokumen pendukung untuk kebutuhan yang akan dirubah, permintaan perubahan dari pemangku kepentingan dan perkiraan dampak perubahan kebutuhan. Gambar 4 merupakan halaman fitur melihat detil perubahan. Fitur ini dapat diakses oleh CCB atau analis untuk melihat kebutuhan yang diminta oleh pemangku kepentingan dan hasil Analisis dari analis. Gambar 3. Fitur menganalisis perubahan kebutuhan Gambar 4. Fitur melihat detil perubahan Gambar 5. Fitur melihat daftar analisis perubahan kebutuhan 6. PENGUJIAN 6.1 Pengujian white box Pengujian white box dilakukan dengan pengujian basis path pengujian dilakukan pada fitur melihat detil perubahan. Operasi-operasi yang akan diuji adalah cekpersetujuanimplementasi(), cekpengirimanccb(), dan cekpersetujuan(). Operasi cekpersetujuanimplementasi adalah untuk mengetahui status perubahan kebutuhan. Operasi cekpengirimanccb adalah untuk status perubahan kebutuhan telah dikirim ke CCB atau belum dan untuk mengetahui apakah perubahan kebutuhan ditolak atau diterima oleh CCB. Sedangkan operasi cekpersetujuan adalah untuk mengetahui apakah CCB yang sedang masuk kedalam sistem telah melakukan voting atau belum pada suatu perubahan kebutuhan. Pengujian tersebut menghasilkan 6 cyclomatic complexity pada operasi cekpersetujuanimplementasi dan cekpersetujuan serta menghasilkan 5 cyclomatic complexity pada operasi cekpengirimanccb. Pengujian pada masing-masing jalur telah dilakukan dan menghasilkan status yang valid pada setiap jalur. 6.2 Pengujian black box Dari 22 pengujian fungsional yang telah dilakukan yaitu pengujian login, pengujian logout, pengujian melihat daftar perubahan kebutuhan sudah dianalisis, pengujian melihat daftar perubahan kebutuhan, pengujian melihat kebutuhan, pengujian menambahkan pengguna, pengujian mendapatkan waktu voting, pengujian mengajukan perubahan kebutuhan, pengujian menganalisis kebutuhan, pengujian menganalisis perubahan kebutuhan, pengujian menghapus kebutuhan, pengujian mengubah kebutuhan, pengujian melakukan voting, pengujian melihat detil perubahan, pengujian

7 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 1953 menambah dokumen, pengujian menambah proyek, pengujian menerima keputusan, pengujian menerima perubahan kebutuhan, pengujian menghapus pengguna, pengujian menghapus proyek, pengujian mengubah pengguna, pengujian mengubah proyek, pengujian menumpuk kebutuhan. Semua pengujian tersebut menghasilkan status yang valid, sehingga pengujian fungsional sistem dinyatakan berhasil dengan tingkat keberhasilan sebesar 100%. Pengujian terhadap portability dan security yang ada pada kebutuhan non fungsional sistem telah dilakukan dan semuanya mendapatkan hasil yang valid. Sehingga pengujian terhadap non fungsional sistem dinyatakan berhasil dengan tingkat keberhasilan 100%. 7. KESIMPULAN. Pembangunan sistem perubahan kebutuhan menggunakan improved framework menggunakan framework CodeIgniter dan Bahasa pemrograman PHP. Bahasa pemrograman php digunakan untuk tahap pengerjaan kode dan framework CodeIgniter untuk kemudahan pengerjaan sistem. Sedangkan untuk pengujiannya menggunakan white box dan black box. 2. Dari 3 pengujian white box yang dilakukan semuanya menghasilkan status yang valid. Kemudian untuk pengujian black box kebutuhan fungsional, dari 22 pengujian didapatkan 22 status yang valid. Sedangkan untuk 3 pengujian black box kebutuhan non fungsional didapatkan 3 pengujiannya valid. Sehingga dapat disimpulkan bahwa pengujian white box dan black box sistem memiliki tingkat keberhasilan sebesar 100%. 3. Pada sistem perubahan kebutuhan menggunakan improved framework, analisis perubahan kebutuhannya dapat menghitung harga, waktu untuk implementasi, dan dampak pada dokumen maupun kebutuhan lainnya. Sedangkan untuk implementasi perubahan kebutuhan, hasil analisis perubahan kebutuhan harus disetujui oleh semua CCB. Jika ada salah satu CCB yang melakukan penolakan maka perubahan kebutuhan tersebut tidak akan diimplementasikan. Hal ini dapat membantu dalam proses perubahan kebutuhan pada lingkup pengembangan perangkat lunak. DAFTAR PUSTAKA Ali, N., & Lai, R. (2016). A method of requirements change management for global software. Information and Software Technology, 70, Khan, A., Basri, S., Dominic, P., & Amin, F. (2012). A Propose Framework for Requirement Change Management in Global Software Development. International Conference on Computer & Information Science (ICCIS), Lai, R., & Ali, N. (2013). Requirements Management Method for Global Software Development. Advances in Information Science, Minhas, N., Qurat-ul-Ain, Zafar-ul-Islam, & A., Z. (2014). An Improved Framework for Requirement Change Management in Global Software Development. Journal of Software Engineering and Applications, 7, Raju, H., & Krishnegowda, Y. (2013). Software Sizing and Productivity with Function Points, Vol. 1, No. 2. Lecture Notes on Software Engineering. Sultana, R., Fahad, J., Ahmad, M., & Ahmad, A. (2012). Empirical and Qualitative Studies by Analyzing Requirement in Global Software Development (GSD). International Journal of Management, IT and Engineering, Westfall, L. (2005). Software Requirements Engineering: What, Why, Who, When, and How.