Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data.

Kirsten Mark Hansen

dblp:05/2666 · DBLP profile ↗
← Back
2ranked-venue papers
1as first author
0since 2021 · last 1998
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
2 papers
Requirements engineering and software design · 50% Software maintenance and evolution · 33% Program verification · 17%
Computer architecture, parallel and distributed computing, and storage systems
2 papers
Embedded and real-time systems · 72% Electronic design automation · 28%

Topics — the 8 heaviest of 8, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software maintenance and evolution
fault tree analysis
0.011998
From Safety Analysis to Software Requirements · IEEE Trans. Software Eng. 1998
Requirements engineering and software design
safety requirements
0.011998
From Safety Analysis to Software Requirements · IEEE Trans. Software Eng. 1998
Embedded and real-time systems › critical systems
safety-critical software
0.011998
From Safety Analysis to Software Requirements · IEEE Trans. Software Eng. 1998
Program verification › reactive system verification
real-time system verification
0.011993
Specifying and Verifying Requirements of Real-Time Systems · IEEE Trans. Software Eng. 1993
Requirements engineering and software design
requirements specification
0.011993
Specifying and Verifying Requirements of Real-Time Systems · IEEE Trans. Software Eng. 1993
Electronic design automation › formal methods
formal specification and verification
0.011993
Specifying and Verifying Requirements of Real-Time Systems · IEEE Trans. Software Eng. 1993
Embedded and real-time systems
distributed real-time systems
0.011993
Specifying and Verifying Requirements of Real-Time Systems · IEEE Trans. Software Eng. 1993
Embedded and real-time systems › networked embedded systems
sensor-actuator networks
0.011993
Specifying and Verifying Requirements of Real-Time Systems · IEEE Trans. Software Eng. 1993

Methods — techniques the papers use, named apart from their topics

temporal logic · 0.0fault tree analysis · 0.0interval logic · 0.0duration calculus · 0.0deduction · 0.0
YearPublicationVenuePosition
1998 From Safety Analysis to Software Requirements
abstract
Software for safety critical systems must deal with the hazards identified by safety analysis. This paper investigates, how the results of one safety analysis technique, fault trees, are interpreted as software safety requirements to be used in the program design process. We propose that fault tree analysis and program development use the same system model. This model is formalized in a real-time, interval logic, based on a conventional dynamic systems model with state evolving over time. Fault trees are interpreted as temporal formulas, and it is shown how such formulas can be used for deriving safety requirements for software components.
Kirsten Mark Hansen, Anders P. Ravn, Victoria Coleman
IEEE Trans. Software Eng.1
1993 Specifying and Verifying Requirements of Real-Time Systems
abstract
An approach to specification of requirements and verification of design for real-time systems is presented. A system is defined by a conventional mathematical model for a dynamic system where application specific states denote functions of real time. Specifications are formulas in duration calculus, a real-time interval logic, where predicates define durations of states. Requirements define safety and functionality constraints on the system or a component. A top-level design is given by a control law: a predicate that defines an automation controlling the transition between phases of operation. Each phase maintains certain relations among the system states; this is analogous to the control functions known from conventional control theory. The top-level design is decomposed into an architecture for a distributed system with specifications for sensor, actuator, and program components. Programs control the distributed computation through synchronous events. Sensors and actuators relate events with system states. Verification is a deduction showing that a design implies requirements.>
Anders P. Ravn, Hans Rischel, Kirsten Mark Hansen
IEEE Trans. Software Eng.3