• Journal of KIISE:Software and Applications
• /
• v.32 no.12
• /
• pp.1164-1177
• /
• 2005

As the software development process becomes complicated, software requirements become complicated, too. Many efforts are needed in requirements management. It is impossible to define all requirements of software at first, and the development environment changes as project is gone. As the cost of requirements change management is much more than development cost, the changes should be controled immediately through systematic change management. In this paper, I suggest a method to manage requirements change systematically based on the change management process in software product lines. The requirements change at the application engineering process is analyzed and managed using the domain engineering process because the application requirements are customized from the domain requirements in software product lines. Such the consistent change management helps to make decisions about changes by change impact analysis and alternative solution design. Through this method, the potential change costs can be saved because same change requests are not repeated by controlling the change requests completely.

• The Journal of Society for e-Business Studies
• /
• v.12 no.3
• /
• pp.33-47
• /
• 2007

The requirements have been changed during development progresses, since it is impossible to define all of software requirements. These requirements change leads to mistakes because the developers cannot completely understand the software's structure and behavior, or they cannot discover all parts affected by a change. Requirement changes have to be managed and assessed to ensure that they are feasible, make economic sense and contribute to the business needs of the customer organization. We propose a feature-oriented requirements change management method to manage requirements change with value analysis and feature-oriented traceability links including intermediate catalysis using features. Our approach offers two contributions to the study of requirements change: (1) We define requirements change tree to make user requirements change request generalize by feature level. (2) We provide overall process such as change request normalization, change impact analysis, solution dealing with change request, change request implementation, change request evaluation. In addition, we especially present the results of a case study which is carried out in asset management portal system in details.

• Journal of KIISE:Software and Applications
• /
• v.30 no.5_6
• /
• pp.503-514
• /
• 2003

In conventional development methodologies, requirements are considered to be not changing after analysis phase, and requirements specifications are used for the next step system design purpose. But in the real world, requirements can be changed and modified throughout the development life cycle according to end-user's more understanding about the target system, new IT technologies, changes of customer environment and market situation, and so on. So there needs a requirements change management process that can extend requirements management over the entire development life cycle and can support managing changes to the requirements after design phase. In this paper, a requirements change management process that can be integrated into conventional development methodologies is proposed to support the extension of requirements life cycle and managing changes to the requirements after design phase. This process was evaluated through an verification test with a widely used development methodology‘MaRMI’.

• Industrial Engineering and Management Systems
• /
• v.11 no.1
• /
• pp.70-81
• /
• 2012

The subject of "Design Requirements" (DR) is central to the design of software and engineering systems. The main reason for this is that quality aspects are usually closely tied to requirements, among other things. In this review paper, we consider how the subject of requirements is being managed in these two seemingly different design disciplines. Two important aspects are covered, namely: (a) requirements development, describing various activities leading to requirements documentation, and (b) requirements change management, describing various activities needed for the proper treatment of the inevitable changes in requirements. Similarities and differences on how these two aspects are handled in software and engineering systems are highlighted. It is concluded from this literature survey that the management of software requirements is quite coherent and well established as a science. On the other hand, management of engineering systems requirements suffer from being unstructured, in particular when requirements changes are involved. Important gaps and future important research areas are identified.

• Journal of the Korean Society of Systems Engineering
• /
• v.14 no.1
• /
• pp.63-71
• /
• 2018

This paper discusses decommissioning procedure requirements management using requirement engineering to systematically manage the technical requirements and criteria that are required in decontamination and decommissioning activities, and the regulatory requirements that should be complied with in a decommissioning strategy for research reactors and nuclear power plants. A schema was designed to establish the traceability and change management related to the linkage between the regulatory requirements and technical criteria after classifying the procedures into four groups during the full life-cycle of the decommissioning. The results confirmed that the designed schema was successfully traced in accordance with the regulatory requirements and technical criteria required by various fields in terms of decontamination and decommissioning activities. In addition, the changes before and after the revision of the Nuclear Safety Act were also determined. The dismantling procedure requirement management system secured through this study is expected to be a useful tool in the integrated management of radioactive waste, as well as in the dismantling of research reactor and nuclear facilities.

• Journal of Internet Computing and Services
• /
• v.22 no.3
• /
• pp.59-66
• /
• 2021

This study proposes a requirements monitoring method that systematically performs traceability management and change management for requirements in order to improve the quality of software systems in the software development process. To this end, we present the artifact change history management models to systematically perform change management for individual artifacts and the traceability matrixes to define the relationship between artifacts. It also proposes a visual dashboard that makes it easy to grasp the situation in which changes are propagated to related artifacts when specific artifacts change.

• The KIPS Transactions:PartD
• /
• v.17D no.4
• /
• pp.271-282
• /
• 2010

Insufficient requirement management accounts for 54% ofunsuccessful software development projects and 22% of insufficient requirement management comes from requirement change management. Hence, requirement management activities are important to reduce failure rates and a tracing method is suggested as the major factor in requirements change management. A traceability table is easy to use because of its legibility accurate tracing. However, traceability tables of existing studies have failed to concretely suggest method of change management and effect of traceability. Also, studies of methods to estimate change impact is complex. Hence, this study suggests how to use a traceability table to manage changes in requirements. Together, in comparison to existing studies, this study suggests easier methods to estimate change rate and change impact. Also Fifteen projects were sampled to test the hypothesis that traceability table influences the success of projects and that it decreases the failure rate that comes from the insufficient requirements management.

• International journal of advanced smart convergence
• /
• v.10 no.2
• /
• pp.130-137
• /
• 2021

In the current software project, it is still very difficult to extract and define clear requirements in the requirement engineering. Informal requirements documents based on natural language can be interpreted in different meanings depending on the degree of understanding or maturity level of the requirements analyst. Also, Furthermore, as the project progresses, requirements continue to change from the customer. This change in requirements is a catastrophic failure from a management perspective in software projects. In the situation of frequent requirements changes, a current issue of requirements engineering area is how to make clear requirements with unclear and ambigousrequirements. To solve this problem, we propose to extract and redefine clear requirements by incorporating Design Thinking methodologies into requirements engineering. We expect to have higher possibilities to improve software quality by redefining requirements that are ambiously and unclearly defined.

• Proceedings of the Korea Water Resources Association Conference
• /
• 2022.05a
• /
• pp.126-126
• /
• 2022

Climate change has continued to impact meteorological factors like rainfall in many countries including Nigeria. Thus, altering the rainfall patterns which subsequently affect the crop yield. Maize is an important cereal grown in northern Nigeria, along with sorghum, rice, and millet. Due to the challenge of water scarcity during the dry season, it has become critical to design appropriate strategies for planning, developing, and management of the limited available water resources to increase the maize yield. This study, therefore, determines the quantity of water required to produce maize from planting to harvesting and the impact of drought on maize during different growth stages in the region. Rainfall data from six rain gauge stations for a period of 36 years (1979-2014) was considered for the analysis. The standardized precipitation and evapotranspiration index (SPEI) is used to evaluate the severity of drought. Using the CROPWAT model, the evapotranspiration was calculated using the Penman-Monteith method, while the crop water requirements (CWRs) and irrigation scheduling for the maize crop was also determined. Irrigation was considered for 100% of critical soil moisture loss. At different phases of maize crop growth, the model predicted daily and monthly crop water requirements. The crop water requirement was found to be 319.0 mm and the irrigation requirement was 15.5 mm. The CROPWAT 8.0 model adequately estimated the yield reduction caused by water stress and climatic impacts, which makes this model appropriate for determining the crop water requirements, irrigation planning, and management.

• Journal of the Korea Safety Management & Science
• /
• v.13 no.4
• /
• pp.71-79
• /
• 2011

The work environment of locomotive cabs has long been an important issue in the design of railload systems since it is quite critical in terms of system's operational safety. It is getting more attention as the running speed of the trains goes up these days. To this end, this paper describes how to systematically construct a DB for the requirements set in the course of the improvement process for the aforementioned cab work environment. As a solution approach, we have adopted the requirement architecture concept to cover the whole activities required to do such as in requirements generation, DB construction, change management, and traceability management. Specifically, based on the requirement architecture framework a requirement process to collect requirements for improvement is discussed, and the guide lines are suggested for verification and validation of the developed requirements. In addition, a base schema and requirements templates are developed, which will be used in generating requirements and constructing a DB. Finally, it is demonstrated how the requirements DB for locomotive cabs can be constructed using a computer-aided tool in an integrated fashion.