• Journal of KIISE:Software and Applications
• /
• v.31 no.8
• /
• pp.1010-1026
• /
• 2004

The goal of product line engineering is to support the systematic development of a set of similar software systems by understanding and controlling their common and distinguishing characteristics. The product line engineering is a process that develops reusable core assets and develops a set of software-intensive systems from a common set of core assets in a prescribed way. Currently, many software development technologies are accomplished in context of product line. However, much of the product line engineering research have focused on the reuse of work products relating to the software's architecture, detail design, and code. The product lines fulfill the promise of tailor-made systems built specifically for the needs of particular customers or customer groups. In particular, commonality and variability play central roles in the all product line development processes. These must be treated already during the requirement analysis phase. Requirements in product line engineering are basis of software development just like as traditional system development engineering, and basis of deciding other core assets' property - commonalities and variabilities. However, it is difficult to elicit, analyze and manage correct requirements. Therefore, it is necessary to develop systematic methods which can develop and manage requirement as core asset, which can be stable in anticipative change and can be well adapted to unpredictable change. In this paper, we suggest a method of managing requirements as core asset in product line. Through this method, the reuse of domain requirements can be enhanced. As a result, the cost and time of software development can be reduced and the productivity can be increased.

• Journal of the Korea Academia-Industrial cooperation Society
• /
• v.17 no.7
• /
• pp.425-433
• /
• 2016

The construction of a light rail transit (LRT) system is a large and complex infrastructure project involving hundreds of billions of won in construction costs for a single route, and it is very important to carry out such a project from a life-cycle perspective because of its long-term operation. Systems engineering is a means and methodology to successfully implement customers' needs, and it is useful in large projects such as light rail transit. An application model called Systems Engineering for Light Rail Transit (SELRT) was developed to support systems engineering activities in light rail transit projects. In order to utilize SELRT, it is necessary to ensure that system requirements are met. As such, in this paper, we present a verification procedure and architecture based on a systems engineering-based methodology, thereby identifying the system requirements and deriving the verification requirements to confirm the SELRT model for the proposed method. The results show that the traceability of the system requirements and verification requirements, the verification method for each requirement, and the demonstration results for computerized tools are mutually connected, and that the initial requirements are clearly implemented in the SELRT. The proposed method is valid for verifying the SELRT, which can also be utilized in a LRT project.

• Journal of Advanced Navigation Technology
• /
• v.24 no.3
• /
• pp.163-172
• /
• 2020

Flight data recorder (FDR) for accident investigation is required to comply with EUROCAE(ED-112) standard so that flight data can be restored when exposed to extreme conditions due to aircraft crash. Since the ED-112 standard defines the general requirements for all aircraft, it is essential to analyze detailed requirements for FDR software to apply appropriate requirements selectively according to the configuration and operation concept of a specific aircraft. In this paper, the software requirements applicable to unmanned aircraft will be analyzed and the FDR software design will be proposed. Also, a software verification method for each requirement will be presented to verify that the implemented software is designed to satisfy all requirements.

• The KIPS Transactions:PartD
• /
• v.14D no.6
• /
• pp.641-648
• /
• 2007

To develop a dynamic system project in which the requirement changes frequently, it's impossible to finish the development within a fixed-cost due to additional budget occurring in need of requirement creep. To manage the successive project within a fixed-cost, it's better to manage the ratio of necessarily changed size of project and necessary optional requirement. According to Bhagwat, it is occurred in the construction phase. Also, he stated that the software development cost, construction phase cost and requirement cost are equal and it was wrong explanation in the ratio of requirement creep and optional requirement. This paper assumes the requirement creep to be happening in the phase of elaboration and construction. In addition, some differences were supposed to happen between software development cost, construction phase cost, and requirement creep cost. As a result, the reality was preferred rather than the ratio of optional requirement and the ratio of requirement creep.

• Journal of the Korea Institute of Information and Communication Engineering
• /
• v.15 no.9
• /
• pp.2050-2058
• /
• 2011

The objective of this thesis is to research the software requirement management system for the development of operational flight program (OFP) which is embedded in aircraft avionics. It offers the function to record the requirement revision log. In fact, the COTS (commercial off-the-shelf) program which has similar function already exists in the market. But this kind of software programs are too complicated and relatively expensive in acquisition. Furthermore, they require too expensive maintenance cost, medium sized business company, this thesis intended to provide the software requirement management system that can be simply installed and easily used.

• Journal of Korean Library and Information Science Society
• /
• v.30 no.2
• /
• pp.93-121
• /
• 1999

The purpose of this study is to develop an experimental model for information needs assessment, which could be utilized to investigate the 'real' information needs of the user(or group). The focus was on the perspectives of users rather than those of system managers. In details, this study identifies the conceptual definition of the keyword 'information need', analyzes the limitation and problems the previously conducted needs assessments in this area, and finally, develops an experimental model based on the cognitive and affective variables which might influence both production and strength of information needs in the user(or group}. The model emphasizes four influencing variable, namely, individual, work-related, organizational(or institutional), and socio-cultural variables. Also discussed is the relationships among these variables.

• Journal of KIISE:Computer Systems and Theory
• /
• v.35 no.8
• /
• pp.394-406
• /
• 2008

Even though context is the most important feature in context-aware systems, the existing requirements engineering cannot support methodology for elicitation and specification of contexts. In this paper, we propose a requirements elicitation method and a requirements specification method for context-aware systems. Our requirements elicitation method is a 6-stepped, incremental, and iterative process. At the beginning steps in the process, we identify the requirements for business logic. Afterwards, we gather the requirements for context logic, model contexts, and identify subsystems. For requirements specification, we suggest a context-aware use case diagram, a context diagram for context modeling, and a context-type-use-case-dependency diagram for the traceability of use cases on the change of context types. We also introduce a case study that we apply our approaches to a real system, and a qualitative evaluation of our approaches. Our study will help stakeholders to efficiently elicit requirements for context-aware systems and to specify them clearly.

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

• Proceedings of the Korean Institute Of Construction Engineering and Management
• /
• 2007.11a
• /
• pp.1015-1018
• /
• 2007

VE is one of the most effective and systematic tool available to achieve the required function at minimum cost and manage in many industrial fields. The purpose of the preparation phase VE job plan is to establish a cooperation system referring to groups for the successful implementation of VE, and to achieve a common objective to collect sufficient materials required in the analysis phase. The Quality Model is used to measure the requirement of shareholders(users and owners)in the project. It also offers a guideline on decision making when executing the function definition, function arrangement, function evaluation, and the idea evaluation of VE. However, the current the preparation phase business confirms that the required items of owners and users has not suggested definite goals and directions. This study analyzes the problems of current work in the preparation phase from case study, survey and interviews of experts. It then proposes a new process after understanding the required items of owners, users and experts.

• Journal of KIISE:Computing Practices and Letters
• /
• v.8 no.1
• /
• pp.46-61
• /
• 2002

Among the many phases involved in software development, requirements analysis phase in generally considered to play a crucial role in determining the overall software quality. Therefore, many software development companies manages the phase as one of the important phase. Especially, safety assurance through requirements analysis for safety-critical systems is quite demanding, and national and international bodies routinely require safety demonstration. Among various approaches, inspection and formal methods are generally shown to be effective. In this paper, we propose a formal verification procedure for SCR(Software Cost Reduction)-style SRS(Software Requirements Specification) using the PVS specification and verification procedure and applied this procedure to an industrial system such that a shutdown system for Wolsung nuclear power plant. This system had been verified through inspection not formal verification. The application of formal methods is rare in Korea, so it is very important to experiment about formal verification to industrial systems.