• 한국전자거래학회지
• /
• 제12권3호
• /
• pp.33-47
• /
• 2007

소프트웨어 개발 초기에 모든 요구사항을 정의하는 것은 불가능하기 때문에 요구사항은 소프트웨어 개발이 진행되는 동안에 지속적으로 변경된다. 이러한 요구사항 변경은 개발자가 소프트웨어 구조나 행위를 완벽하게 이해하지 못하거나 변경에 따라 영향을 받는 모든 부분을 식별할 수 없을 경우 많은 오류를 야기 시킨다. 그러므로, 조직의 비즈니스에 공헌하면서 비용 효과적으로 적절히 처리되기 위하여 요구사항은 관리되고 평가되어야한다. 본 논문은 가치분석을 통하여 생성된 휘처 기반의 요구사항추적 링크를 근간으로 하는 요구사항변경 관리 기법을 제안한다. 이는 사용자 요구사항과 산출물간의 연결을 분석하기 위하여 휘처를 중간 매개체로 활용한 추적 링크를 이용한다. 그리고, 요구사항 변경 요청을 휘처 단위로 상세화하기 위한 변경 트리 모델을 정의하고 변경 관리가 수행되는 전체적인 프로세스를 제시한다. 또한, 요구사항 변경 관리 기법을 자산관리포탈시스템에 적용한 사례의 결과를 기술한다.

• 정보과학회 논문지
• /
• 제43권8호
• /
• pp.857-868
• /
• 2016

소프트웨어 생태계의 시장 중심 개발 환경에서 소프트웨어 기업은 제품의 성공을 위해서 자신의 비즈니스와 고객에게 높은 가치를 제공할 수 있어야만 시장 경쟁력을 가지고 생존할 수 있다. 요구공학적 관점에서 제품 요구사항 선택을 통한 가치 제공을 위해서 이해관계자들 각자의 다른 이해가 조정되어 합의되어야 한다. 즉, 요구공학 단계에서 높은 가치 창출을 고려하는 합의된 요구사항을 선택할 필요가 있다. 기존 연구들은 소프트웨어 생태계에서 요구되는 이해관계자들의 다른 이해에 대한 요구공학적 기법의 필요성을 언급하였을 뿐, 구체적인 가이드라인 및 수행 방법에 대하여 제안하지 않았다. 본 연구에서는 요구공학에서 사용되는 Goal 개념 기반으로 협상 참가자의 의도를 분석하고 이를 바탕으로 요구사항 충돌의 근거를 구조화하여 관리할 수 있도록 한다. 궁극적으로 협상 참가자의 이기적 행동을 바탕으로 게임 이론적 개념을 이용한 요구사항 충돌 해결 방법론을 제안한다.

• 한국정보과학회논문지:소프트웨어및응용
• /
• 제32권12호
• /
• pp.1164-1177
• /
• 2005

현재 소프트웨어 개발 공정이 복잡해짐에 따라 개발하는 소프트웨어의 요구사항 역시 복잡해지고 있으며 요구사항 관리에 많은 노력이 소요되고 있다. 그러나 소프트웨어의 요구사항을 처음부터 모두 정의하는 것은 사실상 불가능하며, 개발이 진행되면서 환경은 변하기 마련이다. 또한 요구사항 변경은 개발보다 많은 비용이 소요되므로 체계적인 변경 관리를 통해 변경에 민첩하게 대응하고 관리되어야 한다. 본 논문에서는 소프트웨어 프로덕트 라인에서 요구사항 변경 관리 프로세스를 기반으로 체계적인 요구사항 변경 관리 방법을 제시한다. 소프트웨어 프로덕트 라인(software product lines)에서 어플리케이션의 요구사항은 도메인 요구사항과 밀접하게 관련되어 있으므로 어플리케이션 공학(application engineering) 단계에서 요구사항 변경이 발생했을 경우 도메인 공학(domain engineering) 단계를 이용하여 변경을 분석하고 관리하는 방법을 제시한다. 이러한 일관된 변경 관리를 통해 변경 범위를 분석하고, 변경 대처방안을 제시함으로써 변경 처리 결정을 내리는데 도움을 주며 한번 요청된 변경이 완벽하게 처리되도록 도와주어 같은 변경의 반복 요청을 막을 수 있기 때문에 잠재된 변경 비용을 절약할 수 있다.

• 한국정보과학회논문지:소프트웨어및응용
• /
• 제33권8호
• /
• pp.655-667
• /
• 2006

본 논문은 목표 및 시나리오 기반의 요구사항을 이용하여 기능점수 (function point)를 산정하는 방법을 제안한다. 기능점수는 소프트웨어의 규모를 계산하는 방법으로 널리 사용되고 있으며 비용계산의 기본자료가 된다. 기능접수를 산정하기 위해서는 요구사항 도출 및 분석이 선행되어야 하나 기존의 기능점수 방법론은 이를 다루지 않고 있다. 한편 시스템 개발의 초기단계에서 대부분의 요구사항은 자연어 형태로 수집된다. 목표와 시나리오 방법론은 자연어 형태의 요구사항을 사용하여 요구사항을 도출하고 분석하는 방법으로 널리 사용되고 있으며 추적성에 대한 장점을 가지고 있다. 그러므로 목표 및 시나리오 기반의 요구사항으로부터 기능점수를 산정 할 수 있다면 요구사항과 기능접수 간의 추적성 관리가 쉬워진다. 이에 본 논문에서는 목표와 시나리오 기반의 요구사항으로부터 기능점수를 산정하는 방안을 제안한다. 제안된 방안은 자연어 형태로 기술된 목표 및 시나리오로부터 기능접수 분석에 필요한 규칙을 제공한다. 제안된 방안은 Order Processing System 예제를 통해 적용 방안을 설명한다.

• 공학교육연구
• /
• 제14권4호
• /
• pp.62-68
• /
• 2011

Many engineering schools in Korea implement ABEEK programs. One of the core parts of ABEEK is accreditation criterion 2, the program outcomes and their appraisal. This paper tries to discuss the program outcomes and to study the impact of applying the program outcomes to one of the graduation requirements. We show simple survey results for implementing ABEEK programs concerning the program outcomes and their relation to graduation requirements. If the program outcomes are used as one of the graduation requirements, some graduates may satisfy the average grade point for graduation requirements but can not meet the program outcome criteria satisfied by other than regular classes. In this case, the graduate may have trouble to try to meet the program outcome criteria, since he may not be able to stay in school without taking classes. The problems of setting the levels of program outcomes as graduation requirements, non classwork related program outcomes, and work burden to professors should be also prudently reviewed for successful ABEEK implementation.

• 항공우주시스템공학회지
• /
• 제7권2호
• /
• pp.29-34
• /
• 2013

Safety requirements for aircraft and system functions include minimum performance constraints for both availability and integrity of the function. These safety requirements should be determined by conducting a safety assessment. The depths and contents of aircraft system safety assessment vary depending on factors such as the complexity of the system, how critical the system is to flight safety, what volume of experience is available on the type of system and the novelty and complexity of the technologies being used. Requirements that are defined to prevent failure conditions or to provide safety related functions should be uniquely identified and traceable through the levels of development. This will ensure visibility of the safety requirements at the software and electronic hardware design level. This paper has prepared to study on promoting the efficiency of establishing hierarchical safety requirements from aircraft level function to item level through system safety processes.

• 한국철도학회:학술대회논문집
• /
• 한국철도학회 2008년도 춘계학술대회 논문집
• /
• pp.1083-1088
• /
• 2008

The first task for the development of a train system is to define the system and to determine its requirements. Reliability target is one of the requirements defined in the system requirements. In railway applications it is advised to follow the procedures given in IEC 62278 to fulfill reliability requirements. The reliability requirements are derived from the customer's needs. The way in which the system requirements reflect the customer's needs is strongly dependent on the characteristics of the product. In general the customer of commercial trains presents the system requirements from their needs. However, the relation between the customer and supplier is equivocal for a project to development a prototype train, and the reliability program should be different from that of an usual commercial project. This paper deals with the reliability management and assessment plan carried out for the on-going "Next generation high-speed train development project".

• 시스템엔지니어링학술지
• /
• 제2권2호
• /
• pp.33-38
• /
• 2006

It is well known that efficient management and thorough implementation of stakeholder requirements is vital for a successful development of a large-scale and complex system. Equally important is to make sure that all the requirements be correctly realized in the developed system. For the purpose, verification requirements are derived with traceability from the system requirements. This paper discusses a step by step process for constructing the requirements verification model which includes : 1) the schema modeling both requirements and their traceability; 2) the template documenting the verification requirements; 3) the verification model constructed from the schema; and 4) the test and evaluation plan that can be printed automatically.

• 한국컴퓨터정보학회논문지
• /
• 제6권4호
• /
• pp.30-37
• /
• 2001

전통적 개발방법론에서는 요구분석단계에서 요구사항들이 한번 정리되면 이들은 개발이 완료될 때까지 변경이 없을 것으로 간주한다. 그러나 현실적으로는 개발기간 중 목표 시스템의 구체화, 정보기술의 발전, 적용환경의 변화 등으로 인하여 요구사항은 끊임없이 변화하게 된다. 본 논문에서는 개발방법론에서 미흡한 요구사항 관리를 개선하기 위하여 요구사항의 관리를 전체 개발 생명주기로 확대하고, 지속적으로 발생하는 요구사항의 변경을 효율적으로 관리할 수 있는 요구사항의 명세화 방안을 제시한다.

• Journal of Positioning, Navigation, and Timing
• /
• 제11권4호
• /
• pp.389-395
• /
• 2022

In order to ensure reliability the high-level automated driving such as Advanced Driver Assistance System (ADAS) and universal robot taxi provided by autonomous driving systems, the operation with high integrity must be generated within the defined Operation Design Domain (ODD). For this, the position and posture accuracy requirements of autonomous driving systems based on the safety driving requirements for autonomous vehicles and domestic road geometry standard are necessarily demanded. This paper presents localization requirements for safe road driving of autonomous ground vehicles based on the requirements of the positioning system installed on autonomous vehicle systems, the domestic road geometry standard and the dimensions of the vehicle to be designed. Based on this, 4 Protection Levels (PLs) such as longitudinal, lateral, vertical PLs, and attitude PL are calculated. The calculated results reveal that the PLs are more strict to urban roads than highways. The defined requirements can be used as a basis for guaranteeing the minimum reliability of the designed autonomous driving system on roads.