Requirement Engineering Analysis Based on Risk Assessment (Development of Management Information System for Domestic Wastewater in Gresik District)

.Abstract―Public services and the provision of proper and sustainable sanitation infrastructure is one of the basic needs of the community, according to the 2030 Sustainable Development Goal (SDG's) and the 2015-2019 Medium-Term Development Plan (RPJMN), the Government of Indonesia has determined that by 2019 achieving 100% Universal Access in the sanitation sub-sector service in order to accelerate infrastructure development to encourage economic growth and equity. This emphasizes the importance of optimizing water supply and sanitation services and especially the domestic wastewater sector. In the implementation of these services the operator operators often experience obstacles in integrating all business processes due to the limitations of the management system they have. The purpose of this study was to analyze the requirements engineering process with risk analysis and then integrate the system with the concept of enterprise resource planning with a case study of the development of a domestic wastewater management information system in the Public Works and Spatial Planning Office of Gresik Regency. This study uses the stages of preparing Requirements Engineering documents in accordance with ISO / IEC / IEEE 29148-2011 standards and Risk Assessment Analysis with ISO 31000 standards. Software Requirement Specifications (SRS) are then used as a reference in developing systems with an Enterprise Resource Planning (ERP) approach. The results of this study produced 20 risk variables that are relevant with 5 variables included in the high category, 6 variables included in the medium category and the remaining 9 variables included in the low category. Lack of stability, availability, scalability, usability, security, extensibility is one of the risk variables that are categorized as high. Ensuring the merger of all SRS modules to function properly is an action that can be carried out from the results of risk mitigation and becomes a consideration in the incorporation of 9 SRS modules using the Enterprise Resource Planning method.


I. INTRODUCTION
The first step in the requirements engineering process is to collect software requirements, but it is difficult to filter information used from various stakeholders. Engineering requirements have categories in many groups of business requirements, functional requirements, non-functional requirements, performance requirements and security requirements. Although there are advanced technologies, a large number of complex software projects often fail to be produced on time and within budget. Most organizations cancel at least one software project per year at a very large cost, around 66% of projects fail to meet business objectives.
Problems that are often faced by many organizations include not being able to understand stakeholder requirements, unable to define the scope of the project properly, not considering the goals and benefits of the organization, and not having a plan that can help them to achieve the desired goals. These problems arise because the requirements phase is not achieved correctly, the effort applied in the coding phase is not estimated correctly, testing efforts are not properly estimated, team skills are not as expected, modification becomes difficult to send software projects on time that the results are extended on the project delivery date.
At the initial stage, functional requirements represent the way the application works. Any errors in functional requirements will have an impact on product functionality so that inconsistencies in functional requirements must be eliminated at an early stage. So it is necessary to do a risk analysis at the level of engineering needs. In the design stage and later stages it is very possible to find the type of error associated with the initial stage. Correcting errors takes time and the cost of reworking becomes higher. This situation has a negative impact on stakeholders. Therefore, there is a need to carry out risk management from the start of the project. Risks are introduced and analyzed at each target and stakeholder mitigation is introduced as part of the system requirements for risk factors calculated based on the amount of attention and time given to implement these requirements.
The integration phase is carried out using the Enterprise Resource Planning (ERP) method in several business processes in the previous stage to facilitate service processes, control, synchronization of human resources, scheduling and finance through data entered in the application function. This research was conducted to find out the stakeholder needs through the requirements engineering process with risk analysis in the initial and design stages, then the system integration step was carried out with the concept of enterprise resource planning with a case study of the development of domestic wastewater management applications Public Works and Spatial Planning (Dinas PUTR) Gresik Regency.

II. METHOD
Definition Requirement is a statement that identifies a product or operational process, functional, or design characteristics or constraints, which are not ambiguous, can be tested or measured, and are needed for the acceptance of products or processes (by consumers or guarantors of internal quality standards). Requirements must be traceable, managed, and must have a clear, single, general understanding of all parties involved. A requirement can determine the product that is built in response to the needs and processes in using things that are built [1]. Definition of Requirement Engineering is an activity that includes finding, analyzing, documenting, and managing several needs for a system [2]. Requirement Engineering adalah bagian yang tak terpisahkan dari kegiatan rekayasa perangkat lunak. Rekayasa Kebutuhan mempunyai peran yang cukup penting, bahkan akan menentukan keberhasilan dari suatu proyek rekayasa perangkat lunak. Mengenai peran penting rekayasa kebutuhan tersebut telah banyak dikemukakan oleh para pakar. Requirements engineering merupakan fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan) [3].
Requirement Definitions is a condition or capability that must be fulfilled or owned by a system or system component to fulfill a contract, standard, specification, or other document that is used formally to solve a problem or achieve a documented goal [4]. Important needs in the system and in it include aspects of truth, realistic, needed, unambiguous, and measurable. The most important step in the requirement process is accurate communication between users who need a system with developers. Good needs engineering is important because the impact is able to reduce project costs, and accept the system by stakeholders so that it can lead to high profits. But also it must be admitted that it takes a lot of energy and time to invest in making really good requirements. To get good requirements, there is a lot of work / tasks to be done, therefore the Requirements Engineering team does not only work at the beginning of the project but works through the development stage to the delivery stage to ensure the requirements are truly appropriate [3]. Needs are grouped into 3 (three) levels e.g. Table 1. In a software development project, it is necessary to carry out a risk assessment for each feature, or the possibility that its implementation will cause adverse effects on completion, cost overruns and even project cancellations. The risk assessment process is carried out in the elicitation phase, the risk of providing relative measurements of potential impacts including certain features in the project. High-risk features have the potential to have a negative impact on the project, although some other features can be completed within the specified time [5].
The development team sets the risk based on each stage using the same low-medium-high scale used to assess efforts. Strategies to mitigate risk vary for each project. Within the scope of system development risk management, it is quite limited to the risks associated with each feature so that smart decisions can be made at the beginning of the project. For example, if features have very important benefits but have high risks, effective mitigation strategies are needed; if features have important benefits and are at high risk, features can be removed or only developed "if time is available". Similarly, as long as there are no commitments made to include a feature and the benefits of the feature are only ordinary but high risk, it can be completely missed [5].
Making a prototype is one way to minimize risk. The software prototype shows some of the desired functionality of the new system, so that it can be an effective tool that helps perfect the real requirements for the system. Users can interact with prototypes in their environment, according to their actual desired needs before developing software production. Making prototypes that are cheap and easy to develop based on the types of risks that might be present in the system [5]. In determining the existing risk criteria based on the possibility / probability (impact) and impact (impact) of the risk posed. For probability criteria consist of: 1. Low (low, impossible) 2. Medium (medium, may occur) 3. High (high, very possible) While the impact criteria consist of: 1. A minor, small impact on business processes; 2. moderate, quite extensive impact on business processes; 3. Major, broad impact on business processes. In risk evaluation (risk evaluation) is made information in accordance with the level of risk 1. Acceptable for low risk levels.
2. Moderately Acceptable (quite acceptable) for the level of moderate risk. 3. Not Acceptable for a high level of risk Enterprise Resource Planning (ERP) systems are standardized information technology support systems that aim to make information management efficient and make business processes more efficient. The system covers the entire company, an overview of the company and management of all company data. ERP systems allow transparency and control of all businesses, which facilitates rational control and quality of decisions. ERP systems are characterized by centralized data storage and application. Business activities are connected to a central database, providing global structures and definitions. The aim of an ERP system is to promote reliability and real-time data about business activities and to coordinate information in a global geographical environment. Another goal of using an ERP system is to minimize operational and maintenance costs [6].
The majority of module-based ERP systems, where each module represents functionality intended to meet operational specific needs. Usually ERP systems provide separate modules for financial management, accounting, human resources, manufacturing, order processing, supply chain management, project management and customer relationship management. Functionality through the module facilitates transparency and allows changes in parts of the system without having to change the entire system structure. It also supports expanding activities because modules and functionality can be added progressively. In addition, ERP systems are characterized by client-server architectures, to centralize application and calculation storage and to decentralize presentations [6].
SPALD management in the Faecal Sludge Management (FSM) concept is a series of collection processes, transportation processes, processing, fecal sludge utilization / storage processes originating from latrines, septic tanks or residential scale wastewater systems [7]. Worldwide sanitation needs that use local system technology are 2.7 billion people, and that number is expected to increase to 5 billion by 2030. Effective and sustainable solutions for sludge management (FSM) are a significant global requirement. FSM is a relatively new field, but is currently growing rapidly and gaining world recognition [8]. The FSM concept aims to realize one of the Sustainable Development Goals (SDGs) milestones, namely Sustainable Development for water and sanitation in helping increase awareness of the risks of poor sanitation management in the SPALD management process chain. This has motivated many countries, cities and organizations to increase the reach of improved sanitation services [8].

A. Data Collection Techniques
Primary Data Collection from this study was obtained from respondents' opinion data. Identification of risks resulting from the assessment of secondary data (previous research, journals, reports, and literature) and then developed by conducting surveys with competent and experienced parties especially related to risk analysis of development projects.
Secondary Data Collection is obtained from research papers, journals, reports and literature in accordance with the object of research to obtain the initial identification of risks.

B. Identification of Research Variables
Identification The variables of this study are derived from literature studies related to risk analysis in engineering requirements projects. The variables obtained are grouped into four categories according to PMI and will be used at the survey stage using questionnaires and interviews. Variables obtained from previous literature studies are attached to Table 3.  [14].

C. Preliminary survey
The preliminary survey was conducted to get perceptions from academics and practitioners who have experience in the field of risk analysis in construction projects related to the variables that will be used in the research obtained from the results of previous literature studies. The flow of the preliminary survey to obtain the research variables can be seen in e.g. Figure 6.

D. Grouping of System Development Modules
This research was conducted to collect and analyze stakeholder needs until the SRS documentation process. In collecting, reveal various problems and objectives to be achieved. In general the flow of research methodology adjusts the framework of the requirements engineering concept with input data using the waterfall risk assessment model and output system requirements arranged with customized user interfaces with the enterprise resource planning concept described in Figure 7. The SRS compilation of each module as a whole text is managed based on themes relevant to the focus of the research (thematic analysis). Textual data is selected according to research needs. Coding is the process of identifying themes from the results of read transcripts. The coding data is labeled for ease of analysis. The coding process is a process of crossing and going back and forth from the transcript to the results of coding, to other transcripts and so on until there is no relevant data left. The process of interpreting data is done simultaneously when coding. When clarifying, the transcripts were carefully read and then broken down into several themes that had been derived from the research problem formulation. When clarifying that the data interpretation efforts were carried out. Textual data that has been categorized according to the theme is reinterpreted in order to find relationships between themes in different labels or codes. Social research always involves interpretation. On the one hand, the interpretation indicates the element of subjectivity in the study. On the other hand, it is precisely there that is the power of qualitative research where researchers as part of research instruments play a very important role in the analysis process.

F. Merging SRS Modules
Documentation of SRS in the form of modules is combined in one management system with a custom Enterprise Resource Planning (ERP) approach as shown in Figure 8, to simplify the data management process. The concept of Merging and interface design for management information systems uses the study method of copying online applications that are widely used by today's millennial generation. To obtain branding and template design interfaces are conducted using the Focus Group Discussion (FGD) method with stakeholders in the service system manager. The results of a preliminary survey of 20 risk variables obtained through a literature study of 20 variables were declared significant for the object of the study. The criteria for preparing the risk variable from the preliminary survey are if one of the respondents states one of the significant factors then the risk is included in the list of risk variables that will be used at the time of the expert judgment. The results of the preliminary survey to determine the relevance of the variable risks to be used.
Risk variables obtained from the results of the next preliminary survey will be used to obtain the dominant risk factors using the expert judgment method. The expert judgment method is carried out by conducting structured interviews using questionnaires to respondents who have been selected to get a perception of the probability and impact of the risk variables during the implementation of the management information system development project at the Gresik Regency Public Works and Spatial Planning Office.
The scale of probability and impact assessment uses a scale of 1 to 3 by grouping scale values according to table 2. From the data on the probability and impact values obtained from respondents through expert judgment, the average probability and impact values for each risk variable will be calculated. From the calculation of the average value then rounding up or down will be done to facilitate the calculation of the level of risk. The results of the recapitulation of calculation of possible and impact values obtained from the results of the expert judgment is then used to calculate the risk level. The results can be seen in e.g. Table 4. Assessment of risk level is determined by probabilityimpact matrix referring to table 2. Probable mean value and average impact value of the risk variables obtained are multiplied to obtain risk level values. Risk ranking is determined based on the level of risk and the highest value from the multiplication of probability values and impact values obtained from the results of expert judgment for each variable. Risk ranking of the existing risk variables can be seen in Table 5.
From the results of the processed data, the results of expert judgment on the probability-impact survey are then included in the probability-impact matrix to determine the distribution position of risk factors based on stakeholders' perceptions to facilitate finding the best solution for the implementation of domestic wastewater management information system development projects in Gresik. The results of plotting the results of a probability-impact survey into a probability-impact matrix can be seen in Table 6.
From the results of the probability-impact survey in this study, there are 5 risk variables that fall into the high category so that it can be concluded that the five risk variables are the most dominant risk variables in the implementation of the domestic wastewater management information system development project in Gresik Regency. Risk mitigation is carried out on variables that fall into the high category to determine actions that can be carried out with the aim of reducing opportunities and impacts if the risk variable actually occurs. Ideas to get actions that can be taken to reduce the probability and impact of a risk event were obtained from an expert opinion through focus group discussion. Each respondent was asked to submit the idea of risk mitigation for risk factors for stakeholder leadership commitment, risk factors for rejection by users, risk factors for poor architectural quality and design, risk factors Lack of stability, availability, scalability, usability, security, extensibility and risk factors New regulations, clash of laws, market share. Furthermore, discussion of existing risk mitigation ideas is carried out, each participant is given the opportunity to express his opinion on the level of possibility and success of the mitigation ideas obtained previously. During the discussion, all respondents agreed on the ideas that could be implemented. So that the results of the focus group discussion found 3 risk mitigation for risk factors for the commitment of stakeholder leaders; 3 risk mitigation for risk factors for rejection by users; 3 risk mitigation for risk factors for poor architectural quality and design; 3 risk mitigation for risk factors for lack of stability, availability, scalability, usability, security, extensibility; and 3 risk mitigation for risk factors for new regulations, legal conflicts and market share.
In the analysis stage, the existing system is obtained from the tasks and functions of the operator. Operator institution consisting of 9 function tasks as well as the Standard Operating Procedure (SOP) which is currently owned by the management stakeholders, then grouping needs and determined 5 categories of the SOP. From the grouping of 5 selected categories, it is then used for the preparation of the SRS module according to stakeholder needs so that 9 modules can be analyzed for each risk and combined with enterprise resource planning.
Information on stakeholders' needs includes business structure, business process, and user requirements. These parts are needed because they have relevance and become one of the sources of information needs in the preparation of information on software requirements specification documents (SRS). Stakeholders related to the development of management information systems for domestic wastewater management are tailored to the area or entity that is related to the business process of domestic wastewater management in Gresik Regency. These stakeholders are defined as system users including UPT PALD (administration, Satgas PATAS, IPLT officers, empowerment officers), private suction business people (Suck Officers) and community/community groups (prospective customers). The business process describes a series of flows that the system can do in every domestic wastewater management activity. The flow of business processes in management activities consists of new customer registration, customer or officer login, customer census, desludging officer, direct desludging, scheduled desludging, complaints and suggestions, customer assessment, maintenance of IPALD, KPP IPALD, disposal to IPLT. The SRS document presentation took several parts (items) on the SRS prototype outline and adjusted to the demands of the stakeholder needs of the operator operator in the UPTD PALD in developing the Gresik Regency domestic wastewater management information system. These sections include: Functional requirements are actually included in the exposure section of the function, but to make it easier to read the results of the functional requirements a sub function or part is created.

d. Logical database 4) Appendices Assumptions and dependencies
The next step is the implementation of ERP through combining modules that have been compiled the results of Software Requirements Specifications (SRS) management information systems for domestic wastewater management that refer to the needs of stakeholders operator operators. ERP systems developed in management information systems generally use a 3 tier user interface architecture system, namely: 1) Presentation Layer: Graphical User Interface (GUI) in the form of an application to enter data or access system functions. 2) Application Layer: business rules, logic functions and programs that receive / send from to the database server 3) Database layer: data transaction management including its metadata However, this research is only limited to the presentation layer to display the interface of the android application and the web dashboard manager, for the application layer and database layer it is necessary to test the functionality of each module and commitment from the leaders so that it takes a long time to implement.
Graphical User Interface (GUI) or user interface in this study is divided into 2 types, namely Android-based application system GUI and GUI information system management website dashboard that uses the goploong.id domain name which both use GO-PLOONG branding. Figure 9. Branding used for GUI applications SRS modules are then integrated and incorporated into the application display. For the display of the application service interface and website dashboard in this study can be seen in Figure 10 and Figure 11. By implementing an ERP system in an organization it will integrate the system which results in: 1) Changes made to one module will automatically update the other modules if the information changed is related to the module. Data will be updated directly once the user enters data into the system. This is known as "real time processing". 2) System integration can occur on the condition that all users must use the same data source, both for customer data, fleet data and service data. 3) Data transparency, all users who have access to the system will be able to see all the most up-to-date information whenever needed even if the information is inputted by other users.

V. CONCLUSION
The dominant risk factor with a high category in the implementation of the domestic wastewater management management information system development project in Kabupaten Gresik is the commitment of stakeholder leaders where there is an opportunity value of 3 (very likely to occur) and impact value 3 (broad impact on business processes). The second biggest risk factor is the use by users with opportunity value 3 and impact value 3. The third biggest risk factor is poor architectural quality and design with opportunity value 3 and impact value 3. The fourth biggest risk factor is lack of stability, availability, scalability, usability, security, extensibility with opportunity value 3 and impact value 3. The fifth biggest risk factor is new regulation, legal clash, market share with opportunity value 2 (possibly happening) and impact value 3 (broad impact on business processes).
Risk Mitigation that can be done by stakeholders for the five factors that have high risk ranking include make a roadmap for domestic wastewater management systems agreed upon by all stakeholders, making branding that is easily recognized and an icon of regional innovation and then legalized by regent regulations, convincing leaders about maximum public services with adequate budget support, providing features that are useful and easily accessible through the application system, conduct counseling, outreach and promotion regarding services using the application, providing benefits or rewards regarding the use of services through the application, creating interface designs that are easy to understand and use, design a merger of modules needed by user stakeholders, creating a dashboard design architecture that is able to manage the management system properly, ensure that the merging of all modules works properly, provide local government external servers, provide customer data protection for each service module, establish a legal umbrella for the implementation of services in the form of regional regulations governing the management of domestic wastewater and service fees, making derivative regulations on Perda in the form of Perkada as a technical explanation of services, socialize regulations that have been made as a means of promotion to the public to gain a wider market share.
Existing system analysis results in the need for 9 service modules, these modules are the new customer registration module, customer or employee login module, customer census module (septic tank census), desludging module, direct desludging module, scheduled desludging module, complaint module and advice, customer assessment module, IPALD maintenance module, IPALD KPP module and disposal module to IPLT.
Each module has user involvement, business processes and risk levels. In terms of the risks posed can be analyzed the causes, impacts and level of risk that may occur in the preparation of information on stakeholders' needs. Information Compilation of stakeholders' needs consists of business structure, business process, and user requirements. These parts are needed because they have relevance and become one of the sources of information needs in the preparation of information in the software requirements specification document (SRS).
Each module has user involvement, business processes and risk levels. In terms of the risks posed can be analyzed the causes, impacts and level of risk that may occur in the preparation of information on stakeholders' needs. Information Compilation of stakeholders' needs consists of business structure, business process, and user requirements. These parts are needed because they have relevance and become one of the sources of information needs in the preparation of information in the software requirements specification document (SRS).
Combining modules that have been compiled as a result of software requirements specification (SRS) for domestic wastewater management information system that refers to the stakeholder needs of the operator operator implemented with ERP using 3 tier user interfaces, namely Graphical User Interface (GUI) in the form of applications to enter data or accessing system functions; business rules, logic functions and programs that receive / send from to the database server; and the management of data transactions and metadata, in this study limited only the first tier, namely the Graphical User Interface (GUI) and the possible impacts of the integration of using ERP.