Gunter, C. A., Gunter, E. L., Jackson, M., and Zave, P. (2000). A reference model for requirements and specifications. IEEE Software, pages 37--43.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....Engineering s theoretical and practical developments typically look forward to the future (i.e. a system to be built) Under certain conditions, however, they can also be used for the analysis of problems related to actual systems in operation. Building on the Jackson Zave reference model [2] for requirements and specifications, this paper presents a framework useful for the prevention, analysis and communication of designer and operator errors and, importantly, their subtle interactions, so typical in complex socio technical systems. 1. Introduction There are three system ....

....but not on all three at the same time. However, it is well known that accidents combine all three [1, 5] In this paper we propose an analytical framework for socio technical systems. The framework is based upon a dynamic view of the reference model (RM) for requirements and specifications [2]. The formal approach of the RM, complemented with the semiformal approach of Jackson s Problem Frames [3] provides a clear distinction between descriptions of the world (or environment of the system) W , the requirements R and the specifications S of a solution machine. This specification S ....

C. A. Gunter, E. L. Gunter, M. Jackson, and P. Zave. A reference model for requirements and specifications. IEEE Software, 17(3):37--43, 2000.

.... this purpose, we have investigated the 3 understanding of ambiguity in linguistics, e.g. in reference [20] and in natural language processing, e.g. in reference [2] Our understanding of the RE context is inspired by the WRSPM (World, Requirements, Specifications, Program, and Machine) model [12] and by the Four World model [16] which structure the RE context: The RE context that must be considered when interpreting a requirement consists of the # requirements document of which the considered requirement is part; # application domain, e.g. organizational environment and behaviors of ....

Gunter, C.A., Gunter, E.L., Jackson, M., and Zave, P., "A Reference Model for Requirements and Specifications," IEEE Software 17(3), pp. 37--43 (May/June 2000).

....reuse process: Domain Modeling, Domain Design and Implementation, and Product Line Development [16] In Figure 3 below, we illustrate the interrelations between these three phases. SEKE JDH.doc submitted to World Scientific: 9 30 00 : 9:35 AM 7 22 We use the formalism introduced by Gunter et al. [17] in their reference model for requirements engineering to label the arrows. The primary information elements manipulated are in the Domain Knowledge W , which encompasses known facts about the domain environment or outside World. The domain modeling activity is constrained by the chosen scope ....

....it follows that S R Wd, and that S M P, where W R = abstract problem model, S M = concrete problem model, G = generic solution model, and P = concrete solution model. A complete analysis of these equations is beyond the scope of our current discussions. Interested readers should look at [17]. Domain Modeling Domain knowledge W Requirements R Domain models Wd R Product Development 3 Products P Target platform M Product Line Design and Implementation 2 Domain libraries G Specification S Scope d Solution Configuration models G Figure 3: The ....

Gunter, C. A., Gunter, E. L., Jackson, M. and P. Zave. A Reference Model for Requirements and Specifications. (IEEE Software, May/June 2000) pp 37-43.

.... For this purpose, we have investigated the understanding of ambiguity in linguistics, e.g. in reference [20] and in natural language processing, e.g. in reference [2] Our understanding of the RE context is inspired by the WRSPM (World, Requirements, Specifications, Program, and Machine) model [12] and by the Four World model [16] which structure the RE context: The RE context that must be considered when interpreting a requirement consists of the # requirements document of which the considered requirement is part; # application domain, e.g. organizational environment and behaviors of ....

Gunter, C.A., Gunter, E.L., Jackson, M., and Zave, P., "A Reference Model for Requirements and Specifications," IEEE Software 17(3), pp. 37--43 (May/June 2000).

....a system that satisfies a given set of requirements. An illustrative case study can be found in [7] In the case of verification, we must also have a formal model of the system, which is called a system specification. A more detailed discussion about requirements and specifications is presented in [21]. Given a specification and a set of requirements, the problem of determining whether the specification satisfies the requirements is called the verification problem. Typically, a specification contains description of the system state and description of the rules that the system uses for moving ....

....it in pseudocode. The main goal of this phase is to achieve a good trade off between clarity and readability of a protocol description. We use a special purpose pseudolanguage called POPSCL 4 (Protocol Object PSeudo Code Language) We 3 A more complete study of all the artifacts is presented in [21]. 4 Pronounced as popsicle . 18 designed this language as an extension of the specification style used by Carolyn Talcott and J.J. Garcia Luna Aceves. POPSCL code is divided into six sections: Constants section lists some fixed or locally configured constants that the routing process uses. ....

Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave. A reference model for requirements and specifications. IEEE Software, May/June 2000.

....information on how the system should be developed, for example which development process should be applied or when the system should be available. Existing approaches to the definition of the notion requirement specification either focus on the content of a document containing requirements ([9, 12, 3]) or on certain properties such a document should satisfy ( 11, 6, 4] We regard both aspects as important. Nevertheless, due to space limitations we concentrate here only on the content. In Section 2.2 we will recapitulate the main aspects of the reference model for requirements and ....

....should satisfy ( 11, 6, 4] We regard both aspects as important. Nevertheless, due to space limitations we concentrate here only on the content. In Section 2. 2 we will recapitulate the main aspects of the reference model for requirements and specifications proposed by Jackson, Zave, et al. [12, 3]) Based on this reference model we define our reference model for problem specifications in Section 2.3. 2.1. Basic Notions A system is a part of the real world that is for some reason considered as a unit. In a system several phenomena are collected and combined. A phenomenon is an aspect in ....

[Article contains additional citation context not shown here]

C. A. Gunter, E. L. Gunter, M. Jackson, and P. Zave. A reference model for requirements and specifications. http://www.cis.upenn.edu/gunter/hol/papers/ refmod.ps, 1998.

No context found.

C.A. Gunter, E.L. Gunter, M. Jackson, P. Zave "A reference model for requirements and specifications", IEEE Software, 17(3):37-43, 2000.

....them and putting the data in these packets together. Network event recognition entails this hierarchical process of recognizing protocol events at di#erent layers. The NER framework can be visualized as in Figure 1. The figure is annotated with terms from the WRSPM software artifact model [GGJZ00] The World W is the operational environment, which includes endpoint activities that spawn network events. The Requirements R are properties expected of the system, such as the requirement that a routing protocol finds paths to destinations. The Specification S denotes the software ....

Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave. A reference model for requirements and specifications. IEEE Software, 17(3):37--43, May 2000.

....for capturing and maintaining complex relationships between different artifacts of requirements and architecture; it has currently been used only in a very particular context. Finally, the industrial strength method REVEAL [11] based on a clear separation between the world and the machine [10], provides a practical approach to developing systems in the manner that we proposed in this paper. REVEAL, however, assumes a more traditional development process that is less fine grained than that suggested by our Twin Peaks model, and therefore potentially less amenable to iterative ....

C.A. Gunter, E.L. Gunter, M. Jackson, P. Zave "A reference model for requirements and specifications", IEEE Software, 17(3):37-43, 2000.

....the objective of a component of the model should be, even without formalization, let al..one machine assisted proof. However, our description is precise enough to support quite formal analyses. For examples of such formal analyses, and a more in depth discussion of some of the logic connections, see [6]. On the whole we think it makes a useful contribution to understanding software artifacts and methodologies at a quite general level without surrendering mathematical precision. Acknowledgements We would like to express thanks to Rajeev Alur, Karthik Bhargavan, Trevor Jim, Insup Lee, and Davor ....

Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave. A reference model for requirements and specifications. Technical report, University of Pennsylvania, January 2000.

....Village Telephone System as a Benchmark for Formal Specification Working Draft Carl A. Gunter University of Pennsylvania July 23, 1999 1 Introduction The Village Telephone System (VTS) case study was introduced in [1] and its correctness conditions were further studied in [2]. The aim of this paper is to specify a variant of the conditions used in [1] in order to pose VTS as a benchmark case study that can be used to study various formal approaches to specification and verification. The VTS specification will be given first in English. This description is imprecise ....

....0 ) t = t 0 This seems reasonable although it forces on the environment an assumption that hook events happen one at at a time. What is worrying about this is the how it relates to an intended distinction between system and environment. The key problem here, explored at length in [1, 2], is the fact that nothing in Sections 2 or 3 above says what would constitute a fair refinement of the original conditions. For instance, 5 a refinement could assert that no more than two phones could be off hook at any time. This is an odd refinement since it seems to be programming the ....

[Article contains additional citation context not shown here]

Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave. A reference model for requirements and specifications. www.cis.upenn.edu/~hol/papers/vts.ps, 1998.

No context found.

Gunter, C. A., Gunter, E. L., Jackson, M., and Zave, P. (2000). A reference model for requirements and specifications. IEEE Software, pages 37--43.

No context found.

Gunter CA, Gunter EL, Jackson MA, Zave P. A reference model for requirements and specifications. IEEE Software 2000; 17(3):37--43

No context found.

Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave. A reference model for requirements and specifications. IEEE Software, pages 37--43, May/June 2000.

No context found.

C. Gunter, A., E. Gunter, L., M. Jackson, and P. Zave. A reference model for requirements and specification. IEEE Software, 17(3):37--43, May/June 2000.

No context found.

C.A. Gunter, E.L. Gunter, M. Jackson, P. Zave, "A Reference Model for Requirements and Specifications", IEEE Software, vol. 17, n. 3, May-June 2000.

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