• Proceedings of the Korea Information Processing Society Conference
• /
• 2002.11c
• /
• pp.1925-1928
• /
• 2002

소프트웨어에 대한 고객의 요구수준이 점점 높아지고 복잡, 대형화됨에 따라 개발인력, 예산, 기간 등 많은 개발 자원이 소요되는 추세이지만, 개발자 직관에 의한 정성적인 판단으로 소요자원의 과부족을 초래하는 원인이 되고 있다. 본 논문에서는 요구분석 단계에서 기존의 정성적 판단에 따른 문제점을 보완하기 위해 요구분석 프로세스를 수정/제안하고, 의사결정기법을 이용하여 요구사항을 정량적으로 분석하고 식별할 수 있는 방법을 제안하였다. 이를 위해 사용자 요구분석 프로세스 검증단계에서 요구사항 평가활동을 추가하고, 의사결정 모델을 이용한 요구사항 가중치 계산, 시스템 기능과의 관련성 평가, 중요도 가중치를 계산하여 요구사항에 대한 식별의 기준으로 삼는다.

• Proceedings of the Korean Information Science Society Conference
• /
• 2003.10b
• /
• pp.391-393
• /
• 2003

최근 요구 사항에 대한 관리가 소프트웨어 시스템 개발의 중요한 성공 요인으로 등장하게 되어 그 중요성은 더욱 부각되고 있다. 특별히 소프트웨어 품질에 관심이 높아지면서 고품질의 소프트웨어 생산을 위한 노력이 활발히 이루어 지고 있다. 이러한 노력의 일환으로 소프트웨어 개발의 초기단계인 요구사항 단계에서 비기능적인 요구사항을 분석함을 제시하고 있으나 극히 미진한 연구가 진행되고 있다. 본 논문에서는 이를 위해 요구사항 단계에 영향을 주는 품질 속성으로 품질 모델을 정의하고 이를 이용하여 기능적 요구사항을 중심으로 관련된 비기능적 요구사항을 추출한다. 그리고 추출된 비기능적 요구사항과 품질 모델을 사용하여 시스템 단계의 비기능적 요구사항을 추가적으로 추출하는 방안을 제시한다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2010.04a
• /
• pp.946-949
• /
• 2010

요구사항은 프로젝트의 성패에 큰 영향을 미치며 체계적인 단계를 통해 생성된다. 요구사항 프로세스의 각 단계별로 의사결정이 요구한다. 그러나 요구공학 프로세스 및 단계의 다양한 요소로 인해 의사결정 절차와 방법의 차이가 발생함으로 요구공학의 자동화에 부정적 영향을 미치고 있다. 본 연구는 요구공학 프로세스의 의사결정 타스크를 정형화하는 것이다. 요구공학 프로세스별로 상이한 의사결정의 공통적인 패턴을 찾아 정형화하는 것을 목적으로 한다. 결과적으로 본 연구는 식별된 공통의 패턴을 기반으로 요구공학의 의사결정 모델과 정형화된 의사결정 타스크를 제안할 것이다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2009.04a
• /
• pp.444-447
• /
• 2009

임베디드 시스템은 여러 유형의 엄격한 제약사항을 지키는 범위 안에서 개발되어야 하기 때문에 요구사항의 우선순위 결정은 매우 중요하다. 이는 결국 개발 초기단계에 요구사항 우선순위화를 통하여 주어진 제품 개발 목표 및 개발 조직의 다양한 상황에 적합한 관점을 고려한 최적의 요구사항을 선택하는 활동이 요구된다. 따라서 본 논문에서는 임베디드 시스템의 다양성과 특수성을 고려한 임베디드 시스템 요구사항 우선순위 기법을 제안한다. 이를 위해 요구사항 우선순위 관점에서 임베디드 시스템 개발에 적합한 관점, 의존 및 상충 관계를 고려하여 요구사항을 우선순위화하며, 제안된 방법을 핸드폰 개발 사례에 적용하여 유용성을 검증한다. 이러한 합리적인 우선순위 선정을 통해 주어진 비즈니스 목표에 부합되고 시장요구에 적극적으로 반응할 수 있는 제품을 만들 수 있다.

• Journal of KIISE:Software and Applications
• /
• v.37 no.3
• /
• pp.161-169
• /
• 2010

The requirement elicitation is the task of eliciting requirements from needs of stakeholders, and preparing for information for negotiation. However, there are methods for gathering needs, but there is no specific method for classifying them, generating information for negotiation. Therefore, To solve the problems, this paper proposes a method to classify requirement and to generate information for negotiation. The proposed methods use Kano model, statistical technique, and identifying relationship between requirements and problems within scope. Finally, we validate the proposed method on simulations, Rough Set Theory, and case study of model.

• 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 the Korea Society of Computer and Information
• /
• v.17 no.11
• /
• pp.149-161
• /
• 2012

In the customer-centered world, which is used internet and social network services actively, it is important that their needs should be embraced into systems. Our study proposes a technique to normalize and select 1,800 customer's needs at C company. In order to normalize the requirements, we have specified requirements by considering a standard for requirements specification, have identified a set of keywords of requirements and have constructed a relation-graph of requirements. The graph presents objectives to design and build a system, and shows a degree of relative importance for each requirement. And then, we propose a techniques for requirements selection according to their contribution points, which are calculated using relative degree. We demonstrates our techniques by a case study of C company.

• 베이커리
• /
• no.6 s.443
• /
• pp.62-63
• /
• 2005

요구르트는 대표적인 웰빙 먹거리로 각광받으며 요즘 한창 몸값이 오르고 있다. 우리나라에 처음 요구르트와 유산균이 소개된 40여 년 전만해도 요구르트의 건강가치에 대해 지금처럼 아무나 줄줄 꾀게 될 줄은 어느 누구도 상상치 못했던 일이다. 지금으로부터 5천 여년 전 터키인의 유목생활에서 비롯됐다는 요구르트에 대한 몇 가지 이야기를 들어본다.

• Journal of Digital Convergence
• /
• v.12 no.12
• /
• pp.477-484
• /
• 2014

This study was examined relation to comprehensive needs and the quality of life in cancer patient. The Study period was 15 to 24 October 2012. The participants were 100 cancer patients more than 20 years old with cancer. Information and educational requirements are the highest need, and social support is the lowest one in patients with cancer. The longer survival time after diagnosis of cancer was, the higher social support requirements were needed. The Information and education requirement about healthy life showed higher in a family history of cancer. The cancer patients with stage IV ask higher service requirement significantly. and showed that physical and psychological requirements were getting higher, the quality of life became lower. As a result of this study, Physical and Psychological requirements were the most significant factors that affect the quality of life in cancer patients. Therefore, it is necessary to develop the physical and psychological supporting system and to provide appropriate Intervention for them.

• The Journal of the Institute of Internet, Broadcasting and Communication
• /
• v.16 no.1
• /
• pp.263-271
• /
• 2016

Software requirement analysis is necessary for successful software development project. Specially, incomplete requirement is the most influential causes of software project failure. Incomplete requirement can bring late delay and over budget because of the misunderstanding and ambiguous criteria for project validation. Software requirement patterns can help writing more complete requirement. These can be a reference model and standards when author writing or validating software requirement. Furthermore, when a novice writes the software scenario, the requirement patterns can be one of the guideline. In this paper proposes an automatic approach to identifying software scenario patterns from various software scenarios. In this paper, we gathered 83 scenarios from eight industrial systems, and show how to extract 54 scenario patterns and how to find omitted action of the scenario using extracted patterns for the feasibility of the approach.