• International conference on construction engineering and project management
• /
• 2020.12a
• /
• pp.243-248
• /
• 2020

In addition to a range of H&S documentation, a range of actions, beliefs, interventions, practices, and states are important in terms of achieving optimum construction H&S. Conclusions include that H&S documentation facilitates and assists planning, organising, leading, controlling, and coordinating H&S. Furthermore, current H&S documentation: is inappropriate in that it can be complex, generic, lengthy, onerous, repetitive (duplicative), and vague; engenders dubious practices; generally, 'does not add the potential value'; shifts the focus from the physical process, and could be improved. Recommendations include: industry associations should review their 'audit system' to interrogate the allocation of points; H&S documents must reflect the intention of the requirement; the synergy between H&S documentation, and actions, interventions, and practices should be investigated, digested, and focused upon, and 'audits', or rather inspections, should focus more on the physical process, actions, interventions, and practices, than documentation.

• The Journal of the Korea Contents Association
• /
• v.8 no.5
• /
• pp.61-71
• /
• 2008

It is often claimed that the descriptive way of documentation is insufficient to define software requirements as being unambiguous. This is caused by not only the difference of knowledge and understanding of the stakeholder as to system but also the difference in the way of documentation like method of representation as well as depth of description. The study explains the process and results of applying a diagraming tool like UML to improve the requirements of GLORY(GLObal Resource management sYstem) initially defined in descriptive way. Especially, the result shows that the requirements are more accurately improved with the good hierarchies and well-leveled functionalities, with the help of diagraming tool, expecting easy maintenance of requirements and prevention of omission of requirements.

• Proceedings of KOSOMES biannual meeting
• /
• 2018.06a
• /
• pp.168-168
• /
• 2018

• Proceedings of the Korean Institute of Information and Commucation Sciences Conference
• /
• 2006.05a
• /
• pp.569-572
• /
• 2006

In this paper, we purpose requirement capturing for RSS reader that be able to aggregate and subscribe to a RSS format document and describing for analysis model. We execute requirement analysis and documentation by using analysis model which is adopted use case model. And the method of requirement analysis is based on Responsibility Driven Design. Analysis model that is not premised on special reader is able to use business model.

• Journal of Information Technology Applications and Management
• /
• v.11 no.4
• /
• pp.121-132
• /
• 2004

This paper surveyed 30 system designers and developers who had been participating in a project for five months to examine the usefulness of design artifacts for object-oriented system development. A set of nine requirement and design documents was selected in consideration of the IEEE guidelines. Overall the respondents appeared to agree that the artifacts were useful for system development. On the other hand, the contribution of design artifacts to maintenance was rated lower due to the frequent changes over the iterative process. Of the artifacts, considered more useful were use case specifications, UI design and operation specifications. The respondents were the most reluctant to write test cases. Designers did not like to document more details in the design artifacts than did developers. A future study is required to determine the economics end change management of documentation.

• International Commerce and Information Review
• /
• v.12 no.4
• /
• pp.405-427
• /
• 2010

This legal study is to compare the Electronic Transactions Act in Thailand(hereinafter 'ETA') with mainly other countries electronic transactions acts, such as UNCITRAL MLEC, UECIC, VETA, UCITA and Korea' Electronic Transactions Act The ETA is consisted of 6 chapters which included preamble and definitions. Each chapter's main point as follows. Preamble is related to the name, time of legal effect, scope and definitions. Chapter 1 is not only general principles of electronic transactions, required restriction in addition to specify the limit of application, documentation, evidential weight in reference to the data message, but also the conditions of offer and acceptance through data message, time and place of dispatch and receipt of data message, certification between origination and addressee. According to media-neutrality and the effectiveness security requirement of data message under the information system, legal certification is related to the exchange's declaration of intention, define about origination-addressee of data message. Chapter 2 is composed to provide expressly about the effectiveness security in electronic signature. Those contents are to compare the MLEC, UECIC and Electronic Transactions Act in Korea. Chapter 3 is related to legal definitions that present legal requirement about service relating electronic transaction which contents accept domestic law, the adequate requirement as eligibility, satisfied matter, self-reliance ratio of finance and other detail standard Chapter 4 is deal with the transaction which are public sector and those application requirements. And also this chapter are composed regulations about direct-indirect purpose of Thailand domestic electronic government.

• Journal of the Korean Society of Systems Engineering
• /
• v.9 no.1
• /
• pp.13-23
• /
• 2013

Operational Concept Descriptions or Document(OCD) shall be developed to understand stakeholder's desire for to-be-delivered system. But there is little study on methodology of OCD generation and many developers do not understand importance of OCD in Korea. According to Nicole Roberts' industry(18 U.S. companies and organizations) survey, only 30% of system development projects had OCD, too. Researchers and developers have opposing views regarding the generation of an OCD. Many researchers believe that the development and use of operational concepts at the start of large projects is essential. Alternatively, developers may view the OCD as a burden to the development process rather than an enabler due to the extensive documentation requirement. In this paper a couple of OCD guidelines were investigated to clarify how to build a CONOPS effectively and what to include. Finally, OCD for rotorcraft based Personal Air Vehicle System(PAVS) was developed as a case study. In the future, a template for generating OCD appropriate to Korean environment could be proposed.

• Journal of the Korean Society of Systems Engineering
• /
• v.9 no.1
• /
• pp.33-45
• /
• 2013

Systems Engineering Approach was applied to the development of operator-support core management system based on the on-site operation experience and document of core management procedures, which is for enhancing operability and safety in PHWR (Pressurized Heavy Water Reactor) operation. The dissertation and definition of the system were given on th basis of investigating and analyzing the core management procedures. Fuel management, detector calibration, safety management, core power distribution monitoring, and integrated data management were defined as main user's requirements. From the requirements, 11 upper functional requirements were extracted by considering the on-site operation experience and investigating documents of core management procedures. Detailed requirements of the system which were produced by analyzing the upper functional requirements were identified by interviewing members who have responsibility of the core management procedures, which were written in SRS (Software Requirement Specification) document by using IEEE 830 template. The system was designed on the basis of the SRS and analysis in terms of nuclear engineering, and then tested by simulation using on-site data as a example. A model of core power monitoring related to the core management was suggested and a standard process for the core management was also suggested. And extraction, analysis, and documentation of the requirements were suggested as a case in terms of systems engineering.

• Proceedings of the Korean Nuclear Society Conference
• /
• 1998.05a
• /
• pp.335-340
• /
• 1998

In this paper a prototype of Requirement Tracking and Verification System(RTVS) for a Distributed Control System was implemented and tested. The RTVS is a software design and verification tool. The main functions required by the RTVS are managing, tracking and verification of the software requirements listed in the documentation of the DCS. The analysis of DCS software design procedures and inter(aces with documents were performed to define the user of the RTVS, and the design requirements for RTVS were developed.

• International Commerce and Information Review
• /
• v.7 no.1
• /
• pp.55-74
• /
• 2005

Recently, many enterprises have attempted to construct data warehousing systems for decision-support. Data warehouse is an intelligent store of data that can aggregate vast amounts of information. Building DW requires two important development issues:(i) DW for the decision making of business users and (ii) metadata within it. Most DW development methodologies have not considered metadata development; it is necessary to adopt a DW development methodology which develops a DW and its metadata simultaneously. Metadata is a key to success of data warehousing system and is critical for implementing DW. That is, metadata is crucial documentation for a data warehousing system where users should be empowered to meet their own information needs; users need to know what data exists, what it represents, where it is located, and how to access it. Furthermore, metadata is used for extracting data and managing DW. However, metadata has failed because its management has been segregated from the DW development process. Metadata must be integrated with data warehousing systems. Without metadata, the decision support of DW is under the control of technical users. Therefore, integrating data warehouse with its metadata offers a new opportunity to create a more adaptive information system. Therefore, this paper proposes a DW development methodology from a metadata perspective. The proposed methodology consists of five phases: preparatory, requirement analysis, data warehouse (informational database) development, metastore development, and maintenance. To demonstrate the practical usefulness of the methodology, one case is illustrated