M. Jackson, P. Zave, Domain descriptions, in: Proceedings of the First IEEE International Symposium on Requirements Engineering (RE93), IEEE Computer Society Press, 1993, pp. 56--64.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....at that floor. The statement can be interpreted either as an environmental property describing a mechanical lock that prevents the doors from opening or as a requirement that must be implemented by the software developer. That is, the statement can be interpreted as either indicative or optative [14, 15]. We classify this mood ambiguity as a developmentdomain ambiguity, because it is unambiguous relative to the application and system domain. However, it remaims open as to whether the statement is a requirement to be implemented in the software or the statement can be assumed as already provided ....

Jackson, M. and Zave, P., "Domain Descriptions," pp. 56--64 in Proceedings of the International Symposium on Requirements Engineering, IEEE Computer Society (1993).

....at that floor. The statement can be interpreted either as an environmental property describing a mechanical lock that prevents the doors from opening or as a requirement that must be implemented by the software developer. That is, the statement can be interpreted as either indicative or optative [14, 15]. We classify this mood ambiguity as a developmentdomain ambiguity, because it is unambiguous relative to the application and system domain. However, it remaims open as to whether the statement is a requirement to be implemented in the software or the statement can be assumed as already provided ....

Jackson, M. and Zave, P., "Domain Descriptions," pp. 56--64 in Proceedings of the International Symposium on Requirements Engineering, IEEE Computer Society (1993).

....cases, the procedure should at least report that the input is illegal. Indicative and Optative Moods The question to ask is, when are universally quantified statements dangerous and when are they not We believe that notions offered by Michael Jackson and Pamela Zave provide the distinction [3, 4]. Jackson and Zave talk about descriptions of domains, or real worlds and requirements, or problems. The domain is the subject matter of the system s computations, and provides the context in which those computations have useful meaning or effect. 3] They consider a domain as a topic for ....

....and Pamela Zave provide the distinction [3, 4] Jackson and Zave talk about descriptions of domains, or real worlds and requirements, or problems. The domain is the subject matter of the system s computations, and provides the context in which those computations have useful meaning or effect. [3] They consider a domain as a topic for description in its own right, independently of any description that we may eventually make of the system to be constructed. Jackson and Zave divide sentences in a specification into two classes, those that describe the domain and those that describe ....

Jackson, M. and Zave, P., "Domain Descriptions," pp. 56--64 in Proceedings of the International Symposium on Requirements Engineering, IEEE Computer Society, 1993.

....the form of code, documentation, and orally communicated (or uncommunicated) assumptions. It is helpful to use a reference model for these artifacts as a foundation for classi cation and analysis. We have proposed a general model called WRSPM in [13] as an extension of work of Jackson and Zave [17, 18, 30] and applied it in a case study [3] We use it again in this paper as a strategy for characterizing the issues in fault origin adjudication. Software projects do not always generate all of the artifacts in the reference model, and it is uncommon for any of them to be described with mathematical ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56-64. IEEE Computer Society Press, 1992.

....For example, a railway signalling system in the UK will have different characteristics from one in France due to the railway systems different funding and operating procedures. Domain expertise may be difficult to acquire. Crucial constraints may be implicit in the domain as domain phenomena [Jackson 93] However, if their significance is opaque to the requirements engineer and if no stakeholder articulates them (perhaps because they assume that they are obvious) they can easily be overlooked. For example, a requirement for error correction may be overlooked if no one explicitly identifies the ....

Jackson, M., Zave, P. 1993. Domain Descriptions, Proc. IEEE International Symposium on Requirements Engineering (RE93), San Diego, Ca., USA. 56-64.

....which employs proof, using a suite of tools, to verify specifications and implementations in both functional and procedural languages against RSL specifications. 3. 4 Multi Paradigmed Approaches Perhaps the most ambitious approach to hybrid formal methods is that adopted by Jackson Zave in [JZ92, ZJ93] Their approach is based on the viewpoint philosophy of Finkelstein et al. [FGKN89, FKN 92] which describes a framework for combining different perspectives 6 In fact, the semantics of CSP is given by Hoare as sets of allowable traces (sequences of actions) However, this is clearly ....

M. Jackson and P. Zave. Domain descriptions. In International Symposium on Requirements Engineering, pages 56--64. IEEE Comp soc. Press, 1992. 24

....of method have been combined in a unifying mathematical framework [Mil90] allowing the specifier full access to the complete expressive powers of each component class in conjunction with each other. A particularly ambitious approach to hybrid formal methods is that adopted by Jackson Zave in [JZ92, ZJ93] Their approach is based on the viewpoint philosophy of Finkelstein et al. [FKN 92] which describes a framework for combining different perspectives of a system in the development of software, and the approach outlined by Wing [Win90] for composing specifications written with ....

M. Jackson and P. Zave. Domain descriptions. In International Symposium on Requirements Engineering, pages 56--64. IEEE Comp soc. Press, 1992.

....to automated analysis [71] On the other hand, soft methods provide rich representations [63] that non technical stakeholders find appealing, but are often difficult to check automatically. 5.4 Domain Modelling. A significant proportion of the RE process is about developing domain descriptions [40]. A model of the domain provides an abstract description of the world in which an envisioned system will operate. Building explicit domain models provides two key advantages: they permit detailed reasoning about (and therefore validation of) what is assumed about the domain, and they provide ....

Jackson, M. & Zave, P. (1993). Domain Descriptions. 1st International Symposium on Requirements Engineering (RE'93),San Diego, USA, 4-6 January 1993, pp. 56-64.

....the form of code, documentation, and orally communicated (or uncommunicated) assumptions. It is helpful to use a reference model for these artifacts as a foundation for classification and analysis. We have proposed a general model called WRSPM in [9] as an extension of work of Jackson and Zave [13, 14, 24] and applied it in a case study [3] We use it again in this paper as a strategy for characterizing the issues in fault origin adjudication. Software projects do not always generate all of the artifacts in the reference model, and it is uncommon for any of them to be described with mathematical ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56--64. IEEE Computer Society Press, 1992.

....specification languages has become an area of considerable interest. The integration of methods, notations and tools has generally been addressed by the use of a common data model, usually supported by a common, centralised database (Alderson, 1991; Wasserman Pircher, 1987) Recent work by Jackson Zave (1993) proposes the composition of partial specifications as a conjunction of their assertions in a form of classical logic. A set of partial specifications is then consistent if and only if the conjunction of their assertions is satisfiable. Other authors have also considered multi perspective or ....

Jackson, M., & Zave, P. (1993). Domain Descriptions. In IEEE International Symposium on Requirements Engineering, San Diego, 4-6 January 1993 (pp. 56-64). IEEE Computer Society Press.

....A domain property is a property about objects or operations in the environment which holds independently of the software to be. Domain properties include physical laws [Par95] regulations, constraints imposed by environmental agents [Lev95] in short, indicative statements of domain knowledge [Jac93, Zav97b]. In KAOS, domain properties are captured by domain invariants attached to objects and by domain pre postconditions attached to operations. A scenario is a domain consistent sequence of state transitions controlled by corresponding agent instances; domainconsistency means that the operation ....

M. Jackson and P. Zave, "Domain Descriptions", Proc. RE'93 - 1st Intl. IEEE Symp. on Requirements Engineering, Jan. 1993, 56-64.

....to be extracted. For instance, the ORDIT method [16] gives limited heuristics that advise checking agent role allocations, but these fall far short of the comprehensive guidance we have proposed. Dependencies between systems and their environment have been analysed in detail by Jackson and Zave [28] who point out that input events impose obligations on a required system. They propose a formalism for modelling such dependencies. Formal modelling is applicable to the class of systems they implicitly analyse, e.g. real time and safety critical 31 applications, but it is less clear how such ....

M. Jackson and P. Zave, `Domain descriptions', in IEEE Symposium on Requirements Engineering, IEEE Computer Society Press, pp. 56-64, 1993.

....to as soft goals) However the i enterprise modelling method does not give advice about creating enterprise models, nor does it contain detailed event dependency analysis such as we have reported. Dependencies between systems and their environment have been analysed in detail by Jackson and Zave [28] who point out that input events impose obligations on a required system. They propose a formalism for modelling such dependencies. Formal modelling is applicable to the class of system they implicitly analyse, e.g. real time and safety critical applications, but it is less clear how such models ....

Jackson M, Zave P. Domain descriptions. In: IEEE Symposium on Requirements Engineering. IEEE Computer Society Press, 1993, 56-64.

....of interval v. 2.2. The vocabulary of the specification The vocabulary of the specification is a set of predicates formalizing real world phenomena that are observable to users of the switching system. The specification does nothing more than make formal assertions about these predicates [Jackson Zave 93] Since these predicates are the bridge between the informal real world and our formal specification, they cannot themselves be defined formally. But this does not excuse us from providing the best informal definitions possible. If we do not explain them, we cannot expect anyone to know what we ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56-64. IEEE Computer Society Press, ISBN 0-8186-3120-1, 1993.

....only (it is typical that most published specifications in the telecommunications domain cover no more than POTS) We are interested in finding methods that work for systems of realistic complexity, such as the one we have specified. We tried out some new ideas for multiparadigm specification [Jackson Zave 93, Zave Jackson 93a, Zave Jackson 93b] We also explored the suitability of Z [Spivey 92] an already well known specification language, for specification of realistic switching systems. It is important to develop conceptual models of telecommunications services. These abstractions avoid ....

....was an obvious addition to the portion of the system being specified in Z. Part III of this series contains the complete Z specification of connections and provisioning. Recent research has yielded a method for composing partial specifications written in a wide variety of different languages [Jackson Zave 93, Zave Jackson 93a] the method is based on using first order predicate logic (only when needed) as a common semantics. Based on this general framework, there is a specific technique [Zave Jackson 93b] applicable to switching systems because it was in fact developed for the purpose of ....

[Article contains additional citation context not shown here]

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56-64. IEEE Computer Society Press, ISBN 0-8186-3120-1, 1993.

....Summary Formulas 1, 2, and 3 are our principle proof obligations. They can be proved by defining a specification S and showing 2, 4, 7 (on the environment side) and 8 (on the system side) 5 Related Work The reference model is a more formal and more complete version of some of our earlier work [7, 8, 14]. Let us look in some detail at some of the most well known formulations of something like the WRSPM artifacts and their relationships. There are many similarities between our reference model and the Functional Documentation model of Madey, Parnas, and van Schouwen [13, 12] Finding a precise ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56--64. IEEE Computer Society Press, 1992.

....only the descriptions of new features need be changed, and all the old features can remain untouched. Formal Methods for DFC 15 1. 4 Formal Methods for Feature Oriented Descriptions A recent reference model of the proof obligations for formal methods of software development ( 13] based on [16,18,29]) proposes three proof obligations. The first proof obligation, loosely paraphrased, says that the domain knowledge must be consistent or satisfiable. This is in no way dependent on how the system is described, so there is nothing special to say about it in the context of feature oriented system ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56-64. IEEE Computer Society Press, ISBN 0-8186-3120-1, 1992.

No context found.

Michael Jackson and Pamela Zave, "Domain Descriptions", Proc. IEEE International Conference on Requirements Engineering, IEEE Computer Society Press, pp. 56--64, 1993.

....Summary Formulas 1, 2, and 3 are our principle proof obligations. They can be proved by defining a specification S and showing 2, 4, 7 (on the environment side) and 8 (on the system side) 5 Related Work The reference model is a more formal and more complete version of some of our earlier work [9, 10, 19]. Before looking at applications using the approach described here, we pause to look in some detail at some of the most well known formulations of something like the WRSPM artifacts and their relationships. There are many similarities between our reference model and the Functional Documentation ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56--64. IEEE Computer Society Press, 1992.

....of modelling and tool integration on an illustrative problem we call the Village Telephone System (VTS) The VTS provides an accessible but non trivial application similar to many others in the telecommunications and networking domains. We analyze it using a methodology we have developed in [5 7, 4] with formal support provided by the HOL90 general purpose theorem prover and the Mocha model checker. First we provide a brief overview of the methodology, referring the reader to the cited work for more details. The main body of the paper is devoted to the treatment of the VTS using this ....

Michael Jackson and Pamela Zave. Domain descriptions. In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 56--64. IEEE Computer Society Press, 1992.

No context found.

M. Jackson, P. Zave, Domain descriptions, in: Proceedings of the First IEEE International Symposium on Requirements Engineering (RE93), IEEE Computer Society Press, 1993, pp. 56--64.

No context found.

M. Jackson and P. Zave, "Domain Descriptions", Proc. of 1st Int. Symposium on Requirements Engineering (RE'93), 56-64, San Diego, USA, IEEE CS Press, 4-6 January 1993. -9-

No context found.

M. Jackson and P. Zave, "Domain Descriptions," Proc. IEEE Int'l Symp. Requirements Eng., IEEE Computer

No context found.

M. Jackson and P. Zave, "Domain Descriptions", Proc. RE'93 - 1st Intl. IEEE Symp. on Requirements Engineering, Jan. 1993, 56-64.

No context found.

: Jackson M., Zave P., `Domain descriptions', IEEE symposium on requirements Engineering, IEEE Computer Society press, 56-64, 1993

First 50 documents

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