Software, architecture, and participatory design

Much work in software architecture has been inspired by work in physical architecture, in particular Alexander's work on `design patterns'. By contrast, Alexander's work is little-used in town planning and architecture. In this paper, we examine some of the reasons that this is so, describe some parallels and differences between the fields of physical and software architecture, and identify areas in which future collaboration may be fruitful. The notion of `participatory design' is important in software engineering and in urban regeneration, but the participatory mechanisms in each field are quite different

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

INCONSISTENCY HANDLING IN MULTIPERSPECTIVE SPECIFICATIONS

Published versio

A Measurement-Driven Process Model For Managing Inconsistent Software Requirements

Inconsistency is a pervasive issue in software engineering. Both general rules of inconsistency management and special case-based approaches to handling inconsistency have recently been considered. In this paper, we present a process model for handling requirements inconsistency within the Viewpoints framework. In this process model, when an inconsistency among viewpoints is detected, a set of candidate proposals for handling inconsistency will be generated using techniques fromMulti-agent automated negotiations. The proposals are then prioritized using an integrated measurement of inconsistencies. The viewpoints involved in the inconsistency will then enter the negotiations by being presented with the candidate proposals and thus selecting an acceptable proposal based on the priorities associated with each candidate proposal. To facilitate usability, in our process, we assume that the natural language requirements statements are first translated into corresponding logical formulas using a translator software. Moreover, the candidate proposals for handling inconsistency are also translated back from formal logic into natural language before being presented for selection

Detecting Inconsistency in Functional Software Requirements

Success in software development depends on the availability of complete, consistent, and unambiguous functional software requirements. Inconsistencies in software requirements can propagate problems throughout the development cycle. We introduce the concept of a quantitative measure for detecting inconsistencies, namely, Potential Structural Inconsistency (PSI). This measure is derived from a structural model for a given set of requirements. We show how this measure can be determined using a case study with known inconsistencies