• Structural Engineering and Mechanics
• /
• v.10 no.2
• /
• pp.93-110
• /
• 2000

An alternative interpretation of the completeness requirements for the higher order elements is presented. Apart from the familiar condition, $\sum_iN_i=1$, some additional conditions to be satisfied by the shape functions of higher order elements are identified. Elements with their geometry in the natural form, i.e., without any geometrical distortion, satisfy most of these additional conditions inherently. However, the geometrically distorted elements satisfy only fewer conditions. The practical implications of the satisfaction or non-satisfaction of these additional conditions are investigated with respect to a 3-node bar element, and 8- and 9-node quadrilateral elements. The results suggest that non-satisfaction of these additional conditions results in poorer performance of the element when the element is geometrically distorted. Based on the new interpretation of completeness requirements, a 3-node element and an 8-node rectangular element that are insensitive to mid-node distortion under a quadratic displacement field have been developed.

• Journal of Software Assessment and Valuation
• /
• v.15 no.2
• /
• pp.35-42
• /
• 2019

In this study, we reviewed the definition of completeness and payment in SW appraisal along to being complicated requirements of the appraisal, and we also presented their meaning and computation method. The completeness in SW appraisals means the degree of functional completion of the final product, and the payment refers cost spent to develop the product. Therefore, the completeness is evaluated based on the functions or interfaces of the final product, while the payment is calculated on the outputs or expenses of development steps. Recently, SW appraisal is complicated and the requirements for completeness and payment are changing. In this paper, we review the meanings and objectives of completeness and payment and present the evaluation methods for those.

• Journal of KIISE:Software and Applications
• /
• v.35 no.12
• /
• pp.731-740
• /
• 2008

A railway control system is one of the typical safety-critical systems. It is required to use formal methods for the requirements specification and verification in order to develop the global-standard railway control systems based on the computer systems. In this paper, we develop a guideline for requirements specification using formal methods, and present a case study of the development of a computer-based railway control system through the application of the proposed guideline. We use the Statechart and the Z method for the formal requirements specifications and verify the consistency and completeness of the formal specifications of the requirements.

• Journal of Software Assessment and Valuation
• /
• v.15 no.2
• /
• pp.9-16
• /
• 2019

More than 25% of software copyright evaluations commissioned to the Korea Copyright Commission are software completeness-defective evaluations. Most of the existing software completeness-defective evaluation cases were made to ensure that the requirements contained in the contract or customer's desired requirements were implemented and able to run, limited to the functionality of the software. This paper proposes a more systematic and reasonable maturity-correction technique to meet software completeness definitions. The ISO / IEC 9241.10 standard is a design standard for improving software quality. The ISO / IEC 9241.10 standard specifies seven items that must be complied with and requires functional integrity for work and operational integrity for work efficiency. The software completeness-defective methodology presented in this paper complements the existing function's implementation-functioning methodology with completeness evaluation on the quality of software.

• The KIPS Transactions:PartD
• /
• v.16D no.2
• /
• pp.201-212
• /
• 2009

There are various methods to trace output in software development to verify the consistency and completeness of requirements. Existing studies do present the trace meta-model or automated tools, but fail to list specifically traced output or traced items. Also, in regards to trace tables, which contain traced items, existing studies don‘t consider the whole software development process but merely its sub-process. Given this, the present study suggests an extended requirements tracetable that tracks output from the inception of the project through the architectural design phase to the application delivery, following up on the researcher’s previous study on a tracetable that considered only a sub-process of the whole development process. In addition, in order to address the problem of the tracking process becoming complicated with increased tracefields due to an extended trace table, the researcher suggests a method for normalizing a requirements tracetable that can integrate and separate by development process phase. Apply it to theH system development project of a D company, and this study caseverified application possibility of study, confirmed an effect of a chase to easily find out an error of requirements. Improve precision of a traceto verify consistency of requirements and completeness through this study, and will minimize failure of a software development.

• Structural Engineering and Mechanics
• /
• v.17 no.6
• /
• pp.767-788
• /
• 2004

The classical 8-node isoparametric serendipity element uses parametric shape functions for both test and trial functions. Although this element performs well in general, it yields poor results under severe mesh distortions. The distortion sensitivity is caused by the lack of continuity and/or completeness of shape functions used for test and trial functions. A recent element using parametric and metric shape functions for constructing the test and trial functions exhibits distortion immunity. This paper discusses the choice of parametric or metric shape functions as the basis for test and/or trial functions, satisfaction of continuity and completeness requirements, and their connection to distortion sensitivity. Also, the performances of four types of elements, viz., parametric, metric, parametric-metric, and metric-parametric, are compared for distorted meshes, and their merits and demerits are discussed.

• Journal of KIISE:Software and Applications
• /
• v.34 no.5
• /
• pp.419-430
• /
• 2007

It is very important to track whether software is properly developed according to requirements. This study suggests a method to track requirements by using a tracking table. In this study, the tracking table indicates why such requirements are included by detailing the content of requests for proposals and proposals. The table also facilitates verification of the consistency between outputs and the integrity by having ID codes of each requirement mapped to each output. Furthermore, as this study was conducted, it was found that some factors were required to be added or supplemented to the outputs at the requirement gathering stage of MaRMI-Ⅲ v.4.0 methodology. Thus, this study seeks to present this additional result along with the enhanced tracking table. By verifying outputs, the tracking table presented in this study will help to reduce all kinds of risks and problems that may occur in software development due to the lack of management of requirements. In addition, the output of the requirement-gathering stage of MaRMI-Ⅲ v.4.0 methodology will be improved/supplemented according to the creation of tracking tables; this will increment the applicability of the MaRMI-III methodology.

• Nuclear Engineering and Technology
• /
• v.48 no.2
• /
• pp.404-418
• /
• 2016

This paper presents a documentation and development method to facilitate the certification of scientific computing software used in the safety analysis of nuclear facilities. To study the problems faced during quality assurance and certification activities, a case study was performed on legacy software used for thermal analysis of a fuelpin in a nuclear reactor. Although no errors were uncovered in the code, 27 issues of incompleteness and inconsistency were found with the documentation. This work proposes that software documentation follow a rational process, which includes a software requirements specification following a template that is reusable, maintainable, and understandable. To develop the design and implementation, this paper suggests literate programming as an alternative to traditional structured programming. Literate programming allows for documenting of numerical algorithms and code together in what is termed the literate programmer's manual. This manual is developed with explicit traceability to the software requirements specification. The traceability between the theory, numerical algorithms, and implementation facilitates achieving completeness and consistency, as well as simplifies the process of verification and the associated certification.

• THE INTERNATIONAL COMMERCE & LAW REVIEW
• /
• v.13
• /
• pp.581-603
• /
• 2000

Beneficiary must present all documents stipulated in the Credit. If the documents conform in all respects with the terms and conditions of the Credit, beneficiary has a right to payment from an issuing or confirming bank. And banks must examine all documents presented by beneficiary for taking up the documents. If the documents appear on their face not to be in compliance with the terms and conditions of the Credit, banks may refuse to take up the documents. But standard for compliant documents with the terms and conditions of the Credit in the UCP or Section 5 of UCC is unclear. Because UCP Article 13(a) provides merely that banks must examine all documents stipulated in the Credit ${\cdots}$ to ascertain whether or not they appear, on their face, to be compliance with the terms and conditions of the Credit. ${\cdots}$ Documents which appear on their face to be inconsistent with one another will be considered as not appearing on their face to be in compliance with the terms and conditions of the Credit. Also UCC Section 5-108(a) provides merely that. ${\cdots}$ an issuer shall honor a presentation that, ${\cdots}$ appears on its face strictly to comply with the terms and conditions of the letter of credit. All problems are not resolve with easy by these regulations. Accordingly, I examined requirements for compliant documents with the terms and conditions of the Credit on the basis of the UCP and cases. To analyse this, I divided into three requirements ; (1) Completeness, (2) Regularity, (3) Linkage.

• Journal of Korean Society for Quality Management
• /
• v.29 no.2
• /
• pp.120-130
• /
• 2001

In this paper, the QFD(quality function deployment) technique is used to acquire the quality requirements of package software which is sold in commercial software shop. To select the principal quality characteristics of package software, an user survey was conducted for a quality model developed based on the international standards and the previous research. The software user is divided into three groups: the general user, the expert, and the developer. Based on the survey results, the top 10 quality characteristics are selected including accuracy, suitability, installability, de-installability, and maturaty. Then, the QFD technique is applied to choose the software quality attributes which have strong correlation with the selected quality characteristics, some of which are traceability, accuracy, modularity, completeness, and self-descriptiveness. The developed procedure can be used in evaluating the quality of package software with lower costs and efforts.