Deposits of clastic carbonate-dominated (calciclastic) sedimentary slope systems in the rock record have been identified mostly as linearly-consistent carbonate apron deposits, even though most ancient clastic carbonate slope deposits fit the submarine fan systems better. Calciclastic submarine fans are consequently rarely described and are poorly understood. Subsequently, very little is known especially in mud-dominated calciclastic submarine fan systems. Presented in this study are a sedimentological core and petrographic characterisation of samples from eleven boreholes from the Lower Carboniferous of Bowland Basin (Northwest England) that reveals a >250 m thick calciturbidite complex deposited in a calciclastic submarine fan setting. Seven facies are recognised from core and thin section characterisation and are grouped into three carbonate turbidite sequences. They include: 1) Calciturbidites, comprising mostly of highto low-density, wavy-laminated bioclast-rich facies; 2) low-density densite mudstones which are characterised by planar laminated and unlaminated muddominated facies; and 3) Calcidebrites which are muddy or hyper-concentrated debrisflow deposits occurring as poorly-sorted, chaotic, mud-supported floatstones. These

Phd by thesis

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.

/pdf/requirements-engineering-a-roadmap-3lcu5ikya8.pdf

Requirements engineering: a roadmap

Investigates and discusses the underlying nature of the requirements traceability problem. Our work is based on empirical studies, involving over 100 practitioners, and an evaluation of current support. We introduce the distinction between pre-requirements specification (pre-RS) traceability and post-requirements specification (post-RS) traceability to demonstrate why an all-encompassing solution to the problem is unlikely, and to provide a framework through which to understand its multifaceted nature. We report how the majority of the problems attributed to poor requirements traceability are due to inadequate pre-RS traceability and show the fundamental need for improvements. We present an analysis of the main barriers confronting such improvements in practice, identify relevant areas in which advances have been (or can be) made, and make recommendations for research. >

/pdf/an-analysis-of-the-requirements-traceability-problem-ecamf894l1.pdf

An analysis of the requirements traceability problem

[서평]「Component Software」 - Beyond Object-Oriented Programming -

Technical foundations introduction software reliability and system reliability the operational profile software reliability modelling survey model evaluation and recalibration techniques practices and experiences best current practice of SRE software reliability measurement experience measurement-based analysis of software reliability software fault and failure classification techniques trend analysis in validation and maintenance software reliability and field data analysis software reliability process assessment emerging techniques software reliability prediction metrics software reliability and testing fault-tolerant SRE software reliability using fault trees software reliability process simulation neural networks and software reliability. Appendices: software reliability tools software failure data set repository.

/pdf/handbook-of-software-reliability-engineering-32dwvaljmm.pdf

Handbook of software reliability engineering

The root causes of safety-related software errors in safety-critical embedded systems are analyzed. The results show that software errors identified as potentially hazardous to the system tend to be produced by different error mechanisms than those that produce nonsafety-related software errors. Safety-related software errors are shown to arise most commonly from: discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system; and misunderstandings of the interface of the software with the rest of the system. These results are used to identify methods by which requirements errors can be prevented. The goal is to reduce safety-related software errors and to enhance the safety of complex, embedded systems. >

Analyzing software requirements errors in safety-critical, embedded systems

The paper describes three case studies in the lightweight application of formal methods to requirements modeling for spacecraft fault protection systems. The case studies differ from previously reported applications of formal methods in that formal methods were applied very early in the requirements engineering process to validate the evolving requirements. The results were fed back into the projects to improve the informal specifications. For each case study, we describe what methods were applied, how they were applied, how much effort was involved, and what the findings were. In all three cases, formal methods enhanced the existing verification and validation processes by testing key properties of the evolving requirements and helping to identify weaknesses. We conclude that the benefits gained from early modeling of unstable requirements more than outweigh the effort needed to maintain multiple representations.

/pdf/experiences-using-lightweight-formal-methods-for-1fys5zuvmf.pdf

Experiences using lightweight formal methods for requirements modeling

gineering for safety and proposes some directions for needed work that appears to be achievable in the near

/pdf/software-engineering-for-safety-a-roadmap-1nicagb1ua.pdf

Software engineering for safety: a roadmap

The use of software fault trees for requirements identification and analysis in an Intrusion Detection System (IDS) is described.

A software fault tree approach to requirements analysis of an intrusion detection system

This paper provides a Safety Checklist for use during the analysis of software requirements for spacecraft and others safety-critical, embedded systems The checklist specifically targets the two most common causes of safety-related software errors: (1) inadequate interface requirements and (2) discrepancies between the documented requirements and the requirements actually needed for correct functioning of the system The analysis criteria represented in the checklist are evaluated by application to two spacecraft projects Use of the checklist to enhance the software-requirements analysis is shown to reduce the number of safety-related software errors

Robyn R. Lutz

Papers

Analyzing software requirements errors in safety-critical, embedded systems

Experiences using lightweight formal methods for requirements modeling

Software engineering for safety: a roadmap

A software fault tree approach to requirements analysis of an intrusion detection system

Targeting safety-related errors during software requirements analysis