M. Feather, `Constructing specifications by combining parallel elaborations', IEEE Trans. Software Engineering, 15, (2), 198--208 (1989).  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... conflicting requirements is inconsistent and should be avoided [17, 7] More recently, a negotiation process was developed for detecting and resolving conflicts on design issues from multiple perspectives [15] It facilitates collaboration which can benefit the requirement engineering process [6, 16]. This is an important step toward conflict resolution although it has not explicitly dealt with the analysis of conflicting imprecise requirements and the assessment of their priorities. The issue based information systems (IBIS) method [14, 3] and the process oriented approaches [10, 11] have ....

Martin S. Feather, "Constructing specifications by combining parallel elaborations", IEEE Transactions on Software Engineering, 15(2):198-208, 1989.

....idealized version of them which liberates him her from too many specification details in the requirements document. In other words, the work of the analyst was based on some assumptions related to the behaviours of the involved agents. In the proposed strategy (inspired by the pioneering work of [Feather89]) we consider two kinds of possible assumptions: The first assumption is based on an omniscience hypothesis i.e. the perfect knowledge an agent has of the states and actions of other agents. The second assumption is based on a reliability hypothesis associated with each agent, i.e. its ....

Feather (Martin S.). -- Constructing specifications by combining parallel elaborations. IEEE Transactions on Software Engineering, vol. SE-15, n 2, February 1989.

....the rules constrain which acts are legal in which context. Agents can then query chains of reasoning made by other agents, and request information which they need to verify the conclusions. In this way, conflicts based on misunderstandings and incomplete knowledge can be detected and resolved. Feather [1989a] proposes a specification model based on parallel elaboration of the various concerns. A basic specification is used as a point of departure for development along separate lines of concern. At some later stage the resulting specifications are merged to produce a single specification which will ....

....state seems to include recalled books both before and after they are returned, and so is not totally captured within the group ON SHELF ON RETURNED STACK. Different decompositions reveal different concerns within the system modelling process, in a similar way to Feather s parallel elaborations [Feather 1989a] Finally there is the case where an item or group of items in one description has no correspondence in the other. This may be because it has been omitted, or because the role played by such an item has been filled in other ways. For example, the SHELVE transition in the second description has ....

Feather, M. S., 1989a, "Constructing Specifications by Combining Parallel Elaborations", IEEE Transactions on Software Engineering, Vol 15, No 2, Feb 1989, p198-208.

....87] the Z specification was translated in Prolog to obtain a running prototype. Several formal methods are available for dealing with system specification. Z or VDM [Jones 90] are formal methods based on not executable languages; operational specification languages like PAISLEY [Zave 84] GIST [Feather 90], and Statecharts [Harel 87] are executable, prototypingoriented simulation languages. However, the design of a software engineering environment requires an approach that is both declarative and operational: declarativeness is necessary because the technology of environments is evolving from a ....

M. Feather, "Constructing Specifications by Combining Parallel Elaborations, IEEE Trans. on Software Engineering, 15:2, 198-208, 19891.

....idealized version of them which liberates him her from too many specification details in the requirements document. In other words, the work of the analyst was based on some assumptions related to the behaviours of the involved agents. In the proposed strategy (inspired by the pioneering work of [Feather89]) we consider two kinds of possible assumptions: ffl The first assumption is based on an omniscience hypothesis i.e. the perfect knowledge an agent has of the states and actions of other agents. ffl The second assumption is based on a reliability hypothesis associated with each agent, i.e. its ....

Feather (Martin S.). -- Constructing specifications by combining parallel elaborations. IEEE Transactions on Software Engineering, vol. SE-15, n 2, February 1989.

....the IS to be implemented but also on the environment around the IS as well as on the nature of the interactions taking place between both. The emphasis on a world oriented or closed system view [Bub83, Dub89, MBJK90, Bj92] led to the elaboration of specification for so called composite systems [Fea89], i.e. systems made of multiple heterogeneous components. For example, in the CIM context, one may think about requirements on an automated production system structured according to different components like, e.g. the storage sub system, the conveyance sub system, the machine tool and the ....

....language itself is characterized by : its expressiveness. Requirements on performances, actions and perceptions are structured in terms of agents having some contractual responsibilities for guaranteeing them. This need for introducing the concept of agent at the RE level is also emphasized in [Fea89, DFvL91, Yu93]; its degree of formality. Different kinds of constraints can be expressed using some variants of typed first order logic, viz temporal logic and deontic logic. Similar formal frameworks are also investigated in [FM90, JSS91] the availability of structuring mechanisms based on ....

Martin S. Feather. Constructing specifications by combining parallel elaborations. IEEE Transactions on software engineering, SE-15(2), February 1989.

....in this paper is the nature of the programming and specification formalisms, and of the relationship between them, which the necessity of synthesising interconnections imposes. Concerns about the systematic development of composite systems can be found in the literature. The work reported in (Feather, 1987, 1989, Fickas and Helm, 1992) in particular should be noted. However, these approaches are mostly concerned with the problem of decomposing a system specification into components, and assume a closed system point of view. In this paper, we take the dual point of view, i.e. we address composition in an ....

Feather, M. (1989) Constructing Specifications by Combining Parallel Elaborations. IEEE Transactions on Software Engineering15(2), 198-208.

....in this paper is the nature of the programming and specification formalisms, and of the relationship between them, which the necessity of synthesising interconnections imposes. Concerns about the systematic development of composite systems can be found in the literature. The work reported in (Feather, 1987, 1989, Fickas and Helm, 1992) in particular should be noted. However, these approaches are mostly concerned with the problem of decomposing a system specification into components, and assume a closed system point of view. In this paper, we take the dual point of view, i.e. we address composition in an ....

Feather, M. (1989) Constructing Specifications by Combining Parallel Elaborations. IEEE Transactions on Software Engineering15(2), 198-208.

.... Software quality interaction experts[20] MAUT[205] MCDM programming [286] MCDM for requirements[221] Software quality architecting[125] QFD[95] QFD for requirements[108] Non functional framework[178] Perspectives Multi view specification [174] Method Engineering[137] Parallel elaboration[58] Requirement Viewpoints[187] Process programming[195] Process compliance[56] Interaction monitoring[69] Products Requirements Modeling Language [88] Requirements traceability[198] Goal oriented requirements[42] Agent oriented requirements[177] Processes Goal based design[123] Goal based ....

....Multi View[6] and Soft Systems[29] combined both social and technical aspects of development in the representation of various views of system requirements. Algorithmic aspects of representing, comparing, and combining various system views have been described in Feather s parallel elaboration work[58], the ViewPoints project[187] and an ever growing body of related research[73] Requirements products have also evolved. To support reasoning about requirements interactions among requirements views, requirements definition languages has evolved. For example, the Requirements Modeling Language ....

[Article contains additional citation context not shown here]

Feather, M., Constructing specifications by combining parallel elaborations, IEEETransactions on Software Engineering V ol. 15 (February 1989)

.... is an inevitable feature of group interaction, to be harnessed for its positive aspects, rather than suppressed [Robbins 1989] Deutsch 1973] Strauss 1978] Some recent software engineering research has identified conflict as an issue [Curtis, Krasner Iscoe 1988] Anderson Fickas 1989] [Feather 1989], Robinson 1990] although as yet little progress has been made towards understanding how such conflict might be handled. Examples of many different types of conflict abound in the literature on organisational psychology. For example, Robbins [1974] describes a newly elected city manager who has ....

....and rules constrain which acts are legal in which contexts. Agents can query chains of reasoning made by other agents, and request information which they need to verify the conclusions. In this way, conflicts based on misunderstandings and incomplete knowledge can be detected and resolved. Feather [1989] uses a basic specification as a point of departure for development along separate lines of concern. At some later stage these are merged to produce a single specification, which will then reflect all the concerns. This model has the benefit of delaying the resolution of conflict between separate ....

[Article contains additional citation context not shown here]

Feather, M. S. (1989) Constructing Specifications by Combining Parallel Elaborations, IEEE Transactions on Software Engineering, 15 (2), Feb 1989, p198-208.

....using generic modification operations which added functionality in a layered manner. The modifications operations are strictly more general than programming techniques of stepwise enhancement ( 5, 9, 7] Incremental construction for software development has been advocated by others as well ([10, 3, 2]) However, in order to reduce the ripple P 2 : nodes(tree(AndOr,Node,Children) Label,Nodes) initial label(AndOr,InitLabel) nodes list(Children,AndOr,InitLabel,Label, ChildNodes) parent inclusion(Label,Node,ChildNodes,Nodes) nodes list( AndOr,Label,Label,Nodes,Nodes) nodes ....

M.S. Feather. Constructing specifications by combining parallel elaborations. IEEE Transactions on Software Engineering, 15(2):198--208, February 1989.

....His work suggests that some empirical analysis of specification marking and editing might be worthwhile. In the area of software engineering Fickas Nagarajan (1988) have conducted some interesting work on critiquing specifications. What we provide can be seen as complementary to this work. Feather (1987) examines how specifications are constructed, his use of the term highlevel editing is suggestive of links with the work outlined above. Clearly our approach, in which we emphasise the cooperative nature of specification relates to concerns shared by workers in the area of computer supported ....

Feather, M. (1987); Constructing Specifications by Combining Parallel Elaborations; [To appear] IEEE Trans. Software Engineering.

....in various guises by a number of authors. Doerry et al. 14] propose a model for composite system design based on multiple cooperating interacting agents with individual behaviours and goals. Dardenne et al. 12] describe a goal directed approach to composite system development, while Feather [19] suggests using many, parallel evolutionary transformations , which may then be merged by replaying them sequentially. Work on program transformation [60, 61] provides an additional vehicle for tackling consistency checks and information transfers between different ViewPoints. Robinson [49] ....

M. S. Feather (1989); "Constructing Specifications by Combining Parallel Elaborations"; Transactions on Software Engineering, 15(2): 198-208, February 1989; IEEE Computer Society Press.

.... stage,speaker,withdraws(Statement) stage,speaker,denies(Statement) ii) Commitment rules Set out how acts affect the commitment store of each viewpoint (we see these changes to the commitments as more or less equivalent to the high level edits described by Feather (1987)) For example: Commitment rule W: After a withdrawal the statement is removed from the speaker s commitment store, the hearer s store remains unchanged. After stage,speaker,withdraws(Statement) committed(stage 1,speaker) committed(stage,speaker) Statement committed(stage 1,hearer) ....

Feather, M. (1987); Constructing Specifications by Combining Parallel Elaborations; To appear IEEE Trans. Software Engineering.

....in requirements acquisition and in formal specification are rather different. Requirements acquisition involves learning [Vla91a] and negotiation [Rob90] whereas formal specification involves data operation refinement and structuring, assertion strengthening and weakening, and so forth [Dub87] [Fea89]. The focus of this paper is on the requirements acquisition task. Our aim is to present elements of a general approach to requirements acquisition we have developed in the context of the KAOS project. KAOS stands for Knowledge Acquisition in autOmated Specification [Vla91b] The driving forces ....

M. Feather, "Constructing Specifications by Combining Parallel Elaborations", IEEE Transactions on Software Engineering, vol. 15 no. 2, February 1989, 198-208.

.... independently of the specification language has already been claimed by several authors [SS83] Gra86] Sin86] Feather and Johnson propose a sizable library of evolution transformations [JF90] to change the meaning of specifications with a derivation model based on parallel development [Fea89]. Their approach deals with how a specification is defined and furthermore some proposed operators concern the specification development. It enhances potential to reuse and maintain specifications by adding, removing or modifying the development and thereafter replaying it. In all cases the ....

M.S. Feather. Constructing specification by combining parallel elaborations. In Transactions on Software Engineering, pages 198--208. I.E.E.E., 1989. 15(2).

No context found.

M. Feather, `Constructing specifications by combining parallel elaborations', IEEE Trans. Software Engineering, 15, (2), 198--208 (1989).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC