Requirements engineering (RE) is the engineering discipline concerned with establishing the requirements that will form the basis of the software development process. This brought about changes in requirements engineering processes such as requirements elicitation, requirements analysis, requirements specification and requirements validation.
LIST OF TABLES
LIST OF SYMBOLS /ABBREVIATIONS
LIST OF APPENDICES
Introduction
Agile requirements engineering practices enable the software development team to develop incrementally, iteratively, and deliver products in a shorter time compared to traditional RE. This paper will examine how companies from different parts of the world and from different industries and sizes adopt agile requirements engineering processes and the types of challenges they face.
Problem Statement
These studies, although not from Malaysia, reported that there are challenges and limitations in adopting Requirements Engineering processes, namely requirements elicitation, requirements analysis, requirements specification and requirements validation in development projects following Agile practices. Recently, Rahman et al. 2014) studied requirements engineering practices and challenges in the Malaysian public sector from a stakeholder perspective.
Project Aim
Project Objectives
Overview of Requirements Engineering
Examining the role of Requirements Engineering in Software and Systems Engineering
Agile Manifesto
Types of popular Agile approaches available
Another proven agile methodology framework popular in software development is Extreme Programming (XP). These are three types of popular agile methodology prevalent in the software development industry.
Comparison with Agile versus Traditional Approach
The primary responsibility for triaging content backlogs, product issues and making decisions about whether to accept a proposed change in requirements rests with the customer (Wiegers and Beatty, 2013).
Requirements Engineering Application in Agile Software Development
- Requirements Elicitation
- Requirements Analysis
- Requirements Specification
- Requirements Validation
- Summary of the Application of Requirements Engineering 2.6.1 Requirements Elicitation
- Summary of the Application of Requirements Engineering (Cont.) 2.6.3 Requirements Specification
Bjarnason, Wnuk, and Regnell (2011) further implemented an integrated RE practice, enabling required engineering task activities to be performed concurrently with other development activities, an example being detailing and formal documentation of requirements that should be worked on at the same time as feature design and development. Moreover, in Melegati et al. 2019), where requirements assessment is considered a crucial stage for start-ups, most interviewees answered that some kind of requirements validation has been done with little or no development with applied techniques such as wireframes, minimum viable product (MVP), models, prototyping and others.
Challenges and Limitations
- Requirements Elicitation
- Requirements Analysis
- Requirements Specification
- Requirements Validation
- Summary of Challenges and Limitations faced in practising Agile RE 2.7.1 Requirements Elicitation
- Summary of Challenges and Limitations faced in practising Agile RE (Cont.) 2.7.4 Requirements Validation
Furthermore, da Silva et al. 2014) show where the lack of business involvement during the requirements analysis process resulted in the “absence of domain and product experts”, suggesting that ensuring the customer is fully involved during the requirements analysis process is critical. In the case of Quispe et al (2010), further exploration is needed to conclude whether the ad hoc process of requirements specification has contributed to loss of requirements or incomplete specifications have arisen due to lack of communication with customers or possibly other reasons.
Conclusion
Introduction
Research Questions
Research Design
First Stage – Secondary Data - Literature Review and Analysis
A common recurring theme is a lack of customer involvement or commitment in the requirements development process, and this gap is subsequently taken up by the developers, who may not have the necessary background or sufficient knowledge about the user requirements to be able to adequately fill them. the gap. Another problem is the lack of proper standard guidelines regarding the process of requirements elicitation, analysis, specification and validation.
Second Stage – Primary Data – Quantitative Survey
- Second Stage – Primary Data – Target Respondents
- Second Stage – Primary Data – Ethical Clearance
If yes is chosen for both questions, they will continue with the rest of the survey. The Likert scale has been constructed based on the analysis of the secondary data, through the application of agile VE and the challenges of VE.
Third Stage – Primary Data – Qualitative Research
The most common or critical issues were highlighted and then constructed into sentences suitable for the Likert scale. The data collected and analyzed in the first and second stages are then used in the construction of the proposed roadmap in the form of a checklist.
Summary
Introduction
Demographic Information and Analysis
- Company / Industry
- Background of Respondents
- Company Culture
Second, the vast majority of respondents can be considered essential team members in an agile team, as they are software engineers, 2 are technical managers or team leaders, and 2 are below others. Based on the collected answers, it was found that all respondents have a certain basic level of understanding of requirements engineering and requirements engineering processes. Do you know the requirements engineering processes: requirements identification, requirements analysis, requirements specification and requirements validation.
Application of Requirements Engineering Processes in Agile Projects
When considering whether requirements verification is an important part of the agile process, all 12 respondents rated it as 4 important and 5 very important. In addition, it can be seen that respondents generally perform checks to ensure that the request documentation meets their expectations. The use of a checklist during the claim validation process is also considered a key point, which was agreed by the majority of respondents.
Challenges of Requirements Engineering Processes in Agile Projects
- Summary of the total influence score for the 13 challenges/resistance factors as rated by the 12 survey respondents
- Ranking of the 13 challenges/resistance factors from the highest to the lowest From the table, it can be seen that the top 3 challenges are inadequate validation, lack of
Respondents are given 5 predetermined options for each resistance factor, ranging from 1 Strongly Disagree, 2 Disagree, 3 Neutral, 4 Agree, and 5 Strongly Agree. Since the majority of survey respondents rated these as 4 Agree and 5 Strongly Agree, representing these responses using the resistance factor will help provide another level of depth regarding the overall level ranking of these challenges. The top-ranked challenges will be further addressed in the proposed roadmap through certain checklist steps to help mitigate these issues as highlighted by survey respondents.
Conclusion
Introduction
Checklist for Requirements Elicitation
Team members' initial engagement will also prove beneficial in ensuring they understand the scope, changes, and technical details of the project (Rasheed et al., 2021). Consideration should also be given to ensuring that sufficient buffer is included in the planning phase of the pre-releases as a way to mitigate demand volatility (Dasanayake et al., 2019). Initiate communication from the start of the project (Rasheed, et al., 2021) &. Schon, et al., 2017) Maintain constant and regular communication between.
Checklist for Requirements Analysis
Provide modeling of the requirements. e.g. Enterprise Modeling, Data Modeling, Domain Modeling, NFR Modeling, etc.).
Checklist for Requirements Specification
2021) suggested that the stakeholders write user stories and case scenarios to better capture the requirements for the software development teams. These tools can help structure requirements capture and align them to different hierarchical levels, ensuring that requirements are adequately collected and well documented (Dasanayake et al., 2019). The last on the checklist on the specification process is similar to the previous processes, namely the review and update of changing requirements according to the Agile manifesto (Beck, et al., 2011).
Checklist for Requirements Validation
Last but not least, reviewing and updating changing requirements according to the Agile Manifesto (Beck, et al., 2011).
Conclusion
Introduction
Interviewees Selection and Background
From the 15 years of work experience, he has 5 years of work experience with Agile, and about 20%-25% of his company practices Agile, with the preferred method being Scrum, or Kanban mostly.
Key Take-Aways
- Current level of Requirements Engineering adoption in their company
- Main challenges faced by the organisation
- Inclusion of risk management
- Providing better clarify, details and examples of the points reflected on the checklist
They also worked to educate stakeholders on how and why these steps are important as part of Agile projects. This is similar to interviewee 1, who said that the organization has a set of project charters, which will remain as their main point of reference during many phases of the project life cycle. Thus, some words and sentences have been restructured or edited accordingly, along with providing concrete examples that best illustrate the statement in the checklist.
Conclusion
This will relate to schedule, budget, process, quality and others; it can be specific to the project, depending on the project's needs and requirements. It has been reconsidered; and the checklist now includes feasibility studies, which are intended for various aspects, such as technical, economic, legal, operational and scheduling. It is a valid concern in the work environment to avoid any form of miscommunication or misinterpretation.
Introduction
Discussion on Research Objectives
To synthesize the challenges, constraints and impacts of Requirements Engineering processes in Agile-based projects. In Objective 3, the proposed roadmap was formed by the various studies using articles, e-journals, books and the combination of the actual survey outcome to be used as an exploratory guide for software practitioners in Malaysia, which certain concerns have with the implementation of requirements engineering process in agile based projects. This gave structure to the proposed roadmap to serve as a foundation checklist in providing the types of processes that can guide the team in properly implementing requirements engineering within the agile context.
Limitation and Recommendation for Future Work
With objective 4, understanding that there may be concerns in proposing the roadmap and how in theory it can be applied but in the real work environment this may not be appropriate or suitable, the research also required some feedback in the form of experts with valuable work experiences in the agile field to evaluate the roadmap and make suggestions for improvements to the roadmap (Section 6). This was done through semi-structured interview with 2 representatives from software companies located in Malaysia (and also different parts of the world) who work with agile and with requirements engineering. Furthermore, they provided positive feedback on the proposed roadmap and expressed optimism that it would prove useful to guide the team leader and team seeking to implement agile and requirements engineering, as the steps are comprehensive and also consistent with their own practice.
Conclusion
A Requirements Engineering Techniques Review in Agile Software Development Methods, International Conference on Computational Science and its Applications [e-joernaal] Julie 2017 pp. On the Pragmatics of Requirements Engineering Practices in a Startup Ecosystem, 2020 IEEE 28th International Requirements Engineering Conference (RE) [e-joernaal] pp Agile and Traditional Requirements Engineering: A Survey, International Journal of Scientific and Engineering Research [e-joernaal] vol 4(9) pp.
APPENDIX A: Ethical Clearance Approval letter
APPENDIX B: List of Companies shortlisted for the Survey
APPENDIX C: Survey Questionnaire
APPENDIX D: Checklist to Guide the Requirements Engineering Process for Software Practitioners in Malaysia
APPENDIX E: Checklist Notes to Guide the Requirements Engineering Process for Software Practitioners in Malaysia.
APPENDIX E: Notes to Checklist to Guide the Requirements Engineering Process for Software Practitioners in Malaysia
Use modeling to support the requirements analysis process (Enterprise Modeling, Data Modeling, Doman Modeling, NFR Modeling). Develop prototypes to serve as a visual medium to understand the requirements of the system, using MVP (Minimum Viable Product) or mock-up to validate the requirements.
APPENDIX F: Interview Transcript – Interviewee 1
So this part of requirements engineering, elicitation, is mainly led by the pre-sales team. For each PI (Program Increment), we will review the requirements before acceptance and select those that will be included in each cycle. Depending on the number of agile sprints, we will refer to the requirements again and again.
Our team will work together to develop or implement requirements; requirements gathering mostly happens in the initial state of the project. Yes, the project document is the high-level project scope and requirements as part of the project management process. Then we will know which things were not specified at the beginning of the project or new requirements would arise.
APPENDIX G: Interview Transcript – Interviewee 2
So, in Agile itself, I would say, for the last 5 years or so, before where I worked, we don't really use Agile methodology. Singapore is trying to use it and Malaysia is, but the rest of the countries in that region don't really follow it. Another thing is that people don't give exact requirements even in interviews, so sometimes you don't get the right information or inaccurate requirements.
Right, it's better than forcing people because if people understand and believe in it, you know, it's more effective. But I've noticed that it's very different in western culture, they practice certification and actually try to embrace it. What about the checklist I developed when proposing a guideline plan, do you think it is sufficient to address all the concerns that respondents have.
