Fine-grain process modelling

In this paper, we propose the use of fine-grain process modelling as an aid to software development. We suggest the use of two levels of granularity, one at the level of the individual developer and another at the level of the representation scheme used by that developer. The advantages of modelling the software development process at these two levels, we argue, include respectively: (1) the production of models that better reflect actual development processes because they are oriented towards the actors who enact them, and (2) models that are vehicles for providing guidance because they may be expressed in terms of the actual representation schemes employed by those actors. We suggest that our previously published approach of using multiple “ViewPoints” to model software development participants, the perspectives that they hold, the representation schemes that they deploy and the process models that they maintain, is one way of supporting the fine-grain modelling we advocate. We point to some simple, tool-based experiments we have performed that support our proposition

Weaving together requirements and architecture

Software development organizations often choose between alternative starting points-requirements or architectures. This invariably results in a waterfall development process that produces artificially frozen requirements documents for use in the next step in the development life cycle. Alternatively, this process creates systems with constrained architectures that restrict users and handicap developers by resisting inevitable and desirable changes in requirements. The spiral life-cycle model addresses many drawbacks of a waterfall model by providing an incremental development process, in which developers repeatedly evaluate changing project risks to manage unstable requirements and funding. An even finer-grain spiral life cycle reflects both the realities and necessities of modern software development. Such a life cycle acknowledges the need to develop software architectures that are stable, yet adaptable, in the presence of changing requirements. The cornerstone of this process is that developers craft a system's requirements and its architecture concurrently, and interleave their development

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

On the consequences of acting in the presence of inconsistency

Managing inconsistency in specifications covers a range of activities from consistency checking and inconsistency analysis to inconsistency handling through action. In this paper we argue that inconsistency analysis is insufficient to determine the choice of actions to take in the presence of inconsistency. Rather, we propose that some form of `hypothetical reasoning' is needed in order to determine the consequences of different actions and thereby facilitate the decision-making process. We suggest some logic-based techniques and associated heuristics for analysing the consequences of acting in the presence of inconsistency. 1. Inconsistencies in specifications Deciding what action to take in the presence of inconsistency is difficult. Most researchers agree that eradicating inconsistency in specifications is a desirable and worthy goal, but there is an emerging view that it may also be acceptable to live with inconsistency in certain circumstances or for transient periods of time [..

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

The Many Facets of Mediation: A Requirements-driven Approach for Trading-off Mediation Solutions

Mediation aims at enabling dynamic composition of multi- ple components by making them interact successfully in order to satisfy given requirements. Through dynamic composition, software systems can adapt their structure and behaviour in dynamic and heterogeneous envi- ronments such as ubiquitous computing environments. This paper pro- vides a review of existing mediation approaches and their key character- istics and limitations. We claim that only a multifaceted approach that brings together and enhances the solutions of mediation from different perspectives is viable in the long term. We discuss how requirements can help identify synergies and trade-offs between these approaches and drive the selection of the appropriate mediation solution. We also highlight the open issues and future research directions in the area

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

Restructuring requirements specifications for managing inconsistency and change: a case study

This paper describes our experiences in restructuring multi-perspective requirements specifications in order to identify and analyse inconsistencies and manage change. A partial, heterogeneous and reasonably large requirements specification from a NASA project was analysed and decomposed into a structure of "viewpoints", where each viewpoint encapsulates partial requirements of some system components described in the specification. Relationships between viewpoints were identified which included not only the interactions explicitly stated in the requirements but also some implicit and potentially problematic inter-dependencies. The restructuring process and a first informal analysis of the resulting relationships enabled the detection of inconsistencies and the definition of some interesting domain-dependent consistency rules. We believe that this restructuring into viewpoints also facilitated requirements understanding through partitioning, and requirements maintenance and evolution through explicit identification of the inter-viewpoint relationships

Deriving security requirements from crosscutting threat descriptions

It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system. This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system