• 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 KIPS Transactions:PartD
• /
• v.14D no.6
• /
• pp.641-648
• /
• 2007

To develop a dynamic system project in which the requirement changes frequently, it's impossible to finish the development within a fixed-cost due to additional budget occurring in need of requirement creep. To manage the successive project within a fixed-cost, it's better to manage the ratio of necessarily changed size of project and necessary optional requirement. According to Bhagwat, it is occurred in the construction phase. Also, he stated that the software development cost, construction phase cost and requirement cost are equal and it was wrong explanation in the ratio of requirement creep and optional requirement. This paper assumes the requirement creep to be happening in the phase of elaboration and construction. In addition, some differences were supposed to happen between software development cost, construction phase cost, and requirement creep cost. As a result, the reality was preferred rather than the ratio of optional requirement and the ratio of requirement creep.

• 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’.

• Proceedings of the Korean Information Science Society Conference
• /
• 1998.10b
• /
• pp.623-625
• /
• 1998

시스템의 변경은 개발 주기의 전 과정 가운데 지속적으로 발생하게 되고, 변경이 발생하면 연관된 다른 요소에 영향을 미칠 뿐 아니라 다음 주기에까지 그 영향이 전달되기 때문에, 개발 초기의 요구공학 주기의 산출물인 요구사항명세서로부터 추적과 관리가 시작되어야 한다. 본 논문에서는 요구사항의 관리를 위해 요구사항 관리 모델을 제안하고, 요구사항 관리 계층을 중심으로 요구사항의 저장, 변경사항의 관리 및 추적을 처리하며, 이를 기반으로 이후 프로젝트 관리와 관련된 작업들을 어플리케이션 계층에서 처리하도록 지원하였다. 또한 이 모델이 효율적으로 컴퓨터를 이용한 공동작업(Computer Supported Cooperative Work: CSW)에 활용 가능하도록 웹을 통해 구현한다.

• 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.

• Proceedings of the Korean Society of Disaster Information Conference
• /
• 2023.11a
• /
• pp.165-166
• /
• 2023

BCMS의 변경관리에 대한 요구사항은 ISO 22301 구성체계의 기획단계인 6.3 변경의 기획에서 수행하고, 기업재난관리표준 구성체계에서 기획단계인 3.5.5 문서화된 정보에서 수행하도록 규정하였으며, 이는 모두가 P-D-C-A 운용 모델의 Plan 단계에 해당된다. 이러한 구성체계는 BCP를 최초에 수립하는 단계에서는 적합하지만, BCP가 수립(제정)되어 운용단계에서 발생되는 변경사항을 처리하는데는 많은 문제점이 도출된다. 따라서 재난 및 안전관리 분야에 해당하는 유사제도의 요구사항을 대상으로 비교분석을 통하여 도출된 개선방안을 연구결과로 제시하고자 한다. BCP를 수립하는 과정에서 발생하는 보완사항은 변경관리 절차에 포함하지 않고, BCP가 수립되어 운용단계에서 발생되는 변경사항만 변경관리 절차에 포함하여 관리하며, P-D-C-A 운용 모델의 Act 단계에서 수행하는 것이 적합하다.

• Proceedings of the Korean Information Science Society Conference
• /
• 2002.04b
• /
• pp.379-381
• /
• 2002

소프트웨어 개발 프로젝트에서 소프트웨어 요구사항의 잦은 변경 또는 요구사항 확정의 지연은 소프트웨어의 품질저하, 납기지연, 개발요구자와 개발담당자 간의 의견충돌을 야기한다. 특히 원자력발전소 환경과 같은 mission-critical 영역의 경우에는 발전소 건설자체를 지연시킬 수 있는 심각한 결과를 초래한다. 본 논문에서는 원자력발전소의 감시와 제어를 담당하는 MMIS(Man Machine Interface System) 환경을 동적으로 모의하는 소프트웨어 개발 과정에서 요구사항 변경의 가능성을 최소화시킬 의도로 시도하였던 요구사항 우선순위 설정에 대한 경험과 교훈을 살펴본다. 또한, 요구사항 우선순위를 기반으로 한 소프트웨어 개발 공정 활동을 토의한다

• Proceedings of the Korea Information Processing Society Conference
• /
• 2017.11a
• /
• pp.631-634
• /
• 2017

앞으로의 프로젝트에서는 시장 변화, 신기술, 경쟁업체의 대응, 설계결함, 테스트 실패 등의 다양한 외부적 요인으로 인해, 더욱 빈번한 요구사항 변경이 요청된다. 그 이전에 명료한 요구사항을 정의하기가 매우 어렵고, 소프트웨어 구축 중에도 수시로 요구사항이 변경되고 있는 실정이다. 이런 문제는 요구사항 추적성 및 변경 관리의 미비함에 있다. 이를 해결하기 위해, 소프트웨어 개발 프로세스인 요구사항, 분석, 설계, 구현, 테스트 단계에서의 추적성 관리를 위한 프로세스의 구축과 내재화가 필요하다. 본 논문에서는 클로즈 아키텍처 메커니즘을 기반으로 소프트웨어 각 개발 단계 산출물들 간의 추적성 매트릭스를 제시한다. 이를 통해 프로젝트 과정에서의 잦은 요구사항 변경에 유연하게 대처함으로써 소프트웨어 품질 향상에 기여 할 것으로 본다.

• 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.