• KIPS Transactions on Software and Data Engineering
• /
• v.4 no.11
• /
• pp.487-498
• /
• 2015

Traceability enables software developers to trace up the changes occurring in software artifacts. In software product line, traceability is more complex than traceability in a single product as commonality and variability should be considered. Modeling traceability between features and requirements has been proposed in the past. However, traceability between requirements and architecture has more factors to consider, including many-to-many mappings and hierarchical structure of architectures. This paper proposes a method of systematically constructing platform traceability between platform requirements and platform architecture. This paper also shows the efficacy of the proposed mechanism through case studies.

• The KIPS Transactions:PartD
• /
• v.16D no.2
• /
• pp.201-212
• /
• 2009

There are various methods to trace output in software development to verify the consistency and completeness of requirements. Existing studies do present the trace meta-model or automated tools, but fail to list specifically traced output or traced items. Also, in regards to trace tables, which contain traced items, existing studies don‘t consider the whole software development process but merely its sub-process. Given this, the present study suggests an extended requirements tracetable that tracks output from the inception of the project through the architectural design phase to the application delivery, following up on the researcher’s previous study on a tracetable that considered only a sub-process of the whole development process. In addition, in order to address the problem of the tracking process becoming complicated with increased tracefields due to an extended trace table, the researcher suggests a method for normalizing a requirements tracetable that can integrate and separate by development process phase. Apply it to theH system development project of a D company, and this study caseverified application possibility of study, confirmed an effect of a chase to easily find out an error of requirements. Improve precision of a traceto verify consistency of requirements and completeness through this study, and will minimize failure of a software development.

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

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

• The Journal of Society for e-Business Studies
• /
• v.12 no.4
• /
• pp.1-15
• /
• 2007

Traceability links are logical links between individual requirements and other system elements such as architecture descriptions, source code, and test cases. These are useful for requirements change impact analysis, requirements conflict analysis, and requirements consistency checking. However, establishing and maintaining traceability links places a big burden since complex systems have especially yield an enormous number of various artifacts. We propose a feature-oriented requirements tracing method to manage requirements with cost benefit analysis, including value consideration and intermediate catalysis using features. Our approach offers two contributions to the study of requirements tracing: (1)We introduce feature modeling as intermediate catalysis to generate traceability links between user requirements and implementation artifacts. (2)We provide value consideration with cost and efforts to identify traceability links based on prioritized requirements, thus assigning a granularity level to each feature. In this paper, we especially present the results of a case study which is carried out in Apartment Ubiquitous Platform to integrate and connect home services in an apartment complex in details.

• Journal of KIISE:Software and Applications
• /
• v.35 no.6
• /
• pp.357-365
• /
• 2008

Requirements traceability enables to reuse various kinds of software artifacts, which are the results from software development life cycle, rather than reuse source code only. To support requirements traceability for reuse of software artifacts, 1) artifacts should be described based on requirements and 2) a requirements tracing method should be supported. In this paper, we provide a description model for annotating requirements information to software artifacts by using requirements ontology. We also provide semantic tagging method users to efficiently annotate artifacts with the requirements ontology. And we finally present how requirements traceability is supported based on requirements ontology and also suggest the system architecture for requirements traceability support.

• Journal of KIISE:Software and Applications
• /
• v.34 no.5
• /
• pp.419-430
• /
• 2007

It is very important to track whether software is properly developed according to requirements. This study suggests a method to track requirements by using a tracking table. In this study, the tracking table indicates why such requirements are included by detailing the content of requests for proposals and proposals. The table also facilitates verification of the consistency between outputs and the integrity by having ID codes of each requirement mapped to each output. Furthermore, as this study was conducted, it was found that some factors were required to be added or supplemented to the outputs at the requirement gathering stage of MaRMI-Ⅲ v.4.0 methodology. Thus, this study seeks to present this additional result along with the enhanced tracking table. By verifying outputs, the tracking table presented in this study will help to reduce all kinds of risks and problems that may occur in software development due to the lack of management of requirements. In addition, the output of the requirement-gathering stage of MaRMI-Ⅲ v.4.0 methodology will be improved/supplemented according to the creation of tracking tables; this will increment the applicability of the MaRMI-III methodology.

• KIPS Transactions on Software and Data Engineering
• /
• v.9 no.11
• /
• pp.357-366
• /
• 2020

As the proportion and complexity of software embedded in aircraft increase, risk factors such as mission failure, function failure and performance failure due to software errors also increase. In the mission-critical software systems such as aircraft software, managing requirement traceability is essential to maintain the software systems with minimal period and cost. However, the development company is not accurately complying with the guideline for managing requirement traceability due to various reasons such as development cost and schedule. Therefore, it is not easy to systematically establish and maintain requirement traceability. In the paper, we analyze actual test cases of aviation software systems from the viewpoint of requirements traceability in order to learn if there are failure cases of test cases due to the absence of systematic traceability management activities. We also check the risks associated with the failure cases according to the type and severity of the cases. As a result of analyzing a total of 7 aircraft-mounted software, failure cases could be divided into three types: omission of requirements, lack of connection between requirements and test procedures, and omission of test procedures. There were a total of 18 failure cases, 6 for each type. The numbers of high, middle and low risks were 1, 13 and 4, respectively, where the number of middle risks is largest.

• Proceedings of the Korean Information Science Society Conference
• /
• 2011.06a
• /
• pp.206-209
• /
• 2011

기존의 요구사항 추적테이블은 요구관리적 관점에서 요구사항의 일관성, 완전성 확보를 목표로 하거나 요구사항 누락과 충돌, 중복 방지 요구사항 변경관리 측면만을 강조해 왔다. 그러나 자체 솔루션 개발관점과 유지보수 측면에서 제시된 요구사항 추적테이블이 없었다. 따라서 본 논문에서는 Pain Chain을 근간으로 개발 후 유지보수 요청관리에 효과적인 요구사항 추적테이블 방안을 제시하고자 한다.

• KIPS Transactions on Software and Data Engineering
• /
• v.7 no.9
• /
• pp.325-334
• /
• 2018

Requirement traceability should be continuously maintained in software development and evolution. However, it is usually updated in practice in the quality assurance phase. The gap between "is" and "should" exists due to the fact that developers must invest considerable effort to update requirement traceability while being able to obtain only marginal benefit from the updated traceability. To close this gap, we propose a spreadsheet application that enables developers to flexibly change mappings in a requirement traceability matrix. In this way, developers can reduce their effort in updating the requirement traceability matrix, but still obtain the common form of a requirement traceability matrix on a spreadsheet. The proposed application maintains the mappings between two artifacts on each sheet so that, whenever an artifact item changes, developers can instantly insert the relevant mapping changes. Then, when developers desire the common form of a requirement traceability matrix, the proposed application calculates the mappings among several artifacts and creates the matrix. The application also checks traceability errors and calculates the metrics so that developers can understand the completeness of the matrix. To understand the applicability of the proposed approach, we conducted a case study, which shows that the proposed application can be applied to the real project and easily incorporate the mapping changes.

• Proceedings of the Korean Information Science Society Conference
• /
• 2005.11b
• /
• pp.466-468
• /
• 2005

임베디드 시스템은 특정 목적을 수행하기 위해 개발되는 컴퓨팅 시스템으로 최적화된 하드웨어 위에서 동작 가능한 소프트웨어로 구성된다. 임베디드 시스템은 개발 단계별로 여러 가지 설계 대안 중 최적의 설계를 선택하는 설계 결정이 이루어지는데 설계 결정 시에는 이에 대한 근거가 제시되어야 한다. 임베디드 시스템은 여러 유형의 제약사항 범위 안에서 개발되어야 하는 특징으로 인해 임베디드 시스템 개발 시에는 기능적 요구사항과 함께 비기능적 요구사항 역시 중요한 요소가 된다. 따라서 제약사항을 담고 있는 비기능적 요구사항은 설계 결정 시에 중요한 영향을 미친다. 그러므로 본 논문에서는 CMMI의 공학 프로세스 영역에 근거하여 임베디드 시스템의 개발주기를 요구사항 개발, 기술적 해결, 제품 통합 각 단계로 나눈 다음, 각 단계에서 이루어지는 설계 결정 활동을 비기능적 요구사항에 근거하여 분석하고자 한다. 이를 통해 임베디드 시스템 개발 단계별 설계 결정에 대한 추적성을 제공하고자 한다.