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

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

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

• 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 단계에서 수행하는 것이 적합하다.

• 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 Information Science Society Conference
• /
• 2002.04b
• /
• pp.445-447
• /
• 2002

최근 국내 기업들은 S/W Process심사를 통하여 기업의 Process수준 향상과 개발 제품의 품질을 향상시키고자 하는 관점에서 CMM, SPICE와 같은 표준에 많은 관심을 보이고 있다 이러한 표준들에서는 소프트웨어 품질 향상을 위만 기반으로 요구사항 관리를 중요시하고 있다. 많은 기업들이 요구사항을 추출하여 분석하고, 관리하는 방안에 대해 관심을 가지고 적용하고 있다. 요구사항 관리는 요구사항 개발, 변경 및 연계성과 관련된 모든 활동을 포함한다. 즉, 상호적이고 협력적인 공정을 통해서 요구사장을 추출, 분석하고 분석된 결과를 문서화하고, 요구 사항들 간의 연계성을 설정 관리하고, 변경 사장을 관리해야 한다. 본 논문에서는 요구사항추출 단계에서부터 개발 완료 시점가지 요구사항을 관리하는 소프트웨어 요구사장 프로세스를 제안하고, 이를 적용한 사례를 제시한다.

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

• Proceedings of the Korean Information Science Society Conference
• /
• 2004.10b
• /
• pp.484-486
• /
• 2004

CMMI는 조직의 역량 성숙도를 향상시키기 위한 소프트웨어 프로세스 개선(SPI) 모델이다 CMMI의 단계적 형태(Staged Representation)의 2레벨을 획득하기 위해서 요구되는 요구사항 관리 프로세스 영역은 요구사항에 대한 협의 확정(Commitment) 활동을 포항하고 있다. 요구사항 관리 프로세스 영역은 이전에 협의 확정된 요구사항이 필요한 경우 변경이 가능하도록 허용하고 있는데, CMMI와 같이 프로세스 중심적인 모델에서 이러한 변경 가능성은 협의 확정 사항의 무한정 확대(Escalation of Commitment)와 같은 문제점을 야기할 수 있다. 본 논문에서는 SPI학계에서 사용되는 협의 확정에 대한 정의를 살펴보고, 이 정의를 CMMI에 적용함으로써 요구사항 관리 프로세스 영역의 협의 확정을 수행하는 활동에서 발생할 수 있는 문제점을 해결하기 위한 방안을 제시한다. 협의 확정의 개념은 Brown에 의해서 정의된 속성(1)과 Meyer에 의해서 제안된 형태(2)를 적용하여 정성적이고 정량적인 관리가 가능할 수 있다. 이를 통하여, 요구사항의 협의 확정에 대한 체계적인 관리가 가능해질 수 있다.

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