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. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Charles B. Haley

dblp:11/6595 · DBLP profile ↗
← Back
5ranked-venue papers
3as first author
0since 2021 · last 2012
—ORCID · none

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

Software engineering, systems software and programming languages · 5 · 3 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 · 100%
Network and information security
2 papers
Network security · 57% Systems and software security · 43%

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

TopicWeightPapersLastEvidence papers
Requirements engineering and software design
model-driven engineering
0.112010
Tool support for code generation from a UMLsec property · ASE 2010
Requirements engineering and software design
requirements analysis
0.112008
Security Requirements Engineering: A Framework for Representation and Analysis · IEEE Trans. Software Eng. 2008
Requirements engineering and software design › non-functional requirements
security requirements
0.112008
Security Requirements Engineering: A Framework for Representation and Analysis · IEEE Trans. Software Eng. 2008
Network security
security modeling
0.012010
Tool support for code generation from a UMLsec property · ASE 2010
Systems and software security › secure software development
security requirements
0.012008
Security Requirements Engineering: A Framework for Representation and Analysis · IEEE Trans. Software Eng. 2008

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

code generation · 0.2problem-oriented notation · 0.2formal argumentation · 0.2
YearPublicationVenuePosition
2012 Privacy arguments: Analysing selective disclosure requirements for mobile applications
abstract
Privacy requirements for mobile applications offer a distinct set of challenges for requirements engineering. First, they are highly dynamic, changing over time and locations, and across the different roles of agents involved and the kinds of information that may be disclosed. Second, although some general privacy requirements can be elicited a priori, users often refine them at runtime as they interact with the system and its environment. Selectively disclosing information to appropriate agents is therefore a key privacy management challenge, requiring carefully formulated privacy requirements amenable to systematic reasoning. In this paper, we introduce privacy arguments as a means of analysing privacy requirements in general and selective disclosure requirements (that are both content- and context-sensitive) in particular. Privacy arguments allow individual users to express personal preferences, which are then used to reason about privacy for each user under different contexts. At runtime, these arguments provide a way to reason about requirements satisfaction and diagnosis. Our proposed approach is demonstrated and evaluated using the privacy requirements of BuddyTracker, a mobile application we developed as part of our overall research programme.
Thein Than Tun, Arosha K. Bandara, Blaine A. Price, Yijun Yu 0001, Charles B. Haley, Inah Omoronyia, Bashar Nuseibeh
RE5
2010 Tool support for code generation from a UMLsec property
abstract
S.357-358
Lionel Montrieux, Jan Jürjens, Charles B. Haley, Yijun Yu 0001, Pierre-Yves Schobbens, Hubert Toussaint
ASE3
2008 Security Requirements Engineering: A Framework for Representation and Analysis
abstract
This paper presents a framework for security requirements elicitation and analysis. The framework is based on constructing a context for the system, representing security requirements as constraints, and developing satisfaction arguments for the security requirements. The system context is described using a problem-oriented notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument consists of two parts: a formal argument that the system can meet its security requirements and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project.
Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, Bashar Nuseibeh
IEEE Trans. Software Eng.1
2006 Using trust assumptions with security requirements
Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, Bashar Nuseibeh
Requir. Eng.1
2004 The Effect of Trust Assumptions on the Elaboration of Security Requirements
Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, Bashar Nuseibeh
RE1