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

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

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

• 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 Korean Information Science Society Conference
• /
• 2011.06a
• /
• pp.206-209
• /
• 2011

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

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

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

비기능적 요구사항은 대상 시스템이 지원해야 할 기능적 요구사항의 속성 또는 품질로써 소프트웨어 품질 속성으로 반영된다. 또한 비기능적 요구사항은 설계를 결정하기 위한 중요한 기준으로 사용되므로 소프트웨어 개발 프로세스 전반에 걸쳐 꾸준히 고려하고, 관리해야 한다. 하지만 비기능적 요구사항은 가시성이 없고, 명확히 명세하기가 어려운 특성으로 인해 간과하기 쉽다 따라서 비기능적 요구사항을 실제 모델링에 반영하고, 이를 추적하여 계속적으로 관리하기 일한 노력이 필요하다. 이에 본 논문에서는 내장형 소프트웨어의 비기능적 요구사항을 모델링 하는 절차를 제안하며, 내장형 소프트웨어의 특성을 가진 지능형 조명 제어 시스템의 사례를 통해 비기능적 요구사항을 반영한 모델링을 수행하고, 다이어그램들 사이' 의 비기능적 요구사항에 대한 추적 과정을 살펴본다

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

• Journal of KIISE:Software and Applications
• /
• v.33 no.7
• /
• pp.615-623
• /
• 2006

A non-functional requirement is a property or quality that the proposed systems have to support the functional requirements. A non-functional requirement is reflected by quality attribute These non-functional requirements playa crucial role during system development, serving as selection criteria for choosing among decisions. It should be continuously considered through the software development process. In spite of the importance of the non-functional requirements, it received little attention because of ambiguousness and invisibility of non-functional requirements. Therefore non-functional model which is a process to analyze the non-functional requirement is proposed for improving the management efficiency of non-functional requirements. Also, this paper presents the trace among the UML diagrams to the conceptual model. According to the non-functional requirement development process, this paper achieved performance-based case study. After then, non-functional requirement should be traced using the UML diagrams.

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

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