Requirements Engineering Project-Based Learning Model Using the Electronic Learning Software Engineering System (ELINS)

TABLE OF CONTENTS

DECLARATION

DEDICATION

ACKNOWLEDGEMENT

ABSTRACT

ABSTRAK

LIST OF TABLES

LIST OF FIGURES

LIST OF APPENDICES

LIST OF ABBREVIATION

1 INTRODUCTION
1.1 Overview
1.2 Background of the Problem
1.3 Problem Statement
1.4 Research Questions
1.5 Objectives of this Research
1.6 Scope
1.7 Importance of Research
1.8 Contribution
1.9 Structure of Thesis
1.10 Conclusion

2 LITERATURE REVIEW
2.1 Introduction
2.2 The Importance of Requirements Engineering
2.2.1 Requirements Engineering Definition
2.2.1.1 The Activities in Requirements Engineering (RE)
2.2.2 The Issue Arose in Requirements Engineering (RE)
2.2.3 Requirements Engineering Practice in the Software Industry
2.2.3.1 Skill Demand in the Software Industry, Malaysia
2.2.3.2 Issues in the Software Development Project in Software Industry
2.2.3.3 Synthesis of Skill Demand in the Software Industry
2.3 Software Engineering Education
2.3.1 Components in Software Engineering Education
2.3.2 Challenges in Software Engineering Education
2.3.3 Software Engineering Education Practice in Malaysia
2.3.4 Synthesis of Software Engineering Education
2.4 Requirements Engineering Education
2.4.1 Requirements Engineering Education Technique
2.5 Learning Method
2.5.1 The Issues in the Traditional Learning Method
2.5.2 The Experiential Method using Project-Based Learning
2.5.3 Comparative Study on Previous Work using RE PjBL
2.5.4 Characteristics of e-Learning
2.5.5 Propose RE PjBL Method to Teach Requirements Engineering Education
2.5.5.1 Techniques used in RE PjBL
2.5.5.2 Technology Used in System Development to Support RE PjBL
2.6 Conclusion

3 RESEARCH METHODOLOGY
3.1 Introduction
3.2 Evolution of Research Methodology to Propose Solution for RE PjBL
3.3 Research Structure
3.4 Data Analysis Using Survey
3.4.1 The Conceptualization of Domain in the Survey’s Questionnaire
3.4.2 The Relationship between Reliability and Validity
3.4.2.1 Reliability of the Quantitative Instrument
3.4.2.2 Validity
3.4.3 Rasch Measurement Model Uses Winstep for the Quantitative Analysis
3.4.3.1 The Step in the Rasch Model Analysis
3.4.3.2 The Rasch Formula
3.5 Data Analysis Using Interview
3.5.1 Semi-structured Interview
3.5.2 Nvivo 8 for the Qualitative Analysis
3.6 Strategy for Pilot Study, Main Study and Experimental Design Approach
3.6.1 The Quantitative and Qualitative Analysis for Pilot Study
3.6.2 The Quantitative Analysis for the Main study
3.6.2.1 Requirements Engineering Project-Based Learning Model Development
3.6.2.2 Prototyping for Electronic Learning Software Engineering (ELINS) Development
3.6.2.3 Case Study
3.6.2.4 Effectiveness Identification for Student Evaluation
3.7 Sample Population
3.7.1 Sampling Technique
3.8 Conclusion

4 DEVELOPMENT OF REQUIREMENTS ENGINEERING PROJECT BASED LEARNING (RE PJBL) ATTRIBUTES
4.1 Introduction
4.2 Sampling Unit
4.2.1 Population
4.2.1.1 Population Constraints
4.2.2 Duration
4.2.3 Synthesis of the Sampling Unit
4.3 Qualitative Research Data: Semi-structured Interview Results and Analysis
4.3.1 The Process Taken in the Qualitative Results and Analysis
4.3.2 Presenting the Results of the Qualitative Result: Cognitive Mapping
4.3.3 The Development of the Questionnaire: Triangulation with the Qualitative Results
4.3.3.1 Scale
4.4 Identifying the Gaps between Practise and Learning: The Pilot Study Results and Analysis
4.4.1 Overview of the Demographic Background
4.4.2 Frequency Analysis: Items with Likert Scale
4.4.3 The Rasch Measurement Analysis
4.4.3.1 Examining the Consistency in Response Category Curves
4.4.3.2 Summary of Fit Statistics
4.4.3.3 Preliminary Rasch Analysis Using Winstep
4.5 Person-Item Map
4.5.1 Horizontal Item Analysis
4.5.2 Person Analysis
4.5.2.1 Vertical Discussion on Wright Map
4.6 Conclusion

5 REQUIREMENTS ENGINEERING PROJECT-BASED LEARNING (RE PJBL) MODEL
5.1 Introduction
5.2 Gap between Practice and Learning: The Quantitative Main Study Result
5.2.1 Preliminary Rasch Analysis: Fit Statistic
5.2.2 Probability of Response Result
5.2.3 Item Misfit
5.2.4 Person Misfit
5.3 Main Study Analysis after Cleaned Data Using the Rasch Measurement Model
5.4 Synthesis of Initial RE PjBL Model Development
5.5 Conclusion

6 ELECTRONIC LEARNING SOFTWARE ENGINEERING (ELINS) SYSTEM
6.1 Introduction
6.2 Initiation the RE PjBL Working Prototype
6.3 The ELINS Requirements Identification
6.4 The ELIN System Process Flow
6.5 The Architecture for ELINS Development
6.6 Class Diagram
6.7 Graphical User Interface (GUI)
6.7.1 Main Interface
6.7.2 Industry Personnel Functionality
6.7.3 Lecturer Functionality
6.7.4 Student Functionality
6.8 Conclusion

7 MEASURING THE EFFECTIVENESS OF REQUIREMENTS ENGINEERING PROJECT BASED-LEARNING
7.1 Introduction
7.2 Student’s Evaluation Process
7.2.1 Sampling Unit
7.2.2 Duration
7.3 Issue in Evaluation Process
7.3.1 SRS for Initial Case Study
7.3.2 SRS for Case Study I
7.3.3 SRS for Case Study II & III
7.3.4 SRS for Mini Project
7.4 Questionnaire Distribution
7.5 Result and Analysis of Evaluation: Rasch Measurement Analysis
7.5.1 Summary Statistic
7.5.2 Standardized Residual variance
7.5.3 Scale
7.5.4 Misfit Order
7.5.5 Wright Map Discussion
7.5.5.1 Comparison between the Wright-Map of Practitioner Suggestions and Student Ability
7.6 Overall Lessons Learned
7.7 Person Analysis
7.8 Conclusion

8 CONCLUSION AND FUTURE WORK
8.1 Introduction
8.2 Summary of the Research Process
8.3 Synthesis the Objectives of the Study
8.3.1 Objective 1
8.3.2 Objective 2
8.3.3 Objective 3
8.4 Conclusion from the Research
8.4.1 Research Contribution to the Society
8.5 Limitations of the Study
8.6 Conclusion and Future Work for Learning and Practise
8.6.1 Future Work for Short and Long Term Projection

REFERENCES

Appendices A - P

DEDICATION

IQRA’, In the Name of ALLAH, The Most Gracious, The Most Merciful.

My special dedication is to my beloved “abang” (Mr. Shazman Asri Shaharuddin), my other main supporters who are “mama” (Hajah Alfah Musa) and “ayah” (Haji Jamaludin Ahmad), my siblings (Azizul Akmal, Nurshazana Akmal, Nurfatihah Akmal and Mursyidi), my mother/father in-law (Mrs. Maria/Mr. Shaharuddin) and all of my relatives who have always offered me words of motivation and love.

I would love to give a big thanks to my daughters Nur Akmal Maisarah , Nur Akmal Mahirah and Muhammad Akmal Khan who were delivered during my PhD duration; they have been with me through all of my difficulties in this PhD journey (those with and without tears). I hope the two of you (and to my future children) will be stronger than me in the future when you too, do your PhD. InsyaAllah. I love you all very much!

ACKNOWLEDGEMENT

In the name of Allah, the Most Gracious and the Most Merciful, I give praise and thanks to Him for supporting me with the strength to complete this thesis, and for providing me with the idea, knowledge, and caring individuals during the study process. Iqra’ statement which recite from surah al-Alaq (al-Quran) give an idea to solve the Software Engineering issues in the first place. This thesis could not have been completed without the recommendations, advice, and suggestions of many people. It may not be possible to mention all of them here, but their contributions, guidance, and support are extremely appreciated.

My deepest appreciation goes to Prof. Dr. Shamsul Sahibuddin for providing me guidance from the moment that I enrolled as a candidate of PhD until the end of my PhD journey. He has taught me a great deal during this PhD journey. I really appreciate his patience in guiding me. I would like to appreciate for his knowledge and experiences shared with me. May Allah bless him always.

In finishing this PhD journey, I made many new friends who gave me encouragement and comforted me through many obstacles these few years in completing my PhD. I thank them for being there for me. The same goes to “Rasch social networking” members who have always supported each other in completing this PhD journey especially to the Adjunct Professor Saidfudin Masodi (University of Ummul Qura’, Makkah) and Dr. Azrilah Abdul Aziz. And I would also like to thank Professor X whom I met at Harvard University for his ongoing support and motivation through emails.

Thank you to my respondents for the interview sessions, pilot study, main study and evaluation. Your input was invaluable to me for this research. I hope that this input and the analysis will help to enhance Higher Learning Education in producing fresh graduates with the knowledge, skills, and attitude employers desire. Last but not least, my deep heartfelt appreciation goes to all my officemates and to anyone who prayed for my success. I am really grateful for it. Finally, thank you to my students who have always been good students to me. Thank you.

ABSTRACT

The success of software project depends on how well it fits the needs of its user and its environment. This research strongly believes that future Requirement Engineering

(RE) engineers should have the necessary generic skills in order to improve the quality of producing Software Requirement Specification. The software industry claims that the software engineering graduates are not able to meet their requirements for employability. Thus, confronting the problems right from the Higher Learning Education level that lead to this disparity will save the software industry the cost of sending new employees for additional training. The objectives of this research are to develop new learning environment model that can be implemented in RE education; construct a prototype namely Electronic Learning Software Engineering System (ELINS) that allows the industry, educators and Software Engineering (SE) undergraduate students to actively communicate and collaborate; and measure the effectiveness of the proposed learning model in teaching RE and enhancing the generic skills of SE undergraduates. This research comprises of pilot and main study to gather the requirement from experience of software industry personnel before evaluating the students after they involve in experimental test. The interview findings from the pilot study provided inputs which guide this research to develop the actual questionnaire for the main study. The study discusses the factors, causes, expected attributes, and importance of allowing undergraduates to improve their generic skills through actual hands-on participation. Rasch Measurement Model’s software, WinStep, is used to analyze the raw data. In experimental test, students are provided with opportunities to practise how to deliver the SRS by doing several case studies from the software industry. The analysis and results have shown a positive improvement of the generic skills among the students who were involved in the Requirement Engineering Project Based-Learning (RE PjBL) model environment compared to those who were taught the course by traditional methods with minimal cost. The results conclude that the RE PjBL which are facilitated by ELINS can enhance student’s knowledge, skills and attitude effectively.

ABSTRAK

Kejayaan perisian bergantung kepada kesesuaian keperluan pengguna dan persekitarannya. Kajian ini percaya bahawa pada masa hadapan jurutera-jurutera Keperluan Kejuruteraan (RE) perlu mempunyai kemahiran generik untuk meningkatkan kualiti menghasilkan Spesifikasi Keperluan Perisian. Industri perisian mendakwa bahawa graduan kejuruteraan perisian tidak dapat memenuhi keperluan untuk mendapat pekerjaan. Oleh itu, masalah yang dihadapi perlu diperbetulkan bermula dari Pengajian Tinggi Pendidikan bagi menjimatkan kos industri perisian menghantar pekerja-pekerja baru untuk latihan tambahan. Matlamat kajian ini untuk membangunkan model baru bagi persekitaran pembelajaran yang boleh dilaksanakan dalam pendidikan RE; membina prototaip Sistem Pembelajaran Perisian Kejuruteraan Elektronik (ELINS) yang membenarkan industri, para pendidik dan pelajar Kejuruteraan Perisian (SE) untuk berkomunikasi dan bekerjasama secara aktif; dan mengukur keberkesanan model pembelajaran yang dicadangkan dalam pengajaran RE dan meningkatkan kemahiran generik pelajar SE. Kajian ini terdiri daripada kajian perintis dan kajian utama untuk mengumpul pengalaman daripada kakitangan industri perisian sebelum menilai pelajar selepas mereka terlibat dengan ujian eksperimen. Kajian temu bual perintis telah memberi input kepada penyelidikan ini untuk membangunkan soal selidik sebenar kajian utama. Kajian ini membincangkan faktor, sebab-sebab dan akibat, sifat-sifat yang dijangkakan, dan kepentingan yang membolehkan pelajar untuk meningkatkan kemahiran generik mereka melalui pengalaman-sebenar. Perisian Model Pengukuran Rasch ini, WinStep, digunakan untuk menganalisis data mentah. Dalam ujian eksperimen, pelajar berpeluang mengamalkan dan menyampaikan SRS dengan melakukan beberapa kajian kes industri perisian. Analisis dan keputusan telah menunjukkan peningkatan positif kemahiran generik di kalangan pelajar yang terlibat dalam persekitaran model RE PjBL berbanding mereka yang dilatih dalam kaedah- kaedah tradisional dengan kos yang minimum. Kesimpulan keputusan-keputusan menunjukkan bahawa RE PjBL yang dipermudahkan oleh ELINS dapat meningkatkan pengetahuan, kemahiran dan sikap pelajar yang berkesan.

LIST OF TABLES

2.1 Issue and Available Solution in Requirements Engineering Practice
2.2 The Trend Over the Past 15 Years by Standish Group’s CHAOS (2009) Report
2.3 Software Industry Skills for Domestic Market at Various Phases of Software Industry Diffusion (Raina, 2007)
2.4 Problems in The Software Industry
2.5 Common Elements of Various Listings of Generic Skills (Curtin, 2004)
2.6 e-Learning in Western Countries (Pegden, Shannon, & Sadowski, 1995)
2.7 Availability of e-Learning in Selected Malaysia Universities (Retrieved in 2010 and 2014)
2.8 Computer Supported Collaborative Learning (CSCL) features for e- Learning (Retrieved in 2010)
2.9 Comparison Theoretical Framework Description (Kolb & Kolb, 2005; Schellhase, 2006)
2.10 The Comparative Study of PjBL in Malaysia
2.11 The Comparative Study of Project-Based Learning in Developed Country
2.12 Similarity Element of Successful Learning

3.1 Research Structure Attributes
3.2 Suggested Contents in the Questionnaire (refer Appendix F and G)
3.3 Types of Measures
3.4 Scale Types and the Properties (Morasca, 2010)
3.5 General Data Analysis Strategies Adapted from Cresswell (2003) and Tobi (2011)
3.6 A Qualitative Structure Adapted from Tobi (2011)
3.7 The Correlation between Factors, Causal, Expected Attributes, and Importance of Industry Practice to Improve Skills
3.8 Sample Population
3.9 Traceability Matrix of Research Objectives (RO) and Method Used

4.1 List of MSC companies (MDEC, 2011 & 2013)
4.2 Target Respondents in the Pilot Study for Quantitative Analysis
4.3 Target Respondents in the Main Study for Quantitative Analysis
4.4 Problems in the Undergraduate Checklist
4.5 Current Practice in Industry Checklist
4.6 Suggestions for Enhancement Checklist
4.7 Content Validity
4.8 Demographic Background of Section A (A)
4.9 Project Experience Information (Section A (B))
4.10 Structure Calibration before Collapsing
4.11 Collapsing Process
4.12 Structure Calibration after Collapsing
4.13 Item Category, Option, Distracter Frequencies: Measure Order (1)
4.14 Summary of Initial Fit Statistics in the Rasch Analysis (N = 32, I =110)
4.15 Initial Standardized Residual Variance (in Eigenvalues units)
4.16 Improvement of Standardized Residual Variance (in Eigenvalues units)
4.17 Consolidated Item Misfit based on the Largest Standardization Residual
4.18 Largest Standardized Residual Correlation
4.19 Summary of Measured 33 Items
4.20 Summary of Measured 27 Persons
4.21 Item Contribution for Assessment
4.22 Item Contribution for General Activity Using the Traditional Method
4.23 Items Agreed by Beginners
4.24 Dimension Agreed by Minor Leader
4.25 Dimension Agreed by Major Leader

5.1 Item-Person Summary Statistic (N = 88, I = 43)
5.2 Item Misfit
5.3 Item Misfit in Similar Dimension
5.4 Item Statistic for Measure Order
5.5 Most Unexpected Responses by Item
5.6 Person Misfit
5.7 Dimension and Items Calibrated with More Than 0.0 Logit ItemMean
5.8 Dimension and Items Calibrated Below 0.0 Logit ItemMean
5.9 Item Summary Statistic Before and After Data was Cleaned
5.10 Person Summary Statistics (N = 50 (non-extreme), 62 (extreme and non- extreme, I = 33)
5.11 Largest Standardized Residual Correlation Used to Identify Dependent Item

6.1 Computer Supported Collaborative Learning (CSCL) features for ELINS
6.2 Requirements Identification
6.3 Traceability between Use Case and Stakeholder
6.4 Software and Hardware Specifications for the ELIN System
6.5 Public User Description in ELINS

7.1 Initial Case Study
7.2 Case Study I
7.3 Case Study II & III
7.4 Mini Project
7.5 Summary Statistic for Item-Person Interaction
7.6 Standardized Residual Variance (in Eigenvalue Units) for 50 Persons
7.7 Standardized Residual Variance (in Eigenvalue units) for 42 Persons
7.8 Item Statistic: Misfit Order
7.9 Frequency Analysis on Male and Female

LIST OF FIGURES

2.1 Top Entry-Level Skills Desired by the Employers (Abraham et al., 2006)
2.2 Education System by Owlia and Aspinwall’s (1998)
2.3 A Full Range of Software Engineering Trends (Boehm, 2006)
2.4 Kolb Experiential Learning. Adopted from Healey & Jenkins (2000)
2.5 Problem-Based Learning, Individual & Collaborative Problem Solving and Product-Based Learning are a subset of Requirements Engineering Project-Based Learning
2.6 Factors Influencing the Software Design Process (Curtis, Krasner, & Iscoe, 1988)
2.7 The Architecture of the System Prototype

3.1 Research Procedure (1)
3.2 Research Procedure (2)
3.3 Best fit line: Linear Regression Model
3.4 Types of Survey Research. Adapted from Tobi (2011)
3.5 Types of Survey Research. Adapted from Tobi (2011)
4.1 Sampling Unit of Personnel involved in MSC Software Industry
4.2 Software Industry Practitioners Perceptions
4.3 Questionnaire Development and Survey
4.4 Metadata of the Questionnaire Development
4.5 Current Practice in Requirements Engineering Industry
4.6 Wright Map Analysis: Initial Analysis
4.7 Before and after Collapsing in 5 Response Category Curve
4.8 Collapsing Rule
4.9 Category Probabilities: Modes - Structure measures at intersections
4.10 Pilot Study Wright Map
4.11 Item - Map - Person
4.12 Initial RE PjBL Attributes from Pilot Study to Enhance Generic Skills

5.1 Probability of Response
5.2 Wright Map for Preliminary Analysis
5.3 Rating Scale after Data Cleaned
5.4 Final Wright-Map
5.5 RE Project-Based Learning Model derived From Software Industry
5.6 Initial RE PjBL Attributes to Enhance Generic Skills From Main Survey

6.1 Initial RE PjBL Attributes with ELINS to Enhance Generic Skills
6.2 Framework of Academia-Industry Collaboration in RE Facilitated by ELIN System
6.3 ELIN System Process Flow
6.4 The Architecture of the ELIN System
6.5 Physical Architecture for the ELIN System
6.6 Class Diagram
6.7 Sample for Main Page of the ELIN System
6.8 Add New Project
6.9 Lecturer Interface for View Project
6.10 Assign Project to the Student
6.11 Student View

7.1 Evaluation Process
7.2 Measure Relative to Item Difficulty
7.3 Wright Map for Student Evaluation
7.4 RE PjBL based on Industry Perspectives and Perceived by Student
7.5 Final RE PjBL Attributes with Electronic Learning Software Engineering (ELINS) System to enhance Generic Skill
7.6 Guttman Scalogram of Person Response

8.1 Summary of the Research Process
8.2 Future Students Learning Process Trend Repetitively
8.3 Future Work for Within 5 Years

LIST OF APPENDICES

illustration not visible in this excerpt

LIST OF ABBREVIATION

illustration not visible in this excerpt

CHAPTER 1

INTRODUCTION

1.1 Overview

This thesis focuses in Software Engineering (SE) field on the issue of enhancing undergraduate generic skills to better prepare them for their future employability. Regrettably, there are gaps between what is currently being taught to undergraduates in Higher Learning Education (HLE) and what is being demanded by the software industry (Haron et al., 2013; Gorschek et al. (2012). These gaps need to be identified and addressed accordingly so that there will be a satisfactory match between what is being taught in HLE and what is sought after and needed by the software industry.

After reviewing the literature, it has been recognized that it is time that some new learning methods be adapted to replace the traditional methods of learning. This research proposes a learning method which is more effective in order to produce better qualified and more efficient graduates, who are not only good at academics but also equipped with the required practical skills. For that reason, this research believes that Requirements Engineering Project-Based Learning (RE PjBL) has to be the learning method to be implemented as it is known to have the potential to cater to the accelerating changes in technology.

RE PjBL is considered to be a superset of Problem-Based Learning, Individual & Collaborative Learning and Product-Based Learning methods in which all of these subsets are interconnected with one another. The students do not only acquire knowledge to excel in their academics, but RE PjBL also enhances students’ skills by undertaking real projects in a RE PjBL environment.

In order to ensure that the RE PjBL is being implemented successfully, this thesis proposes a prototype, namely the Electronic Learning Software Engineering (ELINS) system, be designed as a supportive tool to assist students in doing their projects. It is also suggested that ELINS may be able to help students in experiencing learning, as well as the practical work to carry out the Requirements Engineering until they are able to produce the deliverables called the Software Requirements Specification (SRS).

1.2 Background of the Problem

The software industry has identified that Requirements Engineering (RE) has the biggest impact on software development (Mauger et al., 2010). The importance of RE has been discussed by Thakurta (2013) that reflected about the problems of wrong guessing requirement. Woody (2008) mentioned that only few software developers have been educated as to how to elicit, analyze, document, and verify the quality of the requirements. Boehm (2006) implies that the engineers in the past did not practice to produce the standard Software Requirement Specification (SRS). The critical success factors of software system depend on how well it fits the needs of its user and its environment (Leonard, 2011).

Therefore, this research strongly believes that the future RE engineer should have the necessary generic skill that suggested by Curtin (2004) in order to improve the quality of producing the SRS. HLE should establish a more relevant platform to better educate people on the importance of RE. Though, there is a vast difference between the performance of software developers within the software industry and students in their final year at the university practice RE. In addition, the student will only experience to practice RE in their final year project without other experience or practice. Jiang, Eberlein and Far (2008) argues several challenges in addressing the RE techniques not suite for all projects type. The current trend in education reveals that just because students have a high Cumulative Grade Point Average (CGPA) does not guarantee that they have the right skills. This situation may imply that graduates leaving the university may need more experience and training before they are able to fully contribute (Regev, Gause & Wegmann, 2008) especially in RE.

For that matter, this research believed that Software Engineering Education (SEE) in Malaysia has some weaknesses in preparing students to possess all of the necessary generic skills that potential employers (Rugarcia et al., 2000) in the software industry are looking for. In addition, most students tend to lack an understanding of the processes in the requirements phase and delivery of the output in SRS.

This research identified the gap between working and learning experience through software industry personnel before evaluate with undergraduate students (who are learning the requirements). Such a study could disclose exactly what areas are lacking and whether they require more information or experience and training in meeting industry demand.

In assessing students, there should be an evaluation tools which fulfils the requirements of the industry and the academic outcomes. Researchers have discovered that there is no repository or database that can support and keep track of the continuity of student projects although there are some tools that support RE processes and other developments. In an effort to help enhance student skills for employability, this research also suggests that HLE should identify whether their infrastructures are equipped to effectively support the learning environment.

In order to achieve this objective, an alternative learning method should be employed in order to ensure the enhancement of student skills. This research believes that students can increase their knowledge, skills, and attitude by implementing the RE PjBL. The RE PjBL would allow students to learn and gain experience faster. The most suitable RE PjBL will be discussed in detail by conducting a comparative study with other universities. Many universities in developed countries for example, Oregon State University in the United States has successfully implemented the collaborative and PjBL features (Wolff, 2001; Faulk, 2000). RE PjBL categories are the most successful method of helping students experience a realistic working environment. In addition, this research believes that providing the right kind of projects can help to enhance students’ skills both now and in the future.

Everything starts with education. Better education will have a big impact on the software industry. A good educational system should be able to produce students with the skills and knowledge required by the industry (Rugarcia et al., 2000). For example, with the proper training, graduates may not find it necessarily to seek additional training after graduating in order to improve their skills. This research believes that as a result, the quality of employment will improve dramatically.

1.3 Problem Statement

Currently, both the news and the social media (Hassanbeigi et al., 2011) have publicized the fact that many students have not been given the necessary skills they need because they were not taught the subjects that are relevant within the industry itself. Therefore, it was difficult to have the relevant studies conducted on student skills which are not relevant with their CGPA or subject grade (Martin et al., 2008). In identifying the focus of this research, the software development life cycles were specifically reviewed. Apparently, most of the literature has shown that most of the shortcomings reside within the requirements phase. The success of the requirements phase should have been accommodated by the process, namely a requirement engineering. For this reason, HLE faces the dilemma of providing graduates with the necessary generic skills for the industry, especially the software industry. This issue has been confirmed by software industry personnel who have experiences in both HLE and the industry (Brown et al., 2008). The problem may be due to the learning method, or the mechanism which is not facilitates the collaboration between academic and industry.

1.4 Research Questions

Based upon the background and the statement of the problem, this research aims to answer the following three research questions:

(i) Do students have ample knowledge and skill in learning the Requirements Engineering subject? What are the current methods used by the HLE in assessing student performance? What are the weaknesses in the current learning method?
(ii) What is the proposed model that can enhance student skills for employability by improving the learning method? Is it suitable to implement the new model in SEE? How effective is the proposed model to RE projects and in enhancing student skills for employability by replacing the current failed method? What types of projects can meet the industrial demand in developing the SE undergraduate skills through experiencing and by encountering real problems in the software industry?
(iii) How practical is the system in facilitating students to be connected with the industry and the lecturers?

1.5 Objectives of this Research

The aim of this study is to answer the research questions that address the issue from the research problem. This research is aimed at identifying the weaknesses and gaps in the Requirements Engineering Education (REE), and finding a solution to the problem.

In short, three objectives will be addressed in order to accomplish the primary research questions of this investigation which are outlined as follows:

i) To develop a model for RE PjBL that can be implemented in REE based on weaknesses identification within the current practice of learning Software Engineering.
ii) To construct an ELINS prototype that will allow the industry, educators, and students (Software Engineering undergraduates) to capture and effectively retrieve the changes (major or minor) in RE student projects.
iii) To measure the effectiveness of RE PjBL in teaching RE and enhancing the generic skills of SE undergraduates.

1.6 Scope

Since the duration of this research was limited, the scope of this research has been established. The research only focuses on:

i) RE in SEE.
ii) Using Malaysia as country which has aggressively enhanced their technology and systems in many aspects such as education, engineering, research, medical, and aerospace.
iii) The effectiveness of RE PjBL which will be implemented in RE for SE undergraduates or students that registered in subject SE.
iv) The usability of the ELINS in facilitating RE PjBL.
v) The ELINS that can be viewed by public users such as

- industry (who can provide instant feedback about projects to the students),
- educators (the lecturers who will teach the Requirements Subject)
- students (Software Engineering undergraduates studying RE)

1.7 Importance of Research

The importance of this research is to help reduce the gap between academia and industry in terms of the required generic skills. Therefore, the rationale for this research should be achieved based on the research objectives within the scope discussed in the previous Sections 1.5 and 1.6. This research would give an added value to the Software Engineering Body of Knowledge (SWEBOK, 2008).

In addition, the attributes from the proposed model, namely RE PjBL, will be measured. Based on these measurements, the RE PjBL attributes will be used as a stepping stone to enhance students’ generic skills (Hassanbeigi et al., 2011). In turn, the enhancement of student skills should help the software industry’s demand in terms of graduates’ employability (Almi et al., 2011). The tool proposed, which is the ELIN system, will be the medium for a collaboration between HLE and the software industry. The student will learn and practice the required engineering skills beyond that of the traditional method.

1.8 Contribution

The novelty of this research include:

i) to propose the model RE PjBL in REE. By using this method, REE can carefully plan effective strategies to enhance the SE undergraduate’s skills (see Appendix A).
ii) to provide a tool, namely the ELINS in facilitating the RE PjBL. The ELINS will help the students to learn and practice how to use the Software Requirements Specification (SRS). Software industry personnel will provide the existing requirements and also be involved whenever additional dialogue becomes necessary (See Appendix A).

1.9 Structure of Thesis

This thesis is divided into seven distinct chapters. Each chapter will apply the concept of cross reference which will be interconnected with one another.

Chapter 1 introduces the niche area of this research. The discussion is made by identifying the background problems, problem statement, research questions, research objectives, importance, contribution, and scope of this research.

Chapter 2 provides a detailed overview of the RE importance, definition, and process. Then, Software Engineering Education is reviewed. Some of the learning methods are also discussed. The preliminary conclusions of the gaps and attributes for the RE PjBL are identified.

Chapter 3 describes the details of the research design within the research process. The method of selecting the sampling unit is discussed thoroughly. The duration of the pilot and the main study are also clarified.

Chapter 4 illustrates the actual process derived from Chapter 3. This chapter will show the results and analysis from the pilot study. The validity process and triangulation of the literature review and interview input were in place before executing the pilot study. The purpose of the pilot study is to identify the reliability and validity to help in the development of the study’s questionnaire. At the same time, the initial model of RE PjBL will be proposed using a Wright map.

Chapter 5 shows the gaps were initially discussed and confirmed by the main study. At the end of this chapter, a person from the software industry will analyse in detail to show the competence level using this diffusion theory. In addition, the requirements of the ELIN system were successfully derived.

Chapter 6 discusses the prototype of the ELINS development. The academia- industry collaboration using ELINS is also explained in detail. The requirements identified in Chapter 5 were used appropriately. The figure and manual processes were described accordingly. At the end of this chapter, the Graphical User Interface (GUI) is shown based on the stakeholders involved in the ELINS that include Industry Personnel, Lecturer and Student interface. The GUI will explain the system from the start until the end process.

Chapter 7 discusses the student evaluation. The student evaluation was implemented on the student who was involved in the experimental design. In the experimental design, the participants were separated into two distinct groups, namely the focus group and the control group. Students in the control group were taught using the traditional method, while students in the focus group were taught using the RE PjBL. Then, the student evaluation was analysed and the results discussed.

Chapter 8 summarizes all of the achievements of the research objectives. Finally, the research contribution and future work are discussed.

1.10 Conclusion

This section successfully details the problem background, problem statement, research questions, research objectives, importance of the research, contribution, and scope/limitation/assumption. The next section will examine the literature review in relation to the research questions.

CHAPTER 2 LITERATURE REVIEW

2.1 Introduction

The main flow of the research direction in getting the result is based on several steps (Gregorio, 2000). Firstly, reading, reflecting on, and extracting ideas from articles/books is a compulsory task. Then, the literature is organized into a meta-analysis in order to identify the sequence of the historical view which reflects on and critiques particular pieces of literature to help identify any gaps or problems in the study. Finally, a conclusion is made by building up arguments that should trigger the research objective and research questions.

In this Chapter 2, the main topic will cover about RE importance in Section 2.2, SEE in Section 2.3 and learning method in Section 2.4. The subsection has been produced in detail to discuss each main section.

2.2 The Importance of Requirements Engineering

In order to determine if a requirements statement is sufficiently well defined, it is necessary to read it from the developer’s perspective. If additional clarification is needed from the Software Requirements Specification (SRS) author in order to understand the requirements well enough to design and implement it, then the requirements should be expounded before proceeding with the construction. The activities and issues of RE are defined in the next Section 2.2.1.

2.2.1 Requirements Engineering Definition

RE is the most important activity in the development of large-scale systems (Konrad & Gall, 2008). High-quality requirements are important. The requirements serve as a baseline among multiple teams on the product that needs to be developed, and provides a basis for planning, validating, and testing. This is supported by the findings of Damian, Hadwin & Al-Ani (2006) study which used quantitative (project metric) and qualitative (engineer perception) methods. Their findings showed that RE practice produces long term benefits and impacts throughout the project. Kamsties, Klaus, & Schlich (1998), Sadraei et al. (2007) and Berenbach et al. (2009) highlight three reasons for the importance of RE.

Firstly, RE highlights the importance of "real-world goals" that motivate the development of a software system. These represent the 'why' as well as the 'what' of a system. Secondly, it puts forth the "precise specifications". These specifications provide the basis for analysing requirements, validating that they are indeed what stakeholders want, defining what designers have to build, and verifying that they have been done correctly upon delivery. Finally, the RE provides the specifications' "evolution over time and across software families" which emphasizes the reality of a changing world and the need to reuse partial specifications, as engineers often do in other branches of engineering.

Berander, Khan & Lehtola (2006), Cheng et al. (2009), and Khan & Zulkernine (2009) present five critical factors in RE:

1) Software artifact: ideally requirements descriptions are written entirely in terms of the environment. The environment is to be affected by the propose system.
2) Scale: refers to complexity where cyber-physical systems are a new generation that needs to be highly dependable, efficiently produced, and capable of advanced performance in information, computation, communication, and control.
3) Self-adaptive: a system that responses to conditions, such as hardware/software failure, and able to change and self-regulate with minimal human intervention.
4) Improve software security: to avoid vulnerabilities, to protect systems and information, and to defend/recover from an attack, as computing systems are increasingly becoming more pervasive, mobile, and automated.
5) Trend of globalization: capitalize upon global resource pools, decrease cost, exploit twenty four hour work days and become geographically closer to the end-consumer.

In view of the fact that requirements are the baseline for activities in the software development lifecycle, Section 2.2.1.1 will discuss more on how the RE activities should be executed in getting the right requirements.

2.2.1.1 The Activities in Requirements Engineering (RE)

RE encompasses all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system. The term engineering implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent and relevant (Sommerville & Sawyer (1997); Wiegers (2009)).

The requirements elicitation subarea includes requirements capture, discovery, or acquisition. It concerns as to where requirements come from and how they can be collected by the software engineer. Requirements elicitation is the first stage in building an understanding of the problems that require the software to solve (Bourque et al., 1999). Nomura Research Institute (NRI) is a system integrator company that mainly deals with service business information systems such as distribution systems, and financial systems. NRI strongly recognizes that RE processes, such as requirements elicitation and verification are essential for successful projects (Arao, Goto, & Nagata, 2005).

The requirements analysis subarea is concerned with the process of analyzing requirements (Mauger et al., 2010) which are used to detect and resolve conflicts between the requirements captured. Besides, the requirements analysis is used to discover the boundaries of the system and how it must interact with its environment, and to clarify user requirements (Lemos et al., 2013) of software requirements.

The requirements validation subarea checks for omissions, conflicts, and ambiguities and ensures that the requirements follow prescribed quality standards Ramesh, Cao & Baskerville (2010). The requirements should be necessary, sufficient, and described in a way that leaves as little room as possible for misinterpretation Paulish, Kazmeier, & Rudorfer (2009).

The requirements management subarea spans the whole software life cycle Hong, Kim & Lee (2010). It is fundamentally about the change management in maintaining the requirements in a state that accurately mirrors the software that will or that has been built (Wnuk, 2012).

Without accurate, consistent, and complete requirements specifications, it is very difficult to develop, change, and maintain software. It is now a generally accepted and frequently stated fact that one of the major causes of software development failures is poor RE. Requirements related problems are considered to be persistent, pervasive, and costly. In many cases these problems are due to the failure of the RE processes to effectively manage requirements knowledge and information, and failure to deploy the most appropriate techniques (See Section 2.2.2).

2.2.2 The Issue Arose in Requirements Engineering (RE)

RE is the activity that involves capturing, structuring, and accurately representing the client’s requirements in a manner that can be effectively implemented in a system that will conform to the client’s specifications (Pohl, 2010)

The importance of RE emerged when Weiger (1999) and Ramzan, Jaffar, & Shahid (2011) exposed the problem faced by software developers in attempting to guess the requirements required by the stakeholders. The problems of wrong guessing can create a lot of extra work.

Wiegers (1999) stated that many SRS are filled with badly written requirements. This can cause a lot of problems because the quality of any product depends on the quality of the raw materials (which is the requirements from the stakeholder) being fed into it. If poor requirements are captured and written, then the bad requirements cannot lead to the creation of excellent software. Some authors like Woody (2008) mentioned that only few software developers have been educated as to how to elicit, analyze, document, and verify the quality of the requirements.

In the history of RE which began in 1970’s (Boehm, 2006), there was no question or concern about the methods on how to create, understand and ratify the requirements specification. The situation implies that the engineers in the past did not have the specific training/exercise to produce the specifications. Thus, the engineers were not able to produce the standard SRS.

Al-Rawas & Easterbrook (1996) stated the problem of a lack of effective standard SRS was shown to have been caused by communication barriers between the stakeholders and the analyst (Pa & Zin (2011)). The barriers of communication will inevitably have an impact on how to capture and analyze good requirements (Wiegers, (2009)).

However, Cheng et al. (2009) explained that product developers want to be able to adapt and enhance the product rapidly, in response to the changes both in the user requirements and environmental conditions. In such situations it can be difficult to decide exactly which problems should be tackled and it can be difficult to reach an agreement among the stakeholders. This is because Ko et al. (2011) claimed that the reason for the problem came from the stakeholders, that is due to the stakeholders’ (end-users’) different backgrounds such as culture, education, training, experience, age, abilities, and disabilities.

After fifty years of Boehm (2006) experience, Boehm realized the importance of clear and unambiguous requirements (refer Figure 2.4). However, many organizations ignored the problem as they managed to guess the requirements correctly half of the time. These organizations then rushed headlong into writing code without understanding how the actual system should be developed.

Despite the significant progress that has been made in software development, software projects still suffer from some problems like over-budget, late delivery, and poor quality. The critical success factors of software system depend on how well it fits the needs of its user and its environment (Leonard, 2011). Such human activities may be complex because they generally involve many different types of people, with conflicting interests. In such situations it can be very difficult to exactly decide which problem should be tackled, and it can be arduous to reach an agreement among the stakeholders.

Raatikainen (2011) and Bouillon, Mader, & Philippow (2013) highlighted that the statement of requirements normally contains several requirements and are not specific to a particular statement of requirements that are gathered from the stakeholders. This can cause the test case to fail, because the test case needs to address the specific requirements specification.

In conclusion, issues in relation to RE (See Table 2.1 and Table 2.2) that have emerged over the years have been briefly described in Section 2.2.2 and these issues involved the elements of developer, stakeholder background, environment, communication, requirements process, and requirements specification deliverables that were being in placed. The next section (See Section 2.2.3) will discuss the RE practice in the software industry in more detail.

Table 2.1 : Issue and Available Solution in Requirements Engineering Practice

illustration not visible in this excerpt

2.2.3 Requirements Engineering Practice in the Software Industry

Gorschek et al. (2012) proposed that the Software Development includes three main aspects that involve people, process, and technology. A related study was carried out by Solemon, Sahibuddin, & Ghani (2010) and Haron & Sahibuddin (2010) related all four aspects (strength, weaknesses, opportunity and threat) to the people, process, and technology in the Malaysian public sector in the Software Development. In Haron et al. (2012) study, the findings have indicated that there is a highly urgent inadequacy in the technical skills (people), change management (process) and RE (technology). For that reason, this study will only focus on these three aspects which will detail out a strategy to overcome the issues as there are no recommendations for the opportunity in Haron’s study (2012) to overcome the weaknesses, which is by approaching the Software Engineering Education.

A software development project should not only be the responsibility of the project manager as mentioned in Haron et al. (2012) and Nasir & Sahibuddin (2011). The software development project should be the responsibility of all team members to ensure the success of the project. As an example, the project manager only looks at the timeline, but if the developer or system analyst has a problem such as not having the required technical skills and need more training in order to develop those technical skills, then the timeline will be delayed. At the same time, it will directly lead to cost overrun. For that reason, the supposedly technical skilled person should be trained during their higher learning education and the issue can be overcome from the beginning. This will allow the project to run successfully because everyone is aware of his/her role and understands the process as well as able to deliver the right requirements before going into the development stage. However, Haron (2012) also said that sometimes the reason for the problem is that the project managers did not fully know what the users wanted.

There can be many types of project backgrounds since the project is different according to public (Haron et al., 2013), private and open (Gorscheck et al., 2012) sectors. And each project has its own rules and regulations. However, the template should be similar and only needs a little rearrangement here and there to fit the expected requirements. The product nowadays cannot be fixed into one type of product that is specified for a client. Nowadays, many well-known products do not have a specific client such as Apple Iphone and Samsung Note. A survey needs to be conducted to produce the first version of the product and some feedback about it needs to be collected from unknown clients (Ko et al., 2011). As such, students should be able to experience situations that deal with many types of project backgrounds. This experience will help students in doing a preparation of Requirements phase before going into the developmental phase. This would reduce the cost of training new employees to have technical skills, especially in preparing the requirements deliverables. As a conclusion to those rules, all tasks that trigger more than one task should be separated into different projects in order to ease the monitoring, controlling, and planning.

Information, Communication, and Technology (ICT) have become the key enabler in business success, and are the essential elements in the foundations of today’s dynamic business environments (Bailey & Mitchell, 2006). As the software industry offers more opportunities and strategic value to organizations, the demand for quality software industry professionals is increasing. Even though institutions continue to produce IT graduates, there is a shortage of quality software industry graduates (workforce) produced by the institutions that can meet the demands as mentioned by Brown (2008). As a result, the issue of the non-employability of the software industry workforce has worsened. The understanding of employability must be clear in this aspect, and can be defined as the extent to which employees have skills that the market and employers look for (Vos, Hauw, & Heijden (2011). The reasons behind focusing on the software industry workforce employability are the adequate supply of a skilled software industry workforce and the utilisation of software industry skills to a greater extent, can both help fuel economic growth in every country (Heijden, 2010). Society is increasingly dependent on software. Jackson, Thomas, & Millett (2007) mentioned that software failures can sometimes cause serious accidents that result in death, injury, significant environmental damage, or major financial loss, especially in transportation, health care, and broader infrastructures.

The Standish Group’s (2009) report shows in Table 2.2 marked the decrease in project success rates, with:

i) 32% of all projects surveyed were successful - defined as projects delivered on time, on budget, with required features and functions.
ii) 44% of all projects surveyed were challenged - defined as late, over budget, and/or with less than the required features and functions
iii) 24% of all projects surveyed failed - defined as cancelled prior to completion or delivered but never used.

Table 2.2: The Trend Over the Past 15 Years by Standish Group’s CHAOS (2009) Report

illustration not visible in this excerpt

Software plays a central role in almost all of the aspects of daily life: in government, banking and finance, education, transportation, entertainment, medicine, agriculture, and law. Different development locations and cultures react differently to change (Konrad & Gall, 2008). The longer a location works with similar tools and processes in a culture well protected from the outside, the more difficult it is to change. Such continuous learning impacts motivation and thus reduces turnover rates. Keeping turnover rates low is clearly a key objective in dealing with legacy software, otherwise nobody has the necessary long term view.

Boehm (2006) identified eight surprise-tree trends and two “wild card” trends that would strongly influence future software and system engineering directions (refer Figure 2.4). Two of the eight surprise-tree trends will be covered under 2010’s which is about global connectivity and massive system of systems. Thus, Crawford (2001) and Trauth & Quesenberry (2007) argued about the readiness of complementaries of skills in such area as culture-matching and localizations. Harned & Lundquist (2003) claimed that SE involved low software product and process adoption rates across cultures that include power distance, individualism/collectivism, masculinity/femininity, uncertainty evidence, and long time orientation. Companies attempt to tackle three main problems: cost minimization (finishing a project within budget), tight deadlines (finishing a project within schedule), and a quality product (delivering the product with minimum defects). An engineering approach in software development will help them to overcome these problems. Those categories of problems indirectly will contribute to the issue of manpower in the software industry. The lack of skill demand will be discussed in the next section (See Section 2.2.3.1).

2.2.3.1 Skill Demand in the Software Industry, Malaysia

In general, developed countries such as those in European and North America are leading other countries in Asia Pacific in term of software industry growth worldwide. Following is the discussion about the development of the software industry in Malaysia.

If this research narrow down the scope of the study by looking at the growing software industry countries, seven countries show a positive growth (Raina, 2007). They are comprised of Russia, India, China, Vietnam, Malaysia, Indonesia, and Philippines. The population of Russia, India, China, and Indonesia is greater than that of Vietnam, Malaysia, and the Philippines. For that reason, this research was established in Malaysia as a growing software industry country. Table 2.3 shows that Malaysia is included in the growth phase of the software industry diffusion with six other countries. In growing software industry countries, the importance of the software industry skills which include IT application, infrastructure, security and usage are predominantly required for the domestic market (See Table 2.3).

Table 2.3 : Software Industry Skills for Domestic Market at Various Phases of Software Industry Diffusion (Raina, 2007)

illustration not visible in this excerpt

[...]