Robinson, W.N., "Integrating Multiple Specifications Using Domain Goals", Proc. 1WSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... modeling research has been to abstract programming constructs up to requirements level rather than propagate requirements abstractions down to programming level [My199] Requirements engineering research has increasingly recognized the leading role played by goals in the RE process [Yue87, Rob89, Be91, Dar91, My192, Jar93, Zav97b] Such recognition has led to a whole stream of research on goal modeling, goal specification, and goal based reasoning for multiple purposes, such as requirements elaboration, verification or conflict management, and under multiple forms, from informal to ....

.... Alternative goal refinements allow alternative system proposals to be explored [Lam00c] Managing conflicts among multiple viewpoints is another major RE concern [Nus94] Goals have been recognized to provide the roots for detecting conflicts among requirements and for resolving them eventually [Rob89, Lam98b] Separating stable from more volatile information is another important concern for managing requirements evolution. A requirement represents one particular way of achieving some specific goal; the requirement is therefore more likely to evolve, towards another way of achieving that ....

[Article contains additional citation context not shown here]

Robinson, W.N., "Integrating Multiple Specifications Using Domain Goals", Proc. 1WSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

....a viewpoint analysis strategy for early validation of the requirements elicitation process (so called viewpoint resolution) Work on program transformation [44, 45] provides an additional vehicle for tackling consistency checks and information transfers between different ViewPoints. Robinson [37] proposes an multiple perspectives integration architecture as part of a model of specification design. Meyers and Reiss [29] study inter perspective (cf inter ViewPoint) communication, and propose the development of a single canonical representation for software specification. Finally, Niskier et ....

W.N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. of 5th Int. Work. on Soft. Spec. and Design, Pittsburgh, USA, May 1989, IEEE CS Press, 219-226.

....details back to high level concerns. The higherlevel a goal is, the more stable it is likely to be; goals are thus essential elements for managing requirements evolution [Lam01] Last but not least, goals have been recognized to be the roots at which conflicts can be detected and resolved [Rob89, Boe95, Lam98]. Agents are active system components (or processors ) which may have choice of behavior to ensure the goals they are assigned to [Fea87] Achieving goals in general requires the cooperation of multiple agents. For example, the highlevel goal of safe transportation might require the ....

Robinson, W.N., "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

....of an agent s plan or the fulfilment of a commitment between agents. Viewpoints, facets, and conflicts Beside the formal and qualitative reasoning techniques above, other work on conflict management has emphasized the need for handling conflicts at the goal level. A procedure was suggested in [Rob89] for identifying conflicts at the requirements level and characterizing them as differences at goal level; such differences are resolved (e.g. through negotiation) and then down propagated to the requirements level. In [Boe95] an iterative process model was proposed in which (a) all stakeholders ....

Robinson, W.N., "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

.... stated goals are met by the specification [Yue87] they provide a rationale for requirements a requirement exists because of some underlying goal which provides a base for it [Dar91, Som97] goals represent the roots for detecting conflicts among requirements and for resolving them eventually [Rob89, Lam98b]; goals are generally more stable than the requirements to achieve them [Ant94] In short, requirements implement goals much the same way as programs implement design specifications. Goals are to be achieved by the various agents operating together in the composite system; such agents include ....

W. N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

....a viewpoint analysis strategy for early validation of the requirements elicitation process (so called viewpoint resolution) Work on program transformation [44, 45] provides an additional vehicle for tackling consistency checks and information transfers between different ViewPoints. Robinson [37] proposes an multiple perspectives integration architecture as part of a model of specification design. Meyers and Reiss [29] study inter perspective (cf. inter ViewPoint) communication, and propose the development of a single canonical representation for software specification. Finally, Niskier ....

W.N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. of 5th Int. Work. on Soft. Spec. and Design, Pittsburgh, USA, May 1989, IEEE CS Press, 219-226.

....inconsistencies, merging redundant information, propagating changes, etc. Viewpoint capture has been advocated since the early days of requirements engineering [Ros77] Preliminary proposals for viewpoint oriented acquisition, negotiation, and cooperative modelling appeared only later [Fin89] [Rob89], Pot94] Boe95] Two kinds of approaches have emerged. In a multi paradigm approach, specifications in different viewpoints can be written in different notations. Multi paradigm viewpoints are analyzed in a centralized or distributed way. Centralized viewpoints are translated into some ....

....inconsistencies. As in [Jac95] our specification language is formal; but it is a rich, multi paradigm language for requirements specification. In particular, the explicit modelling and formalization of goals allow conflicts among requirements to be handled at their root, that is, at goal level [Rob89]. Views in our approach are also explicitly linked to their owners. Unlike [Nus93] the specification and assesment process models are kept separate from product level views and defined at a meta level. In our approach, views may also contain formal specifications. 2. Modelling Views in KAOS Our ....

W.N Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

....[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] proposes a multiple perspectives integration architecture as part of a model of specification design. Meyers and Reiss [40] study interperspective (cf. inter ViewPoint) communication, and propose the development of a single canonical representation for software specification. Finally, Niskier et ....

W. Robinson (1989); "Integrating Multiple Specifications Using Domain Goals"; Proceedings of 5th International Workshop on Software Specification and Design (IWSSD-5), Pittsburgh, Pennsylvania, USA, 19-20th May 1989, 219-226; IEEE Computer Society Press.

.... which agents should best perform which actions to fit prescribed constraints (according to their capabilities, reliability, cost, load, motivation, and so forth) Finally, they provide basic information for detecting and resolving conflicts that arise from multiple viewpoints among human agents [Rob89]. The remainder of the paper is organized as follows. Section 2 describes the various abstractions involved in the portion of the meta model relevant to the goal directed acquisition strategy. 5 Requirements fragments from a library system are also provided there to illustrate the use of ....

....Moreover, the system wide goal structure records the history of the acquisition process. This structure is important because: it ties specification components to their rationale (i.e. goal descriptions) it will be used in case negotiation is required to resolve goal conflicts [Rob89]; it can be used to replay some part of the acquisition process in other circumstances where similar portions of the goal structure are recognized. The preliminary identification and characterization of objects from goals ensures that only those 23 objects which are relevant to goals are ....

[Article contains additional citation context not shown here]

W.N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proceedings 5th International Workshop on Software Specification and Design, May 1989, 219-226.

....in the requirements engineering process. Goals drive the identification of requirements to support them; they provide an explanation to clients of the rationale underpinning requirements; they represent the roots for detecting conflicts among requirements and for resolving them eventually [Rob89] they provide a completeness criterion for the requirements specification the specification is complete if all stated goals are met by the specification; they generally represent the most stable information in the requirements product. To sum up, requirements implement goals much the same ....

....functional goals concerned with keeping agents informed about object states; accuracy goals are non functional goals concerned with maintaining the consistency between objects in the environment and their software image. Useful attributes for a goal may include its priority [Dar93] and utility [Rob89] Information about goal types and attributes can be used to define heuristics for goal acquisition, goal refinement, and requirements elaboration. Links between goals are aimed at capturing situations where goals positively or negatively support other goals. Directly borrowed from problem ....

[Article contains additional citation context not shown here]

Robinson, W.N., "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

....software lifecycle; and so on. On the downside, scenarios are inherently partial; they raise a coverage problem similar to test cases, making it impossible to verify the absence of errors such as, e.g. incompleteness with respect to stated goals [73, 13] or conflicts among goals requirements [62, 45]. Instance level trace descriptions also raise the combinatorial explosion problem inherent to the enumeration of combinations of individual behaviors. Scenarios in the form of interaction sequences are also procedural, thus introducing risks of overspecification such as, e.g. too strict ....

W. N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

.... specification the specification is complete if all stated goals are met by the specification [30] goals provide an explanation to clients of the rationale underpinning requirements; they represent the roots for detecting conflicts among requirements and for resolving them eventually [26]; they generally represent the most stable information in the requirements product. In short, requirements implement goals much the same way as programs implement design specifications. Goals are to be achieved by the various agents operating altogether in the composite system; such agents ....

W. N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-225.

....Recent attempts have been made to design languages and methods that support a much wider range of requirements. Within such frameworks why, who, and when questions can be addressed in addition to the usual what questions. It then becomes possible to reason formally about goal satisfaction [Rob89], Dar91] Myl92] Dar93] Fea93] agent responsibilities [Fea87] Fin87] Dar91] Fic92] Dar93] Ken93] Dub93] or triggering events and causalities [Fin87] Dar93] to support the requirements acquisition and evaluation process. The purpose of this paper is to assess the current ....

W.N. Robinson, "Integrating Multiple Specifications Using Domain Goals", Proc. IWSSD-5 - 5th Intl. Workshop on Software Specification and Design, IEEE, 1989, 219-226.

....development participant , that is as an active, autonomous and loosely coupled agent in the distributed artificial intelligence style. This has raised the possibility of interpreting ViewPoints as active agents. Other influences on the approach we have adopted are those of selfish views [Robinson 1989] and contexts in ERAE [Finkelstein Hagelstein 1989] The concept of a separate, explicit structural (configuration) description for the software architecture of a system has been fully investigated in the Conic environment for developing distributed systems [Kramer et al. 89a, Magee et al. 89, ....

Robinson W. (1989); "Integrating Multiple Specifications Using Domain Goals"; Proc 5th International Workshop on Software Specification & Design; pp 219-226, IEEE CS Press.

.... 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 requirements negotiation[220] Program slicing[106] Goal regression for requirements [215] 266] Schema integration[ 11] Inconsistency dialog[76] Inconsistency reasoning[189] Inconsistency framework[40] Multi agent planning[85] Agent negotiation[238] A Historical Perspective of Requirements Interaction Management 13 ....

....interfering preconditions when their simultaneous achievement is sought. Similarly, two requirements may conflict because they mutually deplete the available resources of an operational system. Many of such planning terms have also been applied to characterize interactions among requirements[202][220][228] A simple ontology of supports detracts (i.e. that simply summarizes the details on how requirements interact, has been found to be a practical solution[19] 35] 42] 207] 279] 225] Such work has been extended to incorporate fuzzy logic concerning the degree of conflict[282] More ....

Robinson,W.N., Integrating Multiple Specifications Using Domain Goals, 5th International Workshop on Software Specification and Design, (1989) 219-226

....document[72] and (3) the publication of prior analyses of the case[50] 71] Hence, one can compare CORA with other analyses to determine: 1) if CORA would have also aided other analyses, and (2) if CORA provides new analyses. Finally, because CORA was developed while analyzing the library[56][58] 59] and electronic applet commerce domains[63] the meeting scheduler analysis provided an opportunity to apply CORA in a new domain. The general problem of the meeting scheduler can be summarized by the introduction to the requirements[72] The purpose of a meeting scheduler is to support ....

Robinson, W.N., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

....new deals by tailoring them for organizational acceptance. Interaction Analysis. Ideally, a broker should analyze a client s preference specification (contract proposal) and provide analysis of (1) interactions among preferences, and (2) how the preferences relate to the available alternatives[28][31] Such analysis can occur prior, during, or after contract negotiations. The Disney case ( 3) illustrates the first case: quantity and price and step wise negatively correlated. As an example of the second case, consider a client who provides a preference specification for a software applet ....

Robinson, W.N., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

No context found.

Robinson, W.N., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

.... and Notifier are all reusable service agents developed through a Knowledge Based Programming project in our group for constructing networked applications [6] the Conflict Detector, Design Assistant, and Conflict Resolver were developed specifically for this project, and are described in [13], 14] and [15] The system pictured in figure 1 works as follows: 1)The Requirements Writer gives the Assigner a set of problem requirements. To date, we have used requirements of two of the canonical problems established at the Fourth International Workshop on Software Specification and Design ....

Robinson, W., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

....Hence, we can compare our analysis with those of others to determine: 1) if the restructuring meta model would have aided their analyses, and (2) if the restructuring meta model provides new analyses. Finally, because our restructuring meta model was developed while analyzing the library[42][44] 45] and electronic applet commerce domains[47] we wanted to analyze the meta model in a new domain that of distributed meeting scheduling. The general problem of the meeting scheduler can be summarized by the introduction to the requirements[55] Restructuring Application Fig 1. The ....

Robinson, W.N., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

....Root requirements are the top nodes in a classification hierarchy in which the original requirements form the leaves, and intermediate nodes are derived from generalizing nodes one level lower in the hierarchy. As such, root requirements are most similar to the concept of requirements domain goals[32]. The concept of requirements goals has since been refined[2] 8] 40] However, here we introduce the concept of inducing such goals, or root requirements, from documents where they are not apparent, nor structured. Once requirements are represented as attributed objects, a classification hierarchy ....

Robinson, W.N., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

No context found.

Robinson, W., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226

No context found.

Robinson, W. N., 1989, "Integrating Multiple Specifications Using Domain Goals", Proceedings, Fifth IEEE International Workshop on Software Specification and Design, Pittsburg, Penn.

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