91 research outputs found
Using problem frames with distributed architectures: a case for cardinality on interfaces
Certain classes of problems amenable to description
using Problem Frames, in particular ones intended to be
implemented using a distributed architecture, can benefit
by the addition of a cardinality specification on the
domain interfaces. This paper presents an example of
such a problem, demonstrates the need for relationship
cardinality, and proposes a notation to represent
cardinality on domain interfaces
Recommended from our members
Going on-line on a shoestring: An experiment in concurrent development of requirements and architecture
A number of on-line applications were built for a small university using a micro-sized development team. Four ideas were tested during the project: the Twin Peaks development model, using fully functional prototypes in the requirements elicitation process, some core practices of Extreme Programming, and the use of open-source software in a production environment. Certain project management techniques and their application to a micro-sized development effort were also explored. These ideas and techniques proved effective in developing many significant Internet and networked applications in a short time and at very low cost
Arguing security: validating security requirements using structured argumentation
This paper proposes using both formal and structured informal arguments to show that an eventual realized system can satisfy its security requirements. These arguments, called 'satisfaction arguments', consist of two parts: a formal argument based upon claims about domain properties, and a set of informal arguments that justify the claims. Building on our earlier work on trust assumptions and security requirements, we show how using satisfaction arguments assists in clarifying how a system satisfies its security requirements, in the process identifying those properties of domains that are critical to the requirements
A framework for security requirements engineering
This paper presents a framework for security requirements
elicitation and analysis, based upon the construction of a context for the system and satisfaction arguments for the security of the system. One starts with enumeration of security goals based on assets in the system. These goals are used to derive security requirements in the form of constraints. The system context is described using a problem-centered notation, then this context is
validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in 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
Composing features by managing inconsistent requirements
One approach to system development is to decompose the requirements into features and specify the individual features before composing them. A major limitation of deferring feature composition is that inconsistency between the solutions to individual features may not be uncovered early in the development, leading to unwanted feature interactions. Syntactic inconsistencies arising from the way software artefacts are described can be addressed by the use of explicit, shared, domain knowledge. However, behavioural inconsistencies are more challenging: they may occur within the requirements associated with two or more features as well as at the level of individual features. Whilst approaches exist that address behavioural inconsistencies at design time, these are overrestrictive in ruling out all possible conflicts and may weaken the requirements further than is desirable. In this paper, we present a lightweight approach to dealing with behavioural inconsistencies at run-time. Requirement Composition operators are introduced that specify a run-time prioritisation to be used on occurrence of a feature interaction. This prioritisation can be static or dynamic. Dynamic prioritisation favours some requirement according to some run-time criterion, for example, the extent to which it is already generating behaviour
Using Problem Frames and projections to analyze requirements for distributed systems
Subproblems in a problem frames decomposition frequently make use of projections of the complete problem context. One specific use of projec-tions occurs when an eventual implementation will be distributed, in which case a subproblem must interact with (use) the machine in a projection that represents another subproblem. We refer to subproblems used in this way as services, and propose an extension to projections to represent services as a spe-cial connection domain between subproblems. The extension provides signifi-cant benefits: verification of the symmetry of the interfaces, exposure of the machine-to-machine interactions, and prevention of accidental introduction of shared state. The extension’s usefulness is validated using a case study
A taxonomy of asymmetric requirements aspects
The early aspects community has received increasing attention among researchers and practitioners, and has grown a set of meaningful terminology and concepts in recent years, including the notion of requirements aspects. Aspects at the requirements level present stakeholder concerns that crosscut the problem domain, with the potential for a broad impact on questions of scoping, prioritization, and architectural design. Although many existing requirements engineering approaches advocate and advertise an integral support of early aspects analysis, one challenge is that the notion of a requirements aspect is not yet well established to efficaciously serve the community. Instead of defining the term once and for all in a normally arduous and unproductive conceptual unification stage, we present a preliminary taxonomy based on the literature survey to show the different features of an asymmetric requirements aspect. Existing approaches that handle requirements aspects are compared and classified according to the proposed taxonomy. In addition,we study crosscutting security requirements to exemplify the taxonomy's use, substantiate its value, and explore its future directions
Towards the Model-Driven Engineering of Secure yet Safe Embedded Systems
We introduce SysML-Sec, a SysML-based Model-Driven Engineering environment
aimed at fostering the collaboration between system designers and security
experts at all methodological stages of the development of an embedded system.
A central issue in the design of an embedded system is the definition of the
hardware/software partitioning of the architecture of the system, which should
take place as early as possible. SysML-Sec aims to extend the relevance of this
analysis through the integration of security requirements and threats. In
particular, we propose an agile methodology whose aim is to assess early on the
impact of the security requirements and of the security mechanisms designed to
satisfy them over the safety of the system. Security concerns are captured in a
component-centric manner through existing SysML diagrams with only minimal
extensions. After the requirements captured are derived into security and
cryptographic mechanisms, security properties can be formally verified over
this design. To perform the latter, model transformation techniques are
implemented in the SysML-Sec toolchain in order to derive a ProVerif
specification from the SysML models. An automotive firmware flashing procedure
serves as a guiding example throughout our presentation.Comment: In Proceedings GraMSec 2014, arXiv:1404.163
Recommended from our members
Arguing satisfaction of security requirements
This chapter presents a process for security requirements elicitation and analysis,
based around the construction of a satisfaction argument for the security of a
system. The process starts with the enumeration of security goals based on assets
in the system, then uses these goals to derive security requirements in the form of
constraints. Next, a satisfaction argument for the system is constructed, using a
problem-centered representation, a formal proof to analyze properties that can be
demonstrated, and structured informal argumentation of the assumptions exposed
during construction of the argument. Constructing the satisfaction argument can
expose missing and inconsistent assumptions about system context and behavior
that effect security, and a completed argument provides assurances that a system
can respect its security requirements
An aspect-oriented approach to relating security requirements and access control
Affecting multiple parts in software systems, security requirements often tangle with functional requirements. In order to separate crosscutting concerns and increase modularity, we propose to represent security requirements as aspects that can be woven into functional requirements. Using problem frames to model the functional requirements, weaving is achieved by composing the modules representing security aspects with the requirement models. Moreover, we provide guidance on how such security aspects are structured to implement a particular access control solution. As a result, such security aspects become reusable solution patterns to refine the structure of security-related problem
- …