A logic-based calculus of events
New Generation Computing
Four dark corners of requirements engineering
ACM Transactions on Software Engineering and Methodology (TOSEM)
On the criteria to be used in decomposing systems into modules
Communications of the ACM
Problem frames: analyzing and structuring software development problems
Problem frames: analyzing and structuring software development problems
Relating Software Requirements and Architectures Using Problem Frames
RE '02 Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering
Composing Requirements Using Problem Frames
RE '04 Proceedings of the Requirements Engineering Conference, 12th IEEE International
Requirement Progression in Problem Frames Applied to a Proton Therapy System
RE '06 Proceedings of the 14th IEEE International Requirements Engineering Conference
Commonsense Reasoning
Problem Oriented Software Engineering: Solving the Package Router Control Problem
IEEE Transactions on Software Engineering
What's in a feature: a requirements engineering perspective
FASE'08/ETAPS'08 Proceedings of the Theory and practice of software, 11th international conference on Fundamental approaches to software engineering
Artificial intelligence today
Early Identification of Problem Interactions: A Tool-Supported Approach
REFSQ '09 Proceedings of the 15th International Working Conference on Requirements Engineering: Foundation for Software Quality
Specifying software features for composition: A tool-supported approach
Computer Networks: The International Journal of Computer and Telecommunications Networking
Hi-index | 0.00 |
Central to the problem frames approach is the distinction of three different descriptions: requirements R, domain assumptions W and specifications S, tied together with the so-called 'frame concern', a proof obligation that has to hold between them if a problem diagram is to be correct: S, W |- R. The form this proof should take is not fixed a priori. It might, however, be desirable to automate it in order to allow for an efficient analysis of large diagrams. To make this possible, we follow some earlier suggestions to use the Event Calculus as a suitable formalism for these descriptions. The main contribution of the present paper is a set of consistency rules as well as guidelines for passing from a problem diagram to its formal description.