Checking Sanity of Software Requirements

Barnat, Jǐŕı; Bauch, Petr; Brim, Luboš

doi:10.1007/978-3-642-33826-7_4

Cited by 9 publications

(8 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Similar observations have given rise to the concepts of requirements sanity checking [2] and implementationless verification, meaning validation and verification methods that solely rely on declarative specifications without considering imple-mentations, even abstract ones, to show the correctness and consistency of requirements and their decomposition, and of the intended component system. In this fashion the blind spot of implementation-based verification can be avoided.…”

Section: Problem Statement and Objectivesmentioning

confidence: 82%

Evaluating Embedded-Software Specifications -- Quantitative and Structured Assessment of Declarative Interface Descriptions

Forster

2014

2014 IEEE International Symposium on Software Reliability Engineering Workshops

View full text Add to dashboard Cite

Relying on implementations in verification results in specifications and implementations that do not lend themselves well to reuse. Moreover, conventional verification tells engineers rather little about actual software or design quality ("Trust me, it's good."). We regard ease of formal specification, quality assessment and specification reuse, particularly in the form of declarative specifications, to be decisive factors in furthering the application of formal methods in software development. We aim to provide new, tool-supported techniques combining, and enabling, practical specification formalisms, implementationless model checking of structured specifications and complex measures for specification quality.

show abstract

Section: Problem Statement and Objectivesmentioning

confidence: 82%

Evaluating Embedded-Software Specifications -- Quantitative and Structured Assessment of Declarative Interface Descriptions

Forster

2014

2014 IEEE International Symposium on Software Reliability Engineering Workshops

View full text Add to dashboard Cite

show abstract

“…This is in contrast to the original paper[2] where redundancy has been called vacuity as the paper did not include vacuity witnesses.…”

mentioning

confidence: 79%

“…The primary interest of this paper is to re-state and extend techniques of our own [2] that allow the developers of computer systems to check sanity of their requirements when it matters most, i.e. during the requirements stage.…”

Section: Introductionmentioning

confidence: 99%

“…In this paper we extend [2] with a modified workflow that allows requirement engineers to explicitly specify universal (∀) and existential (∃) nature of individual requirements allowing thus to more naturally express some of the system properties. We also evaluate the robustness and sensitivity of our consistency and completeness checking procedures with respect to the use of different LTL to BA translators.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Analysing sanity of requirements for avionics systems

et al. 2016

Self Cite

View full text Add to dashboard Cite

In the last decade it became a common practice to formalise software requirements to improve the clarity of users' expectations. In this work we build on the fact that functional requirements can be expressed in temporal logic and we propose new sanity checking techniques that automatically detect flaws and suggest improvements of given requirements. Specifically, we describe and experimentally evaluate approaches to consistency and redundancy checking that identify all inconsistencies and pinpoint their exact source (the smallest inconsistent set). We further report on the experience obtained from employing the consistency and redundancy checking in an industrial environment. To complete the sanity checking we also describe a semi-automatic completeness evaluation that can assess the coverage of user requirements and suggest missing properties the user might have wanted to formulate. The usefulness of our completeness evaluation is demonstrated in a case study of an aeroplane control system. arXiv:1510.02669v1 [cs.SE] 9 Oct 2015 the system itself can be checked using model checking [4,12] or theorem proving [7] tools. If there are some requirements the system does not meet, the cause has to be found and the development reverted. The longer it takes to discover an error in the development, the more expensive the error is to mend. Consequently, errors made during requirements specification are among the most expensive ones in the whole development.Model checking is particularly efficient in finding bugs in the design, however, it exhibits some shortcomings when it is applied to requirement analysis. In particular, if the system satisfies the formula then the model checking procedure only provides an affirmative answer and does not elaborate for the reason of the satisfaction. It could be the case that, e.g. the specified formula is a tautology, hence, it is satisfied for any system. Tautologies can be obvious, such as p ∨ ¬p or subtle, such as p U ¬(r ∧ q),

show abstract

“…Benchmarks Since the applications of MUSes in the LTL domain have begun to be studied quite recently [6,5,9], there is no publicly available database of industrial benchmarks (or at least, we are not aware of it). Therefore, to obtain experimental data, we followed the approach of Barnat et al [5] and generated a collection of random benchmarks using the randltl tool from the SPOT library [19].…”

Section: Ltl Domainmentioning

confidence: 99%

Evaluation of Domain Agnostic Approaches for Enumeration of Minimal Unsatisfiable Subsets

Bendík¹,

Černá²

EPiC Series in Computing

View full text Add to dashboard Cite

In many different applications we are given a set of constraints with the goal to decide whether the set is satisfiable. If the set is determined to be unsatisfiable, one might be interested in analysing this unsatisfiability. Identification of minimal unsatisfiable subsets (MUSes) is a kind of such analysis. The more MUSes are identified, the better insight into the unsatisfiability is obtained. However, the full enumeration of all MUSes is often intractable. Therefore, algorithms that identify MUSes in an online fashion, i.e., one by one, are needed. Moreover, since MUSes find applications in various constraint domains, and new applications still arise, there is a desire for domain agnostic MUS enumeration approaches.In this paper, we present an experimental evaluation of four state-of-the-art domain agnostic MUS enumeration algorithms: MARCO, TOME, ReMUS, and DAA. The evalu- ation is conducted in the SAT, SMT, and LTL constraint domains. The results evidence that there is no silver-bullet algorithm that would beat all the others in all the domains.

show abstract

Checking Sanity of Software Requirements

Cited by 9 publications

References 18 publications

Evaluating Embedded-Software Specifications -- Quantitative and Structured Assessment of Declarative Interface Descriptions

Evaluating Embedded-Software Specifications -- Quantitative and Structured Assessment of Declarative Interface Descriptions

Analysing sanity of requirements for avionics systems

Evaluation of Domain Agnostic Approaches for Enumeration of Minimal Unsatisfiable Subsets

Contact Info

Product

Resources

About