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

• Journal of KIISE:Software and Applications
• /
• v.31 no.7
• /
• pp.869-882
• /
• 2004

This paper proposes an effective method to create logically consistent and structured requirement model by applying consistency control approach of the formal method to the use-case modeling. This method integrates the multi-perspective scattered requirement segments that may overlap and conflict each other into a structured requirement model. The model structure can be analyzed based on context goal and concerned area overlap analysis. The model consistency can be achieved by using specification overlap-based consistency checking method as an integration vehicle. An experimental application to case study shows that the Proposed method can successfully identify requirement overlaps and inconsistency. It can also transfer multi-viewpoint requirement segments into a consistently integrated use-case model to clarify software behaviors and functionality This method helps users to enhance capability to identify specification inconsistency in the use-case modeling at the early stage of software engineering development. The proposed approach can also facilitate communication between users and developers to ensure customer satisfaction.

• Electric Engineers Magazine
• /
• v.266 no.10
• /
• pp.28-33
• /
• 2004

전기사업법 규정에 의한 기술기준은 전기설비의 안전확보를 위하여 필요한 최소한의 사항을 준수하도록 의무화하고 있다. 또 전기관련기관, 학계, 단체 및 업계의 참여로 작성되는 전기설비의 기술규정은 이러한 기술기준에 필요한 기술적인 사항을 규정함과 동시에 민간자율규정으로서 설계, 시공, 유지, 검사 등에 관한 사항을 구체적이고 알기 쉽게 풀이하여 권고적 사항, 권장적 사항으로 구분하여 규정하고 있다. <중략>

• Monthly Korean Chicken
• /
• v.14 no.12
• /
• pp.97-99
• /
• 2008

이번호에서는 축산업의 경쟁력을 강화하고 농가소득을 증진시키며 과세상 불합리한 점을 개선하기 위해 세법의 개정이 필요한 사항을 정리하고 모든 축산업자들이 의견을 모아 정부에 개정을 요구할 것을 제안해 본다. 다음의 사항은 어디까지나 세법의 개정이 필요한 사항이지 개정될 것이 아니므로 혼동하지 않길 바라며, 오로지 축산업자의 세무업무를 대행하면서 파악된 애로사항을 개선하고 축산 업자의 세부담을 완화하기 위해 꼭 필요하다고 사료되는 것들을 중심으로 기술해 본다.

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

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

• The KIPS Transactions:PartD
• /
• v.15D no.4
• /
• pp.505-512
• /
• 2008

In order to do requirement-based testing of embedded system, we must have correct requirement specifications. But, natural language requirements of a client have ambiguity, inaccuracy, and inconsistency. To solve these problems, natural language requirements are modeled with modeling language such as UML and Simulink. During a modeling phase, the requirements are rearranged and retranslated in use-case. These activities are disadvantages of modeling. In this paper, we propose the technique, which is how to model a embedded system requirement into a model without rearranging and retranslating. This technique 1) represent a embedded system requirement with graphical language, and 2) model a requirement into a model. Because this technique only describes "what-to-do" of the requirement, this technique is useful to not only the low-level requirements but also the high-level requirements. We show some example systems modeled by REED, which has adopted this technique.

• Proceedings of the Korea Water Resources Association Conference
• /
• 2023.05a
• /
• pp.457-457
• /
• 2023

본 연구에서는 위성영상 상황판연계·표출시스템을 개발하기 위하여 사용자 요구사항을 조사 및 분석하였고 분석 결과, 요구사항정의서와 시스템규격서를 도출하였다. 먼저, 위성영상 상황판 연계·표출시스템의 요구사항 조사를 위해 중앙재난안전상황실 근무자를 대상으로 설문(수요) 조사를 수행하였다. 상황실 실무자별 요구사항을 취합한 설문 결과와 연구 1차년에 수행했던 상황실 근무자 인터뷰 결과, RFP, 연구단 내부협의 결과를 검토하여 정보제공 측면 및 위성영상 활용 측면의 사용자 요구사항을 도출하였다. 도출 결과를 기반으로 시스템 요구사항을 정의한 결과, 시스템 기능은 54개의 기능과 9개의 비기능으로 분류되었다. 또한, 시스템 구성요소별 요구기능을 세부적으로 구분하여 요구사항정의서를 작성하였다. 시스템 요구기능 분류는 사용자기능/관리자기능/사용자서비스/사용자인터페이스/시스템기능/시스템서비스 등으로 상세 구분하였다. 마지막으로, 연구단 협의를 통해 요구사항정의서를 기반의 시스템규격서를 작성하였다. 시스템규격서는 일반규격, 각 시스템별 성능규격, 인터페이스규격, 기능규격으로 구분하여 세부 정의하였다. 본 연구내용은 지속적인 연구 개발을 통해 위성영상 상황판연계·표출시스템 설계 자료로 활용될 계획이며, 향후 위성영상을 활용한 재난안전 상황관리 대비/대응 체계 마련에 도움을 줄 것으로 사료된다.

• Proceedings of the Korean Institute of Navigation and Port Research Conference
• /
• 2016.05a
• /
• pp.249-251
• /
• 2016

해상교통안전진단은 해사안전법에 의해 시행되는 법적인 사항이다. 해상교통안전진단에서는 안전취약요소를 도출하고 취약요소에 대한 조치사항, 사업자의 의견 및 조치사항에 대한 시행주체를 정해야 한다. 안전취양요소에 대한 조치사항 중에는 사업자가 감당할 수 없는 사항이 다수 존재하지만 사업에 대한 심의, 승인 등의 권한을 갖는 처분기관과의 종속적인 관계로 인해 사업을 진행하기 위해 사업자가 그 부담을 지는 사례가 발생하고 있다. 이 연구에서는 VTS를 중심으로 그 사례를 소개하고자 한다.

• Proceedings of the Korean Information Science Society Conference
• /
• 2002.04b
• /
• pp.379-381
• /
• 2002

소프트웨어 개발 프로젝트에서 소프트웨어 요구사항의 잦은 변경 또는 요구사항 확정의 지연은 소프트웨어의 품질저하, 납기지연, 개발요구자와 개발담당자 간의 의견충돌을 야기한다. 특히 원자력발전소 환경과 같은 mission-critical 영역의 경우에는 발전소 건설자체를 지연시킬 수 있는 심각한 결과를 초래한다. 본 논문에서는 원자력발전소의 감시와 제어를 담당하는 MMIS(Man Machine Interface System) 환경을 동적으로 모의하는 소프트웨어 개발 과정에서 요구사항 변경의 가능성을 최소화시킬 의도로 시도하였던 요구사항 우선순위 설정에 대한 경험과 교훈을 살펴본다. 또한, 요구사항 우선순위를 기반으로 한 소프트웨어 개발 공정 활동을 토의한다