A Multiple Viewed Approach To Software Requirements
A Dissertation Presented to the Faculty of the School of Engineering and Applied Science (Unofficial copy)
University of Virginia In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy ( Computer Science )
by
Harry S. Delugach
May 1991
ABSTRACT
A problem in current requirements development techniques is that the viewpoints (including implicit pre-existing assumptions) of multiple participants must be satisfied by the resulting requirements. Choosing a single language for all participants requires the additional burden of learning the new language and being prepared to overlook some requirements for which the language was not intended. This dissertation proposes a framework and methodology whereby multiple requirements specifications can be produced in several languages of the participants’ own choosing, then translated into a meta-language (that is, a language capable of capturing features of several different requirements languages) in order to analyze their common features. The meta-language of conceptual graphs is used to capture requirements expressed in various conventional requirements development notations. Once translated into conceptual graphs, the set of requirements is analyzed in order to find the most likely counterpart concepts between the partcipants’ requirements specifications. These counterparts represent the overlap between views and form the basis for joining the multiple graphs into one requirements graph. Ambiguous counterparts (i.e., concepts that cannot be distinguished from other concepts) are also identified, guiding the requirements analyst in asking participants further questions about the assumptions that underlie the concepts. i
A Multiple-Viewed Approach To Software Requirements
Harry S. Delugach Department of Computer Science Computer Science Building Rm 109 University of Alabama in Huntsville Huntsville, AL 35899 U. S. A. Telephone: (205) 895-6614 Electronic mail: [email protected]
Table of Contents
Table of Contents ...... i List of Figures...... iv Abbreviations and Symbols ...... v 1. Introduction...... 1 1.1. Problems With Software Requirements...... 1 1.2. Context of Work...... 2 1.3. Multiple Views...... 3 1.4. Improving Requirements Development ...... 4 1.5. Outline Of Dissertation...... 5 2. Views In Software Requirements Development...... 6 2.1. Views in Requirements...... 6 2.1.1. Purpose Of Using Views...... 7 2.1.2. Basics Of A View...... 7 2.1.3. A Participant’s View ...... 9 2.2. Example Requirements and Assumptions ...... 12 2.3. Support For A Single View...... 14 2.4. Multiple Viewed Requirements ...... 15 2.4.1. Interaction Between Views...... 15 2.4.2. Support For Multiple Viewed Requirements ...... 16 2.5. The Multiple Viewed Approach...... 18 2.6. Summary ...... 18 3. Analyzing Multiple-Viewed Requirements...... 20 3.1. Role Of the Requirements Analyst ...... 21 3.2. Analyzing Overlap Between Views...... 23 3.2.1. Identifying Overlap Between Views ...... 25 3.2.2. Kinds Of Associations ...... 26 3.2.3. Association Graph Technique...... 28 3.3. General Issues For Multiple Views...... 35 3.4. Summary ...... 37 4. A Framework and Methodology For Multiple-Viewed Analysis ...... 38 4.1. Conceptual Graphs: An Analyst’s Meta-Language ...... 38 4.2. Definition Of A View...... 40 4.2.1. Domains ...... 40 4.2.2. Requirements Specification ...... 42 4.2.3. Requirements Specification Graph ...... 42 ii
4.2.4. Translation Scheme...... 42 4.2.5. Assumption Graphs...... 43 4.2.6. View ...... 43 4.3. Analyst’s Framework ...... 44 4.3.1. Analyst’s Canon...... 44 4.3.2. Analyst’s Requirements Specification Graph...... 44 4.4. Analysis of Multiple Viewed Requirements ...... 44 4.4.1. Describing Overlap ...... 45 4.4.2. Analyzing Overlap...... 47 4.5. A Methodology For Multiple Viewed Requirements...... 49 4.5.1. Methodology Steps ...... 50 4.5.2. Products of Analysis...... 56 4.5.3. Analyst’s View...... 56 4.6. General Features Of Approach ...... 57 4.7. Summary ...... 58 5. Translating Requirements Into Conceptual Graphs...... 59 5.1. Entity-Relationship Diagrams ...... 60 5.1.1. Example Entity-Relationship Diagram...... 60 5.1.2. Discussion...... 61 5.2. Data Flow Diagrams...... 61 5.2.1. Example Data Flow Diagram ...... 62 5.2.2. Discussion...... 63 5.3. State Transition Diagrams ...... 63 5.3.1. Example State Transition Diagram...... 63 5.3.2. Discussion...... 64 5.4. Requirements Networks (SREM)...... 65 5.4.1. Example Requirements Network...... 65 5.4.2. Discussion...... 66 5.5. Summary ...... 67 6. A Multiple Viewed Analysis Example...... 68 6.1. Analysis: First Association ...... 69 6.2. Analysis: Second Association...... 71 6.3. Analysis: Third Association...... 75 6.4. Results of Analysis ...... 77 6.5. Summary ...... 78 7. Validating Multiple Viewed Analysis...... 79 7.1. Overlap Characteristics...... 80 7.2. Cost Considerations Of Multiple Views ...... 81 7.2.1. A Requirements Error Cost Model ...... 81 7.2.2. Measuring Actual Projects...... 84 7.3. Reasonableness of Overlap...... 84 7.4. Summary ...... 85 8. Preliminary Validation Of Patient-Monitoring...... 87 8.1. Derived Overlap Characteristics ...... 87 8.1.1. Counterparts in Patient-Monitoring ...... 87 8.1.2. Assumptions Underlying Views in Patient-Monitoring...... 87 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring...... 88 8.1.4. Incompleteness in Single Views of Patient-Monitoring ...... 88 8.2. Reasonableness of Overlap...... 88 8.2.1. Empirically Determined Overlap ...... 88 8.2.2. Comparing Relative Importance in Overlap ...... 90 8.3. Summary ...... 90 9. Results of Multiple-Viewed Requirements Development...... 91 9.1. Major Findings...... 91 iii
9.2. Tractability...... 92 9.3. Duties Of The Requirements Analyst...... 92 9.4. Limitations of the Approach ...... 93 9.5. Summary ...... 94 10. Conclusion...... 95 10.1. Summary of Thesis ...... 95 10.2. Future Research...... 96 10.2.1. Exploring Overlap ...... 97 10.2.2. Expanding View Coverage ...... 97 10.2.3. Practical Support ...... 97 10.2.4. Enhancements To Framework ...... 97 10.3. Speculation...... 98 10.4. Concluding Remarks...... 99 Appendix A: Conceptual Graphs...... 100 A.1. Conceptual Graph Notation ...... 100 A.1.1. Nodes and Links...... 100 A.1.2. Type Hierarchy ...... 103 A.1.3. Contractions ...... 104 A.1.4. Canonical Graphs ...... 105 A.1.5. Canonical Transformation Rules...... 105 A.1.6. Projection...... 106 A.1.7. Generalization...... 106 A.1.8. Lambda Abstraction...... 107 A.1.9. Context...... 107 A.1.10. Line of Identity ...... 108 A.1.11. Equivalent Representations...... 110 A.2. Conceptual Graphs and Logic ...... 111 A.2.1. First-Order Logic with Quantification...... 111 A.2.2. Functions ...... 113 A.3. Conceptual Graph Extensions...... 113 A.3.1. Private Referent...... 113 A.3.2. Demons ...... 114 Appendix B. Translation Schemes...... 117 B.1. Entity-Relationship Translation Scheme...... 117 B.2. Data Flow Translation Scheme...... 121 B.3. State Transition Translation Scheme...... 123 B.4. Requirements Network Translation Scheme...... 126 B.5. Summary ...... 128 References...... 129 iv
List of Figures
Figure 2.1. Simple Requirements Validation Cycle...... 9 Figure 2.2. Actual Requirements Validation Process...... 11 Figure 2.3. Customer’s Example Requirements...... 13 Figure 2.4. Designer’s Example Requirements...... 13 Figure 2.5. A Multiple-Viewed Requirements Validation Cycle...... 15 Figure 3.1. Multiple-Viewed Framework...... 21 Figure 3.2. Multiple Viewed Requirements Process...... 23 Figure 3.3. Regions Of Overlap Between Views...... 24 Figure 3.4. Kinds Of Counterparts...... 27 Figure 3.5. Association Graph. 29 Figure 3.6. Association Graph Nodes After One Iteration...... 30 Figure 3.7. Sample Graphs. 33 Figure 3.8. Association Arcs For Sample Graph...... 33 Figure 3.9. Association Weights For Sample Graph...... 34 Figure 3.10. Association Graph After Choosing A Seed Counterpart...... 35 Figure 4.1. Multiple-Viewed Methodology Using Conceptual Graphs...... 50 Figure 5.1. Original Entity-Relation Diagram...... 60 Figure 5.2. Conceptual Graph From Entity-Relation Diagram...... 61 Figure 5.3. Original Data Flow Diagram...... 62 Figure 5.4. Conceptual Graph From Data Flow Diagram...... 62 Figure 5.5. Original State Transition Diagram...... 63 Figure 5.6. Conceptual Graph From State Transition Diagram...... 64 Figure 5.7. Original Requirements Network Diagram...... 65 Figure 5.8. Conceptual Graph From A Requirements Network...... 66 Figure 6.1. Assumptions For Patient-Monitoring...... 73 Figure 7.1. Errors In the Software Development Lifecycle...... 82 Figure 8.1. Manually Derived Overlap Characteristics...... 89 Figure A.1. Example Graph Containing Actors...... 103 Figure A.2. A Type Hierarchy. 104 Figure A.3. A Line Of Identity Between Different Contexts...... 109 Figure A.4. Two Graphs Connected By A Line Of Identity...... 109 Figure A.5. Line Of Identity Removed Via Join...... 109 Figure A.6. Equivalent Forms of Conceptual Graphs...... 111 Figure A.7. Logic Formula As A Conceptual Graph...... 112 Figure A.8. Representing A Private Referent...... 113 Figure A.9. A Referent External to Conceptual Graphs...... 114 Figure A.10. Example Graph Containing Demons...... 115 Figure A.11. Changing Conceptual Graphs Over Time...... 116 Figure B.1. Translation Of R-net Nodes Into Conceptual Graphs...... 127 v
Abbreviations and Symbols
Absurd type; can denote “false” or “no possible thing” (App. A) (I; J) Counterpart pair of concept I in one view and concept J in another. (Ch. 3, 4). (C1; C2; …; CM) An M-order counterpart where Ci is a concept in view i. (Ch. 3) ri (I J) A relation ri with dependency such that J depends on I. (Ch. 3) > Proper supertype of (App. A) ‡ Supertype of (App. A) < Proper subtype of (App. A) £ Subtype of (App. A) (r) Conceptual graph relation named “r” (App. A) <
1. Introduction
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.3. Analyst’s Framework 4.4. Analysis of Multiple Viewed Requirements 4.5. A Methodology For Multiple Viewed Requirements 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.2. Data Flow Diagrams 5.3. State Transition Diagrams 5.4. Requirements Networks (SREM) 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.2. Reasonableness of Overlap Ch. 1 2
8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.3. Speculation 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.2. Conceptual Graphs and Logic A.3. Conceptual Graph Extensions Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
The choice of a point of view is the initial act of a culture.
José Ortega y Gasset, The Modern Theme, 1923
Large software-laden projects are usually undertaken by many people using valuable resources. Before embarking on such a costly enterprise, they must first agree upon what they want it to accomplish — a process called software requirements development. Effective requirements development involves the activities of description, analysis, communication, and compromise. Although these activities may be assisted by automated tools, the process remains essentially a human cognitive endeavor. Requirements should describe a need to be fulfilled (the WHAT). They should not specify any particular answer to that need (the HOW). Attention during requirements is focused on understanding the problem to be solved, not the details of how to solve it. A given set of requirements may lead to several acceptable solutions.
1.1. Problems With Software Requirements Software engineering, as a discipline, has made great strides in improving most phases of software development. One notable exception is in the area of requirements: as Roman points out, there are still important unresolved issues [Roman85]. With all our experience in developing software systems, why is requirements development still so difficult? There are several reasons for this. Decomposition doesn’t always work. Our time-honored decompositional approaches don’t always work to produce a set of satisfactory requirements — a phenomenon often called “losing sight of the forest for the trees”. An end-user isn’t interested in the the logical structure of a system, nor should he be. He is interested in getting a job done, for which the software system is just another tool. If even one part of the system fails to meet his needs, he may rightfully decide that the entire system is inadequate. Bailin gives an example of how decomposition may, in fact, hinder identification of requirements [Bailin89]: some overall requirements (e.g., end-to-end-service constraints in a real-time system) are inherently non-decomposable unless we ignore some of their intended meaning. Alford, in justifying SREM’s development, Ch. 1 3 explains that “[b]ecause the hierarchy-of-functions model does not explicitly represent the conditions or sequences of processing, requirements generated under it are ambiguous with respect to them” resulting in the need for manual interpretations. [Alford85] (For an entertaining discussion on the non-decomposability of requirements, see [Swann83].) Requirements development is not design. The purpose of design is to devise a solution with the characteristics demanded by requirements. Design therefore proceeds under a set of constraints (i.e., requirements) against which the design can be subsequently validated. Many design techniques have been used, with some success, in producing systems which meet their stated needs. The success of any design technique, however, is based on having a set of correct and complete requirements, thereby begging the question of how to know whether requirements are correct and complete. Requirements stem from human needs, in some cases prior to or external to system development. Thus when requirements change (as they inevitably do), designs must necessarily change also. Requirements lack a theoretical basis. A computation can be seen as the mechanical realization of a mathematical or symbolic mapping from its inputs to its outputs — i.e., a function — albeit an often complex one. The principles of coupling and cohesion help us to effectively design software systems that are understandable and useful. Formal logic and theories of computation support the design and construction of correct programs. No such theories are available to the requirements analyst, though there have been successful ad-hoc approaches (e.g., SADT [Ross85], CORE [Mullery79]). Requirements are human-based. Most of the tasks given to software personnel are centered around the behavior of machines: designing, constructing, testing, and adapting programs for machines to execute. Mechanical tools with well-defined syntax rules are clearly appropriate for these tasks. Requirements, however, originate with human beings, who do not necessarily follow rules. As a consequence, software requirements are not derivable from a theory: they originate from human needs which an effective requirements method must capture. Requirements must satisfy many people. A major problem with large systems’ software requirements is that they must satisfy the needs of many people and organizations. Different people have different perspectives on a desired system — different priorities, interests, knowledge, experience and vocabulary. This thesis considers their perspectives as a priori knowledge upon which subsequent requirements will be based. A participant’s perspective of a proposed system will be called his view. If important participants do not contribute until near the end of a project, or if some developers assume they know what the others want, then a significant portion of requirements will either be missing or just plain wrong. Requirements have many viewpoints. In the past, a system was often characterized by a simple phrase, such as a “real-time” or “interactive” system. Certain design approaches would then be based on the phrase chosen. Even a supposed “real-time” system, such as a patient-monitoring system, possesses some interactive characteristics: How should an emergency be signalled? What information should be presented in case of an emergency? Does the information to be presented depend upon who might respond to the alarm? Other characterizations also can be considered, such as “distributed,” “expert system,” “accounting,” etc. CORE [Mullery79] addresses several of these facets. Most work has focused on the developer or designer’s (“technical”) view; in most cases, only one view is meant to be captured by the various methods. Being limited to a particular view, they are inadequate to describe all requirements. Furthermore, current requirements methods are generally aimed at one category of system, such as embedded, interactive, communications, graphics, database, real-time, distributed, etc. Although each method is useful in its own right, a large system seldom falls completely into just one of these categories; each of its subsystems possesses characteristics of different categories, involving different kinds of requirements. Zave makes a similar argument about programming paradigms [Zave89]. Requirements change over time. Requirements for a large system (or even a smaller one) will change over time. Software life cycle models place requirements in one of their early phases [Agresti86a]. Without regard to a particular lifecycle model, improving requirements (the earlier the better) gives us valuable leverage on reducing overall software costs, since the need for later re-work can be eliminated.
This thesis is founded on the assumption that the first challenge for developers of a software system is to conquer the cognitive aspects of requirements — being able to understand and communicate them. A framework is introduced for developing large-scale software requirements involving many developers, based on the belief that Ch. 1 4 each participant’s understanding of the overall requirements can be increased by including other participants’ requirements. Its goals are to enhance the consistency, correctness, and clarity of requirements by considering the diverse perspectives of requirements developers. We will support the human process of creating and evaluating multiple-viewed requirements, and offer opportunities for analyzing the overlap between requirements perspectives.
1.2. Context of Work We are interested in requirements for large-scale software systems, often comprising several subsystems. Several different organizations, in different geographic locations, may participate in the development process as customers, sub-contractors, consultants, or suppliers. Current requirement specifications may take up several volumes on a bookshelf, defying any single person to understand them all. Whenever we mention requirements, we will be speaking of software requirements unless some other meaning is specifically mentioned. Requirements includes all “real” requirements, including all needs, desires, and constraints on the proposed system, whether actually known or not. Naturally, we want to capture as many requirements as possible. This thesis introduces a framework for analyzing the overlap between multiple participants’ requirements. In order for developers of requirements to share some understanding about a system, there must exist some common element(s) in their mental models. A primary goal of this thesis is to help people discover and communicate relationships between their conceptual models. Once areas of overlap are identified between their views, participants’ conceptions of the system are altered to reflect their new understanding. In this thesis, we do not attempt to show that two developers’ mental models are identical — on the contrary, gaining an understanding of their differences provides an excellent basis for improving overall system requirements. The ideas contained herein are intended to serve human developers in their quest for correct, consistent and complete requirements. As that quest is primarily a cognitive endeavor, some decisions along the way must be made by human beings. Automated tools can merely point developers in the right direction or suggest candidate areas for further study. This thesis does not offer explicit support for the entire software life cycle, e.g., through the phases of software, design, implementation or testing. It is primarily intended for the early conceptual stages of development. It does provides a framework under which both heuristic decisions of participants and their pre- existing assumptions can be explicitly represented, and under which requirements can be explicitly compared between viewpoints. We believe that subsequent development will be improved when preceded by better requirements analysis. To summarize, we postulate the following four assumptions about requirements development, in order to motivate and justify this thesis: Assumption 1. Requirements development is primarily a human-centered, cognitive activity whose most important goal is human understanding of the requirements. When dealing with an unknown set of requirements (i.e., a system we don’t yet understand), we may be easily misled by automated techniques unless they are based on correct assumptions. Tools should therefore augment the human decision-making process, not supplant it, so that humans remain the final arbiters. Assumption 2. Effective requirements development depends upon the participation of everyone affected by a proposed system. This collaboration is often performed by periodic committee meetings or some other informal review process, perhaps spanning several years. Too often an initial requirement (sometimes implicit) is overlooked or discarded in the process, so that the delivered system is unacceptable to participants who considered that requirement an important one. All participants, therefore, have a stake in incorporating everyone’s requirements. Assumption 3. Each participant in software requirements has a different view of the target system. A view is based on a participant’s knowledge, interests, vocabulary, and needs; these may differ widely even among participants with similar experience. Each one’s view may directly affect the software requirements of another. Assumption 4. Describing any participant’s view of the system or its environment will tend to improve the overall understanding of that system. This is true because (a) writing something down improves the clarity of one’s ideas, (b) even if the description is faulty, the process of identifying its faults will increase human Ch. 1 5 understanding of the system being described, and (c) if the description is accurate, then other participants have access to the explicit requirements they need.
1.3. Multiple Views This thesis uses the notion of a view around which to organize requirements development. In the next section, we offer our reasons for introducing multiple views as an effective means of discovering requirements. A key feature of large-scale systems is the quantity and variety of knowledge possessed by their builders. In this thesis, a participant refers to any person or organization involved in the requirements development process, including customers, managers, end-users, maintainers, documenters, testers, designers, and implementors. A participant has his own viewpoint of a proposed system, its environment and its requirements. Any single view, no matter how carefully chosen, will be inadequate by itself to describe all requirements, not only because of the number of participants, but also the richly varied perspectives they possess. This thesis proposes a framework for incorporating existing diverse views, so that they can be analyzed in combination. This will be called a multiple viewed approach. It is a compositional approach, unlike most approaches which rely on requirements’ decomposability. The reasons for incorporating multiple views are as follows: • Variety of participants. Their cooperation is essential in developing requirements, yet they possess a rich variety of viewpoints, experience, knowledge, interests, and vocabulary. In addition to computer specialists, there are scientific, economic, legal, psychological, and managerial specialists (see [Wood-Harper85]). Requirements must ultimately satisfy all of them. • Limitations of special purpose methods. Each method has its weaknesses which limit the requirements it can model [Zave89]. Adherence to a single special purpose method will cause a participant to miss those requirements for which it was not intended. For instance, SREM is intended for real-time systems using a stimulus-response model — it would be inadequate to define, say, an interactive interface where a human user may provide a variety of unpredictable responses. • Strengths of special purpose methods. Existing methods have evolved from practical experience with certain kinds of systems because of their demonstrated strengths in expressing requirements. Requirements participants have a valuable investment in their current notational systems — both economically and intellectually — which ought to be exploited. • Overlapping Requirements Views. A requirement may appear in the view of two or more participants. A requirement cannot always be classified as a customer’s requirement, or a designer’s requirement. A multiple viewed approach serves as an open-world model to which additional views can be added. • Increased understanding. The overlap between views provides a starting point for mutual discussion among human participants. If a requirement is brought out by the inclusion of a single view, then that requirement is potentially available to others (albeit perhaps only informally) so that all participants may examine its impact on their own views. While the framework introduced herein captures several different views, it itself is still yet another view — the view of the requirements analyst employing multiple views. Chapters 4 and 10 describe some limitations of this approach to requirements development; however, this thesis constitutes an important step in a process of integrating several views of requirements into a coherent whole.
1.4. Improving Requirements Development This thesis introduces the following important results for requirements development:
Multiple views are represented in a general framework. A framework is given for multiple viewed requirements, with practical methods to support it with a general representation. The framework supports requirements knowledge acquisition and re-use: participants can incrementally expand a domain model, as new views are added, and existing views are augmented. Ch. 1 6
Overlap between views is formally represented. Using the representation of conceptual graphs, the framework offers formal techniques for representing and analyzing the overlap between diverse participants” requirements. Requirements development is person-oriented. The framework is centered around multiple participants’ cognitive needs, rather than technical processes, and uses a variant of semantic networks as its representation. Participants’ pre-existing assumptions are explicitly stated, supporting re-use and reducing later misunderstandings. Current methods can be incorporated Not all wheels have to be re-invented. The methods given in this thesis are meant to augment, not supplant current methods. Current methods can continue to be utilized. The approach hopes to complement existing development methods without reducing their effectiveness.
1.5. Outline Of Dissertation This introduction outlined the problems with current approaches to software requirements, and provided some of the rationale for including multiple views in the requirements process. Chapter 2 surveys representative existing requirements development views and notations, with the aim of identifying their major strengths and weaknesses. Chapter 3 informally sketches our framework for handling multiple views. Chapter 4 elaborates the framework in terms of conceptual graphs and gives a development methodology to support the approach. (Readers unfamiliar with conceptual graphs may wish to look at Appendix A before reading Chapter 4). Chapter 5 describes how requirements developed under existing techniques are first translated into conceptual graphs. Chapter 6 gives an extended example illustrating how the methodology works. Chapter 7 describes an evaluation process that can be used to validate the multiple-viewed approach to see whether it is better than current methods. Chapter 8 begins such an evaluation procedure using the extended example. Chapter 9 describes results of applying the methodology. Chapter 10 summarizes the thesis and outlines future directions. Appendix A explains the notation of conceptual graphs [Sowa84] that will be used to describe the formal multiple-viewed framework. Appendix B provides details of the translation schemes illustrated in Chapter 5. References are listed at the end. Ch. 2 7
2. Views In Software Requirements Development
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View A Participant’s Requirements Specification A Participant’s Pre-Existing Assumptions 2.2. Example Requirements and Assumptions Sample Participants 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst Requirements Analyst’s Tools Requirements Analyst’s Process 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views Counterparts Dependency 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap Ch. 2 8
4.4.2. Analyzing Overlap Association Graph 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram An Entity-Relationship R-Spec An Entity-Relationship R-Spec-Graph 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram A Data Flow R-Spec A Data Flow R-Spec-Graph 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram A State Transition Diagram R-Spec A State Transition Diagram R-Spec-Graph 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network A Requirements Network R-Spec A Requirements Network R-Spec-Graph 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Discussion After First Association 6.2. Analysis: Second Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. 6.3. Analysis: Third Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and repeat step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. In this example, we will use English as our description. 6.4. Results of Analysis Counterparts in Patient-Monitoring Assumptions in Patient-Monitoring Inconsistencies in Patient-Monitoring Ch. 2 9
Incompleteness in Patient-Monitoring 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics Counterparts Participant Assumptions Inconsistencies/Ambiguities 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model Relative Cost of Requirements Errors Proportion of Errors Identified By Multiple Views Multiple Views’ Cost 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap Comparison To Empirically Determined Overlap Ex Post Facto Judgments 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings Conceptual Graphs Utility Overlap Characteristics 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach Limitations of Conceptual Graphs Limited Support Over Life Cycle Granularity Limitations 9.5. Summary 10. Conclusion 10.1. Summary of Thesis Methodology For Identifying Multiple Viewed Requirements Requirements Analyst’s Framework and Knowledge Base Participants’ Requirements In Conceptual Graphs Participants’ Assumptions As Conceptual Graphs Determination of Overlap Between Views 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework Non-Functional Requirements Re-Use Of Assumptions 10.3. Speculation Potential for Simulating Requirements Ch. 2 10
Automated Acquisition of Assumptions Convergence of Views 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.1.1. Nodes and Links Concept Relation Actor A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules Copy Restrict Join Simplify A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations Display Form Linear Form Paraphrase Form Transformations Among Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.1.1...... Compilation Algorithm 1a B.1.2...... Extraction Algorithm 1b B.2. Data Flow Translation Scheme B.2.1...... Compilation Algorithm 2a B.2.2...... Extraction Algorithm 2b B.3. State Transition Translation Scheme B.3.1...... Compilation Algorithm 3a B.3.2...... Extraction Algorithm 3b B.4. Requirements Network Translation Scheme B.4.1...... Compilation Algorithm 4a B.4.2...... Extraction Algorithm 4b B.5. Summary References
By definition, a paradigm offers a single-minded, cohesive view — that is, in fact, how the popular paradigms help us think clearly, offer substantial analytical capabilities, and achieve their reputations for elegance. The corresponding disadvantage is that each paradigm is too narrowly focused to describe all aspects of a large, complex system. Ch. 2 11
Pamela Zave, “A Compositional Approach to Multiparadigm Programming,” 1989.
This chapter shows the role of views in software requirements. Since this thesis describes a method of integrating multiple requirements specifications based on multiple participants’ views, we first describe what is meant by a view, and why it is a useful notion for characterizing participants’ requirements. Most of this chapter is devoted to showing how views are captured by several existing requirements methods. We pay particular attention to the purpose of each method, the kind of requirements each is designed to capture, and to what degree integration is possible between different views as captured by each method. To facilitate later discussion, we introduce an example system and its participants’ requirements. Most development methods have centered around the software designer’s or implementer’s view. Previous work has identified needs in a customer view [Wartik83, Wood-Harper85, Hirschheim89] and an end-user view [Wasserman82, Mullery79]. Rapid prototyping (see [Agresti86b]) can be considered a general strategy for obtaining the end-user’s view indirectly from his interaction with a prototype. Our approach will be to consider several participants’ views as they are naturally presented in a typical software development process. First, we will introduce the parts of a view, and explain why it is a useful starting point for requirements analysis.
2.1. Views in Requirements This section shows how views influence requirements development, and lays the groundwork for most of our later discussion. We explain that a view includes both a participant’s requirements specification, and all of his underlying assumptions. Although some of these underlying assumptions can be made explicit, we know that not all of them can. Consequently, any representation of a view must be incomplete, no matter how well-chosen our language of expression. This chapter introduces views in an informal way. Later we will call our informal notion a viewpoint; reserving the term view for our (to-be-presented) formal definition. In this chapter, view and viewpoint are used interchangeably.
2.1.1. Purpose Of Using Views Using the word view emphasizes an explicit human viewer involved in creating requirements. Imagine a participant who observes a system, either an existing one, or a proposed one. The features that he perceives, along with their meanings, constitute his view of that system. Part of a view is explicitly embodied in a participant’s requirements specification; the rest is implicit in a participant’s pre-existing underlying assumptions. Requirements development seeks to bring out a participant’s implicit knowledge (albeit imperfectly or incompletely) and make it explicit, so that we can more fully represent a participant’s view, and analyze it with respect to its effect upon other views (also imperfectly represented). Finkelstein and Fuks [Finkelstein89] refer to the implicit assumptions as a viewpoint. We claim the following purposes are served by considering views of requirements:
More views provide more complete coverage of requirements This thesis is based on the premise that inclusion of multiple views provides a more complete understanding of requirements than any single view. As Borgida, et al. have stated: If the specifier views the same situation from multiple points of view, he is less likely to omit a significant fact. Furthermore, if multiple descriptions of the same situation do not agree, then at least one of them is incorrect — a fact that may not be uncovered if only one description is presented. [Borgida85, p. 85]. In fact, identifying a previously unseen view may be the single most important step toward increasing participants’ understanding of a proposed system as a whole. Ch. 2 12
Participants are naturally observable entities Since participants are readily identifiable (people are easily distinguishable from software or hardware!), it is natural to identify requirements as originating with particular participants. Every requirement therefore has an "owner" — the participant(s) from whom it originates. Requirements specifications are organized around each participant’s own pre-existing assumptions and resulting requirements. In fact, using multiple views may establish that some requirements have multiple “owners”.
Notations support understanding of a view Organizations have already made a significant investment in tools to assist software development. These tools may provide traceability, automatic design generation, simulation, or rapid prototyping of requirements. Even if a given tool only supports one notation, its value in gaining understanding of a view expressed in that notation should be acknowledged and utilized, since it aids in understanding others’ requirements.
2.1.2. Basics Of A View In this thesis, participant means anyone involved in software requirements development. The originating viewpoints are each associated with a participant. The term viewpoint is described in [Finkelstein89] — a logical participant in the requirements development dialog. A view will encompass the knowledge, vocabulary, interests, and experience possessed by some distinguishable participant(s). The following are elements of a view: an explicit human observer, a proposed system, a set of pre-existing assumptions, an optional associated notation, and an optional identified paradigm, as in [Zave89]. A formal classification of different views is beyond the scope of the present work. We might even make the claim that adopting any classification scheme will necessitate simplifying the views such that important properties are ignored. This work seeks only to capture views and effectively utilize them for software requirements.
Explicit Human Observer A view must have an explicit human observer, i.e., some participant. The presence of a participant’s name in some specification indicates his view.
Proposed System A view contains a reference to a proposed system, often called a target system. This thesis refers to a target system by name, e.g., the patient-monitoring system. Participants are assumed to be describing the same system.
Associated Paradigm(s) The recognition of the paradigm as a programming design concept has been recently discussed ([Zave89] and elsewhere). A requirements paradigm consists of some coherent, integrated model, with underlying assumptions about what features to consider (and thus what not to consider) when analyzing requirements. For example, in the data flow paradigm, there exist only processes and data, with data flowing between the processes. In adopting this paradigm, therefore, a participant focuses on data flow and processes, not on data structure, or anything else. A view may be constrained by one or more accompanying paradigms, e.g., some assumptions may be simplifications of the actual world, and may provide templates or other guidance for learning and understanding a target system. Since a paradigm can be considered apart from any participant, it comprises only one component of a view. Unfortunately, the notion of a paradigm is still too vague to be useful in this thesis. Including pre-existing assumptions in the definition of a view (see Chapter 4) is the extent of our use of paradigms.
Associated Notation(s) A view is distinct from a notation. Any participant’s view is potentially expressible in several forms. Each representational form is called a notation. His ideas of a system, as (partially) expressed by the notation, is called a Ch. 2 13 requirements specification, or simply a specification. In the past, a specification’s notation was hierarchical text (outline) form, usually with accompanying figures and tables, e.g.: 1. Purpose of System ... 2. Major system components ... 3. Functional requirements ... 4. Acceptance Tests ... etc. Some standards have been disseminated for the form of requirements specification documents [Defense85, IEEE84]; however, their impact on actual development is not yet clear. Although a view is logically distinct from a notation (in that a single view may be expressed in several notations), in fact they are often intertwined, because what we can imagine depends largely on what languages are available to express our ideas. A given notation may be chosen for its familiarity to participants, its perceived appropriateness for a given system, or its being mandated by contract. Participants may already assume a particular mental model of requirements based on a particular notation, making it sometimes difficult to distinguish a view from a particular notation. Many requirements methods prescribe a particular notation for their specifications. Structured Analysis uses data flow diagrams [DeMarco80, Yourdon79], SREM uses RSL based on entity-relationship diagrams [Alford77, Bell77, Alford85], SADT uses SA diagrams [Ross77], PSL/PSA uses the Problem Statement Language [Teichroew77], USE uses the language RAPID (a state transition derivative) [Wasserman82], DARWIN uses an Ada-like functional language [Wartik83], and a recent object-oriented requirements approach uses an amalgam called entity-dataflow diagrams [Bailin89]. All of these methods have their strengths in identifying some kinds of requirements. We would like to take advantage of them without succumbing to the narrowed focus they inevitably entail. The approach described herein allows us to continue using these methods, exploiting their strengths as much as possible; the use of multiple views merely extends requirements analysis beyond what any one method can do.
2.1.3. A Participant’s View Acquiring participants’ views for requirements is difficult for three reasons. First, participants may not yet know what features are possible or reasonable. Second, many of their actual requirements are pervaded by implicit assumptions that may never appear in any description. Lastly, different people have different ideas about what they want in the system (some conflicting, some complementary). Rapid prototyping [Agresti86b], [Wasserman82], [Balzer82] — i.e., quickly providing a concrete functioning product for participants to observe and evaluate — addresses the first difficulty. A rapid prototype is not wholly adequate for expressing requirements primarily because its correctness is based on testing which can never be exhaustive. We therefore need additional techniques. This thesis addresses the other two difficulties, namely, capturing participants’ assumptions in explicit form, and accommodating views of multiple participants.
A Participant’s Requirements Specification Figure 2.1 shows an idealized requirements development process for a single view. A participant P has a certain view of a target system S. He describes its characteristics and behaviors by creating a requirements specification — a set of requirements in some language, e.g., entity-relationship diagrams*. He may then examine
* For the purposes of this work, we do not discuss how a participant originally chooses a language or creates his requirements; they depend on the participant's individual insight. Likewise, for the purposes of multiple views, we do not consider language-specific internal validation procedures that may help him to improve his original requirements. Most requirements techniques provide their own guidelines for use and prescribe their own internal validation procedures. Ch. 2 14 the specification’s correctness according to the internal consistency and correctness rules of his originating language (e.g., in an entity-relationship model, entities can only be connected to relations), and may modify his view as a result. We refer to this as the validation cycle. Once his view is altered, he repeats the validation cycle using a new specification based on his new view. A participant’s view is therefore constantly changing, as new decisions are made and old ones are revised.
System S
P’s view
as seen by modifies/ augments
conflicts, Participant P incompleteness
uses may insight to discover create P's Requirements Specification
Figure 2.1. Simple Requirements Validation Cycle.
Experience and intuition have shown us that Figure 2.1 is incomplete. Validation comprises much more than just carefully transforming requirements specifications; in order to validate requirements, we use additional information. Pre-existing assumptions, usually implicit for each participant, add meaning to a specification beyond its actual structure or contents. This additional meaning enables validation. For example, a hospital may require a system whereby each patient’s vital signs are monitored automatically. A doctor or nurse may assume that the system’s main purpose is to support a speedy response when vital signs are out of range; however, the explicit requirements might not say so (as in some previous treatments of this example, e.g., [Alford77], [Zave82]). A hospital administrator may be concerned with reducing the number of (expensive) hospital personnel required, yet nowhere is there explicitly mentioned the cost of a doctor/nurse’s response. We now discuss further the role of these pre-existing assumptions in validating requirements.
A Participant’s Pre-Existing Assumptions We assume that the meaning of a participant’s requirements is implicitly constrained by whatever pre- existing assumptions he possesses. A participant’s pre-existing assumptions may consist of the following: (a) definitional knowledge (e.g., properties and purposes of pieces in his requirements), For example, a nurse may assume by definition that “a monitor is an analog sensing/display device attached to a patient,” thus implying a relationship between monitor and patient. (b) meta-knowledge about his requirements language (e.g., its limitations or alternate forms) or (c) constraint knowledge about the system that cannot be expressed using one’s chosen language or paradigm, such as data flow characteristics not being captured by an entity-relationship model. If an assumption were expressible in the participant’s own chosen language (e.g., we wish to express the fact that entity monitor is related to entity patient), the original specification is simply incomplete — we can usually add such an assumption directly to the original specification. There are, however, assumptions affecting our requirements that we cannot express in the chosen language. Since they fall outside of our chosen language, these assumptions may only be made explicit with some representational form that can capture both our chosen Ch. 2 15 language and our underlying assumptions. In this chapter’s discussion, we use natural language (e.g., English) to express these assumptions; later, a formal representation will be used (see §4.1 below). Regardless of the language we choose, we seek to analyze requirements to determine whether they are faulty — i.e., incorrect, incomplete, inconsistent, or ambiguous. This validation activity, labeled modifies/augments in Figure 2.2, may be supported by manual or automated tools. Its results are a set of problems to be corrected or studied further, resulting in an altered view of the system by a participant who prepares a new (improved!) set of requirements, and the cycle starts anew.
System S
P’s view
as seen by modifies/ augments
conflicts, Participant P P's pre-existing incompleteness assumptions underlies constrains
uses may insight to discover create P's Requirements Specification
Figure 2.2. Actual Requirements Validation Process.
Although we may be able to propose rules for determining correctness and self-consistency in a requirements specification, the notion of completeness will be elusive when dealing with requirements. Even with re-use of existing knowledge, inclusion of plausible knowledge from schemas, or other sources of information, it is likely that we will never know if requirements are in fact complete — we do not believe that all assumptions can be expressed. If requirements development necessarily involves working with incomplete information, our validation process must allow for incompleteness, with human judgment and feedback at all stages. Because any judgment of completeness will be supported by whatever explicit assumptions are available, it is important to make explicit as many implicit facts as we can. Participants’ pre-existing assumptions underlie the actual requirements. If we can identify these assumptions, then they are potentially available for re-use in future systems. To clarify the discussion, some example assumptions are considered below. The example assumptions given may seem simple, but then the difficulty in dealing with pre-existing assumptions is not necessarily their complexity — it is the very fact that they are hidden. Even simple assumptions, when left implicit, may affect requirements in far-reaching ways. Some assumptions reflect “common knowledge,” about gravity, time, and persons. These are applicable to many knowledge-based problems, not just requirements. For example, an assumption about time is: If event A precedes event B in some view, then it is not possible for event B to also precede event A. An assumption about Euclidean space is: If object A is bigger than object B, then object B cannot be bigger than object A. Participants’ assumptions may reflect their training or professional orientation. For example, a nurse assumes: If a patient’s vital signs are out of range, that patient needs attention immediately. Although deceptively simple, it does not in fact appear in previous treatments of the patient-monitoring system, e.g., [Alford77], [Zave82]. Borgida, et al. point out the difficulties in employing broad class definitions, even when a class seems simple enough to do so [Borgida85]. For example, a hospital manager may use the term patient specifically to Ch. 2 16 mean a person who has been admitted to the hospital. This may lead to interesting consequences; e.g., if a pregnant patient is properly admitted, and then gives birth to a baby, is that new baby a patient? When a participant’s language is based on a popular paradigm (e.g., SREM/DCDS is based on finite state machines), assumptions may express knowledge about features of the paradigm. For example, when using a stimulus–response paradigm, one assumption is: A stimulus is an event that precedes its response event. The use of particular languages may involve their own assumptions. For example, using two popular requirements languages, we may assume: An attribute in an entity-relationship model is equivalent to an arc label in a data flow model. This sort of assumption is used in conventional programming language compilation and translation. Some assumptions are specific to a certain class of systems, e.g., all patient-monitoring system(s). For example, A patient is a person who may not be conscious or alert. As we will see, pre-existing assumptions are important not only because they contain important pieces of requirements information, but also because they may be the only way to relate the requirements in different participants’ viewpoints. We will discuss multiple-viewed requirements, and begin forming a framework in which they can be related. Before doing so, we introduce a sample system to facilitate our subsequent discussion of requirements and views.
2.2. Example Requirements and Assumptions This section gives some features of an extended example which will be developed during this thesis. First we introduce sample participants in the requirements development process, then introduce each one’s requirements based on a language they might typically choose. Next we show some of their underlying assumptions. Although the assumptions underlie (and in a sense logically precede) the requirements, the order is reversed here because in practice, it is often easier to identify assumptions within the context of actual system requirements. This thesis refers to a sample patient-monitoring system system. This example has been used in previous work to demonstrate particular development methods [Alford77, Zave82, Wasserman82, Hewett89]. The system’s informal requirements (paraphrased from [Alford77]) are: 1. A patient monitoring program is required for a hospital. 2. Each patient is monitored by an analog device which measures factors such as pulse, temperature, blood-pressure, and skin resistance. 3. The program reads these factors on a periodic basis (specified for each patient) and stores each of them. 4. For each patient, safe ranges for each factor are specified (e.g., patient X’s valid temperature range is 98 to 99.5 degrees Fahrenheit). 5. If a factor falls outside of the patient’s safe range, or if an analog device fails, the nurses’ station is notified. This system description is a reasonable example for purposes of illustrating requirements, because it shows some important features of requirements. It displays: • Customer needs (requirements 1 and 5) • Descriptions of the environment (requirements 1, 2 and 4) • Examples of typical data (requirements 2 and 4) • Interaction with an existing environment (requirements 1, 2 and 5) • Specific desired behaviors (requirements 3 and 5), • Some ambiguity (requirements 2, 3, and 5), • Freedom from implementation detail (requirements 3 and 5) • Provision for unusual circumstances (requirement 5) The next section describes how these requirements might be expressed by some sample participants in software development. We introduce the participants and show their requirements in a notation they might Ch. 2 17 typically choose. These sample participants’ requirements and assumptions should only be regarded as typical; they are not intended as definitive prescriptions for all requirements development processes.
Sample Participants This section introduces two participants considered in this chapter. These particular participants’ views were chosen for being typical to modern requirements development, and yet diverse in their viewpoints. Other sample participants are discussed in Chapter 5. A customer represents the organization desiring a system to be developed. His chief interest is achieving fundamental system goals with respect to its most important objects and relationships. In this example, the customer is a hospital administrator responsible for overseeing the patient-monitoring system. He has knowledge about how the patient-monitoring system is supposed to fit into the hospital’s overall operation. A software designer has experience in developing previous software systems, and possesses knowledge about data structures, interactive data base query languages, system architecture, systems analysis and software design. In the examples, we assume the designer knows little about the actual workings of a hospital.
Customer’s Requirements and Assumptions A hospital administrator creates a requirements specification using an entity-relationship model, as shown in Figure 2.3. Attributes are shown under their associated entities.
1 1 N Symbol key Patient connec- Monitor plug tion into entity vital signs current readings 1 attribute(s)
Nurse M 1 Database rela- alert tion normal ranges
Figure 2.3. Customer’s Example Requirements.
Some of the assumptions underlying the customer’s specification are: 1. Meaning of patient — a person who may or may not be conscious or alert. 2. Meaning of vital_signs — includes four specific factors: temperature, pulse, respiration, and blood- pressure. Other factors, such as skin conductivity or brain waves, are not vital signs.
Designer’s Requirements and Assumptions The software designer creates a requirements specification using a data flow model, as shown in Figure 2.4. Bubbles are shown as ovals. Ch. 2 18
factors sensor Symbol key
source current readings alarm process Doctor / database Nurse normal ranges flow
Figure 2.4. Designer’s Example Requirements.
Some of the designer’s underlying assumptions are: 1. Meaning of alarm — a signal of an emergency situation requiring immediate attention. 2. Underlying query/process/response paradigm — the designer knows about the process of querying a query database, and later getting an answer. His assumption could be shown in data flow as: response database ; however, he also assumes the query must occur before the response — a fact not captured by the diagram’s semantics.
2.3. Support For A Single View We now describe previous work in software requirements analysis with respect to their treatment of views — whether multiple or not. For obvious reasons, we will spend more time discussing those methods which do consider multiple views. Even when considering multiple views, previous work has only been able to formally integrate multiple views by a data dictionary or other bookkeeping support. Such a capability is an essential ingredient in effective requirements analysis; however, bookkeeping alone does not satisfy the needs of analysis. A few methods contain some formal basis for semantic notions such as the overlap or inconsistency between views, and the incompleteness of one view relative to another. This thesis builds a formal framework in which these characteristics can be defined and analyzed. The following development methods are each based on a single paradigm, mostly from a software developer or designer’s view. Each captures requirements using a prescribed notation. This section explains the view of requirements each method is meant to capture.
SREM/DCDS The Software Requirements Engineering Methodology (SREM) [Alford77, Bell77, Alford85], currently incorporated into the Distributed Computing Design System (DCDS), assumes a stimulus-response paradigm of real-time requirements, based on finite state machines. It provides two equivalent notations: requirements networks (R-nets) in graphical form, and the accompanying Requirements Statement Language (RSL) in textual form. An R-net begins with a stimulus whose subsequent processing is shown in steps related by a few logical operators. A processing step may itself produce a stimulus, to be processed by another R-net. A processing step may also be decomposed into an inner R-net. See Chapter 5 for an example. Several case studies of SREM have been made [Scheffer85, Fullerton83]. In general, SREM is useful for real-time response requirements, although it uses several large tools that must be learned in order to reap its full benefits. It is intended primarily for software developers, and is therefore tailored to their view.
PSL/PSA The Problem Statement Language/Problem Statement Analyzer [Teichroew77] is intended for the analysis of functional requirements; in particular, input/output processing using a data flow paradigm. It not only Ch. 2 19 prescribes a development methodology, it also prescribes organizational changes that acknowledge the influence of human organizations on the requirements development process, later emphasized in [Hirschheim89]. It thus implicitly acknowledges the importance of views other than the software developer’s.
RAPID/USE The RAPID technique [Wasserman86] uses an extended state transition paradigm that is intended to describe interactive information systems from an end-user’s view. It consists of a language (both graphical and textual) that expresses current states, input/output events, and transitions to new states. It is useful in describing dynamic system behavior.
Operational Specification An operational specification represents behavioral requirements for embedded systems [Zave82]. As described in [Zave84], an operational specification’s logical relationships can be described by a formal description of the requirements using logical (rather than procedural) expressions. It adds the semantics of a logic programming paradigm, the basis for languages such as Prolog [Clocksin84], in order to gain two benefits: a declarative style naturally tends toward describing the WHAT, not the HOW, and its behavioral semantics provide the power to define and automatically analyze requirements expressed in a logic language.
2.4. Multiple Viewed Requirements When involving more than one participant, the development process in Figure 2.1 above becomes more complicated, as shown in Figure 2.5. Each participant produces a requirements specification as before, but the validation now includes determining their overlap, with feedback (understanding) affecting both participants. Overlap is simply a general term for any information that has meaning in more than one view. We must consider it carefully: one viewer’s vocabulary may seem different from another’s, but not necessarily. For example, a nurse may use monitor to mean an analog device attached to a patient, while designer may use sensor to mean the same thing.
2.4.1. Interaction Between Views To analyze a combination of views, each participant must be able to use external information from several sources. Participant P’s requirements specification already depends upon pre-existing assumptions that are outside his language. Some other participant Q’s specification (possibly in a different language than P’s) contains more information that is, of course, external to P’s specification. In addition, participant Q’s underlying assumptions, which are external to P’s specification, must also be considered. Since each participant’s specification can be in any language, and not necessarily formally manipulable, there is generally no formal basis for analyzing their overlap. Ch. 2 20
System S
P’s view Q’s view
as seen by as seen by modifies/ P's pre-existing augments Q's pre-existing assumptions assumptions Participant P OVERLAP Participant Q underlies constrains conflicts, constrains underlies incompleteness
uses may uses insight to discover insight to create P's Q's create Requirements Requirements Specification Specification
Figure 2.5. A Multiple-Viewed Requirements Validation Cycle.
Figure 2.5 suggests some of the difficulties in dealing with overlap. Two participants’ views may interact in several ways: they may (a) overlap completely, (b) overlap only in some aspects, or (c) not overlap at all. Where they do overlap, the views may or may not be consistent. In any event, they are rarely equivalent, even in theory. Another important conceptual issue suggested by Figure 2.5 is the question of how overlap should be expressed. Should the overlap between participant P’s view and participant Q’s view be expressed in P’s language, Q’s language, some other participant’s language, or some universal language? A participant will benefit most if the overlap is presented in his own language; however, if overlap is expressed in P’s language, Q might not understand or believe it, and vice versa, if Q’s language is used. If the overlap is presented using some other participant’s language, then possibly neither participant would understand or trust it, unless both participants learn the new language. A universal language would be ideal, but is probably unattainable in practice. There are at least two basic approaches for capturing overlapping requirements. One is to select a single language to express requirements so that analysis within the language is supported, while paying the price that everyone must learn the new language. This is the approach taken by most software requirements methods, e.g., SREM [Bell77, Alford77, Alford85], SADT [Ross77, Ross85], and PSL/PSA [Teichroew77]. As already discussed, the major weakness of this approach is that using any single language may cause developers to overlook important requirements for which the language was not intended. Another drawback is that some (or all) participants must expend effort to learn a new unfamiliar language in order to produce requirements. A second approach is to include requirements specifications in multiple views, and informally relate them, under the belief that using them will increase everyone’s understanding in some way. This approach is used in [Wasserman82], [Wartik83], [Agresti87], [Finkelstein89], and [Davis90]. Its drawback is that (except for bookkeeping support) there is no way to amalgamate the multiple specifications into one set of requirements that can be analyzed and presented together. If the number of views were small (e.g., two), then we might accommodate them by a careful study of their common features; however, our results would be limited to that pair of views. If the number of views were large (e.g, a dozen), then each possible pairing would have to be studied, requiring exponentially increasing effort. As we show in Chapter 3, this thesis will combine the two approaches, relying on a special participant called the requirements analyst, who uses a single knowledge representation (his meta-language) to capture all views in one model for analysis. Participants can still use existing requirements development methods and tools to produce requirements which are each translated into a single meta-language for use by a requirements analyst. We therefore rely on a human analyst to manage the requirements development process, much as Structured Analysis refers to the role of the systems analyst [DeMarco80]. Ch. 2 21
We now summarize some multiple viewed requirements methods.
2.4.2. Support For Multiple Viewed Requirements Where §2.3 described some single view development methods, this section shows some instances of multiple-viewed approaches. Some methods explicitly accommodate multiple views (i.e., more than one) and incorporate them into a single requirements development framework. In most cases, their particular views are pre- selected and fixed throughout requirements development. The following methods are multiple viewed methods, in that they allow for the explicit inclusion of requirements from the viewpoint of more than one participant.
SADT As described in [Ross77] and [Ross85], the Structured Analysis and Design Technique (and its variants, such as IDEF0) comprises two interlocking paradigms: a data flow paradigm and a control flow paradigm (activity diagram), both using a similar graphical notation. It has been used in a wide assortment of development projects. SADT’s lack of a theoretical basis means that “at the present time, we don’t know how to bound or characterize the problems to which SADT is easily applicable and the ones to which it is not” [Ross85]. Since it depends on a proprietary Design Technique for its success, there is a tendency to blame SADT’s failures on improper use of the methodology. In several cases, its strengths are introduced with notions such as “by choosing viewpoint and purpose properly...” and “If multiple model orientations are properly chosen...”. SADT does not incorporate pre-existing requirements knowledge (in fact, some consider it to be knowledge-neutral). As with any decomposition method, it also suffers from the limitations mentioned in Chapter 1. Validation of requirements is accomplished manually.
CORE The technique called Controlling Requirement Expression (CORE) [Mullery79] is one of the first techniques to explicitly acknowledge multiple views of requirements. One of its important activities is to propose and define appropriate viewpoints, in this case varying viewpoints of either the analyst or user. The analyst, by skillfully questioning users, prompts construction of requirements that capture all relevant viewpoints. Mullery maintains that “there is no one top to a system and at every step in decomposition there are multiple viewpoints which contribute to a full understanding of the requirements at that level”. The only top level is that of the participants. The four parts of decomposing a viewpoint are to identify it, define it, establish its consistency relative to other viewpoints, and then establish its user acceptance. The biggest drawback to this method is that it is manually based, and relies on the skill of the analyst, much as does SADT. The method has nonetheless been successful, and has been adopted by British Aerospace as its method-of-choice for development.
A-7E Requirements The requirements document for the A-7E flight software [Heninger78] introduces a notation and formal for effectively representing requirements from multiple views. It provides a simple yet powerful notation. It has two drawbacks as a multiple viewed requirements technique as we are considering in this thesis. First, there is no explicit representation of each view; participants were interviewed, and the results of the interviews combined manually into one requirements document. Second, there is no methodology or process laid out that leads an analyst in a step-by-step fashion to accommodate the multiple views. While it is an excellent example of well- written requirements, it lacks a clear underlying process definition.
DARWIN DARWIN [Wartik83] is a requirements language based on Ada capable of expressing two different participants requirements. A customer’s view and designer’s view of requirements are both captured — a developer’s by standard Ada semantics, and the customer’s by a less rigid Ada notation. Ch. 2 22
DARWIN clearly illustrates that customers and designers have different needs from the system, and benefit from having the flexibility to express requirements in a language appropriate to their desired level of detail.
Software Through Pictures Software Through Pictures® (StP) [Wasserman86] supports several notational forms in one programming environment accommodating multiple specifications. Integration among the notations is limited to a common underlying data dictionary, where all development information is kept. Several design methods are supported, but only certain kinds of items can appear in more than one picture with a duplicated name. For example, an entity- relationship model’s entity may have the same name as a dataflow arc label. Such overlap is based entirely on two items having the same name. As we discuss in later chapters, using identical names to relate views is not reliable. StP does not support a particular methodology per se, although each of its diagram editors is based on one or two specific instances of a method. Judging by its commercial success, StP provides evidence that working with multiple views is practical and useful, even if the views are only informally related.
Composite Specification Method The Composite Specification Model (CSM) [Agresti87] employs three widely-used specification techniques to describe requirements. The techniques are entity-relationship diagrams [Chen76], data flow diagrams [Yourdon79, DeMarco80], and state transition diagrams [Wasserman86, Aho72]. These three specifications are supported in common by a data dictionary, providing typical static information such as a data item’s name/type and where it is used in any of the three specifications. This method is being used in several development efforts within NASA, and serves as practical illustration of multiple views’ usefulness in identifying requirements, even without explicitly analyzing inter-view effects. Validation between the views is accomplished manually.
Multiview Multiview [Wood-Harper85] introduces an explicit non-technical (organizational) view into the system development process. It is concerned with managing organizations through successive need analysis, requirements, design, and implementation of a data processing system. The customer’s, manager’s and end-user’s views are considered even more important than “technical” views. Multiview is an explicit attempt to acknowledge the views of specific persons and organizations in development. It does not, however, have a formal basis, simply a methodology prescribing particular views and the order in which the views are best considered.
Multiparty Specification The multiparty specification employs a dialog model of technical discourse, whereby the discussion and negotiations of participants are formalized [Finkelstein89]. Although less adaptable for use with existing notations, it does provide a way to formally accommodate differing participants’ views. It provides a framework for negotiation between different participants, whereas our multiple viewed approach builds a framework for examining the cognitive interaction between views by using pre-existing assumptions.
Multiparadigm Programming This approach as described by Zave [Zave89] refers to the composition of several programming paradigms (e.g., logic programming, PAISLey, CSP) for the solution of a single problem. She identifies several forms of non- determinism as the common concepts for performing her composition. Although specifically aimed for the programming (implementation?) aspects of software, much of her rationale for including multiple paradigms is also applicable to the requirements aspects of software.
Object-Oriented Requirements A recent paper on requirements for object-oriented software [Bailin89] includes two distinct paradigms: an entity-relationship paradigm, and an extended data flow paradigm. It describes a hierarchy of domain levels that permit abstraction and aggregation of objects. As with any decompositional method, it may not handle top- level requirements without using some structure similar to R-nets [Alford77]. Ch. 2 23
Borgida, et al. employ an object-oriented paradigm in their RML language [Borgida85] in order to more naturally capture real-world (“natural”) types. In this way, their methods come closer than some of the previous methods to being a true knowledge-based technique.
2.5. The Multiple Viewed Approach In this thesis, we will establish a framework for acquiring and analyzing multiple participants’ requirements specifications as well as some of their underlying assumptions. We then propose a methodology whereby each participant produces a specification which the analyst combines with the others to analyze their overlapping features. The term view is centered around a participant. Since a person may express his view in different forms (e.g., data flow diagrams, hierarchical text, etc.), a view is distinct from the notation(s) used to represent it. A view may be expressed in some language which consists of defined syntax and semantics. Once written down, a system description is called a requirements specification or simply a specification of that system expressed in the notation. A notational form may vary in complexity from hierarchical text to a formal specification method such as SADT or SREM. Requirements expressed in these existing notations will be translated into a common language for analysis purposes. After analyzing their overlap, we can identify certain areas that need additional information, thereby guiding the analyst in seeking additional assumptions from participants. With these new assumptions, expressed in the common language, further analysis can be performed. The approach thereby supports not only the analysis of multiple viewed requirements, but also the acquisition of new requirements knowledge.
2.6. Summary This chapter introduced the important aspects of analyzing multiple views of requirements. We described the general problems and informally outlines some solutions. We argued that software developers usually organize requirements around some particular mental model, a decision which has two opposing consequences: (1) such a focus on the model’s concepts increases the range of requirements fitting the model that are liable to be identified, and (2) focusing necessarily narrows the range of requirements outside of the model which are apt to be identified. Multiple-viewed requirements help overcome the limitations of (2) without sacrificing the benefits of (1). Existing development methods, along with their tools, environments, etc., can still be used to create and analyze original requirements specifications; thus some requirements can be identified without the need for multiple views. After a participant has created requirements using his mental models, his understanding of the overall requirements can be extended by inclusion of another participant’s requirements. Toward that end, some requirements methodologies already advocate using several views. We have defined the notion of a view as being centered around actual persons. A notation provides support for a view. We have seen how views are accommodated in various ways by various development methods. The role of multiple views was discussed with respect to its impact on requirements development. The requirements analyst’s role in applying multiple views was discussed. To provide a concrete basis for our discussion, sample participants and requirements were introduced. This chapter showed ways that multiple views are brought to bear on software requirements. What is lacking is a framework for relating differing views. Although it is unlikely that all requirements can be integrated, even their partial integration can help identify some problems in overlapping requirements. The next chapter begins the development of a framework for determining such overlap. Ch. 3 24
3. Analyzing Multiple-Viewed Requirements
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View A Participant’s Requirements Specification A Participant’s Pre-Existing Assumptions 2.2. Example Requirements and Assumptions Sample Participants 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst Requirements Analyst’s Tools Requirements Analyst’s Process 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views Counterparts Dependency 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap Ch. 3 25
4.4.2. Analyzing Overlap Association Graph 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram An Entity-Relationship R-Spec An Entity-Relationship R-Spec-Graph 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram A Data Flow R-Spec A Data Flow R-Spec-Graph 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram A State Transition Diagram R-Spec A State Transition Diagram R-Spec-Graph 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network A Requirements Network R-Spec A Requirements Network R-Spec-Graph 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Discussion After First Association 6.2. Analysis: Second Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. 6.3. Analysis: Third Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and repeat step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. In this example, we will use English as our description. 6.4. Results of Analysis Counterparts in Patient-Monitoring Assumptions in Patient-Monitoring Inconsistencies in Patient-Monitoring Ch. 3 26
Incompleteness in Patient-Monitoring 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics Counterparts Participant Assumptions Inconsistencies/Ambiguities 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model Relative Cost of Requirements Errors Proportion of Errors Identified By Multiple Views Multiple Views’ Cost 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap Comparison To Empirically Determined Overlap Ex Post Facto Judgments 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings Conceptual Graphs Utility Overlap Characteristics 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach Limitations of Conceptual Graphs Limited Support Over Life Cycle Granularity Limitations 9.5. Summary 10. Conclusion 10.1. Summary of Thesis Methodology For Identifying Multiple Viewed Requirements Requirements Analyst’s Framework and Knowledge Base Participants’ Requirements In Conceptual Graphs Participants’ Assumptions As Conceptual Graphs Determination of Overlap Between Views 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework Non-Functional Requirements Re-Use Of Assumptions 10.3. Speculation Potential for Simulating Requirements Ch. 3 27
Automated Acquisition of Assumptions Convergence of Views 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.1.1. Nodes and Links Concept Relation Actor A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules Copy Restrict Join Simplify A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations Display Form Linear Form Paraphrase Form Transformations Among Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.1.1...... Compilation Algorithm 1a B.1.2...... Extraction Algorithm 1b B.2. Data Flow Translation Scheme B.2.1...... Compilation Algorithm 2a B.2.2...... Extraction Algorithm 2b B.3. State Transition Translation Scheme B.3.1...... Compilation Algorithm 3a B.3.2...... Extraction Algorithm 3b B.4. Requirements Network Translation Scheme B.4.1...... Compilation Algorithm 4a B.4.2...... Extraction Algorithm 4b B.5. Summary References
During problem analysis, different people may have very different views of the problem. It is important to be able to track these different perspectives and relate them to each other. When these perspectives are in conflict, a good problem analysis technique will surface the conflict to aid in its resolution rather than burying it. Ch. 3 28
Alan M. Davis, Software Requirements, 1990
This chapter introduces formal techniques for analyzing multiple-viewed requirements; full details are elaborated in later chapters. §3.1 explains the important role of the requirements analyst in applying these techniques. §3.2 forms the bulk of the chapter; it introduces different kinds of interaction between views and shows the association graph approach that we will use to identify such interactions in a measurable way. §3.3 outlines some important issues we have yet to address, and gives some of the limitations of the approach. The next chapter elaborates and refines these techniques based on a particular analyst’s meta-language; here we show only the general approach. The previous chapter outlined two approaches currently in use for handling multiple views: we can either adopt one single language that every participant must learn, or we can start with views in several currently-used languages and relate them. This thesis combines the two approaches, relying on a special participant called the requirements analyst, who uses a single knowledge representation (his meta-language) to capture all views in one model for analysis. Participants still use existing requirements development methods and tools to produce requirements which are each translated into a single meta-language for use by a requirements analyst. We need not prescribe any particular form for participants’ specifications. Overlap and inconsistency are analyzed within the single meta-language, then translated either into an English expression or back into one or more of the originating languages. Figure 3.1 shows information flow between the basic components of this approach.
analyst's meta-language model
Model in Model in Model in language L language M language N
Participant P's Participant Q's Participant R's view view view
Figure 3.1. Multiple-Viewed Framework.
Using Muehlbacher’s terminology [Muehlbacher90], translation from one of the participants’ models into the meta-language will be called compilation, while translation back into the participants’ language will be called extraction. This work deals primarily with the compilation process; some discussion of the extraction process is found in Chapters 5 and 10. These compilation processes can be largely automated. Although the figure shows a participant’s view potentially expressed in each of the languages, in this thesis’s examples, each participant chooses only one language. Figure 3.1 also shows information flowing directly between the participants’ views and the analyst’s meta- language model. These “compilations” and “extractions” are performed manually by the analyst himself. Ch. 3 29
Performing them automatically is comparable in difficulty to natural language translation (e.g., see [Schank75]), since much of a participant’s view may not be expressed (or expressible) in his specification language. In particular, we are interested in expressing participants’ assumptions in the analyst’s meta-language. An important feature of this framework is that there is no information flow directly between the participants, or between their models. All communication is handled through translations to and from the analyst’s meta-language. This approach is similar in spirit to Schank’s [Schank75], where our meta-language serves the role of his interlingua.
3.1. Role Of the Requirements Analyst As mentioned before, the requirements analyst (or simply analyst) is a special participant in requirements development. His job is to oversee all of the requirements, perform all translations and analysis, and report his findings to other participants. He must be familiar with the language and paradigms employed by the others, as well as understanding the rationale and techniques for using multiple views. Others have stressed the importance of having an experienced analyst in developing requirements (e.g., [Mullery79]). Sometimes the analyst’s job is that of corporate psychiatrist, trying to determine participants’ underlying implicit assumptions by carefully examining what is stated explicitly. Much of that determination is based on his expertise and insight when dealing with several participants. Some underlying assumptions may have been already determined by prior requirements development. Automated support may help the analyst decide what knowledge to include or how to express it, but gathering participant assumptions cannot presently be automated. In addition to his knowledge of several theoretical paradigms, the analyst’s decisions are bounded by realistic issues, such as organization politics, managerial style, and limited budgets. Some of these decisions cannot be made on any existing theoretical basis; the analyst must use his judgment, coupled with judgments of other participants. The purpose of analysis is to determine whether items present in each view are compatible with each other. We would like a means of accurately telling a participant just which part of his original specification led to the inconsistency, so that he at least knows where changes to his requirements are most likely needed.
Requirements Analyst’s Tools The analyst needs at least the following to achieve effective requirements analysis using multiple views:
Meta-language An important tool needed by the multiple-viewed analyst is a language in which to represent several different paradigms, languages, and systems. We call it a meta-language because its purpose is to explore relationships among concepts in different languages. This chapter’s purpose is to show the meta-language’s role in multiple-viewed requirements without introducing the details of an actual language. In the next chapter, we discuss our choice of conceptual graphs [Sowa84] as the meta-language that will be used in this thesis; details of the notation are given in Appendix A. Up to now, we used natural language for expressing overlap, since that is the only language known by all participants. Since we know that natural language can be quite ambiguous, we will want to determine the overlap by more formal means, although we may still use natural language to express it. This thesis attempts to identify those properties which any adequate meta-language must possess. Borgida, et al. discuss the value of appropriate knowledge representations in developing formal requirements [Borgida85]. The important features of an appropriate language are: ability to describe entities, events, constraints and assumptions in the application domain. They further state that a requirements language should also support abstraction, and provide some redundancy; namely through the use of multiple views. Finally, they mention that like all languages, an appropriate language should be easy to learn, easy to read and convenient to use. Heninger, et al. [Heninger78] introduced a common notation to express functional requirements taken from several views. Although their approach does not support a formal analysis of multiple views, it does provide a basis for describing important requirements information. Whatever language we use to express overlap, it must possess the following characteristics: 1. It must be general, since one purpose of multiple views is to expand the range of knowledge that can be captured in requirements. Ch. 3 30
2. It must be a formal language, since without well-defined rules on which to base analysis, we might just as well use hierarchical English outlines for all our requirements. 3. Our language must be able to represent common software engineering concepts, such as hierarchical decomposition, since they are often useful to participants, and participants have already invested mental effort toward understanding them. The following characteristics, while not required, are desirable in a practical meta-language: 4. It should have a mapping into natural language, one of our most general languages. 5. It should be able to be expressed in graph form, to capture objects and relationships among them. This characteristic is not restricted to just binary relations between objects; we want to be able to handle more complex relations.
Translation Procedures The analyst needs algorithms for translating participants’ requirements specifications into meta-language specifications. A set of translated specifications provide a starting point for multiple viewed analysis. Because participants’ requirements specifications do not always capture their underlying assumptions, the analyst also needs to capture and express those assumptions in the meta-language. Chapter 2 discussed the role of assumptions in understanding requirements specifications. Underlying assumptions (once expressed in the meta-language) can also be included after we have analyzed the originally translated requirements specifications. The next chapter has more to say about how we go about capturing such assumptions.
Requirements Analyst’s Process The requirements analyst examines all the views and tries to determine the properties of their overlap. The next section discusses some of the analyst’s procedures. Broadly speaking, the analyst supervises the following tasks: 1. Translation of requirements into his meta-language. 2. Combination of meta-language requirements into one set of requirements. 3. Analysis of the combined requirements. 4. Acquisition/clarification of more participant assumptions/requirements. These activities are performed in conjunction with participants, as shown in Figure 3.2. Translation methods are used to obtain requirements from participants expressed in the meta-language. These requirements are then combined and analyzed to determine their overlap. Any ambiguities or inconsistencies are given to participants in the form of questions whose answers form the basis of additional assumptions and requirements which are then expressed in the meta-language as well. The process repeats until no new ambiguities are found. Ch. 3 31
Translation methods Requirements in translation Meta-language combination
Originating Requirements Analyst's Specifications Knowledge Base and Participants Heuristics
Combined Additional Queries about Analyst Requirements assumptions other possible overlap Answers Meta-language Determined Knowledge Overlap
acquisition/ analysis clarification
Figure 3.2. Multiple Viewed Requirements Process.
3.2. Analyzing Overlap Between Views The goal of using multiple views is to identify overlap between views. Overlap is a general term; this section will distinguish different kinds of overlap and what they mean. Given any two views P and Q, represented as sets, we can imagine their overlap as represented in Figure 3.3: In Figure 3.3(a) there is no overlap between P and Q, so that the set P Q = . The two may contain conflicting information. In Figure 3.3(b), there is some overlap between P and Q, so that the set P Q is a proper subset of P and proper subset of Q. However, P Q. The two may still contain conflicting information. In Figure 3.3(c) the two views completely coincide, i.e., P = Q. All information in each is also contained in the other. At the start of development, situation (a) prevails since we have not yet found any elements in common. As we find common elements during analysis, situation (b) prevails, where there is overlap between some parts of the views, but not all parts. If we are completely successful in identifying all elements as common, then we may reach situation (c) where the two views coincide. If this last were to occur, it would indicate that we did not need both views in the first place. We mention it here only to emphasize the unlikelihood of two views being identical. Ch. 3 32
P P P Q Q Q (a) (b) (c)
Q Q
P P
(d) (e) Figure 3.3. Regions Of Overlap Between Views.
In practice, neither situations (a) or (c) are likely to prevail. If after analyzing two views of the same system, we remain in situation (a), we are in serious trouble: how can two participants communicate if they have nothing in common? At the other extreme in situation (c), if every element in one view is found in the other, then the two views are identical. We consider this unlikely, since one of our assumptions is that different participants have differing views. We must therefore spend our effort dealing with situation (b), by dealing with partial overlap between views. In discussing situation (b), there are three regions of interest: the overlap itself, and the parts of P and Q that are not in the overlap. These last two regions represent the absence of common elements; i.e., elements existing in one view, but not the other. It is important for participants to be aware of the overlapping region, but we must also consider how they might use information in the non-overlapping regions. In particular, if overlapping elements depend upon non-overlapping elements in either view, then a change in the non-overlapping part may still affect the overlap. Participants need to know which parts of their view are within the overlap, which parts are not overlapping but on which the overlap depends, and finally those parts which have no effect on the overlap. The situation in Figure 3.3(d) is where region represents elements in P’s view on which some element in the overlap (region ) depends, and region likewise represents elements in Q’s view on which some element in the overlap depends. With this information, participants gain knowledge about which elements in their own view affects the other views, leading to an increased understanding of other views. Complete dependency (as shown in Figure 3.3(e)) is where everything in P’s view is either part of the actual overlap or else is depended upon by parts in the overlap; a similar situation may prevail with respect to Q’s view. For participant P, gaining new knowledge from view Q may change P’s view. Likewise, for participant Q, the new knowledge from view P may change Q’s view. If P and Q are using different languages, this new knowledge may not be expressible in the language of the other’s requirements specification. The problem is to somehow characterize the meta-knowledge in a way that the viewers can understand the new knowledge. For example, information external to an entity-relationship model may say that “entity C precedes entity D.” Although such knowledge cannot be captured directly by the model, it may still be beneficial to the person who created the original entity-relationship model. Whenever overlap is suspected between two views, we would like to measure the degree of overlap. A strong connection indicates more confidence that relationships in one view correspond to relationships in the other; a weak connection indicates less confidence, and may suggest we look for a stronger one. Ch. 3 33
3.2.1. Identifying Overlap Between Views This section introduces two key notions in discussing the overlap between views: counterparts and dependency. Both are important, not only in determining features of the overlap, but also in presenting such overlap to the participants. These notions were chosen because they are general enough to apply to requirements in many views. They are explained further below. This thesis will not deal with other kinds of overlap, although several may be useful. See the Conclusion (Chapter 10) for some discussion on this point. In order to establish commonality between views, we must first acquire knowledge from the respective participants as to the importance of the objects in their requirements specifications. We begin by determining which elements of their requirements refer to currently existing “real-world” objects. Schank referred to Picture Producer (PP) concepts that cause mental pictures to form in our minds [Schank75]. These are reasonable points of departure, since multiple participants can actually “point” to these in the real world; however, participants may focus on different features of those pictures within their views. A participant may well have opinions as to which elements are common between his view and others, perhaps stated outright, perhaps expressed as assumptions about what already exists before the system is built. In either case, a pre-selected common element may be treated as a “seed” with which to start analyzing the overlap between multiple views.
Counterparts Our fundamental correspondence between objects in different views is the notion of a counterpart. A counterpart is a set of two or more objects each from a distinct view specification that represent the same object in the proposed system. Although participants may be able to offer suggestions as to appropriate counterparts, we can also attempt to identify them using automated analysis procedures (as shown below). A naive approach is to find PPs in two views that each have the same name. Unfortunately, the names given to individuals in two different views are not particularly helpful. Two individuals with the same name do not necessarily refer to the same object. For example, to a nurse monitor means a single analog device attached to a patient, while to a designer monitor means a controller that polls several analog devices. Lacking such prior knowledge, we might believe that the two refer to the same thing. Moreover, two PPs with different names may be the same, e.g., the nurse’s monitor is the same as the designer’s sensor. We need other ways of determining counterparts. It is possible that other heuristic rules might assist us in finding counterparts, such as the following. (Some of these are clearly more fruitful than others.) C and D may be counterparts to each other, if C in one view has the most number of relationships in the view, while D in another view has the most number of relationships in its view. If one view contains an unspecified instance of a class, and another view contains a particular instance of the same class, then the two instances may be counterparts to each other. D and C may be counterparts to each other, if C is the input to a process P in two views, and D is the input to a process Q in two views. C and D may be counterparts to each other if participants have identified C in one view as an already-existing object and D in another view is identified as the same already-existing object. Participants have intuitively decided that two objects are counterparts to each other. We do not assert that counterparts are identical. Just because two elements serve a similar role in two views does not make them the same in every respect. Much of this thesis will be concerned with determining what assertions and inferences can be made regarding counterparts. The next section discusses a related notion, that of dependency between counterparts. Both notions will be used below to form a model for measuring the overlap between views. Ch. 3 34
Dependency Earlier we said that participants benefit from knowing what information in their view is depended upon by elements that are common among views. Once counterparts are known, we can examine the dependency among them to help determine consistency between views. The notion of dependency as used here is as follows: If concept F is dependent upon concept E, then the existence of F implies the prior and necessary existence of E. We denote this as E F. For example, if E and F are persons, and E is the parent of F, we can say that F cannot exist without the prior existence of E. When comparing this to another dependency (e.g., we may find elsewhere that F depends upon E), certain conflicts can be identified. Dependencies already exist between elements of a single view even before we account for multiple views. Although some views may be expressed in a language that explicitly captures dependency, a human analyst may have to provide such information. Some dependency rules are: If A is a process, then A’s output depends upon A’s input. In an entity-relationship model, an instance of an attribute depends upon the entity possessing it.
3.2.2. Kinds Of Associations In order to identify a counterpart, it is necessary to decide that two things in different views have the same meaning. What is the basis for their meaning? Objects acquire meaning by their relationships to other objects in their respective views. If each view consisted of a collection of unrelated objects, it would be impossible to determine counterparts between the views unless a human makes a decision based on intuition; no other information is available with which to validate such a choice. We therefore must begin the analysis of multiple views by focusing on relationships between objects within their own view. We adopt the following notational conventions in the following discussion. An object in a view will be shown by an upper case letter. A counterpart pair will be shown as (C; D), meaning that C is counterpart to D, where C and D are called components of the counterpart. A relationship will be shown by ri(C D) meaning that there exists a relationship named ri between C and D, and further that D depends on C. The objects’ order denotes their mutual dependency; i.e., r(C D) is not the same as r(D C). A symmetric relationship is shown by a two-headed arrow: r(C D) means that C is related to D but neither is dependent on the other. In using the word relationship in the above discussion, we do not wish to imply a direct connection to any particular specification language (e.g., entity-relationship diagrams) that happens to have some component called a “relation” in it. A relationship might be a relation in an entity-relationship diagram, a process in a data-flow diagram, a transition in a state transition diagram, and so on. Each of these constitutes a relationship between two objects for the purposes of discussing their dependency (see below). In Chapter 4, when we tie our framework to conceptual graphs, we will provide a detailed definition. There are four distinct kinds of associations possible between two counterpart pairs, based on the agreement of the relationships between their respective components. These associations are shown in Figure 3.4 with respect to object C in view P and object H in view Q being considered the counterpart pair (C; H). In order to identify counterpart pairs between views P and Q, we are therefore interested in those pairs of objects in views P and Q which bear a similar relationship to C and H in their respective views. Ch. 3 35
view P strongly inconsistent view Q associated pair
conflicting common relation D J E strongly consistent I associated pair r r j agreeing common j ri relation ri
C counterpart pair H being considered r r m l commonly dependent r relation r k n F weakly consistent L associated pair G K counter dependent relation
weakly inconsistent associated pair
Figure 3.4. Kinds Of Counterparts.
We will discuss two degrees of association between counterpart pairs. One is a strong association where the relationships are the same, shown as common relations. The other is a weak association where the relationships are different, shown as dependent relations. In both cases, the association may either be consistent (relation and dependency agrees) or inconsistent (relation or dependency disagrees). All four associations will be described with respect to (C; H) in Figure 3.4. Before discussing the various kinds of association, we should point out that an arbitrary counterpart pair may not be associated with every other counterpart pair. Consider the arbitrary counterpart pair (E; L): it is only associated with a pair (i; j) if E is related in some way to i while L is related in some way to j. Since E is related only to C, and L is related only to H, the only possible association for the pair (E; L) is with the pair (C; H). We point this out to remind the reader that not all possible associations in Figure 3.4 are discussed here (e.g., (C; H) and (D; F)); we are just introducing the four basic types.
Consider the potential counterpart pair (E; I) with respect to (C; H). Since the relation ri(C E) is in view P, and relation ri(H I) is in view Q, we have an agreeing common relation, giving (E; I) a strongly consistent association with (C; H). Contrast these with the relationships of the counterpart pair (D; J). Although both D and J are related to the pair (C; H) through a common relation ri, the relations are in opposite directions (a conflicting common relation), giving (D; J) a strongly inconsistent association with (C; H). The two situations above involve objects associated by a common relation. We can also consider situations where objects are related by different relations; in these cases, we only have information about the relations’ dependency. The dependency may either agree or disagree.
Consider the potential counterpart pair of (F; L) with respect to (C; H). There is a relation rl(F C) in one view, and a different relation rm(L H) in the other, where the relations’ dependencies agree. We call this an occurrence of commonly dependent relation. Even though the relations themselves are different, the very fact that C depends on F while H depends on L gives us some evidence in favor of (F; L) as a counterpart. We therefore see that (F; L) has a weakly consistent association with (C; H). Ch. 3 36
The potential counterpart pair (G; K) illustrates the case where different relations have opposite dependency. Considering rk(G C) and rn(H K), not only are the relations different, but their dependencies are in opposite directions. This counter-dependent relation leads us to conclude that (G; K) has a weakly inconsistent association with (C; H). These examples consider cases where exactly one kind of association holds between each pair of counterpart pairs. In larger examples below, however, more than one kind of association may hold if there is more than one relationship between the two counterpart pairs’ components. In that case, it does not make sense to attach one particular kind of (in)consistency to the association. We will analyze such combinations using relative weights for each relationship. We have now identified four different ways that counterpart pairs may be associated: strongly consistent, strongly inconsistent, weakly consistent, and weakly inconsistent. The degree of compatibility between pairs will be measured by attaching some relative weight to each association. We will attach a larger weight to strong associations than weaker ones, making consistent weights positive and inconsistent weights negative. Associations will be evaluated in the order just given: all strongly consistent associations first, followed by all strongly inconsistent associations. Once these are identified, only weak associations possibly remain. The next section shows some brief illustrations; Chapter 4 shows a more complicated example, while Chapter 6 shows an actual set of requirements.
3.2.3. Association Graph Technique This section proposes a formal model for determining counterpart pairs. We need not assume here any “seed” counterpart pairs or any other manually-supplied information. We assume here only that each view can be somehow expressed as a directed graph of objects and relationships. Chapter 5 supports this assumption. This technique is based on the idea of an association graph. Such graphs have been used to match visual scenes as graphs in image processing [Chipman90]; we have adapted them here for use in matching mental “scenes”. The basic principle is this: first assume that every possible pairing of objects in two views might be a counterpart pair, and then examine the relationships between each pair and all other possible pairs to measure the evidence that supports or refutes the counterpart. We illustrate this idea using two views as directed graphs. The technique is to create an association graph based on the two views, where each node of the association graph consists of a counterpart pair (I; J), with I in one view, and J in the other. We then draw non-directed arcs between every node of the association graph, where each arc represents any associations between the two counterpart pairs. For example, the arc from (I; J) to (H; K) represents the consistency of all relations between I and H with respect to the relations between J and K. If there are no relations at all, either between I and H or between J and K, then no arc is drawn. We call this a 2nd-order association graph, because each node has two components. Starting with the two (admittedly pedagogic) views in Figure 3.4, the resulting association graph is shown in Figure 3.5: Ch. 3 37
G; I G; H F; L F; K G; J F; J G; K F; I
G; L F; H
E; L C; I
C; J C; H E; K
E; J C; K
C; L E; I
E; H D; H D; I D; J D; K D; L
Figure 3.5. Association Graph.
In applying the association graph technique, we assign relative weights to each association node and arc, then find each node’s “best” association with respect to all of its connected nodes. Initial node weights are based on the similarity of the counterpart pair’s members, using local attribute information. Since the present discussion deals only with arbitrary nodes, all nodes will be assumed to have the same arbitrary initial weight. This initial weight will be adjusted during analysis by the association graph technique. For each arc between association nodes (i; j) and (h; k), we pair-wise examine every relation between i and h in the original view P, and between j and k in the original view Q. Once assigned, the arc’s weight is not changed; only nodes’ weights are altered. For each node pair, we determine which of the four associations (see above) are present. The table in Figure 3.6(a) shows the results of this simple analysis on the association graph in Figure 3.5. The symbols are as follows: d+ one commonly dependent relation. d- one counter dependent relation. r+ one agreeing common relation. r- one conflicting common relation. The table in Figure 3.6(a) summarizes the results of analyzing each association arc. For example, the entry “Arc(C; H) to (D; I) d+” indicates that there is one commonly dependent relation between C and D (namely, rj) in view P, and between H and I (namely, ri) in view Q. The entry “Arc(C; H) to (D; J) r–” indicates that there is a conflicting common relation (rj) between C and D in view P and between H and J in view Q. If there were more than one relation between any two individuals, entries in Figure 3.6(a) would have a symbol for each relation. Once the initial arc determinations are made, new node weights are determined in iterative fashion to identify only the strongest possible associations as follows. For each node (i; j) we seek its strongest associations to all other compatible association nodes. That is, for all x such that (h; x) is connected to (i; j), we find the maximum product of the arc and the weight of (h; x). Such a maximum product represents the strongest association of all the nodes containing h with respect to (i; j). In evaluating the maximum, the absolute values of weights are used, so that it is possible for an inconsistency to be the strongest weight. Ch. 3 38
The next step is to gather all such maximum products (i.e., over all h’s) in order to measure (i; j)’s compatibility with respect to all its other associated nodes. We could calculate a node’s weight by summing up its strongest associations. Doing so, however, would tend to favor association nodes with many arcs, which does not necessarily represent the best association. For instance some original nodes may in fact be strongly associated, yet have few relations. A simple sum would “penalize” such a node, even though it might reasonably belong in the strongest sub-graph. We therefore take the average of these products, rather than their sum, in order to ensure that a large number of weak associations does not not outweigh a small number of strong associations.
Arc(C; H) to (D; I) d+ Arc(C; H) to (F; L) d+ Arc(C; J) to (F; H) d– Arc(C; H) to (D; J) r– Arc(C; H) to (G; I) d– Arc(C; J) to (G; H) d– Arc(C; H) to (D; K) d+ Arc(C; H) to (G; J) d+ Arc(C; K) to (D; H) d– Arc(C; H) to (D; L) d– Arc(C; H) to (G; K) d– Arc(C; K) to (E; H) d– Arc(C; H) to (E; I) r+ Arc(C; H) to (G; L) d+ Arc(C; K) to (F; H) d+ Arc(C; H) to (E; J) d– Arc(C; I) to (D; H) d– Arc(C; K) to (G; H) d+ Arc(C; H) to (E; K) d+ Arc(C; I) to (E; H) r– Arc(C; L) to (D; H) d+ Arc(C; H) to (E; L) d– Arc(C; I) to (F; H) d+ Arc(C; L) to (E; H) d+ Arc(C; H) to (F; I) d– Arc(C; I) to (G; H) d+ Arc(C; L) to (F; H) d– Arc(C; H) to (F; J) d+ Arc(C; J) to (D; H) r+ Arc(C; L) to (G; H) d– Arc(C; H) to (F; K) d– Arc(C; J) to (E; H) d+
(a)
Node (C; H) ((max( d+ r– d+ d- ) + Node (E; J) d– (max( r+ d- d+ d- ) + Node (E; K) d+ (max( d- d+ d- d+ ) + Node (E; L) d– (max( d- d+ d- d+ )) /4 Node (F; H) (d+ d- d+ d-) / 4 Node (C; I) (d- r- d+ d+) / 4 Node (F; I) d– Node (C; J) (r+ d+ d- d-) / 4 Node (F; J) d+ Node (C; K) (d- d- d+ d+) / 4 Node (F; K) d– Node (C; L) (d+ d+ d– d–) / 4 Node (F; L) d+ Node (D; H) d- r+ d- d+ Node (G; H) (d+ d- d+ d-) / 4 Node (D; I) d+ Node (G; I) d– Node (D; J) r– Node (G; J) d+ Node (D; K) d+ Node (G; K) d– Node (D; L) d– Node (G; L) d+ Node (E; H) (r- d+ d– d+) / 4 Node (E; I) r+
(b)
Figure 3.6. Association Graph Nodes After One Iteration.
Evaluation of an arc from (i; j) to (h; k) affects two things: first, our evidence that (i; j) is a counterpart pair, and second, our evidence that (h; k) is a counterpart pair based on (i; j) being a counterpart pair. For every pair (i; j) we find the strongest association to (h; k) for all k’s representing the most likely counterparts involving h with respect to (i; j) to get the total measure of its “counterpart-ness”. Averaging all maximum products for each node, we get the table in Figure 3.6(b). For example, node (C; I) with the symbols “(d- r- d+ d+)/4” was obtained Ch. 3 39 from all entries in Figure 3.6(a) that involve (C; I) — in this case, the arcs to (D; H), (E; H), (F; H), and (G; H). Since there is only one arc for each of D, E, F, and G, the maximum consists of the entry itself This example illustrates why averaging the products is a reasonable thing to do. Just because (E; I) happens to have few relations, it does not necessarily deserve a lower weight than (C; I) — in fact, (E; I) has only a strongly consistent association, so it may represent a stronger node than (C; I) which happens to have more relations. To measure the overall strength of a counterpart pair, we assign numeric weights to the various kinds of relations shown above, and multiply by the node weight. It is clear that strong consistency should add greater weight than weak consistency; likewise strong inconsistency should subtract greater weight than does weak inconsistency. Once new node values are obtained, the process repeats with the same arc weights until the node weights level off. Since it is possible that the node weights may not converge, we terminate the process after some large number of iterations. Further details are shown in the next chapter. The weak association weights pose somewhat of a problem. The presence of relations with like dependency lends some evidence that the two nodes represent actual counterpart pairs; the question is: just how much weight should it be assigned? Likewise the presence of relations with conflicting dependency is evidence that if both pairs are counterparts, then the two views are inconsistent. We could simply assign some small weight to both kinds of dependency, with one positive and the other negative. The strengths of association are shown on a number line as: Ch. 3 40
strongly weakly weakly strongly inconsistent uninteresting consistent negative <———————————————0———————————————> positive
The problem with this approach is that the presence of several commonly-dependent relations may be just a coincidence that leads us into assuming counterpart pairs that are incorrect. On the other hand, the weakly inconsistent dependencies may also lead us to erroneously conclude that actual inconsistency exists. One can argue that either policy is unsound; however, since we seek to identify both inconsistency and consistency, we may adopt one policy, and then the other and observe the results. To identify consistency, we will assign weak (small) positive values to weakly-consistent relations, while assigning even smaller (slightly negative) values to weakly inconsistent ones. Even though this may cause us to overlook some reasonable counterpart pairs, we are better off than if we erroneously determine that an inconsistent counterpart pair is consistent. We will show some actual weights in the next examples. Because the views in Figure 3.4 are quite simple, there is only one relation between any two objects. In general, there may be any number of relations; we assume only that the number is small relative to the total number of object pairings. Still in the worst case, if Ni is the number of objects in view i, the number of 2 association arcs between views P and Q is O(NP*NQ) . (We address computational issues in §3.3 and in later chapters.) The technique of matching views as graphs differs from visual scene matching in two important ways. First, scene matching tries to match a sought-after object’s pattern graph with a graph of some scene being considered, and second, scene matching seeks a matching between only two graphs. The first factor means that incompleteness is decidable relative to the sought-after object’s pattern. The second factor means that an association graph only needs to compare two graphs. Since we may have more than two views, and since no view is considered the “true” view, we must adapt the association graph approach to accommodate more than two graphs. Our approach is to adopt a divide-and-conquer strategy that reduces the number of views one by one as follows: Given M views, for each pair of views, we construct a 2nd-order association graph, and select the best association subgraph (maximal clique) for that view pair. From the set of M (M – 1) / 2 best subgraphs (one for each pair of M views), we choose the best subgraph B. This best subgraph represents the strongest overlap between any two views; we assume that such a subgraph will be contained in whatever strongest overlap is eventually determined for the set of M views. If B is formed from the pair of views P and Q, then we remove views P and Q from the set of M views for the duration of this association and replace them with the subgraph B, calling it view [P, Q]. We thus have reduced the number of views to M – 1. Our rationale for this substitution is presuming that the strongest M-order sub-graph will contain components from nodes in the strongest 2nd-order sub-graph. Even if a counterpart pair has a high weight, in order to become part of an M-order counterpart set, its components also have to be part of other high- weighted counterpart pairs. It is certainly possible that an extremely high-weighted counterpart pair (I; J) between one pair of views might not be included because other counterpart sets containing I and J have extremely low weights. In that case, it is reasonable that the pair not be available in the rest of the association. We continue the process until we reach the last two views’ best subgraph, which represents the accumulated best overlap between the original M views. We now use two simple 3-graph illustrations of the higher-order association graph, and assign actual numbers to the arcs. We will use the graphs of Figure 3.7. The nodes are numbered for convenience. Ch. 3 41
v1 v2 v3 [v1,v2] v3
1 4 7 1,4 7
r r r r r r
2 5 8 2,5 8
s s s s
3 6 3,6
(a) (b) Figure 3.7. Sample Graphs. The association graph for Figure 3.7(a) is shown in Figure 3.8.
5; 8 5; 7 4; 8 6; 7 4; 7 6; 8 3; 8 1; 4 3; 7 1; 5
3; 6 1; 6 3; 5 1; 7
1; 8 3; 4
2; 4 2; 8 r+ r- 2; 5 2; 7 d+ 2; 6 d- Figure 3.8. Association Arcs For Sample Graph. We adopted the following heuristic weights for the association graph, to reflect our intuition that an agreeing relation is an order of magnitude stronger than mere dependency agreement. It is only the relative size of these weights that matters. r+ = +12.0; r- = -12.0; d+ = 3.0; d- = -1.5; The tables in Figure 3.9(a) and (b) summarize the relevant node weights for the graphs in Figure 3.7(a), sorted in order of their strength (either positive or negative). Figure 3.9(a) shows the 2nd-order results; based on them we can decide the strongest overlap is between views v1 and v2. The strongest association sub-graph, shown as [v1,v2] in Figure 3.7(b), is then associated with view v3 to get the strongest overlap between the three views. The results of the higher-order association are shown in Figure 3.9(b). Ch. 3 42
2nd-order node Weights Node(1; 4) = 123.928 Node(2; 8) = 48.288 Node(3; 4) = -13.281 Node(2; 5) = 123.928 Node(5; 8) = 48.288 Node(2; 4) = -13.543 Node(3; 6) = 123.928 Node(2; 7) = -26.841 Node(2; 6) = -13.543 Node(1; 7) = 95.844 Node(5; 7) = -26.841 Node(1; 5) = 12.282 Node(4; 7) = 95.844 Node(3; 8) = 25.986 Node(3; 5) = 12.282 Node(1; 8) = -93.425 Node(6; 8) = 25.986 Node(3; 7) = -9.613 Node(4; 8) = -93.425 Node(1; 6) = -13.281 Node(6; 7) = -9.613 Strongest 2nd-order association sub-graphs Views v1 and v2 Views v1 and v3 Views v2 and v3 Node(1; 4) = 123.928 Node(1; 7) = 95.844 Node(4; 7) = 95.844 Node(2; 5) = 123.928 Node(2; 8) = 48.288 Node(5; 8) = 48.288 Node(3; 6) = 123.928 Total 371.785 Total 144.133 Total 144.133 (a)
3rd-order node Weights Node(7; [1,4]) = 137.410 Node(8; [2,5]) = 137.410 Node(7; [2,5]) = 118.538 Node(8; [1,4]) = -31.294 Node(7; [3,6]) = -14.061 Node(8; [3,6]) = 11.285 Strongest 3rd-order association sub-graph Views [v1,v2] and v3 Node(1; 4; 7) = 137.410 Node(2; 5; 8) = 137.410 (b)
Figure 3.9. Association Weights For Sample Graph. Views v1 and v3 have only two nodes in their strongest 2nd-order sub-graph because the next strongest nodes (3;8) and (2;7) are not compatible with the stronger two already shown. Node 8 cannot be counterpart to both node 2 and node 3, etc. Note that the counterparts (1; 4; 7) and (2; 5; 8) have the highest weight (137.410); they show the strongest association between all three graphs. Furthermore, since none of their components overlap, the two nodes can be made part of the analyst’s graph; they present no ambiguity. The next-highest positive node (2;5;7) has a lesser weight (118.538) indicating that either (a) it is less likely to be a counterpart or (b) individual 8 in view v3 is a combination of both (2; 5) and (3; 6) in their respective views. The negative weights show counterpart pairs whose assertion would cause contradictions. Since the strongest nodes are positive, we can conclude that there is some consistent overlap between the three views. In order to relate any two views, the analyst may provide a starting point — a “seed”. This starting point represents some common object in both views. If one view contains an object that bears certain relationships (in kind and number) to other objects in its view, and another view contains an object bearing the same relationships Ch. 3 43
(in both kind and number) in the other view, then the pair of objects forms a seed. If no such seeds exist, then the analyst may manually choose an initial counterpart between every pair of views, either by intuition or by an initial application of the association graph technique (see below). If participants can identify “seed” counterparts prior to analysis, then the association graph can be simplified. That is, if participants can agree that some object in one view does, in fact, represent the same real- world object as some object in another view, then that agreement can be incorporated into analysis to reduce the work required. For example, if the participants in the views of Figure 3.4 decided that (C; H) was a seed counterpart pair, we can remove all association graph nodes and arcs which represent the possibility of C or H being counterpart to any others, i.e., any other nodes containing C or H along with their associated arcs. The association graph in Figure 3.5 would then be reduced to the graph in Figure 3.10:
G; I F; L F ; K G; J F; J G; K F; I
G; L
E; L
C; H E; K
E; J
E; I
D; I D; J D; K D; L
Figure 3.10. Association Graph After Choosing A Seed Counterpart.
The above illustrations are limited in their scope. We did not employ any semantic knowledge of the views, nor did we attempt to accommodate any of their underlying assumptions. We merely operated on their structural components. Our purpose here is just to introduce the association graph approach and explain its general features. The next chapter refines the techniques by making use of a view’s semantics, as well as its additional underlying assumptions, resulting not only in a richer set of weights for determining counterpart pairs overlap, but also a reduction in the number of possible association graph nodes.
3.3. General Issues For Multiple Views This section discusses some general issues raised by the multiple viewed approach. These issues do not depend on features of the analyst’s meta-language that is discussed in the next chapter. We briefly discuss granularity (level of detail) considerations. Representing overlap involves two problems: first, how should we express it, and second, what does it really mean? Finally, we must be aware of the additional cost and effort needed to use multiple views. These questions are discussed briefly below.
Computational Complexity For two views P and Q, if there are NP objects in view P and NQ objects in view Q then there will be NP*NQ nodes in the resulting association graph. In the worst case, if every object in a view were related to every Ch. 3 44 other object in the view, there would be an association arc between every pair of association nodes, or (NP*NQ ) * (NP*NQ – 1) / 2. We assume, however, that the average degree in each view is small compared to the N’s. This is because in our experience with graphical specification methods, we rarely see diagrams where every node is connected to every other node. To consider the general case of M views, we assume each has the same number of nodes N and an average degree per node of d, i.e., average number of other nodes to which a single node is related). We have already assumed that d << N in a given graph. To construct an L-order association graph, we must have L original vertices M L in each association graph node. We may therefore have to deal with possibly as many as NL nodes and (M – L) ! M L dL NL arcs. Fortunately, we are interested in the case where M = L, so that the maximum number of arcs (M – L) ! to consider is actually dL NL. For more than two views, our computational complexity rapidly increases. The next chapter shows how applying a view’s meaning reduces the number of possible counterparts so that the complexity can be reduced. We discuss this issue further in Chapters 9 and 10.
Identifying Incompleteness This problem is probably the most difficult to address. Incompleteness of a view means that it lacks something — either in its own view (an omission by some participant) or in some other view. By including multiple views, we are acknowledging the incompleteness of any one view with respect to the complete requirements. Two incompleteness rules are: If part of a pre-existing assumption is present in some requirement, we can insert the remaining parts of the assumption that are not present. If one member of a strongly-consistent counterpart pair has additional relations that are not present with the other member of the pair, the additional relations may be missing from the other member’s view. If a counterpart is found spanning all but one view, we may seek to add some object to the remaining view that was omitted.
Granularity of Multiple Requirements Specifications An important limitation of the outline approach is our restriction to identifying only one-to-one counterparts. When dealing with multiple requirements specifications, we must acknowledge the possibility that two participants may view a system with quite different levels of detail. For example, a customer may view a database as a single entity — a “black box” — whereas a database designer may create much more detail concerning its internal structure and functions. Establishing any kind of correspondence under such circumstances may be difficult, both computationally and conceptually. In our association graph, we did not consider arcs between the counterpart pairs that indicate an object is a counterpart to itself. For example, what is the meaning of the association arc between (C; H) and (C; I)? Such an association is possible if there are relations (such as a state’s transition back to itself) that go from C to C. If strongly consistent associations are found, this might indicate that C is a counterpart to the cluster of H and I. This issue must be studied further. After we have proposed a formal notation for expressing multiple requirements, we may be better able to address this problem, but only in a pragmatic way. We can arbitrarily limit the size of possible sub-graph counterparts to some small integer m. For a single object in one participant’s requirements, it may be possible to seek out groups of m or fewer objects in another’s requirements such that the one object corresponds to the group of m. For example, consider the following views P and Q where m = 5: Ch. 3 45
P Q
In order to preserve tractability, it will be necessary to restrict the size of m. At present, we have no basis for deciding what is a “good” maximum size of a corresponding group; our choice would be based merely on practical or heuristic considerations in order to reduce complexity. Of course, the problem of an n-object group corresponding to an m-object group is even harder.
Cost Effectiveness Any additional techniques must cost something. The methods shown herein are simple and straightforward, suggesting that they are inexpensive to undertake. Because requirements mistakes are so costly over the lifetime of a software project, eliminating even some mistakes at early stages provides much leverage in substantially reducing re-working costs later. Even so, more accurate estimates of such savings are desirable in order to better understand the role of multiple views in reducing software costs. Chapters 7 and 8 discuss the cost issue more fully, and outline a practical evaluation procedure to measure the cost-to-benefit ratio of this technique. It should be pointed out that in certain critical systems, cost is no consideration. To avoid potentially life- threatening software errors, we are willing to spend whatever time and effort is needed to eliminate them from our requirements, but only if we know how.
3.4. Summary We described the kinds of overlap that can be determined between disparate views by considering the characteristics of a counterpart (common element) and its dependency (relationships). Details of a framework for multiple views were explained, introducing such notions as strong and weak consistency. The association graph technique was used to attach numbers to these notions. Some issues and limitations of multiple views were briefly discussed. We adopted several heuristics to facilitate the technique. We assumed that counterparts exist in a one-to-one correspondence. We assumed a set of weights to favor matching relations over merely matching dependency. We chose a threshold weight to serve as a lower bound between “interesting” strengths and “dull” ones. We assumed that the degree of a view’s graph is small relative to its number of nodes. Much of the process described above will depend upon having an appropriate meta-language in which to capture several different sets of requirements and their underlying assumptions. This chapter was intentionally presented without regard to any particular meta-language — we simply described how we would use such a meta- language. The next chapter explains why we chose the notation of conceptual graphs to serve as the analyst’s meta-language for the remainder of this thesis. The next chapter uses conceptual graphs as the meta-language for a multiple-viewed framework. We will use the terminology introduced informally in this chapter to define a methodology with which to analyze multiple viewed requirements. Ch. 4 46
4. A Framework and Methodology For Multiple-Viewed Analysis
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View A Participant’s Requirements Specification A Participant’s Pre-Existing Assumptions 2.2. Example Requirements and Assumptions Sample Participants 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst Requirements Analyst’s Tools Requirements Analyst’s Process 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views Counterparts Dependency 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap Ch. 4 47
4.4.2. Analyzing Overlap Association Graph 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram An Entity-Relationship R-Spec An Entity-Relationship R-Spec-Graph 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram A Data Flow R-Spec A Data Flow R-Spec-Graph 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram A State Transition Diagram R-Spec A State Transition Diagram R-Spec-Graph 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network A Requirements Network R-Spec A Requirements Network R-Spec-Graph 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Discussion After First Association 6.2. Analysis: Second Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. 6.3. Analysis: Third Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and repeat step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. In this example, we will use English as our description. 6.4. Results of Analysis Counterparts in Patient-Monitoring Assumptions in Patient-Monitoring Inconsistencies in Patient-Monitoring Ch. 4 48
Incompleteness in Patient-Monitoring 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics Counterparts Participant Assumptions Inconsistencies/Ambiguities 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model Relative Cost of Requirements Errors Proportion of Errors Identified By Multiple Views Multiple Views’ Cost 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap Comparison To Empirically Determined Overlap Ex Post Facto Judgments 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings Conceptual Graphs Utility Overlap Characteristics 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach Limitations of Conceptual Graphs Limited Support Over Life Cycle Granularity Limitations 9.5. Summary 10. Conclusion 10.1. Summary of Thesis Methodology For Identifying Multiple Viewed Requirements Requirements Analyst’s Framework and Knowledge Base Participants’ Requirements In Conceptual Graphs Participants’ Assumptions As Conceptual Graphs Determination of Overlap Between Views 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework Non-Functional Requirements Re-Use Of Assumptions 10.3. Speculation Potential for Simulating Requirements Ch. 4 49
Automated Acquisition of Assumptions Convergence of Views 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.1.1. Nodes and Links Concept Relation Actor A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules Copy Restrict Join Simplify A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations Display Form Linear Form Paraphrase Form Transformations Among Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.1.1...... Compilation Algorithm 1a B.1.2...... Extraction Algorithm 1b B.2. Data Flow Translation Scheme B.2.1...... Compilation Algorithm 2a B.2.2...... Extraction Algorithm 2b B.3. State Transition Translation Scheme B.3.1...... Compilation Algorithm 3a B.3.2...... Extraction Algorithm 3b B.4. Requirements Network Translation Scheme B.4.1...... Compilation Algorithm 4a B.4.2...... Extraction Algorithm 4b B.5. Summary References
Order and simplification are the first steps toward mastery of a subject — the actual enemy is the unknown.
Thomas Mann, The Magic Mountain, 1924 Ch. 4 50
This chapter provides a formal framework and methodology for an approach based on multiple views. We have already shown in Chapter 2 that most requirements methods are based upon a limited set of conceptual views, imposing an inherent limit on their range of applicability. In Chapter 3, we gave a general framework for accommodating multiple views of requirements, referring only to an unspecified analyst’s meta-language to assist us. This chapter will show how the framework in Chapter 3 is applied using the notation of conceptual graphs [Sowa84] summarized in Appendix A. Readers unfamiliar with conceptual graphs are encouraged to look there before continuing.
4.1. Conceptual Graphs: An Analyst’s Meta-Language We have made frequent mention of an unspecified meta-language for the analyst to use in determining the overlap between multiple viewed requirements. Because views are associated with people, we have chosen conceptual graphs [Sowa84] — a notation that is based on human cognitive structures, rather than the formally designed structures (e.g., state transition diagrams) used in some conventional requirements techniques. As we will emphasize often throughout this thesis, current techniques are still useful in their own right; our purpose in combining them through multiple views is to examine overlapping requirements once they have been identified. Conceptual graph notation is merely a convenient vehicle for examining the overlap. Some previous work in software engineering has made use of conceptual graphs as an appropriate knowledge representation. Ameen [Ameen89] used conceptual graphs to model software module information for re-use. Muehlbacher [Muehlbacher90] used conceptual graphs to capture several system analysis notations. This section outlines the major characteristics needed for the analyst’s meta-language, and shows how conceptual graphs possess those desired characteristics.
General Applicability By definition, views of a target system may vary widely. Participants may be interested in quite different aspects of the target system. A method that attempts to capture several views should have the capability to express a wide range of characteristics. Ideally, we would like to be able to capture any knowledge which a person can conceive, imagine, or express. Conceptual graphs can represent much of the knowledge expressible by natural language (in itself a powerful way of expressing knowledge). We do not claim that conceptual graphs can express all possible requirements views, only that they express a broad range of them, as illustrated in Chapter 5.
Psycho-linguistic Basis Actual requirements originate in the needs of people and organizations; the expressed requirements therefore reflect mental processes that we cannot (yet) formally describe. A requirements representation should therefore handle cognitive structures. Conceptual graphs (a natural outgrowth of work in semantic networks) help bridge the gap between known psychological and linguistic principles on the one hand and known mathematical methods on the other, so that we can begin to formally record and manipulate cognitive structures. Unfortunately, there is much we do not know about actual mental operations and structures. As a result, the notation of conceptual graphs (or any other representation, no matter how “good”) remain inherently limited in its usefulness. We do not claim that conceptual graphs represent the actual internal structure of the “mind” (however it be defined), nor that conceptual graphs can represent all knowledge (e.g., the concepts of JUSTICE and MERCY). We claim only that they form a model with which we can reason about cognitive structures on a more general level than most current representations.
Logical Basis As discussed in §A.2, a conceptual graph forms an assertion or proposition in quantificational first-order logic. Assertion of a conceptual graph implies that there exist concepts and relations satisfying the graph’s constraints (see Appendix A, §A.2). First-order logic has been studied extensively and its utility for the design and analysis of computer systems is well-known. The relationship between conceptual graphs and logic is discussed in Appendix A. Ch. 4 51
Requirements themselves often contain ideas that cannot be expressed by first-order logic. A requirement itself is a need — anything deemed necessary by a participant. Other requirements may include possible occurrences, or rules that change over time (non-monotonic logic). Others have noted the limitations of first-order- logic for expressing semantic knowledge (e.g., Roman90). Although a conceptual graph can express these non- standard logics, its capacity for analyzing them is somewhat limited. In order to extend conceptual graphs to these forms of logic, such as temporal or dynamic logic, a new kind of node (demon) is introduced in §A.3.2 in Appendix A.
Analytical Basis We want to examine views in order to determine their correctness and appropriateness. A conceptual graph serves as a model of some mental conceptual structures. One measure of its usefulness is how well it captures requirements knowledge. Another important measure is whether or not we can manipulate the graphs so that new graphs are consistent with the original one. In particular, we must be able to capture relations between concepts to determine counterparts and to capture dependency between concepts for determining dependency. Well-defined transformation rules (e.g., specialization and join), ensure that properties of a conceptual graph are preserved when forming new graphs. Rules operating upon graphs should reflect mental operations on the actual concepts represented by the graphs, such as abstraction, generalization, specialization, instantiation, etc. One important rule (join) allows us to combine two graphs by applying each one’s constraints to the other. This feature will be important when we are combining multiple views into a single view.
Decomposition and Aggregation Support Certain well-established principles guide much of our thinking about software engineering. We make much use of the techniques of decomposition (dividing a single unit into sub-units) and aggregation (forming groups of units into a single higher-level structure). Our requirements representation should permit both of these generally useful principles. Conceptual graphs support both of these notions using abstractions and contexts (see Appendix A). A single concept such as PROPOSITION may actually represent an entire conceptual graph. Not all mental notions are decomposable or combinable, however. Elsewhere in this thesis (Chapter 2) we argued that decomposition of requirements is not always a good thing. Since this same caveat applies to conceptual graphs as well, we do not emphasize decomposition over any other analysis technique. Abstractions allow generalization and specialization of conceptual graphs to be governed by the constraints in the body of the abstraction’s definition (see Appendix A).
Multiple Modes of Expression The availability of more than one mode of expression (e.g., pictorial or textual) is desirable in a requirements language for two reasons: (a) the requirements can be made understandable to a wider audience, and (b) redundant representations can help the requirements analyst (and others) manually catch errors and inconsistencies which might otherwise escape notice. A conceptual graph can be expressed in three equivalent forms: a visual representation, a linear (text) representation, and a paraphrase into English. Transformations between the forms are straightforward. Appendix A describes them in more detail. Readers unfamiliar with conceptual graphs are advised to look at the material there before proceeding to the framework’s definition and the methodology.
4.2. Definition Of A View We said in Chapter 3 that a viewpoint includes both a participant’s requirements specification, and the complete set of his underlying implicit assumptions. Since knowing all underlying assumptions is a formidable (impossible?) task, our definition includes only observable or expressed knowledge. First we will define a few of the terms that Chapter 3 introduced informally. This section explains concept types that are fundamental to the development of requirements using conceptual graphs. Some subtypes of PROPOSITION will also be pre-defined, whose sets of conceptual graphs will support the multiple-viewed methodology. Each is shown by a rectangle whose label denotes the domain(s) to Ch. 4 52 which its entire contents belong. Since knowledge may exist in overlapping domains, there may be more than one domain indicated by a label (e.g., VP customer VP designer) meaning that the context comprises the overlap between the customer and designer’s view. We first define the components of a participant’s view, noting special meanings when considering the special view of the analyst. Then additional knowledge used by the analyst is explained, and features of his analysis are defined. Finally we introduce a methodology based on conceptual graphs, and describe the steps for analyzing multiple views under the framework.
4.2.1. Domains
Participant Any piece of requirements information may be treated as originating from a particular participant’s viewpoint.
Definition: A participant in software requirements development is any person or role involved in the identification, implementation or validation of software requirements. The requirements analyst (see §4.2 below) is a special participant who uses additional meta-information about multiple view requirements.
Abbreviation: A participant is denoted by a prefix VP (for “viewer-participant”) followed by the name. Examples: VP P some generic participant VP customer the customer VP analyst the analyst The analyst’s view will include all global information, such as a general catalog, type definitions, etc.
Target System Requirements deal with a particular target system. We assume that participants are trying to develop requirements for at least what they perceive to be the same system. Of course, the system itself is what we are trying to specify requirements for, so the system’s name is an integral part of its specification.
Definition: A target system is the system whose requirements are being developed. Sometimes we will refer to it as a proposed system.
Abbreviation: A target system is denoted by the abbreviation SYS followed by the name of the system. We usually abbreviate the system name as well. Examples are: SYS S some system, used for general rules about systems SYS patient_monitoring the patient-monitoring system SYS pms also the patient-monitoring system SYS all knowledge applicable to any target system SYS pms VP customer customer’s view of the patient-monitoring system For example, in Chapter 6 this work uses a particular target system (a patient-monitoring system) for illustration purposes.
Notation Since participants express requirements in notations with well-defined syntax and semantics, we want to use our knowledge of those notations to enhance the knowledge available during analysis. By “remembering” where a conceptual graph came from, we may use rules later that are based on a particular notation, and we may also extract information from the analyst’s combined graph back into a participant’s chosen notation. Ch. 4 53
Definition: A notation is some representational form that adheres to well-defined formal syntax rules. We further restrict our definition to notations that are used in requirements development, such as entity- relationship diagrams, state transition diagrams, data flow diagrams, the Requirements Specification Language of SREM [Alford77], etc. We exclude natural language or purely hierarchical requirements specifications.
Abbreviation: A notation is denoted by putting LANG in front of a notation name. We will often abbreviate the notation name as well. For example, LANG dataflow_diagram data flow diagram notation LANG dfd data flow diagram notation LANG conceptual_graphs conceptual graph notation (implied if omitted) SYS pms VP customer LANG era customer’s view of the patient-monitoring system using entity- relationship diagrams (era).
Domain
A domain is an identified context of sub-domains wherein a particular graph is applicable. Each of the preceding three definitions covered a single sub-domain of requirements development knowledge.
Definition: A conceptual graph’s domain is identified by specifying one or more of the following: participant, notation, and/or target system.
Usage: When more than one domain is present, they will be given in the order SYS, then VP, then LANG . For example, SYS pms VP customer LANG state-transition diagrams means that the following item (concept, graph, etc.) is considered to be (i) from the customer’s viewpoint, (ii) using state-transition diagrams notation, and (iii) describing (part of) the patient- monitoring system. If omitted, the sub-domains have the following defaults: VP defaults to analyst LANG defaults to conceptual_graphs SYS defaults to all.
4.2.2. Requirements Specification As stated earlier, we use the term requirements to mean those requirements that we are able to capture. A specification comprises a participant’s attempt to describe his target system.
Definition: A requirements specification is a private referent (see Appendix A, §A.3.1) of type R-Spec, a sub-type of PROPOSITION. It contains a participant’s original description of a target system, in whole or in part. A requirements specification expresses some needs that the system is intended to satisfy. These are considered originating requirements. As far as conceptual graphs are concerned, a requirements specification is private, not decomposable or alterable, except by a translation scheme (see below).
Abbreviation: A requirements specification is abbreviated as R-Spec. For example, [_ SYS pms VP enduser LANG std R-Spec _] denotes an enduser’s requirements for a patient-monitoring system using state transition diagrams. Ch. 4 54
4.2.3. Requirements Specification Graph A requirements specification graph is a set of requirements in conceptual graph form. It is not a private referent, but a well-formed set of conceptual graphs. Normally, such a conceptual graph is obtained via a translation scheme from an R-Spec in some originating notation, but this is not strictly necessary for the methodology — a participant may specify requirements using conceptual graphs at the outset.
Definition: A requirements specification graph is a referent of type R-Spec-Graph, a subtype of PROPOSITION. It contains the conceptual graph representing a participant’s R-Spec of a target system. A type hierarchy may be included as part of the graph.
Abbreviation: A requirements specification graph is in a context with a domain for a participant, an originating notation, and a target system. The name of the context is R-Spec-Graph; e.g., [ SYS S VP P LANG notation R-Spec-Graph: * ] . See Chapters 5 and 6 for several examples.
4.2.4. Translation Scheme A translation scheme is an algorithm specifying how any R-Spec in a given notation is to be translated into a set of conceptual graphs containing no less information than the original. For each notation used in expressing requirements, there will be one translation scheme. The algorithm itself is considered an actor’s private algorithm. A translation scheme allows the analyst to quickly obtain conceptual graph representations of requirements, without the need to teach conceptual graphs to each participant.
Definition: A translation scheme is an algorithm that takes as input an R-Spec that is well-formed according to the rules of a given notation, and produces as output an R-Spec-Graph consisting of one or more conceptual graphs with the same sub-domains. The process of producing conceptual graphs from some external representation we will call compilation, using Muehlbacher’s terminology [Muehlbacher90]. We define an actor compile and and actor extract that operate as follows:
extract
VP viewer_A LANG N LANG N SYS S TRANSLATION VP viewer_A R-Spec _SCHEME LANG N SYS S R-Spec-Graph
compile
A translation scheme may also produce a type label hierarchy that is included with the new R-Spec-Graph.
Usage: Example translation schemes are shown in Appendix B. Whenever an R-Spec-Graph has a LANG domain, the use of a translation scheme is implied. In order to (partially) validate the translations, and provide a means for expressing new conceptual graph results in a participant’s originating notation, a reverse algorithm is also given. The translation into conceptual graphs (compilation) is in Algorithm “A”; the reverse algorithm translating a conceptual graph back into the original notation (extraction) is in Algorithm “B”. Ch. 4 55
4.2.5. Assumption Graphs A pre-existing assumption represents any information that underlies a participant’s requirements. During multiple viewed requirements development, the analyst gathers assumptions from participants and manually expresses them in conceptual graphs. Since we take as given that we cannot capture every possible pre-existing assumption, our definition covers only those assumptions that we have expressed in conceptual graphs.
Definition: An assumption graph is a referent of type PROPOSITION or DEFINITION that is associated with any particular domain, excluding the R-Spec-Graph. New type labels may be included with any assumption graph.
Abbreviation: An assumption graph will be called an A-Graph. We will use this term whether the A- Graph is a type definition, a relation definition, an abstraction, or a pre-existing assumption gathered from a participant and supplied by the analyst.
4.2.6. View Although informally a viewpoint includes all pre-existing assumptions, whether explicit or not, our formal definition of view is restricted to those explicit assumptions expressed by conceptual graphs.
Definition: A view is a context containing one participant’s R-Spec-Graph, his originating R-Spec (as a private referent), and zero or more A-Graphs, with associated type hierarchies for each graph.
Usage: “In P’s view” or “from P’s view” means within any component within SYS S VP P, where S is the particular system being discussed. Participant P’s “pure” view is a context labeled simply VP P, which contains knowledge relating just to participant P. We do not attempt to determine what belongs in the “pure” view; any information labeled simply VP P (i.e., SYS all VP) would imply, for example, that there is some universal participant “P” whose knowledge can be considered independent of whatever system or notation is being used. An exception is made for the analyst (see below).
4.3. Analyst’s Framework We have already mentioned a special participant called the requirements analyst (or simply analyst). The analyst uses conceptual graphs as a uniform knowledge representation (meta-language) to capture all views, analyzes them using the framework herein, and then presents the overlap. His job is to coordinate all of requirements development, perform any translations or analysis needed, and report his findings to other participants. He must be familiar with the language and paradigms employed by the others, as well as understanding the rationale and techniques for using multiple views.
4.3.1. Analyst’s Canon The analyst’s canon contains the analyst’s A-Graphs about requirements development. This includes a general catalog of conceptual graphs expressing pre-existing knowledge about requirements development. After this approach is used for several systems’ development, we expect the analyst’s canon to comprise large amounts of knowledge, some of it specific to particular systems, while some will capture “common knowledge” from the natural world.
Definition: The analyst’s canon consists of a set of type label orderings (type hierarchy), and a set of canonical graphs, i.e., relation/type definitions and type abstractions. Each definition may have an associated paraphrase template that tells how to express its knowledge in natural language. Each definition may also have dependency information associated with its components.
Abbreviation: A fact in the analyst’s canon is indicated by VP analyst. Whenever a participant domain is omitted, VP analyst is assumed. Ch. 4 56
4.3.2. Analyst’s Requirements Specification Graph
Definition: The analyst’s R-Spec-Graph is a referent of type R-Spec-Graph, a subtype of PROPOSITION. It is made up of graph components which originate in one or more views. Each component is linked to at least two other views by one or more counterpart relations (see §4.4.1 below).
Abbreviation: The analyst’s R-Spec-Graph is denoted by [ SYS S VP analyst R-Spec-Graph: * ]. This differs from a participant’s R-Spec-Graph in that there is no notation name; the analyst is assumed to use conceptual graphs directly. We refer to the analyst’s view (VP analyst) meaning all information that is available to the analyst. All participants’ views (including R-Specs, R-Spec-Graphs, and A-Graphs), a general catalog of conceptual graphs, and the techniques of the methodology are included. A formal definition will be deferred until the the methodology is introduced.
4.4. Analysis of Multiple Viewed Requirements We use two primitive notions on which to base our analysis of multiple views. This section defines a counterpart relation and dependency. Other primitive notions may likely be added in the future; however, here we restrict ourselves to these two. The following section parallels the discussion in §3.3.1 in the previous chapter, except that now it is specifically tied to the meta-language of conceptual graphs.
4.4.1. Describing Overlap In this work, overlap refers to relationships occurring between components of two or more views. In the previous chapter, two basic overlap characteristics were identified: counterparts and dependencies. This section defines these characteristics in terms of conceptual graphs.
Counterpart Since one’s mental notions are difficult for others to see, the basis for communication between views is to identify those common individuals appearing in more than one view. Our fundamental correspondence between individuals is to consider them as part of a counterpart set.
Definition: A counterpart set is a group of individual or generic concepts in more than one view which represent the same object in the proposed system. In this work, we consider only one-to-one counterparts, where one concept in one view is a counterpart to a single concept in another view. For counterparts between single concepts, we show: VP P SYS S PROPOSITION:
C2 VP analyst SYS S counterpart R-Spec-Graph:
C1 VP Q SYS S PROPOSITION:
C3 Ch. 4 57
In the linear form of conceptual graphs, we write: [ SYS S VP analyst Graph: [C1] ] <— (counterpart) — <— [ SYS S VP P Graph: [C2] ], <— [ SYS S VP Q Graph: [C3] ].
Usage: We write a counterpart set as (C2; C3) denoting that “C2 is counterpart to C3”, meaning either (i) the analyst, using human judgment, asserted that the two represent the same individual, or (ii) the counterpart relation was derived from already-existing counterparts (see below). C2 and C3 are called components of the counterpart.
Definition: A counterpart pair is a pair of concepts (I; J) where concept I appears in one view (either its R- Spec-Graph or an A-Graph) and concept J appears in some other view.
Definition: An M-order counterpart set is a set of concepts (C1, C2, ... CM) where each Ci is in a different view. We may refer to these as higher-order counterparts. A counterpart pair is thus a 2nd-order counterpart. These definitions do not say that components of counterparts are equivalent to each other; there are a limited set of conclusions that we will draw from the existence of a counterpart.
Relationship
Definition: A relationship is a conceptual graph relation, actor or demon.
Definition: A symmetric relation is a relationship with mutual dependency (see below); i.e., where its links are either all incoming or all outgoing links. For example, consider the relation [PERSON] —> (sibling) <— [PERSON].
Definition: A canonical relationship is where the conceptual graph relation, actor or demon appears in a definition as part of the analyst’s canon of pre-existing knowledge. A non-canonical relationship is some other relation, actor or demon that has been used without being defined.
Definition: A common relationship with respect to the potential counterpart pairs (I; H) and (J; K) is a relationship ri such that concepts I and J are in one graph, concepts H and K are in another graph and there is a relationship ri between I and J and a relationship ri between H and K.
Dependency A dependency between concepts exists when there is a concept whose existence or meaning is dependent upon another concept in the same view. A dependency is shown by the direction of arrows in a conceptual graph’s relation, actor, or demon, where the existence or meaning of one concept is dependent on the prior existence of another. Definitions and abstractions may also have dependency information associated with them, so that these dependencies can be used to analyze consistency. Conceptual graph theory holds that the direction of links indicates the dependency between concepts. A relationship may have no dependency associated with it; such relationships are called symmetric relationships. Conceptual graph theory prescribes that there will be at least one outgoing link; this restriction is relaxed for purposes of allowing symmetric relationships.
Definition: If B’s existence depends first upon A’s existence, then we say that B is dependent upon A. Dependency is defined only between concepts, not actors, or demons. Dependency is thus transitive — if B depends on A and C depends on B, then C depends on A. Dependency is not symmetric; i.e., if A depends on B, B does not depend on A. The dependency of a relationship is denoted by the direction of its connecting links, as follows, using the notational convention from Chapter 3. All three expressions Ch. 4 58
result in the relation rb(A C) meaning that concept C is dependent upon concept A through the relation, actor, or demon b. [A] —> (b) —> [C] [A] —> —> [C] [A] —> << b >> —> [C]
Usage: If B is dependent upon A, we use a double arrow in text, e.g., A B, or a double-wide arrow in
A the display form of graphs, e.g., B . A symmetric relationship is shown by a two-headed double-wide arrow, e.g., A B.
Strong vs. Weak Association Counterpart pairs can be related to each other in several ways: through a combination of strong and weak relationships, as discussed in Chapter 3. We now define these in terms of conceptual graphs.
Definition: For nodes I and H in view P and nodes J and K in view Q, a pair of concepts (H; K) has a strong association with the pair (I; J) if there exists a relation ri such that one of the following is true: (i) ri(I H) and ri(J K) (ii) ri(H I) and ri(K J) (iii) ri(I H) and ri(K J) (iv) ri(H I) and ri(J K)
Definition: A strongly-consistent association is an association between (I; J) and (H; K) such that either (i) or (ii) above is true. We abbreviate the relationship as r+. If ri is a canonical relation (i.e., one that appears in the analyst’s pre-existing canon) then the relationship is abbreviated as cr+.
Definition: A strongly-inconsistent association (or conflicting association) is an association between (I; J) and (H; K) such that either (iii) or (iv) above is true. We abbreviate the relationship as r–. If ri is a canonical relation (i.e., one that appears in the analyst’s pre-existing canon) then the relationship is abbreviated as cr–.
Definition: For nodes I and H in view P and nodes J and K in view Q, a pair of concepts (H; K) has a weak association with the pair (I; J) if there exists relations ri and rj (ri rj) such that one of the following is true: (i) ri(I H) and rj(J K) (ii) ri(H I) and rj(K J) (iii) ri(I H) and rj(K J) (iv) ri(H I) and rj(J K)
Definition: A weakly-consistent association is an association between (I; J) and (H; K) such that either (i) or (ii) above is true. We abbreviate it as d+.
Definition: A weakly-inconsistent association is an association between (I; J) and (H; K) such that either (iii) or (iv) above is true. We abbreviate it as d–. Ch. 4 59
4.4.2. Analyzing Overlap Analysis is the process of determining whether items present in the meta-language representations are compatible with each other. We would like a means of accurately telling a participant just which parts of his original specification are consistent or inconsistent with other views, so that he at least knows where changes to his requirements are most likely needed. The ideas in this section were introduced in Chapter 3; here we tie the definitions specifically to conceptual graphs.
Association Graph As described in Chapter 3, an association graph is used to analyze possible counterpart pairs with respect to other possible pairs. The purpose of this section is to show association graphs originating from specifications expressed through conceptual graphs.
Definition: An association graph is constructed from two conceptual graphs as follows: 1. Each concept in a conceptual graph is treated as an original node. 2. Each relationship in a conceptual graph is treated as a directed arc between two original nodes. A binary node with in-degree 1 and out-degree 1 (a binary relation) is treated as a single directed arc between two original nodes. A relation that is other than binary, with in-degree a and out-degree b (a 1, b 1) is treated as a*b separate binary relations. 3. A 2nd-order association graph node has two components, each taken from two different graphs. Each association graph node is assigned a weight, denoting its likelihood of being an actual counterpart pair. We use the 2nd-order graph to find the association subgraph which represents the strongest overlap between the strongest related two views. 4. Any two association graph nodes may be connected by an association graph arc that is assigned a weight based on the relationships between the original nodes contained in each association node. The arc weight thus captures our evidence that if one node is an actual counterpart, then the other connected node is also a counterpart. 5. An M-order association graph node has M components, taken from M different graphs. To ease the computational burden, the M nodes will be in two sets – each set being drawn from a previously determined strongest subgraph. Each M-order association graph node can be assigned a weight, capturing the evidence that all its components are counterparts to each other.
Definition: A valid subgraph between two graphs is a set of 2nd-order association nodes (I; J) such that no original graph concept I appears in more than one association node, and no original graph concept J appears in more than one association node. If an original concept I were to appear in more than one association sub-graph node, the sub-graph would represent a case where I would simultaneously be a counterpart to more than one concept in another graph; by providing the definition, we disallow this (see below, Ambiguous Counterparts).
Definition: A strongest valid subgraph between two graphs is a valid 2nd-order association subgraph such that there is no other valid subgraph G between the two views that has a higher sum of absolute node weights. There may be more than one equally strong valid subgraph between two graphs.
Establishing Counterparts
Definition: An established counterpart set is an association graph node whose components have been determined to be counterparts in one of the following ways: a. The analyst assumes its components are counterparts to each other, based on heuristics or intuition. We may refer to these counterparts as “seeds”, and give them a strong positive weight. b. The node has a high weight assigned to it after iterations through the association graph technique (see below). Ch. 4 60
Type Distance Types in conceptual graphs are arranged in a hierarchy with T at the top. One way to relate concepts in different views is to consider how type-compatible they are. Two concepts in two different views being of the same type is certainly some evidence in support of their being counterparts. If two concepts are of “similar” types, that also provides evidence in favor of their being counterparts. We can use the type hierarchy to measure “similarity” by obtaining their distance apart in the hierarchy. An exception is made if the two types have T as their least common supertype: in that case, we consider the two types to be dissimilar (distance = infinity) since all we know is that they exist in the universe together. Definition: The type distance between two concepts I and J is obtained in the following way: (i) Find the least common supertype S of both I and J; i.e., a type S such that S is supertype to I and J and there is no other type S’ such that S’ is supertype to I and J, and S is supertype to S’. (ii) If S is T, then consider the distance to be infinity, and exit. (iii) If S is not T, then determine the relative depth DI of type I — i.e., how many types up the hierarchy from I is S. (iv) Determine the relative depth DJ of type J also. (iv) The type distance D is therefore DI + DJ. We abbreviate it as T+D. The type distance is generalized for three or more types by finding the least common supertype of them all, then adding together each one’s distance from the supertype. Examples using the type distance are found in Chapter 6.
Measuring Dependencies Dependency information may identify a conflict; e.g., if both A ==> B and B ==> A appear. The only way for both to be true is if A and B are identical; otherwise, we consider that it is not possible for each of two things to depend on the other. Rules for identifying dependency among counterparts may involve information external to a participant’s model, but the knowledge may be nonetheless useful in increasing understanding. The previous chapter’s dependency rules (§3.3.1) can be formulated in conceptual graphs as follows: 1. An actor’s output concept(s) depend upon its input concept(s). This rule is captured by use of an actor, in that an actor’s output referents depend upon the result of computation using its input referents. 2. The definition for relation “attribute” is [ENTITY] —> (attribute) —> [T] 3. An actor or demon depends upon its input concept(s). 4. An output concept of an actor or demon depends upon that actor or demon.
Ambiguous Counterparts
Definition: An ambiguous counterpart pair between two views P and Q is a counterpart pair (I; J) such that there is another counterpart pair, either (I; K) or (H; J) with the same weight. An ambiguous M- order counterpart set is a counterpart set between M views where at least one of the components (C1; C2; ...; CM) appears in another counterpart set with the same weight. If the strongest counterpart set is ambiguous, then the analyst needs to seek additional information to be added to the graphs from the participants whose views are being considered. An ambiguous counterpart set does not necessarily indicate ambiguity in the original requirements. We interpret such a counterpart set to mean that the analysis is as yet incomplete; i.e., there is not yet enough information to distinguish between the two possible counterparts. Ch. 4 61
4.5. A Methodology For Multiple Viewed Requirements This section describes a methodology for analyzing multiple views. First we show the steps of the methodology, justifying each one in terms of the conceptual graph framework just discussed. Then we summarize the products resulting from applying the methodology. This section does not discuss evaluating the results for purposes of determining the approach’s usefulness; such a discussion is deferred until Chapters 7 and 8. Figure 4.1 gives a general overview of the methodology steps, showing where pre-existing knowledge is employed, and where the analyst and participant play a role.
R-Spec-Graphs Translation R-Spec- Heuristic w/ dependency schemes 1 Graphs 2 3 weights
2nd-order A-Graphs Dependency Pre-existing assoc R-Specs Knowledge dependency graph knowledge Participants 4 8 Meta-language Analyst Knowledge M-order assoc Heuristics Answers Queries about Unambiguous graph for pruning Pre-existing counterparts counterparts assumptions
7 6 5 Ambiguous counterparts
Figure 4.1. Multiple-Viewed Methodology Using Conceptual Graphs.
The numbers in Figure 4.1 indicate the methodology steps as we will now describe them. The reader may wish to compare this figure with Figure 3.2 in the previous chapter.
4.5.1. Methodology Steps The following steps constitute our development methodology for multiple views. For illustrations of these steps, see Chapters 5 and 6. We make the following assumptions: Assume participants are numbered from 1 to M. Assume that the analyst has available a canon containing a type hierarchy, relation definitions, type abstractions, and pre-defined actors and demons. Assume that the analyst has available a translation scheme for each notation that participants might use. (See Appendix B and Chapter 5 for translation algorithms and examples.) Assume an integer function type_distance that calculates the type distance between its two arguments. If the types have no similarity, the distance is infinity. Assume an integer function lookup with one argument being one of the following: cr+, cr–, r+, r–, d+, d–, or T+n, where n represents the type distance. Assume a heuristically determined seed weight for pre-determined counterpart pairs and threshold for deleting uninteresting nodes. Ch. 4 62
Assume a heuristic factor alpha valued between zero and one that represents an association node’s original weight contribution to its own weight total. The steps are summarized as follows. Details of each step are shown below. 1. Obtain R-Spec-Graphs from each participant. These are the originating requirements. Join with A- graphs, if already obtained. 2. Obtain dependency relations. Some notations require that participants identify the dependency among elements in their views before proceeding. 3. Measure 2nd-order interactions between graphs. Examine associations between counterpart pairs to determine which graphs have the strongest overlap. 4. Combine two strongest graphs. Replace two graphs with one subgraph representing their strongest overlap. If there are any other graphs left, go to step 3. 5. Propose analyst’s R-Spec-Graph. Propose an analyst’s R-Spec-Graph containing one concept for every M-order counterpart that was identified. 6. Present results to participants. Inform participants as to the results of the previous analysis, telling them what are likely counterparts and where ambiguities still remain. If there are no ambiguities, then the multiple viewed analysis is completed. 7. Obtain assumptions from each participant. Use the analyst’s graph to guide the questioning of participants to provide additional underlying assumptions that elaborate the meaning of counterparts in their views. 8. Express assumptions as conceptual graphs. Re-write assumptions in conceptual graph form. 9. Restore all graphs and go to Step 2. The details of each step are shown below. Comments are shown in italics. Each LOOP construct is given an explicit exit condition. 1. Obtain R-Spec-Graphs from each participant. If there are M participants, there will be M R-Spec-Graphs. Order the views from 1 to M, calling them views V1 through VM. Participant interaction required here. a. Obtain R-Spec from each participant in notation of his own choosing. b. Translate the R-Spec into an R-Spec-Graph, including its type hierarchy. c. Assign unique ids to every concept in every R-Spec-Graph so that no two concepts in any two views have the same id. 2. Obtain dependency relations. For each view, perform the following on R-Spec-Graph and A-graphs: Determine direction of all dependency relations. FOR ALL relations, actors, or demons DO IF relation/actor/demon matches an existing definition from analyst’s canon THEN IF existing arcs do not have correct dependency THEN fix a translation error ELSE Participant interaction required here. Manually obtain dependency information by querying participants. ENDIF ENDIF END FOR 3. Measure 2nd-order interactions between graphs. a. Create association graph nodes. ; Only create nodes where their least common supertype is not T. Ch. 4 63
Let AG = { }. FORALL P and Q such that P< Q DO FORALL concept I in VP and concept J in VQ such that id(I) < id(J) DO IF neither I nor J is in a seed counterpart THEN Let D = type_distance (type(I), type(J)). IF D THEN Let weight(I; J) = lookup( T+D ) Put (I; J) in AG. ENDIF ELSE IF (I; J) is a seed THEN Let weight(I; J) = seed_weight Put (I; J) in AG. ELSE ignore (I; J). ENDIF END FORALL END FORALL FORALL (I; J) in AG Let orig_weight( (I; J) ) = weight(I; J) ; Results in all non-zero association graph nodes in AG. b. Examine relationships and assign weights to arcs. FORALL (I; J) in AG DO FORALL (H; K) in AG such that I and H are in VP and J and K are in VQ and there exists at least one relationship between J and K DO Let R = set of all relationships between I and H. Let S = { }. ; S contains the relations already evaluated in this loop Let weight( (I; J) , (H; K) ) = 0. LOOP IF R = { } THEN exit loop ; Evaluate all strongly-consistent relations for this node LOOP Let r = { } IF ri (I H) R and ri (I H) S and ri (J K) is in Vj THEN Let r = { ri (I H) } ENDIF IF ri (H I) R and ri (H I) S and ri (K J) is in Vj THEN Let r = { ri (H I) } ENDIF IF r = { } THEN exit loop ELSE IF ri is a canonical relation THEN let weight( (I; J), (H; K) ) = weight( (I; J), (H; K) ) + lookup( cr+ ) ELSE let weight( (I; J), (H; K) ) = weight( (I; J), (H; K) ) + lookup( r+ ) ENDIF ENDIF Let S = S + r. END LOOP ; Evaluate all strongly-inconsistent relations for this node LOOP Let r = { } IF ri (I H) R and ri (I H) S and ri (K J) is in VQ THEN Let r = { ri (I H) } ENDIF Ch. 4 64
IF ri (H I) R and ri (H I) S and ri (J K) is in VQ THEN Let r = { ri (H I) } ENDIF Ch. 4 65
IF r = { } THEN exit loop ELSE IF ri is a canonical relation THEN let weight( (I; J) , (H; K) ) = weight( (I; J) , (H; K) ) + lookup( cr– ) ELSE let weight( (I; J) , (H; K) ) = weight( (I; J) , (H; K) ) + lookup( r– ) ENDIF ENDIF Let S = S + r. END LOOP ; Evaluate all weakly-consistent relations for this node LOOP Let r = { } IF ri (I H) R and ri (I H) S and rj (J K) in VQ and ri rj THEN Let r = { ri (I H) } ENDIF IF ri (H I) R and ri (H I) S and rj (K J) in VQ and ri rj THEN Let r = { ri (H I) } ENDIF IF r = { } THEN exit loop ELSE let weight( (I; J) , (H; K) ) = weight( (I; J) , (H; K) ) + lookup( d+ ) Let S = S + r. END LOOP ; Evaluate all weakly-inconsistent relations for this node LOOP Let r = { } IF ri (I H) R and ri (I H) S and rj (K J) in VQ and ri rj THEN Let r = { ri (I H) } ENDIF IF ri (H I) R and ri (H I) S and rj (J K) in VQ and ri rj THEN Let r = { ri (H I) } ENDIF IF r = { } THEN exit loop ELSE let weight( (I; J) , (H; K) ) = weight( (I; J) , (H; K) ) + lookup( d+ ) Let S = S + r. END LOOP END LOOP IF weight( (I; J) , (H; K) ) 0 THEN Create arc ( (I; J) , (H; K) ). ENDIF Let R = R – S. END FORALL END FORALL ; Result is a set of weights attached to arcs. c. Get average of maximum arc weights for each association graph node. FORALL (I; J) DO Let numberH = 0; Let sum_of_maxs = 0; FORALL H such that there is an arc ( (I; J) , (H; K) ) DO max Let sum_of_maxs = sum_of_maxs + K (weight ( (I; J ), (H; K ) ) * weight(H; K )) Let numberH = numberH + 1 END FORALL Let weight(I; J) = alpha *orig_weight( (I; J ) ) + (sum_of_maxs / numberH ) END FORALL Ch. 4 66
; Delete uninteresting nodes with weight below a threshold FORALL (I; J) DO IF | weight(I; J) | < threshold THEN FORALL (H; K) such that there is an arc ( (I; J) , (H; K) ) DO Delete arc( (I; J) , (H; K) ) END FORALL FORALL (H; K) such that there is an arc (( H; K), (I; J)) DO Delete arc ( (H; K), (I; J) ) END FORALL Delete node (I; J). ENDIF END FORALL
d. Measure strength of association between each pair of graphs. ; Gather highest weighted subgraph between all pairs of graphs. Let Max = 0.0; FORALL graphs P and Q DO FORALL valid subgraphs S between P and Q DO Let W = |weight (I; J)|, where (I; J) is in S. IF W >= Max THEN Call S by the name [P, Q ]. IF there is more than one [P, Q] with the same weight W THEN Note ambiguous subgraphs but choose one for later steps. ENDIF IF W > Max THEN Let Max = W. Forget any previous ambiguous subgraphs. Let Strongest = [P, Q ] ENDIF ENDIF END FORALL END FORALL ; Results in the set of strongest (positive or negative) nodes representing ; counterpart pairs in strongest subgraph. 4. Combine two strongest graphs. Use Strongest from the previous step. IF sum of actual node weights in Strongest has negative actual weight THEN There is an inconsistency between views P and Q Go to Step 6 ENDIF IF sum of actual node weights in Strongest has negative actual weight THEN Note an ambiguity between views P and Q ENDIF Assert a new graph called [P, Q] where each node is of the form (I; J), with (I; J) in Strongest. FORALL nodes (I; J) in graph [P, Q] DO Label node (I; J) with two (possibly composite) types: type(I) and type(J). END FORALL FORALL (I; J) and (H; K) such that there exists a relationship r between I and H or between J and K DO Insert a relationship r between nodes (I; J) and (H; K). END FORALL Remove graphs P and Q. IF there is more than one graph remaining, go to step 3. Ch. 4 67
5. Propose analyst’s R-Spec-Graph Determine the strongest M-order association sub-graph(s). IF its weight is negative THEN There is some inconsistency between the M views ELSE IF there is more than one strongest subgraph THEN There are ambiguous counterparts to be distinguished in later analysis ELSE Overlap is represented by single strongest subgraph. ENDIF ENDIF ; Results in a list of ambiguous counterparts (M-order) 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. a. Extract analyst’s R-Spec-Graph into each of the originating notations: For each view P in notation N, use N’s extraction algorithm to produce a private referent R- Spec of the analyst’s graph in N. b. Paraphrase the analyst’s R-Spec-Graph into English for validation and discussion. c. Evaluate results through discussion with participants. d. Propose counterparts. After counterparts have been accepted, declare them to be new “seed” counterparts, give them each a high weight, and continue to find next highest counterparts. If there are no ambiguous counterparts, then the multiple viewed analysis is completed. 7. Obtain assumptions from each participant. For each participant P, perform a and b. Participant interaction and ANALYST interaction required here. a. Gather an assumption manually, based on already-obtained R-Spec-Graphs, that involves a counterpart pair that was shown to be ambiguous at step 4 or 5. b. Decide if there are any counterparts already known within the assumptions. 8. Express assumptions as conceptual graphs. Re-write assumptions in conceptual graph form. ANALYST interaction required here. a. Construct A-graph that expresses the assumption. b. Include A-graph in VP P by joining A-graph to P’s R-Spec-Graph using a common concept. Requires a common concept in both A-Graph and R-Spec-Graph. Multiple viewed methods may also be used to find such a concept. 9. Restore all graphs and go to Step 2. With the newly-augmented R-Spec-Graph (now joined to one or more A-Graphs), including all previous graphs (even if they were removed during previous assocaiton) so that all concepts are again potentially available, repeat the steps to refine the analyst’s graph.
The steps may be repeated many times, until in Step 6 the participants are satisfied with the presentation of the analyst’s R-Spec-Graph. Several steps of the methodology involved heuristic or manual decisions of the analyst, namely: 1. Seeking new assumptions based on ambiguous counterparts. 2. Joining participant assumptions in conceptual graph form to their R-Spec-Graph. 3. Weight assigned to each common relation (either canonical or not) 4. Weight assigned to each weak association (either consistent or not). 5. Weight assigned to increasing type distances 6. Weight given to an assigned seed counterpart pair in the 2nd-order graph. 7. Weight threshold that divides interesting weights from uninteresting ones. Ch. 4 68
8. Proportional importance (alpha) given to a node’s previous weight. In Chapter 6, these decisions will be illustrated with typical actions or numbers chosen by the analyst.
4.5.2. Products of Analysis The following deliverables are produced at the end of analysis. Some of them, as indicated, are maintained in partial form during the process for preliminary analysis as desired. Once these products are obtained, participants or the analyst may make changes in their respective contributions, and the entire analysis process may be repeated. (It is not clear how analysis could be incrementally performed; i.e., just the affected parts re- analyzed.)
Requirements in Common (Analyst’s R-Spec-Graph) Requirements in common are represented in the analyst’s R-Spec-Graph, where each counterpart provides the concepts from which its original graph nodes were formed. The actual counterpart arcs are not included (since they may come from differing relations, e.g., dependencies). The analyst’s R-Spec-Graph makes up a subgraph of the M-order association graph, with the arcs filled in by the actual relations from the original participant graphs.
Requirements in Combination (Join) If counterpart concepts in differing R-Spec-Graphs were considered to be equivalent to each other (i.e., all counterparts of one concept comprise exactly one instance of that concept), then the rules of conceptual graphs allow us to join all participants’ R-Spec-Graphs together. This forms a complete set of requirements, including all views; however, since the joined graph is in conceptual graph form, it may be of limited usefulness to any participants other than the analyst. (See later chapters for a brief discussion of how to present results.) Since it represents the combined requirements, however, it serves as a concise summary of all requirements captured.
Set of Inconsistencies If the strongest nodes of the M-order association graph consist of negative weights, participants are informed of that fact. Resolution of such conflicts must be performed by the participants in whose views the conflicting relations occur. If there is more than one strongest subgraph for a given set of M views (i.e., there are ambiguous counterparts), then the analyst should seek additional information from participants about the original views in order to distinguish between the subgraphs.
Indications of Incompleteness At the end of analysis, determinations of incompleteness may be performed. As we have already discussed, the whole issue of completeness is problematic for requirements, since it is difficult to know when all necessary requirements have been gathered from human participants. If the analyst’s canon contains definitions or schemata, either the analyst’s R-Spec-Graph or the combined graph can be compared to the canon to determine if there are missing relations and/or concepts. Such a definition forms a constraint on the meaning of conceptual graphs. If a definition’s relations or concepts are missing, that is a strong indication that something is incomplete in the original requirements, although the incompleteness may not materially affect the outcome. Most requirements techniques already provide for some analysis of incompleteness within a single specification. If a schema’s relations or concepts are missing, we may present such information to the analyst or other participants for their evaluation; however, since such relations or concepts represent knowledge whose presence is not required, participants may choose not to include them.
4.5.3. Analyst’s View The analyst’s view consists of the following: 1. Requirements Specifications (R-Spec) — one for each participant. 2. Translation Schemes — one for each notation used by participants. Each scheme has two parts: Ch. 4 69
Compilation (“A”) algorithm: translates the structure of an R-Spec into an R-Spec-Graph. May insert a type hierarchy. Extraction (“B”) algorithm: (partially) translates any conceptual graph into the notation. 3. Requirements Specification Graphs (R-Spec-Graph) — one for each participant. Each includes its own type hierarchy. 4. Analyst’s Requirements Specification Graph (R-Spec-Graph) — all requirements combined into one set of conceptual graphs. 5. Assumption Graphs (A-graphs) — zero or more for each participant. May include additional orderings for the type hierarchy, and heuristic techniques for joining to a participant’s R-Spec-Graph. 6. Weights For Association Graph Relations — heuristically determined weights to be used for the various kinds of associations (strong/weak, consistent/inconsistent, sharing supertype or not, etc.) 7. 2nd-order Association Graph — representing all possible counterpart pairs between two views, and arcs whose weights represent the strength of association between possible counterpart pairs. 8. Higher Order Association Graphs — representing all possible counterparts between successively higher order combinations of views. 9. Analyst’s R-Spec-Graph— a conceptual graph containing the strongest M-order association graph nodes (whether positive or negative) and the dependency relations between them. 10. Paraphrase Templates — sentence patterns showing what words to use when paraphrasing a relation into natural language; must be supplied by the analyst for each new relation.
4.6. General Features Of Approach This section discusses some general strengths and limitations to this approach using conceptual graphs. These are in addition to the general ones given in §3.4 for any multiple-viewed approach. Two characteristics of conceptual graphs allowed us to refine the assignment of weights beyond the mere structure of the graphs. When a common relation was one of our canonically defined relations, we give it more weight in our analysis, since canonical relations constitute part of our pre-existing knowledge rules. We were also able to consider the type of each node to further constrain our determination of counterparts. If two nodes are of the same type, we can favor them as possible counterpart pairs. If they are different types, but similar (as we showed how to measure above) then we can still favor them, but to a lesser amount. If they share no common supertype other than T (i.e., all we know is that they both exist in the universe), we gain nothing from our knowledge of their types. Conceptual graphs as extended can capture only some of the information necessary to develop realistic requirements. While we have argued that conceptual graphs are more general than some existing methods, we must still acknowledge limitations that affect the scope of requirements we can capture. For example, the handling of nested conceptual graph contexts (see R-nets in the next chapter) is not clear. Chapter 9 discusses this further. One particular limitation is the inability to capture cost information about any processes described under conceptual graphs (that is, beyond simply adding a (cost) relation). If any view (e.g., a manager’s) is concerned with the costs of operating the target system (a non-trivial concern!), then conceptual graphs offer no particular advantage in their expressive power as compared to existing notations. For example, if a manager is concerned with the cost of responding to a false alarm, he may require that the system produce fewer false alarms, whereas a doctor may be concerned that true emergencies might thereby go un-signaled. Appropriate avenues for presenting the results of analysis are still open to discussion. We can suggest two ways: (1) paraphrasing results into English (or other natural language) for feedback and interpretation, or (2) extraction of conceptual graphs into whatever notation a participant chose for his original requirement specification. Both of these have limitations: paraphrasing has many of the same problems as informal natural language requirements, and extraction necessarily captures only part of the combined requirements for each participant. Perhaps a combination of the two would be useful; however, we will not explore these issues here. Ch. 4 70
The approach does not address the issues of determining whether two relations in two different views may be counterparts to each other, nor do we address the issue of actors or demons as potential counterparts. Actors are handled merely as relations between concepts. 4.7. Summary This chapter introduced the important aspects of analyzing multiple views of requirements using conceptual graphs. We defined certain contexts that help us organize different kinds of requirements knowledge. A requirements analyst’s framework was introduced and discussed. Various means of examining overlap between the views were discussed, using the notions of a counterpart and dependency. A methodology was proposed that applies these ideas in a development framework. Since conceptual graphs are capable of expressing several existing requirements notations within a single notation, we can analyze different views using one set of conceptual graph rules, including forming an association graph to analyze the views’ overlap. The next two chapters show an extended example of how the methodology works, and illustrate the flavor of the multiple-viewed approach. Ch. 5 71
5. Translating Requirements Into Conceptual Graphs
CHAPTER SUMMARY Error! No table of contents entries found. We define an interlingua as a representation of meaning of natural language that does not involve any of the words of the language. This representation of meaning should be extractable from any language and capable of being generated into any other language.
Roger C. Schank, Conceptual Information Processing, 1975
This chapter explains how we translate requirements specifications into conceptual graphs. Our purpose is two-fold: first, since we claim that conceptual graphs are more general than current specification methods, we want to show how conceptual graphs capture a few of them, while familiarizing the reader with the notation. Second, since we want to use requirements developed under existing methods, we must be able to quickly translate them into conceptual graph form, in order to analyze each specification with respect to the others. This chapter illustrates steps 1 and 2 of the methodology given in §4.4.1. Later steps are shown in the next chapter. This chapter explains a translation scheme’s purpose, and provides results for each of four notations. Details of each translation scheme are given in Appendix B. Each section of this chapter has the same structure: first, the notation is briefly described, then an example diagram is shown along with its translation into conceptual graphs. The particular notations in this chapter were chosen because of their diversity, and because they are representative of the different kinds of information typically captured by different requirements methods. The four notations are: entity-relationship diagrams, data flow diagrams, state transition diagrams, and requirements networks (R-nets) from SREM. We do not claim that these are the “best” notations, only that they are typical notations which participants might use today in developing requirements.
5.1. Entity-Relationship Diagrams This section illustrates the process of obtaining an R-Spec-Graph from an entity-relationship diagram. An entity-relationship diagram is a bipartite, non-directed graph where every node is either an entity or relation [Chen76]. Nodes of either type may have associated attributes. Labels on arcs indicate the arity (many-to-many- ness) of a relation, e.g., one-to-one, one-to-many, etc. The basic strategy of the translation (see §B.1) is that entities in an era diagram are translated into concepts of type ENTITY, relations in an era diagram are translated into conceptual graph relations whose dependency is determined manually by the analyst.
5.1.1. Example Entity-Relationship Diagram The following example is introduced in order to illustrate Algorithm 1a in §B.1. This diagram was produced by the customer, who is responsible for the overall patient-monitoring system.
An Entity-Relationship R-Spec Consider the entity-relation diagram in Figure 5.1 below. Entities in C are denoted by a rectangle , and relations in R are denoted by a diamond . There are zero or more attributes (each denoted by a text string
attribute ) associated with an entity or relation. The graph’s edges consist of the set E, each member having a many- to-many-ness label (default 1) in order to express one-to-one, one-to-many, or many-to-many relations. For 1 M example, A r B means r is a one-to-many (1 to M) relation — there is one A for several B’s. Ch. 5 72
SYS pms VP customer LANG era R-Spec
1 1 N Patient connec- Monitor plug tion into vital signs current readings 1
Nurse M 1 Database alert
normal ranges
Figure 5.1. Original Entity-Relation Diagram.
An Entity-Relationship R-Spec-Graph Performing Algorithm 1a on Figure 5.1 results in the specification graph shown in Figure 5.2. Note that arcs linked to the relations connection, plug_into, and alert are assigned a direction by the analyst, whereas the relation attribute has a pre-defined direction.
SYS pms VP customer LANG era R-Spec-Graph:
VITAL CURRENT attribute SIGNS READINGS @N
PATIENT connection MONITOR attribute
plug into
DOCTOR/ DATA- NORMAL NURSE: { * } alert attribute @M BASE RANGES
VITAL_SIGNS < ATTRIBUTE. CURRENT_READINGS < ATTRIBUTE. NORMAL_RANGES < ATTRIBUTE. PATIENT < ENTITY. MONITOR < ENTITY. DATABASE < ENTITY. DOCTOR_NURSE < ENTITY. Figure 5.2. Conceptual Graph From Entity-Relation Diagram.
5.1.2. Discussion The cardinality of the entities’ referents are derived from the many-to-many-ness implied by the original era relations. For example, the one-to-many era relation plug_into results in the individual DATABASE having a cardinality of 1, whereas the individual MONITOR implies a cardinality of N for its enclosing context. Ch. 5 73
Era relations with attributes are not easily handled unless one either changes conceptual graphs’ makeup (allowing relations to link other relations) or creates a new dummy concept (e.g., [Attrset]) from which to hang the attributes. This does not affect Algorithm 1b, however. In any case, attributes to relations are somewhat uncommon in practical experience. The direction of a newly-created relation’s arrow is arbitrary, unless there are already-existing definitions (canonical graphs) specifying its direction. For an era relation that is not in the canon, the direction of the arrow should reflect the dependency underlying the relationship; the analyst makes a heuristic choice, possibly consulting the participant in question. Whatever choice is made does not affect Algorithm 1b, which ignores the direction of the links. While the attribute relation (with pre-existing definition) is introduced by Algorithm 1a, other relations may be introduced that have no definitions. Although we therefore run the risk that the name of the relation is badly chosen, at worst we will end up considering only its dependency if its name does not match any other relation’s. When translating the customer’s specification into its specification graph, either existing canonical graphs will determine the direction (see Chapters 5 and 6), or else for a completely new relation, a human analyst must decide which direction is appropriate.
5.2. Data Flow Diagrams This section illustrates the process of obtaining an R-Spec-Graph from a data flow diagram. In order to represent data flow diagrams using conceptual graphs, we use actors, as explained in Appendix A (§A.2.2). An actor represents a data flow process that is allowed to change the referents of its outputs, using steps known as its private algorithm. Its arcs are classified as either input or output arcs, shown by dashed lines.
5.2.1. Example Data Flow Diagram The following example is introduced in order to illustrate Algorithm 2a in §B.2. This diagram was produced by the data base designer, who is responsible for determining the data base requirements of the patient monitoring system.
A Data Flow R-Spec Consider the data flow diagram in Figure 5.3:
SYS pms VP designer LANG dfd R-Spec
factors sensor
current readings alarm Doctor_ database Nurse normal ranges
Figure 5.3. Original Data Flow Diagram.
A Data Flow R-Spec-Graph Performing Algorithm 2a on Figure 5.3 results in the graph of Figure 5.4: Ch. 5 74
SYS pms VP designer LANG dfd R-Spec-Graph: FACTORS sensor
ALARM CURRENT database READINGS
doctor_ NORMAL nurse RANGES
FACTORS < DATA.CURRENT_READINGS < DATA. ALARM < DATA. NORMAL_RANGES < DATA. Figure 5.4. Conceptual Graph From Data Flow Diagram.
5.2.2. Discussion The originating specification shows some fundamental limitations of data flow semantics, e.g., the Doctor_Nurse appears as a process that consumes an alarm and produces normal ranges, a somewhat different interpretation than our common sense would lead us to make. In later chapters, we will show how other specifications can actually augment this one so that the role of the Doctor_Nurse is portrayed more accurately. The effectiveness of translating data flow diagrams is made possible by the semantics of a conceptual graph actor, which models a process. In fact, one of the reasons Sowa introduced actors was to model data flow. Since actors occur in translating other notations (e.g., see §5.4), it would seem that the notion of a process is fundamental to modeling cognitive information. Without actors, many desired properties of real-world things could not otherwise be expressed using conceptual graphs. Writing down an actor must be followed eventually by supplying an additional private algorithm describing how the actor alters its output concepts based on its input concepts.
5.3. State Transition Diagrams This section illustrates the process of obtaining an R-Spec-Graph from a state transition diagram. Instead of the usual definition of state transitions based on input symbols [Aho72], we generalize our definition to include any event as an input symbol or output symbol. In the standard definition, each event therefore means the arrival of an input symbol or the creation of an output symbol. We will translate state transition diagrams into conceptual graphs by using instances of the concept STATE to represent each state, a demon to represent each transition, and instances of EVENT to represent input and output.
5.3.1. Example State Transition Diagram The following example is introduced in order to illustrate Algorithm 3a in §B.3. This diagram was produced by the enduser (a doctor or nurse) who is concerned with the actions of the patient-monitoring system during its operation. Ch. 5 75
A State Transition Diagram R-Spec Consider the state transition diagram of Figure 5.5. States are indicated by ovals; transitions are shown as input-event / output-event (with “—” denoting a null event).
SYS pms VP enduser LANG std R-Spec
readings normal / — plug in / — START normal
readings off — / — normal / alarm — / —
readings false readings true repair / — check / — treat pt monitor pt
Figure 5.5. Original State Transition Diagram.
A State Transition Diagram R-Spec-Graph Performing Algorithm 3a on Figure 5.5 results in the specification graph of Figure 5.6:
SYS pms VP enduser LANG std R-Spec-Graph:
REPAIR_ T START transition MONITOR
READINGS FALSE_ PLUG_IN transition _OFF transition _NORMAL READ
transition NORMAL transition CHECK_PT
TRUE READINGS transition READINGS _NORMAL ALARM
transition TREAT_PT
START < STATE. NORMAL < STATE. CHECK_PT < STATE. TREAT_PT < STATE. REPAIR_MONITOR < STATE. PLUG_IN < DATA. READINGS_OFF_NORMAL < DATA. ALARM < DATA. READINGS_NORMAL < DATA. TRUE_READINGS < DATA. FALSE_READ < DATA. Figure 5.6. Conceptual Graph From State Transition Diagram. Ch. 5 76
5.3.2. Discussion The effective translation of a state transition diagram is made possible by the semantics of the demon, which we have introduced in this thesis. Since a state transition diagram expresses a set of dynamically changing STATEs, its true semantics cannot be captured by an actor. The demon’s semantics are appropriate for state transition diagrams. The loopback arc from STATE nominal readings is represented by a << transition >> demon that re-creates its input state. Figure 5.6 effectively “eats” its input events (whose origin is not specified), and produces a temporal series of output events (whose disposition is not specified). The output events accumulate, since they do not serve as input to any demons. If state transition diagrams were extended to accommodate multiple concurrent states, these algorithms can be adapted with only minor modifications, to represent multiple start states, and multiple concurrent transitions. There is no restriction on the number of demons active at any one time, so many transitions may take place simultaneously. Likewise, there is no restriction on the number of concepts that may exist at any time, so many different states (and their output events) may exist. Thus conceptual graphs with demons are an adaptable representation for systems that change state. A more accurate (and more complex) transformation would better capture the notion that the arrival of an input token is an event. This would allow us to model generalized state transition diagrams where a state transition is triggered by some arbitrary event instead of the particular event of an input token arriving. The above diagram is somewhat suggestive in that regard, since certain data “tokens” (e.g., READINGS_OFF_NORMAL) involve an implied event.
5.4. Requirements Networks (SREM)
This section illustrates the process of obtaining an R-Spec-Graph from a SREM R-net. Details of requirements networks are described in [Alford77].
5.4.1. Example Requirements Network The following example is introduced in order to illustrate Algorithm 4a in §B.4. This diagram is produced by the software tester, who is responsible for determining that the functions of the patient-monitoring system are fulfilled by the requirements. Ch. 5 77
A Requirements Network R-Spec Consider the requirements network (R-net) diagram in Figure 5.7 taken from [Alford77]:
SYS pms VP tester LANG Rnet R-Spec
From_ Device
Determine Message Type type_message “failure” else &
Notify_Nurses_ Store_ Examine_ Station_ of_Failure Factor_Data Factors Range “safe” else To_Nurses_ Station Tell_Nurse_ Of_Factors
To_Nurses_ Station
Figure 5.7. Original Requirements Network Diagram. Ch. 5 78
A Requirements Network R-Spec-Graph Performing Algorithm 4a on Figure 5.7 results in the specification graph of Figure 5.8:
SYS pms VP tester LANG Rnet R-Spec-Graph:
MESSAGE: Determine TYPE_MSG: Start From_ Message {failure, else} Device Type @1
TYPE_MSG: TYPE_MSG: failure else
Store_ Examine_ Factor_ Notify_ Factors ¬ Nurses_ Data ¬ Station
RANGE: {safe, else} RANGE: ¬ MESSAGE: ¬ @1 safe To_Nurses_ Station
Tell_ RANGE: Nurse_Of_ else Factors
¬ ¬
MESSAGE: To_Nurses_ Station
MESSAGE < DATA. TYPE_MESSAGE < ATTRIBUTE. RANGE < ATTRIBUTE.
Figure 5.8. Conceptual Graph From A Requirements Network.
5.4.2. Discussion The nested contexts may interfere with understanding, particularly for a large R-net. Some shorthand notations have been proposed for conceptual graphs that provide new constructs to express some first-order logic conditions more naturally. Our only purpose here is to show that the information is captured by conceptual graphs and then transformed back into an R-net having the same components and structure as the original. This transformed R-net’s graph does not explicitly capture the real-time nature of the stimulus/response paradigm. In the next chapter, we show how additional assumptions, provided by the analyst after consulting with the creator of this diagram, allow such time-oriented features to be included. Ch. 5 79
5.5. Summary This chapter provided examples of performing steps 1 and 2 of the multiple-viewed methodology. We showed how to translate several different notations into conceptual graphs. The multiple-viewed approach accommodates existing notations and therefore is compatible with some existing software requirements development procedures. Using conceptual graphs can be useful in understanding even a single specification; however, it is their generality which is most important when we go about analyzing multiple views. Once requirements specifications in different notations are translated into conceptual graphs, we have a basis for comparing them. The next chapter shows how we determine the overlap between these multiple specifications, applying the methodology to their conceptual graph representations as described in Chapter 4. Ch. 6 80
6. A Multiple Viewed Analysis Example
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.3. Analyst’s Framework 4.4. Analysis of Multiple Viewed Requirements 4.5. A Methodology For Multiple Viewed Requirements 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.2. Data Flow Diagrams 5.3. State Transition Diagrams 5.4. Requirements Networks (SREM) 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics Ch. 6 81
8.2. Reasonableness of Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.3. Speculation 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.2. Conceptual Graphs and Logic A.3. Conceptual Graph Extensions Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
For the sake of persons of different types, scientific truth should be presented in different forms, and should be regarded as equally scientific, whether it appears in the robust form and the vivid coloring of a physical illustration, or in the tenuity and paleness of a symbolic expression. James Clerk Maxwell, 1870
This chapter illustrates the analysis of the methodology for multiple view requirements development. In Chapter 3, we showed how a participant’s view is expressed in a requirements specification (R-Spec) and then we introduced our general multiple viewed approach. Chapter 4 was a formal refinement of Chapter 3, tying the methodology in §4.5 to the conceptual graph notation (as described in Appendix A). Chapter 5 illustrated steps 1 and 2 of the methodology where each participant’s R-Spec was translated into a conceptual graph called an R- Spec-Graph. This chapter illustrates steps 3 through 8 of the methodology. As explained in Chapter 4, assumptions of each participant, in conceptual graph form (each called an A-Graph), will be gathered manually by the analyst. As defined in Chapter 4, a single view is composed of a participant’s R-Spec-Graph and zero or more of his A-graphs. The purpose of analysis under multiple views is for the analyst to create and maintain a conceptual graph meta-model of all the multiple views in order to first determine and then display the overlap. The analyst possesses the following information before any requirements development begins: Ch. 6 82
Type Hierarchy — common-sense types, e.g., PERSON, EVENT and TIME in a pre-existing hierarchy, such as in Sowa’s conceptual catalog [Sowa84]. We assume the following hierarchy: T
ENTITY EVENT TIME STATE
INFORMATION INTERVAL PROPOSITION ACT ANIMATE
PERSON ATTRIBUTE DATA DEFINITION Ch. 6 83
Canonical Graphs — “common-sense” information, defining the allowed types and link directions for relations, e.g., an event occurs at some point in time: [EVENT] —> (pt-in-time) —> [TIME]. or, an act is an event with an animate agent, object entity and recipient entity: [ACT] — —> (agent) —> [ANIMATE], —> (object) —> [ENTITY], —> (recipient) —> [ENTITY]. The rest of the analyst’s view is summarized in §4.5.3. We have already mentioned that association graph weights are heuristically determined. Since we only intend to add and subtract weights, it is the relative values of the weights that are important. For these examples, we used the following weights: cr+ +24.0 canonical common relation agreement in dependency r+ +12.0 non-canonical common relation agreement in dependency cr– –24.0 canonical common relation conflict in dependency r– –12.0 non-canonical common relation conflict in dependency d+ +3.0 shared relation has different name but same dependency d– -1.5 shared relation has different name and different dependency T+0 +50.0 concepts are of the same type T+1 +25.5 concepts have type distance of 1. T+2 +16.6 concepts have type distance of 2. T+3 +12.5 concepts have type distance of 3, etc. These numbers were chosen with the following rationale. Canonical relations (i.e., relations from the pre- existing catalog) are considered twice as strong as relations that were introduced from participants’ diagrams, because the canonical relations have definitions and meanings already associated with them. A same-named relation is considered four times as strong as a dependency because (as we have mentioned previously) a single dependency may not necessarily indicate useful information for relating multiple views. If we find several dependencies of interest, then their combined weights will be comparable to a single relation. Type distance weights are assigned a scale whereby small distance is “rewarded” with a larger weight. Experience will ultimately decide an appropriate choice for these weights. We now proceed to illustrate steps 3 through 8 of the methodology.
6.1. Analysis: First Association The previous chapter showed four different participants’ R-Specs being translated into R-Spec-Graphs. In the case of the customer’s entity-relationship R-Spec, the analyst had to manually determine the dependencies of the new relations introduced during the transformation. Once these four R-Spec-Graphs are obtained, the further steps of the methodology are applied.
Step 3. Measure 2nd-order interactions between views. The following are the strongest weight counterpart pairs for each pair of views derived from the 2nd-order association graph. Some view pairs have more than one counterpart pair shown because more than one counterpart pair had the same strongest weight. Most importantly, there are no view pairs shown for the end user’s view at all (recall that we deleted the lowest weight possible counterpart pairs), indicating that we need more information about the end user’s view before we can begin to determine its overlap.
STRONGEST NODES BETWEEN VP designer and VP tester Ch. 6 84
( VP designer NORMAL_RANGES; VP tester TYPE_MSG: { failure, else }) = 71.958 STRONGEST NODES BETWEEN VP customer and VP tester ( VP customer VITAL_SIGNS; VP tester TYPE_MSG: failure) = 35.65 ( VP customer VITAL_SIGNS; VP tester TYPE_MSG: else) = 35.65 ( VP customer VITAL_SIGNS; VP tester TYPE_MSG: { failure, else }) = 35.65 ( VP customer VITAL_SIGNS; VP tester RANGE: safe) = 35.65 ( VP customer VITAL_SIGNS; VP tester RANGE: else ) = 35.65 ( VP customer VITAL_SIGNS; VP tester RANGE: { safe, else }) = 35.65
STRONGEST NODES BETWEEN VP customer and VP designer ( VP customer PATIENT; VP designer FACTORS) = 25.925 ( VP customer PATIENT; VP designer ALARM) = 25.925 ( VP customer PATIENT; VP designer CURRENT_READINGS) =25.925 ( VP customer PATIENT; VP designer NORMAL_RANGES) = 25.925 ( VP customer VITAL_SIGNS; VP designer ALARM) = 25.925 ( VP customer VITAL_SIGNS; VP designer CURRENT_READINGS) =25.925 ( VP customer VITAL_SIGNS; VP designer NORMAL_RANGES) = 25.925 ( VP customer CURR_READINGS; VP designer ALARM) = 25.925 ( VP customer CURR_READINGS; VP designer NORMAL_RANGES) = 25.925 ( VP customer MONITOR; VP designer ALARM) = 25.925 ( VP customer MONITOR; VP designer CURRENT_READINGS) =25.925 ( VP customer MONITOR; VP designer NORMAL_RANGES) = 25.925 ( VP customer DR_NURSE; VP designer ALARM) = 25.925 ( VP customer DR_NURSE; VP designer NORMAL_RANGES) = 25.925 ( VP customer DATABASE; VP designer ALARM) = 25.925 ( VP customer DATABASE; VP designer NORMAL_RANGES) = 25.925 ( VP customer NORMAL_RANGES; VP designer ALARM) = 25.925 ( VP customer NORMAL_RANGES; VP designer NORMAL_RANGES) = 25.925 The occurrence of a single strongest node between the designer and tester’s graphs suggests that they may be assumed to be a “seed” counterpart pair; however, in this example we continue with the example to show how analysis proceeds without seeds. Examining pairs between the customer/tester and the customer/designer reveals that the R-Spec-Graphs as given are still ambiguous with respect to each other. The list of counterpart pairs between the customer and designer view (which includes every concept in the customer’s view!) shows clearly that at this stage, we cannot distinguish between the designer’s ALARM, NORMAL_RANGES, or CURRENT_READINGS, since they appear in several equally likely counterpart pairs between the customer’s and designer’s view. There are six equally likely counterpart pairs between the customer’s and tester’s view, all involving VITAL_SIGNS, suggesting that later we should query the customer for his assumptions about vital signs. The existence of many equally likely counterpart pairs at this first stage is to be expected; we do not yet have any information beyond the actual requirements specifications. Since there are several ambiguous 2nd-order counterpart pairs, we can use them as starting points for seeking additional information from the participants. In other words, we now know to ask participants for assumptions about their half of each ambiguous counterpart pair. This is shown in step 7 below. Because no counterpart pairs appear between the end user’s view and any of the other views, there is no guidance as to what to ask the end user. Ch. 6 85
Step 4. Combine two strongest graphs, and go to step 3 The strongest subgraphs were found between the customer and tester’s view, although as the results above suggest, there were quite a few equally-weighted subgraphs. We note the large ambiguity, but still pick a single representative subgraph to replace both the customer’s and tester’s view. We also include the relationships between its components in the original graphs (not shown here). In this case, the representative graph picked was:
( VP cust DATABASE; VP tester TYPE_MSG: {failure,else}) = 29.524 ( VP cust DR_NURSE; VP tester MSG_TO_NURSE_STATION) = 30.287 ( VP cust PATIENT; VP tester TYPE_MSG: failure) = 31.162 ( VP cust MONITOR; VP tester TYPE_MSG: else) = 31.819 ( VP cust CURR_READINGS; VP tester RANGE: {safe,else}) = 33.543 ( VP cust NORMAL_RANGES; VP tester RANGE: safe) = 34.527 ( VP cust VITAL_SIGNS; VP tester RANGE: else) = 35.650 These counterparts are clearly not very meaningful; they are shown here merely to show what a valid subgraph looks like — namely, where no concept in a counterpart pair appears more than once in the customer’s view nor in the tester’s view.
Step 5. Propose analyst’s R-Spec-Graph For the first association, these two steps aren’t very interesting. Recall that one of our rules for constructing the M-order association graph holds that if even one pair of components of an M-order counterpart set is not present, the M-order counterpart set is not possible. At this stage, since there are no counterpart pairs involving the end user’s view (because there were no common supertypes between its concepts and other views’ concepts), there can be no M-order counterparts yet, no matter how strongly associated might be the other three views. See the next association for more meaningful examples of these steps.
Step 6. Present results to participants. Due to the lack of any M-order counterparts, we inform the participants that we need more information. We know to ask the tester about TYPE_MSG: { failure, else } and RANGE: { safe, else }, we know to ask the customer about VITAL_SIGNS, and we know to ask the designer about ALARM, NORMAL_RANGES, or CURRENT_READINGS. Since no overlap was determined between the end user’s view and any other view, the framework offers no guidance as to what to ask the end user; he must be queried for some general assumption that the analyst can use.
Discussion After First Association We notice a lack of interesting results after the first association. Since there were no participant assumptions used in this first phase, it is not surprising that our derived overlap is weak. If mere structural combination were sufficient for adequately determining overlap, we would not need to include assumptions to find out interesting features of the overlap. The next association begins the same way as the previous one, only this time we will have the benefit of additional knowledge in the form of A-graphs which have been joined to each participant’s previous R-Spec-Graph. Then the benefits of including assumptions in multiple viewed requirements will become apparent.
6.2. Analysis: Second Association The second association actually begins by inquiring about participants’ assumptions that involve the ambiguous counterpart sets already identified. In order to provide some realistic flavor to the process, the participants are not directly responsive to the particular questions asked by the analyst, although they all offer additional information that matters to them. Ch. 6 86
Step 7. Obtain assumptions from each participant. The following assumptions are gleaned from each participant at this stage: The customer has nothing to say now about the VITAL_SIGNS; however, he mentions that when the alarm sounds, he wants to know the response time between the time a person hears the alarm and the person treats the patient. The designer describes a query-response process with respect to a database — some question is asked of the database, and a set of records is given back as the answer. The tester is asked about TYPE_MSG and RANGE, but at this moment he is interested in measuring the time response at a test point in his R-net. That is, he wants to state that the the nurse’s station message is sent no later than some maximum time limit from the time a message first arrives from a device. We had no specific questions to ask the end user; he mentions only the fact that the alarm goes to some medical staff person.
Step 8. Re-write assumptions in conceptual graph form. a. For each participant’s assumption, construct an A-Graph that expresses it. The following A-Graphs were formed by the analyst working with the previous assumptions. Figure 6.1(a) shows the customer’s response-time assumption; Figure 6.1(b) shows the designer’s query-response assumption; Figure 6.1(c) shows the end user’s brief assumption, and Figure 6.1(d) shows the tester’s time limit assumption.
VP customer SYS pms A-GRAPH: response_time VP designer SYS pms A-GRAPH: query-response ALARM ALARM recipient pt-in-time ANIMATE ANSWER _TIME object
recipient
PERSON RESPONSE QUERY agent agent RECORD: result _TIME: *r difference {*}
recipient
object ASK DATA- TREAT- TREAT BASE agent MENT pt-in-time _TIME QUERY < DATA. ANSWER < ACT. ALARM < EVENT. TREAT_TIME < TIME. ASK < ACT. DATABASE < ANIMATE. TREATMENT < EVENT. RESPONSE_TIME < INTERVAL. RECORD < DATA. ALARM_TIME < TIME. PERSON < ENTITY. (b) (a)
VP tester SYS pms A-Graph: test_point1
MSG: MSG_ ARRIVAL object pt-in-time From_ ARRIVES _TIME Device
VP enduser SYS pms A-Graph: med_person TIME_ RESPONSE MED_ ALARM LIMIT: less_than recipient _TIME: *r difference PERSON Limit
MED_PERSON < PERSON. MSG: MSG_ TIME_OF_ To_Nurses object pt-in-time (c) _Station LEAVES RESPONSE
MSG_ARRIVES < EVENT. ARRIVAL_TIME < TIME. MSG_LEAVES < EVENT. RESPONSE_TIME < INTERVAL. TIME_OF_RESPONSE < TIME. TIME_LIMIT < INTERVAL. (d) Ch. 6 87
Figure 6.1. Assumptions For Patient-Monitoring. b. Include A-graph in VP P by joining A-graph to P’s R-Spec-Graph. To join an A-Graph to its respective participant’s R-Spec-Graph requires at least one common concept in both the A-Graph and the R-Spec-Graph. In fact, the problem of where to join the graphs (or if they can be joined at all) is just a smaller version of our general problem of combining views as graphs — we have two graphs (although in the same view) that we seek to overlap. The association graph technique as given was applied to the customer’s R-Spec-Graph in Figure 5.2 and Figure 6.1(b). Its strongest 2nd-order counterpart pair was between [ DR_NURSE ] in the R-Spec-Graph and [ PERSON ] in the A-Graph* . We therefore join the assumption by a line-of-identity between these two concepts. In the designer’s view, [ QUERY ] in Figure 6.1(b) is joined to [ FACTORS ] in Figure 5.4. In the end user’s view, Figure 6.1(c) is joined to Figure 5.6 via the concept [ ALARM ] in both figures. In the tester’s view, the two messages [ MESSAGE: From_Device ] and [ MESSAGE: To_Nurses_Station ] are joined to their identical concepts in the R-Spec-Graph.
Step 3. Measure 2nd-order interactions between views. Assuming the same weight values as before, the following strongest-weight 2nd-order counterpart pairs were obtained:
STRONGEST NODES BETWEEN VP customer and VP designer ( VP cust DR_NURSE; VP designer ANIMATE) = 156.423 ( VP cust DR_NURSE; VP designer DATABASE) = 156.423 ( VP cust ALARM; VP designer ANSWER) = 156.423 ( VP cust ALARM; VP designer ASK) = 156.423 ( VP cust TREATMENT; VP designer ANSWER) = 156.423 ( VP cust TREATMENT; VP designer ASK) = 156.423
STRONGEST NODES BETWEEN VP customer and VP enduser ( VP cust DR_NURSE; VP enduser MED_PERSON) = 444.550
STRONGEST NODES BETWEEN VP customer and VP tester ( VP cust ALARM; VP tester MESSAGE_ARRIVES) = 252.308 ( VP cust RESPONSE_TIME; VP tester RESPONSE_TIME) = 252.308 ( VP cust TREATMENT; VP tester MESSAGE_ARRIVES) = 252.308
STRONGEST NODES BETWEEN VP designer and VP enduser ( VP designer ANIMATE; VP enduser MED_PERSON) = 137.500 ( VP designer ANSWER; VP enduser ALARM) = 137.500 ( VP designer ASK; VP enduser ALARM) = 137.500 ( VP designer DATABASE; VP enduser MED_PERSON) = 137.500
STRONGEST NODES BETWEEN VP designer and VP tester ( VP designer RECORD; VP tester MSG: To_Nurse_Station) = 248.442
*Using a separate association graph for each joining may not always be successful (i.e., there may not be any resulting distinguishable concepts), in which case the analyst must then use his judgment in joining the graphs. Ch. 6 88
We have thus identified two 2-view counterpart pairs that are unambiguous: ( VP cust DR_NURSE; VP enduser MED_PERSON) = 444.550 ( VP designer RECORD; VP tester MSG: To_Nurse_Station) = 248.442 The rest of the pairs are ambiguous, since in each strongest group there is more than one pair sharing the same strongest weight, and in each group there is a concept which appears in at least one other counterpart set. For instance, between the views customer and designer, there are two possible counterpart pairs that include the customer’s concept DR_NURSE; therefore we cannot decide whether it is a counterpart to ANIMATE or DATABASE in the designer’s view.
Step 4. Combine two strongest graphs, and go to step 3 There were four strongest-weighted subgraphs between the customer and tester’s view, so we chose one of them:
( VP cust ALARM; VP tester MSG: To_Nurses_Station) = 190.651 ( VP cust ALARM_TIME; VP tester ARRIVAL_TIME) = 193.613 ( VP cust TREAT_TIME; VP tester TIME_OF_RESPONSE) = 193.613 ( VP cust RESPONSE_TIME; VP tester RESPONSE_TIME) = 252.308 ( VP cust TREATMENT; VP tester MESSAGE_ARRIVES) = 252.308 We remove the customer and tester’s graphs and replace them with just the graph [cust, tester] above, along with the relations between its components. A 3rd-order association graph is constructed as we explained in §3.2.4 and §4.5.1. A single strongest 3rd-order subgraph is as follows:
(VP enduser ALARM; VP [cust,tester] [TREATMENT,MESSAGE_ARRIVES]) = 210.0 (VP enduser READINGS_OFF_NORMAL; VP [cust,tester] [ALARM, MSG: To_Nurses_Station) = 210.0 We re-write this in a clearer fashion:
(VP cust TREATMENT VP enduser ALARM VP tester MESSAGE_ARRIVES) = 210.0 (VP cust ALARM VP enduser READINGS_OFF_NORMAL VP tester MSG: To_Nurses_Station) = 210.0 This intermediate step shows how the methodology works; it also shows how including assumptions leads to more reasonable results. Using the above 3rd-order subgraph as the strongest graph, we then associate it with the last remaining view (the designer’s). In seeking a 4th-order subgraph, no 4th-order association nodes remain, because the particular nodes in the strongest 3rd-order subgraph above did not share common subtypes with the original nodes in the designer’s graph.
Step 5. Propose analyst’s R-Spec-Graph Since there were no association nodes left after the 4th-order association (not even ambiguous ones), we cannot propose any subgraph that captures overlap between all four views. We use the intermediate results to guide the analyst in querying participants about the ambiguous 2nd-order nodes as before. a. Find strongest M-order nodes. b. Identify strongly-consistent M-order association sub-graph. Find strongest set of M-order nodes node( C1; C2; ... ; CM ) such that there is no Ci that appears in more than one node There is no strongly-consistent 4th-order association sub-graph. We still cannot distinguish between the designer’s ASK and ANSWER. We have two possible counterparts in the customer’s view to the tester’s MESSAGE_ARRIVES, and two possible counterparts in the designer’s view to the end user’s MED_PERSON. Since these were the strongest weights determined, we now know that on the next association we should query the designer about his concept ANSWER and/or his concept ASK to obtain further assumption that might distinguish Ch. 6 89 them; likewise we should query the tester for further information about his concept MESSAGE_ARRIVES, and the end user for further information about the concept MED_PERSON.
Step 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. In this example, we will use English as our description, and forego performing step 6a from Chapter 4. b. Paraphrase the analyst’s R-Spec-Graph into English for validation and discussion. Since there is no 4th-order subgraph, we need to seek further assumptions about the 2nd-order counterpart pairs above c. Evaluate results through interaction. The participants are asked to comment on the counterpart pairs identified so far. This discussion may be the most valuable part of multiple-viewed analysis; however, it lies outside the framework itself. Afterward, with altered views of the system, we continue the development process by gathering additional assumptions and/or changing the original requirements specifications.
6.3. Analysis: Third Association The third association shows how additional assumptions continue the process of refining the analysis and distinguishing counterparts.
Step 7. Obtain assumptions from each participant. The following assumptions are gleaned from each participant at this stage: The customer is asked about the three ambiguous counterparts in the above association. His response is that the vital signs go into a monitor and current readings come out. The current readings are then compared to the normal ranges. The designer is questioned about his concepts of ASK and ANSWER. He replies simply that ASK occurs before ANSWER. The tester is asked to differentiate between MESSAGE_ARRIVES and MESSAGE: To_Nurses_Station and relate them to his original specification. Although the difference seems obvious to the tester, he offers the information that the message arriving causes the message from device to appear, and that the message leaving causes the message to the nurse’s station to appear.
Step 8. Re-write assumptions in conceptual graph form. a. For each participant’s assumption, construct an A-Graph that expresses it. The following A-Graphs were formed by the analyst working with the previous assumptions: [ SYS pms VP customer A-Graph: readings_etc : [ VITAL_SIGNS ] —>
[ SYS pms VP designer A-Graph: ask_before_answer: [ ASK ] —> (precedes) —> [ ANSWER ] ]
[ SYS pms VP tester A-Graph: messages_etc : [ MESSAGE_ARRIVES ] —> (causes) —> [ MSG: From_Device ] [ MESSAGE_LEAVES ] —> (causes) —> [ MSG: To_Nurses_Station ] ] b. Include A-graph in VP P by joining A-graph to P’s R-Spec-Graph. Ch. 6 90
Since these assumptions are based on the original R-Spec-Graphs in their same views, we join them as follows: The customer’s VITAL_SIGNS, NORMAL_RANGES, and CURRENT_READINGS in A-Graph readings_etc are all joined to their respective concepts in the R-Spec-Graph. The designer’s ASK and ANSWER concepts are joined to his already-existing A-Graph from the previous association. The tester’s A-Graph’s four concepts all appear in the previous A-Graph. They are joined as appropriate.
Step 3. Measure 2nd-order interactions between views. Assuming the same weight values as before, the strongest 2nd-order association nodes are as follows:
STRONGEST NODES BETWEEN VP customer and VP enduser ( VP customer DR_NURSE; VP enduser MED_PERSON) = 444.550
STRONGEST NODES BETWEEN VP customer and VP designer ( VP customer DR_NURSE; VP designer DATABASE) = 245.374
STRONGEST NODES BETWEEN VP customer and VP tester ( VP customer ALARM; VP tester MESSAGE_ARRIVES) = 252.308 ( VP customer RESPONSE_TIME; VP tester MESSAGE_ARRIVES) = 252.308 ( VP customer TREATMENT; VP tester MESSAGE_ARRIVES) = 252.308
STRONGEST NODES BETWEEN VP customer and VP tester ( VP customer ALARM; VP tester MESSAGE_ARRIVES) = 252.301 ( VP customer RESPONSE_TIME; VP tester RESPONSE_TIME) = 252.301 ( VP customer TREATMENT; VP tester MESSAGE_ARRIVES) = 252.301
STRONGEST NODES BETWEEN VP designer and VP enduser ( VP designer DATABASE; VP enduser MED_PERSON) = 179.925
STRONGEST NODES BETWEEN VP designer and VP tester ( VP designer RECORD; VP tester MSG: To_Nurse_Station) = 248.442 We see that the end user’s MED_PERSON is now unambiguously a counterpart to the customer’s DR_NURSE. The tester’s MSG_ARRIVES cannot be distinguished from the customer’s ALARM, RESPONSE or TREATMENT.
Step 4. Combine two strongest graphs, and repeat step 3 The strongest subgraph is the same as in the previous association — namely the customer and tester’s views. We combine them as before, and perform the 3rd-order association, again giving the same resulting strongest 3rd-order subgraph between the customer’s, end user’s and tester’s views. We would expect such behavior, since the assumptions added in this association comprise few concepts. The strongest 4th-order subgraph is different however. We get the following unambiguous 4th order subgraph with two 4th-order association nodes:
( VP designer ASK; VP [cust,enduser,tester] [ALARM, READINGS_OFF_NORMAL, MSG: To_Nurses_Station) = 94.677 ( VP designer ANSWER; VP [cust,enduser,tester] [TREATMENT,TREAT_PT, MESSAGE_ARRIVES]) = 80.322 Now the tester’s MESSAGE_ARRIVES is an unambiguous counterpart to customer’s TREATMENT. Ch. 6 91
Step 5. Propose analyst’s R-Spec-Graph a. Find strongest M-order nodes. These were listed above. b. Identify strongly-consistent M-order association sub-graph. Find strongest set of M-order nodes node( C1; C2; ... ; CM ) such that there is no Ci that appears in more than one node. We are now in a position to propose an analyst’s combined graph that captures the overlap as determined so far. The analyst’s graph consists of the two 4th order counterpart sets identified in Step 4, along with the only direct relationship between them (from the customer’s original A-Graph): [ VP customer ALARM VP designer ASK VP enduser READINGS_OFF_NORMAL VP tester MSG: To_Nurses_Station ] —> (result) —> [ VP customer TREATMENT VP designer ANSWER VP enduser TREAT_PT VP tester MESSAGE_ARRIVES ]
Step 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. In this example, we will use English as our description. b. Paraphrase the analyst’s R-Spec-Graph into English for validation and discussion. We paraphrase the analyst’s R-Spec-Graph using each of the views’ original relationships between the established counterparts, as follows: The following are counterparts to each other: customer’s entity alarm, designer’s act ask, end user’s data readings_off_normal and tester’s message “to nurse’s station”. The following are also counterparts: customer’s event treatment, designer’s act answer, end user’s state treat_pt, and tester’s event message arrives. The customer’s alarm, designer’s ask, end user’s readings_off_normal and tester’s “to nurse’s station” result in the customer’s treatment, the designer’s answer, the end user’s treat_pt and tester’s message_arrives. The first two sentences was obtained from the 4th-order counterparts. The third sentence was obtained from the customer’s ALARM and TREATMENT from A-Graph response_time. c. Evaluate results through interaction. The participants are asked to comment on the paraphrase as to whether they understand it and whether they agree with it. 6.4. Results of Analysis This section summarizes the findings of the previous analysis. These results are to be presented to the participants, initially in paraphrase form, in order to show the overlap between views. We could also use the extraction (“B”) algorithms from Chapter 5 to display the combined graph in four separate ways: as an entity- relationship diagram, a data flow diagram, a state transition diagram, or an R-net. This would allow each participant to examine the overlap in his own terms, although clearly not all the overlap would be expressible for each participant. We have already discussed the problem of how to best present the results of analysis. Ch. 6 92
Counterparts in Patient-Monitoring The following counterparts between views have been identified during analysis: [ VP cust ALARM [ VP customer TREATMENT VP designer ASK VP designer ANSWER VP enduser READINGS_OFF_NORMAL VP enduser TREAT_PT VP tester MSG: To_Nurses_Station ] VP tester MESSAGE_ARRIVES ]
Assumptions in Patient-Monitoring The assumptions were shown above in Figure 6.1, and at the beginning of the third association. See Chapter 8 for a complete list.
Inconsistencies in Patient-Monitoring Of course, one goal of this technique is to resolve inconsistencies as they are detected. Still, some potential inconsistencies remain. ALARM being a subtype of both EVENT and DATA may be an inconsistency. To resolve it, we may leave intact the two ALARMs, one an EVENT, the other DATA, and then try to relate them by gathering further assumptions.
Incompleteness in Patient-Monitoring One indication of incompleteness is the presence of a strong counterpart between fewer than M views, in which case we might want to assume its presence in the views in which it is missing. For example, the customer’s alarm, the end user’s alarm, and the designer’s answer form a 3-view counterpart. We can surmise that somewhere in the tester’s view there is a concept that is a counterpart to the answer. Further associations of analysis may uncover it.
6.5. Summary This example illustrates the benefit of explicitly including pre-existing assumptions. Adding a single assumption to the end user’s view, [ A-Graph :med_person ], allowed us to determine a unique counterpart set for the four views. In the customer’s view, the strongest counterparts were found in the assumptions. Inclusion of assumptions decreases ambiguity, as measured by the number of same-weight nodes in the association graphs. This is what we would expect: that providing more information increases our ability to distinguish between similar concepts. As the quality of analysis improves with each association, more and more assumptions will be gathered and more distinctions will be possible. Note that some counterparts were between same-named concepts in different views. We did not use the names themselves in the analysis, however, in deciding that they were counterparts. Our determination was based entirely upon their meaning in their respective views, as captured by their conceptual graph representations. Interaction between assumptions and an R-Spec-Graph was demonstrated by showing how a graph representing assumptions can be joined to the specification graph, thereby further specializing it. The overlap between the views was then expressed formally by finding a common generalization from a joined conceptual graph. Obviously more detail needs to be incorporated into the body of pre-existing assumptions; this chapter merely showed how to use the assumptions in the development of multiple-viewed requirements. This example illustrated the flavor of a multiple-viewed software requirements development approach. Each step of the methodology was shown with examples taken from two typical requirements settings. The purpose of this chapter was to demonstrate that conceptual graphs support multiple-viewed requirements development. We did not attempt to develop exhaustive, definitive requirements for either example system. The role of pre-existing assumptions was illustrated to show how requirements can be augmented by explicitly considering them. Ch. 7 93
7. Validating Multiple Viewed Analysis
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View A Participant’s Requirements Specification A Participant’s Pre-Existing Assumptions 2.2. Example Requirements and Assumptions Sample Participants 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst Requirements Analyst’s Tools Requirements Analyst’s Process 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views Counterparts Dependency 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap Ch. 7 94
4.4.2. Analyzing Overlap Association Graph 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram An Entity-Relationship R-Spec An Entity-Relationship R-Spec-Graph 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram A Data Flow R-Spec A Data Flow R-Spec-Graph 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram A State Transition Diagram R-Spec A State Transition Diagram R-Spec-Graph 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network A Requirements Network R-Spec A Requirements Network R-Spec-Graph 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Discussion After First Association 6.2. Analysis: Second Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and go to step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. 6.3. Analysis: Third Association Step 7. Obtain assumptions from each participant. Step 8. Re-write assumptions in conceptual graph form. Step 3. Measure 2nd-order interactions between views. Step 4. Combine two strongest graphs, and repeat step 3 Step 5. Propose analyst’s R-Spec-Graph Step 6. Present results to participants. Show analyst’s R-Spec-Graph in original notations or English. In this example, we will use English as our description. 6.4. Results of Analysis Counterparts in Patient-Monitoring Assumptions in Patient-Monitoring Inconsistencies in Patient-Monitoring Ch. 7 95
Incompleteness in Patient-Monitoring 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics Counterparts Participant Assumptions Inconsistencies/Ambiguities 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model Relative Cost of Requirements Errors Proportion of Errors Identified By Multiple Views Multiple Views’ Cost 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap Comparison To Empirically Determined Overlap Ex Post Facto Judgments 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings Conceptual Graphs Utility Overlap Characteristics 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach Limitations of Conceptual Graphs Limited Support Over Life Cycle Granularity Limitations 9.5. Summary 10. Conclusion 10.1. Summary of Thesis Methodology For Identifying Multiple Viewed Requirements Requirements Analyst’s Framework and Knowledge Base Participants’ Requirements In Conceptual Graphs Participants’ Assumptions As Conceptual Graphs Determination of Overlap Between Views 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework Non-Functional Requirements Re-Use Of Assumptions 10.3. Speculation Potential for Simulating Requirements Ch. 7 96
Automated Acquisition of Assumptions Convergence of Views 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.1.1. Nodes and Links Concept Relation Actor A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules Copy Restrict Join Simplify A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations Display Form Linear Form Paraphrase Form Transformations Among Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.1.1...... Compilation Algorithm 1a B.1.2...... Extraction Algorithm 1b B.2. Data Flow Translation Scheme B.2.1...... Compilation Algorithm 2a B.2.2...... Extraction Algorithm 2b B.3. State Transition Translation Scheme B.3.1...... Compilation Algorithm 3a B.3.2...... Extraction Algorithm 3b B.4. Requirements Network Translation Scheme B.4.1...... Compilation Algorithm 4a B.4.2...... Extraction Algorithm 4b B.5. Summary References
When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science. Ch. 7 97
William Thomson, Lord Kelvin, 1894
Although readers may believe intuitively that using multiple views increases the quality of whatever requirements are produced, we would like specific ways to determine whether these requirements are, in fact, better than the requirements that would be produced using the other methods. This chapter describes a validation framework to evaluate the effectiveness of a multiple-viewed approach in analyzing multiple views of requirements. The framework consists of criteria on which to base comparisons between this multiple-viewed approach and existing approaches. We start with an important caveat. We have not claimed that this multiple viewed approach possesses all the power of existing approaches and more. Our framework cannot capture all characteristics of existing views; previous chapters have discussed some of the framework’s limitations. We exploit multiple views in order to improve the quality of overall requirements in conjunction with the strengths of existing approaches. In this chapter we show how to measure those improvements to requirements that are made possible by the explicit inclusion of multiple views. This chapter describes the validation framework itself. The next chapter shows how the evaluation framework can be applied to the patient-monitoring system of Chapters 5 and 6. Evaluating the benefits of multiple views involves two aspects: cost and quality. Since costs can be measured (as Lord Kelvin suggests), it is important to show that software development costs less using multiple views than the cost of developing software without them. In addition, we want to show that multiple views improve the quality of requirements as compared to requirements developed under other methods, i.e., their ease of understanding, their reasonableness, and other hard-to-measure, but nonetheless important characteristics. The validation procedure consists of three parts: 1. Derive the list of overlapping characteristics from multiple views and compare them with those from other methods. a. Counterparts. b. Explicit participant assumptions. c. Inconsistencies and/or ambiguities. 2. Measure cost savings in detecting or identifying multiple viewed characteristics. a. Make manual estimates based on human judgment, either prior to development or ex post facto. b. Measure the actual costs to fix overlap errors after they occur. c. Measure the total cost to fix all requirements errors at all stages of development, and determine its proportion to the total cost of all software errors. 3. Obtain judgments of overlap characteristics’ reasonableness from the list of multiple-viewed characteristics. a. Compare overlap characteristics determined under the framework with overlap determined by manual means. b. Gather opinions as to the validity and relative importance of each identified characteristic. The rest of this chapter discusses each of these steps more fully.
7.1. Overlap Characteristics Previous chapters described various forms of overlap that can be established using the framework. The validation process begins by listing those occurrences of overlap that were detected, and compare them to the overlap detectable using other methods. Previous chapters already described these characteristics and showed the details of how they are obtained from an original collection of views; they are repeated here to emphasize their role in the evaluation framework. Instances of incompleteness may be identified by multiple views if one considers that parts of one view could be included in another view. We have not proposed any formal techniques for this, however, so we do not discuss it further here. Ch. 7 98
Counterparts The list of counterparts is the core of multiple viewed analysis. Counterparts capture the basic overlap between views, showing how the views are related through common objects. Identification of counterparts shows that multiple viewed analysis identifies information that is useful to all participants, and that would otherwise not be available. Other methods use ad-hoc knowledge to derive certain similarities between models. Software through Pictures [Wasserman86] provides a few specific instances where overlap is captured, such as an arc label in data flow being compatible with an entity-relation entity, but its determination of overlap instances is confined to those having the same name. In Structured Analysis [Yourdon79], it is expected that for every data store in a data flow diagram there will exist an entity in an ER diagram. Such ad-hoc knowledge is incorporated in multiple views by choosing types into which the original model is translated that captures similarity in their meaning. The multiple viewed approach can obtain overlap from other information about the objects.
Participant Assumptions Multiple views help identify implicit assumptions by leading the analyst to ask questions about the ambiguous counterpart sets he identifies. Making these assumptions explicit is a vital part of multiple views, since only when assumptions are explicit can they be examined by all participants. Although some of these assumptions could be identified through manual single-viewed means (often by a skilled analyst, e.g., as in SADT [Ross77] or CORE [Mullery79]), the multiple-viewed approach quickly pinpoints those areas where additional knowledge (i.e., pre-existing assumptions) are needed to distinguish counterparts. For example, Finkelstein and Fuks [Finkelstein89] address the importance of participant assumptions in modeling a dialog, but it is not clear how those assumptions are made explicit during the course of requirements development.
Inconsistencies/Ambiguities If a counterpart cannot be found or if several equally-likely counterparts are found, then the views involved contain an inconsistency with respect to multiple views. Since each participant’s view is previously examined for its own internal consistency, any inconsistency or ambiguity identified by multiple views will be in addition to whatever could be determined through self-consistency checks alone. In some cases, if a counterpart is found in all but one view, we may be able to propose that it needs to be included in that view. This approach needs more study before any formal techniques can determined for adding missing pieces to views.
7.2. Cost Considerations Of Multiple Views The methods of multiple views do not appear to be very expensive. Furthermore, mistakes in requirements are very expensive to correct at later stages. Roman estimates that mistakes in requirements may cost up to 100 times more to correct later [Roman85]; Davis says up to 200 times [Davis90]. We therefore believe that using multiple views to catch even a few errors at the early stages will pay for itself in reduced re-working over the software’s lifetime. We will form a preliminary model of multiple views’ cost effectiveness, from which we can attempt to measure costs in an actual project. We should point out that for certain critical applications, the cost of requirements is not a major factor. In these cases, requirements are not so much constrained by cost as by our inability (at any price) to find errors that prevent life-threatening situations brought on by software failures.
7.2.1. A Requirements Error Cost Model In order to determine the cost-effectiveness of applying multiple views to requirements development, we must answer three questions: 1. What is the cost of requirements errors as compared to the cost of all software errors over the entire life cycle? 2. What is the proportion of requirements errors at each stage that can be avoided by using multiple views at the requirements stage? Ch. 7 99
3. What is the cost per view of using multiple views? In order to answer these two questions, we will propose a two-part cost model. This model considers only errors that are detected at some point in the life-cycle. The following symbols are used:
W cost of including one additional view in a multiple viewed analysis
n the number of views being considered
Exy is the number of software errors occurring during software development stage x that are detected and corrected development stage y
Cy is the relative cost to detect/repair an error detected at stage y. where x and y are the first letter of one of the following six stages: Requirements, Design, Coding, Unit testing, Acceptance testing, Maintenance. Davis [Davis90, (p. 23)] gives the following figures for the Cy’s, derived from several studies: CR = 1-2; CD = 5; CC = 10; CU = 20; CA = 50; CM = 200
Relative Cost of Requirements Errors The following is a simple requirements error cost model. We start with the table in Figure 7.1 containing the number of errors occurring and detected at various stages of development: Ch. 7 100
Number of Stage errors repaired Stage Require- Acceptance Main-tenance occurred ments Design Coding Unit testing testing Require- ments ERR ERD ERC ERU ERA ERM Design EDD EDC EDU EDA EDM Coding ECC ECU ECA ECM Unit testing EUU EUA EUM Acceptance testing EAA EAM Main-tenance EMM
Figure 7.1. Errors In the Software Development Lifecycle.
Using the above symbols, the total cost of software errors is
M y Ctotal =  Cy  Exy y = R x = R We are interested only in the cost of those errors originating with requirements, i.e., only CRy. In Figure 7.1, the ERy’s are shown inside a double border. The cost of fixing requirements errors, CRy, is therefore M E CRy = ÂCy Ry y = R We now face the task of determining values for the percentage of errors at each stage that are attributed to requirements. Ideally, we would obtain numbers for each of the Exy’s in every cell; then multiply by the preceding cost constants (Ci’s) to determine the cost of repairing errors at each stage. This model assumes that the cost of fixing an error at a given phase is independent of the error’s origin; e.g., during the unit testing phase, a requirements error costs as much to fix as does a coding error. For each phase, we are interested only in the value of ERy and the sum of the other Exy’s, to get the proportion of requirements errors. Although we do not have accurate values for these numbers, some can be estimated from previous studies, as summarized in [Davis90]. In one project, 56% of all bugs detected were traced to errors in requirements; however, these bugs are not broken down by the stage in which they were detected, so their correction cost cannot be determined. Another study by Boehm suggests that ( ExA + ExM) / Etotal is 56% and that (ERA + ERM
+ EDA + EDM) / Etotal is 45%; however, these figures are not broken down further between requirements and design. Once numbers have been obtained for this table, the proportional cost of fixing requirements errors over the entire life cycle is simply CRy / Ctotal. This allows us to estimate the actual costs saved by using multiple views.
Proportion of Errors Identified By Multiple Views In one study, non-clerical requirements errors comprised 77% of all requirements errors. The non-clerical errors were categorized as one of five types, in the following proportions (from [Basili81]): Ch. 7 101
Incorrect fact 49 % Omission 31 % Inconsistency 13 % Ambiguity 5 % Misplacement 2 % We can estimate multiple views potential benefit by identifying those types of errors that it can detect. Three types of errors can be found using multiple views. Finding a conflict under multiple views can identify some errors of inconsistency. Finding indistinguishable counterparts leads us to conclude an instance of ambiguity exists. Explicitly including participants’ pre-existing assumptions can identify some errors of omission. We therefore conclude that multiple views can capture at most 49 % (31% + 13% + 5%) of non-clerical requirements errors, or 38% (49% * 77%) of all requirements errors. We need also to estimate the proportion of requirements errors detected at each stage that could have been detected by multiple views at the requirements development stage. In particular we need to identify the proportion of requirements errors that would not be detected until the later stages. Knowing this proportion is important due to the increased cost leverage in detecting unit testing and/or maintenance errors. Since the relative cost of the delayed detection of these errors is 50-200 times that of detecting them early, if we can determine that multiple views could eliminate even a few of the later errors, its cost effectiveness will be enhanced. For now, we will make the naïve assumption that errors detectable by multiple views are evenly distributed among all phases of development.
Multiple Views’ Cost In measuring multiple views’ cost, we want to emphasize the relationship between requirements development and the succeeding stages of development. It is expected that using multiple views will incur additional requirements costs above that needed for single-viewed requirements; however, that cost will be re-paid in the long run by improved requirements. Since a large proportion of development costs are incurred by use of human resources, a method such as this one that allows more automated analysis will save human time and effort for other tasks, thus lowering overall costs. The cost of using multiple views is based on the fact that overlap is analyzed between any pair of views. Assuming that the cost of determining overlap between any two views is a constant W, then the cost for n views will be Wn(n – 1)/2. Conceptual graphs may not ease this complexity, since each view forms a separate set of graphs that must be compared to each other view. Since some of the overlap determination may be automatable through the multiple viewed approach in this thesis, we may be able to reduce W for a given set of views. Actual experience is needed to obtain values for W. We can make some working assumptions about multiple views to estimate their effectiveness relative to total software error costs. Let us assume that including one additional view allows us to detect a constant fraction V1 of all requirements errors that are detectable by multiple views (38%, see above). We might naïvely assume that we simply need to include n views such that n*V1 = 1; however, including an additional view incurs additional cost. We will now determine the relationship between the cost per view W and n. Assuming also that the errors detectable by multiple views are equally distributed among all the phases of development, the benefits (reduced cost) of using n multiple views relative to the total error cost is just n * V1 * 0.38 * CR. Since the cost per view is assumed to be the constant W, we can say that multiple views are only cost effective when their benefit outweighs their cost, or when
Wn(n – 1) / 2 < n * V1 * 0.34 * CRy
Rewrite this so that the right-hand side forms an upper limit on W / V1: W 0.76 * CRy < V1 (n – 1) Since the limit approaches zero for increasing n, there will be some upper limit on the number of useful views for which multiple views will be cost effective. The preceding discussion made some assumptions that may not be valid. For example, V1 (the fraction per view of detectable errors) is probably not a constant for every view. We also assumed that the distribution of Ch. 7 102 detectable errors was uniform across all phases of development, an assumption for which we have no evidence. Testing these assumptions in actual software projects will lend more insight into our cost analysis. When we have learned more, the approach given here can be adapted to more accurate assumptions.
Another cost incurred by using multiple views is the increase in the complexity of requirements, and the additional mental effort required to understand them. This cost is difficult to measure; moreover, in a sense we must always be willing to pay it, since the alternative is to not consider the additional requirements at all and suffer the resulting consequences. It is possible, however, that the additional complexity of multiple viewed requirements may itself make them more error-prone or harder to manage than current requirements methods. The previous cost model did not address this issue, except to say that the cost per additional view increases with O(n2). Although we believe that such complexity costs are well worth the benefits to requirements quality, this somewhat pessimistic perspective must nevertheless must be considered.
7.2.2. Measuring Actual Projects In order to measure actual cost savings of multiple views, we can try two different approaches. Each approach may be used both in comparing multiple viewed requirements to single-viewed requirements, as well as comparing the approach described in this thesis with other multiple-viewed approaches. First, we can consider several actual projects that are beginning their requirements phase, perform the multiple viewed analysis on each one (while keeping track of the cost of analysis), and simply save the results without telling the participants about them. Then as one project is finishing its design phase, we could inform its participants about our results, and measure how much it costs them to fix the design. As another project finishes its implementation phase, we could do the same, and measure the cost of fixing the implementation to comply with the changed requirements, and so on. This method would be quite expensive, since it would mean affecting several actual software projects. We would also have to consciously withhold information that we believe might significantly improve participants’ efforts, perhaps leading to an ethical conflict and possibly affecting morale. Nevertheless, doing so would provide accurate measurement of re-working costs without having to determine how knowledge of overlap affects mental models. A second (and probably less accurate) approach to measure the cost savings would be to use multiple viewed analysis at the beginning of development and make the results immediately available to participants, thus presumably improving the quality of their requirements and subsequent development. At any point, participants could be asked to estimate the amount of effort saved by already having overlap characteristics in hand; however, this involves knowledge about cost factors during development that are quite vague. A more useful estimate would be obtained after detailed design and implementation, at which point participants might be better able to determine how much more work they would have had to do. Both these varieties of the second approach are liable to result in under-estimates, since there is a tendency, once an error is known, to think that it would have been easy to find and correct. Using multiple viewed requirements adds an additional cost to software development, particularly during requirements development. Although this framework may be useful for smaller systems’ requirements, its cost may be difficult to justify in those cases. This is not meant to imply that multiple views don’t exist or aren’t important for smaller systems, only that the cost of analyzing them may not be cost-effective for a small system.
7.3. Reasonableness of Overlap Since we have repeatedly argued that requirements are a human-centered activity, it is important to validate the results of multiple views against human judgments, to ensure that any resulting requirements characteristics are reasonable, even if they may be somewhat unexpected. This section outlines some aspects of reasonableness that may be examined by obtaining human judgments that can be compared to the overlap characteristics determined by the framework. Human judgments may themselves be erroneous, of course, if they are based on an incorrect intuitive understanding of the proposed system, but they nevertheless provide some confidence that the requirements which Ch. 7 103 are augmented by multiple-viewed analysis will reflect actual needs, rather than mere artifacts of the particular requirements specification techniques incorporated. The translation schemes in the multiple viewed approach (see Appendix B) attempt to capture some of the semantic content of a requirements specification in terms of general concepts. By carefully choosing translation strategies, generalized overlap features between notations is captured by the fact that each notation’s translated concepts will be similar or dissimilar in their conceptual graph formulation. The translation schemes ensure that similar things in different notations will be translated into similar concepts.
Comparison To Empirically Determined Overlap One comparison method is to give the originating R-Specs to some test subjects (either the actual participants or other experienced developers), then ask them to find as many occurrences of consistency, inconsistency, dependency and incompleteness as they can. (A short description of each quality may precede the evaluation.) This should be done before the multiple viewed analysis is performed, so as not to bias the answers in favor of those occurrences that are identified by the analysis. The answers should, however, be hidden from the requirements analyst, so as not to bias subsequent analysis which involves some judgments on his part. Only after the analyst has completed his work should the manual list be revealed. The purpose of this first procedure is to begin our measure of the completeness of a multiple-viewed approach by comparing our results to an “oracle” list; i.e., does it capture every interesting part of the overlap between views? In fact, it is unlikely that we will be able to capture them all — such a comparison will, however, suggest further areas of analysis that we might develop. To further refine our measurement of overlap’s reasonableness, we may ask several participants to decide the relative importance of overlapping characteristics. Such judgments can be performed both on their previously- determined manual list and on the list obtained using the framework. The purpose is to determine whether multiple views captures the most important instances of overlap. Clearly, if our analysis does not capture the most important ones, it is less useful in reducing important errors in requirements. Again, identifying important areas that are overlooked will help us determine where multiple viewed analysis is deficient, and where we should concentrate our efforts at improving them.
Ex Post Facto Judgments A less useful approach to evaluation can be applied after multiple viewed analysis has been performed. Actual participants can then evaluate each instance of identified overlap to decide whether or not the overlap actually exists. This technique is less useful because it does not consider any instances of overlap that were not identified by the framework; the previous evaluation technique would allow such instances to be considered. Still, ex post facto evaluation of the benefits of multiple viewed requirements is easy to do, instills confidence in the technique (that is, if the instances are found to be reasonable!), and provides valuable feedback on the requirements development process. This is the technique used in Chapter 6 — providing examples of overlap that readers can judge for themselves. An open question remains as to how one’s understanding of overlap examples leads to better understanding of the multiple viewed requirements process in general.
7.4. Summary This chapter outlined a framework by which multiple viewed analysis may be validated against existing requirement methods. This validation began by listing all of the overlap that can be identified, such as inconsistencies, dependencies and areas of incompleteness. Getting participants to provide a manual list allows us to evaluate the reasonableness of our results, in two ways: to find whether we have captured the overlap at all, and to find whether we have identified the most important areas of overlap. Finally we would have to measure the cost savings achieved by using multiple views, involving actual projects and possibly hindering their progress in order to determine how multiple views would have speeded them up. The following table format summarizes the information needed for these evaluations: Ch. 7 104
Overlap Kind of overlap: Identified Identified by Estimate of cost Actual cost Charac- e.g., whether by participants (YES savings incurred by not teristic counterpart, framework /NO); if yes, then achieved by identifying the (YES/NO); rank of identification; characteristic; dependency, if yes, then importance phase where phase in which inconsistency, how estimate made costs occurred incompleteness
Our next step is to begin a preliminary evaluation of our patient-monitoring system example. The list of overlapping characteristics was already given in Chapter 6. In the next chapter we show some results of applying human judgments for comparison. Unfortunately, we do not have the time or resources to properly measure multiple views’ cost effectiveness on an actual project. Ch. 8 105
8. Preliminary Validation Of Patient-Monitoring
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap 4.4.2. Analyzing Overlap 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach 4.7. Summary Ch. 8 106
5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework 10.3. Speculation 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation Ch. 8 107
A.1.1. Nodes and Links A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
The previous chapter outlined some procedures that, when performed on the results of multiple viewed analysis, compare requirements identified by this approach to requirements developed without it. Some of the steps, such as measuring costs in a large, real-world project, are not feasible for this thesis to undertake. Nevertheless, we would like to show part of a validation example using some steps that are feasible. This chapter evaluates the patient-monitoring results given in Chapters 5 and 6. 8.1. Derived Overlap Characteristics One of the main purposes of using multiple views is to identify overlap between views that would otherwise be lacking in the conventional approaches. The first step in evaluation is to list characteristics of the overlap, as de facto evidence of the additional requirements knowledge provided by multiple views. This section lists those characteristics that were derived in previous chapters. They are repeated here to emphasize that these characteristics would not be found by the usual requirements methods. 8.1.1. Counterparts in Patient-Monitoring Here are listed the counterparts derived in Chapter 6.
[ VP customer ALARM [ VP customer TREATMENT VP designer ASK VP designer ANSWER VP enduser READINGS_OFF_NORMAL VP enduser TREAT_PT VP tester MSG: To_Nurses_Station ] VP tester MESSAGE_ARRIVES ] Because the customer’s TREATMENT and end user’s TREAT_PT have similar names, one might assume that they might easily be determined without using our formal methods; however, it is important to point out that our determination was based on each component of the counterpart within its own view and did not depend on each having the same name. If we had been seeking a counterpart that existed in all four views at once, we would not have easily found one. The methods above allow intermediate results in the form of 2nd-order counterpart pairs, to support the later determination of M-order counterparts. Some of these counterparts were determined from assumptions that we were led to gather by the steps of multiple-viewed analysis. Such assumptions would never have been made explicit under conventional approaches. Ch. 8 108
8.1.2. Assumptions Underlying Views in Patient-Monitoring Here are listed assumptions underlying the views examined in Chapters 5 and 6. One important result of this work is that the assumptions are available in explicit graphical form in a way such that their meaning can be combined with the original requirements specifications. The conceptual graph versions of these assumptions are shown in Figure 6.1. 1. The customer assumes that when the alarm sounds, he is interested in the response time between the time a person hears the alarm and the person treats the patient. 2. The designer assumes a query-response process with respect to a database — some question is asked of the database, and a set of records is given back as the answer. He also assumes that the asking precedes the answering. 3. The enduser assumes that the alarm goes to some medical staff person. 4. The tester assumes that the nurse’s station message is sent no later than some maximum time limit from the time a message first arrives from a device. 5. The customer assumes that the vital signs go into a monitor and current readings come out. The current readings are then compared to the normal ranges. 6. The tester assumes that the message arriving causes the message from device to appear, and that the message leaving causes the message to the nurse’s station to appear. If these assumptions seem rudimentary, the reader should be reminded that the example just begins the analysis of the patient-monitoring system’s requirements, and that some of these “simple” assumptions are nevertheless absent from some previous treatments of patient-monitoring requirements (e.g., [Alford77], [Zave82]). 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring Some ambiguities were discovered by the analysis in Chapter 6. These inconsistencies did not appear when we were considering only the originating views. One ambiguity concerns the MESSAGE_ARRIVES/ MESSAGE: To_Nurses_Station of the tester. There is not enough information in the specification to distinguish between the two. Since these concepts arose from a participant assumption, they would not have been identified had we not used the multiple-viewed approach. 8.1.4. Incompleteness in Single Views of Patient-Monitoring The customer’s ALARM, the enduser’s ALARM and the designer’s ANSWER are all counterparts, yet we could not find their counterpart in the tester’s view. For the moment, we may consider that this lack represents an incompleteness, although later analysis may reveal a distinguishable component within the tester’s view. Still, such an incompleteness could never even be detected without using multiple views. 8.2. Reasonableness of Overlap There are two facets in using human judgment to examine the reasonableness of overlap characteristics: having developers provide a manually-determined list of overlap characteristics and comparing them, and arranging the characteristics in order of importance. This section shows the results of an preliminary study to obtain the results of applying human judgment to decide overlap. 8.2.1. Empirically Determined Overlap A customer’s entity-relationship (ER) diagram and the designer’s data flow (DF) diagram (see Chapter 3 and 4) were provided to senior computer science undergraduates in an advanced project course, who were then asked to identify some overlapping characteristics between the two diagrams. Each participant was asked to provide ten instances from the following categories: (a) Inconsistency between the two diagrams. (b) A common element appearing in both diagrams. (c) Two differently-named things that are really the same. (counterparts) (d) A limitation of one diagram that is overcome by the other. Ch. 8 109
The students had all been trained in the meaning and purpose of both ER and DF; however, none had any practical experience in using them in large-scale development. The information was not gathered as a controlled experiment; rather, it is an empirical study of the overlap between views. Figure 8.1 shows the characteristics identified by these seven participants: Ch. 8 110
Inconsistency Common Different-named Limitation element Counterpart current alert & alarm ER connection and plug_ into Partici- readings monitor & sensor do not show what is pant 1 database vital signs & factors connected or plugged in normal DF doesn’t show where vital ranges signs are from database patient-vital signs & DF doesn’t show patient as the Partici- factors source of factors pant 2 monitor & sensor DF doesn’t show several alert & alarm factors and readings nurse & doctor/nurse DF current readings do not show plug-in to Partici- ER shows multiple sensors; database monitor & sensor DF allows modification of pant 3 DF only one nurse nurse & doctor/nurse normal ranges ER shows multiple nurses; DF alarm?? only one No patient in DF Partici- ER shows normal ranges database alert & alarm ER shows patient-connection pant 4 already exist in database monitor & sensor rather than “nowhere” of DF database is entity in one; a ER shows alerting more than process in other one nurse Partici- ER has only nurse; DF has database vital signs & factors DF doesn’t show whence pant 5 doctor/nurse current monitor & sensor factors/vital_signs come readings alert & alarm ER doesn’t show how normal ranges get into database Partici- ER has only nurse; DF shows current vital signs & factors ER shows database used by pant 6 doctor/nurse readings monitor & sensor many monitors not just one ER shows normal ranges database DF doesn’t show where factors already in database; DF come from; ER shows it to be shows them input from patient doctor/nurse DF shows only one nurse Partici- DF shows one monitor, not database patient – vital signs & ER shows how things are pant 7 several as in ER normal factors related before they start ER has many nurses; DF has 1 ranges alert & alarm happening; DF shows how doctor/nurse nurse monitor & sensor they happen. ER shows ranges already in database; DF shows their origin Number of (7) database (7)monitor & sensor (4) DF doesn’t show where mentioned items (3) current (5) alert & alarm vital signs come from (only frequent readings (3)vital signs & factors consistency or (2) nurse (2) patient-vital signs limitation shown) (2) normal & factors ranges (2)nurse & dr./nurse
Figure 8.1. Manually Derived Overlap Characteristics.
This empirical study shows some interesting results. Differently-named counterparts seemed relatively easy to identify, even for these somewhat inexperienced participants. Inconsistencies between the two diagrams, however, were harder to identify. In several cases the subjects saw a limitation as an inconsistency; this may be due to their misinterpretation of the notion of inconsistency. Some same-named counterparts were not identified by many participants (e.g., CURRENT_READINGS). This may indicate that data items in data flow diagrams are not perceived as analogous to entity-relationship attributes, providing further evidence that multiple views in general, and conceptual graphs in particular, are needed to identify such counterparts. Ch. 8 111
8.2.2. Comparing Relative Importance in Overlap An easy first guess might be to assume that the relative importance of overlap characteristics is the order in which they were presented. This is not accurate in the above list for two reasons. First, the students were participating in a graded examination and therefore could be expected to look for the most obvious (easiest!) items first, rather than the most important ones. Second, some students ordered their characteristics as given in the instructions (items a through d), which bears no particular relation to their relative importance.
8.3. Summary The following table described in the previous chapter has be partially filled in to summarize the results of our partial evaluation. The rank of importance and the method of identification in the “identified by framework” column are now shown. The former was not obtained during the preliminary study, and the latter is explained in previous chapters.
Overlap Kind of overlap: Identified Identified by Estimate of Actual cost charac- counterpart, by participants (YES cost savings incurred by not teristic inconsistency, framework /NO); if yes, then achieved by identifying ambiguity (YES/NO); rank of importance identifi- characteristic incompleteness if yes, then cation how database counterpart YES YES monitor/ counterpart NO YES sensor
no vital signs incompleteness YES in data flow (data flow) response_time counterpart YES YES (important) alarm counterpart YES YES (somewhat important) factors/message counterpart YES NO _from_ device designer’s counterpart YES NO answer/alarm No alarm in incompleteness/ YES NO tester’s view ambiguity This chapter began the process of validating multiple viewed requirements analysis, as described in Chapter 7. Two of the three parts — listing of overlap characteristics and comparisons to manually determined overlap — were discussed for the patient-monitoring system example that has been considered in previous chapters. The third part — determining the cost effectiveness of applying multiple views — has not been performed here, due to its substantial cost and commitment on the part of some real-world software developers. Ch. 9 112
9. Results of Multiple-Viewed Requirements Development
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.3. Analyst’s Framework 4.4. Analysis of Multiple Viewed Requirements 4.5. A Methodology For Multiple Viewed Requirements 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.2. Data Flow Diagrams 5.3. State Transition Diagrams 5.4. Requirements Networks (SREM) 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.2. Reasonableness of Overlap Ch. 9 113
8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.3. Speculation 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.2. Conceptual Graphs and Logic A.3. Conceptual Graph Extensions Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
This chapter summarizes the results obtained by using conceptual graphs to examine multiple views of requirements. I list the major findings of the thesis, summarize the human responsibilities involved, and explain some limitations inherent in any multiple viewed approach.
9.1. Major Findings The major findings of this thesis are summarized below.
Conceptual Graphs Utility Conceptual graphs are capable of representing several different popular forms of requirements. Conceptual graphs also aid in capturing participants’ underlying assumptions, by providing a convenient means of representing them and combining them with the requirements specification.
Overlap Characteristics The methods in this thesis permit the determination of overlap via traceable, semi-automated means. Previous chapters described various forms of overlap that can be established using the framework. The validation process begins by listing occurrences of detected overlap, as de facto evidence of the additional power provided by multiple views. Previous chapters have already described these characteristics and shown the details of how they are obtained from a collection of views.
Counterparts The list of counterparts and their originating views is the core of multiple viewed analysis. These counterparts capture the basic overlap between views, showing how the views are related through common objects. Having a common meta-language with which to represent each view allows us to determine dependencies between counterparts and thus show dependencies between views. This is important, since participants need to know that changing some parts of their views can potentially change other views. Also important is for Ch. 9 114 participants to know which parts of their views are independent of other views, and therefore can be freely changed without regard to other views. Such information could never be identified when using a single view.
Assumptions Underlying Views We have argued that as more assumptions are included in multiple viewed analysis, the more accurate and distinguishable are the relative strengths of the counterparts we find. Multiple views helps identify particular objects that need additional clarifying assumptions so that the analyst need not seek them in a haphazard way.
Consistency Between Views The central measure of multiple views’ worth is the ability to determine overlap between views of requirements. Inconsistencies between views can be identified because each additional view represents external information that would not ordinarily be available during the analysis of a single view. For example, dynamic information from a view expressed via state transition diagrams can help point out inconsistencies that an entity- relationship diagram would not. The list of found consistencies again forms de facto evidence of characteristics which were not identified by single viewed analysis.
Incompleteness Of Single Views We wish to make explicit multiple views’ value in extending the complete set of usable requirements. Pointing out where existing views are insufficient provides additional evidence that multiple views are needed to achieve a more comprehensive set of requirements. We must also indicate those areas of incompleteness identified through multiple views that would not otherwise be identified.
9.2. Tractability The task of reconciling differences in granularity between the two views is well exemplified by considering how to identify a single concept that corresponds to some sub-graph (i.e., more than one concept) in another view (see Chapter 3). Since any concept or sub-graph in one specification might be counterpart to any concept or sub- graph in another, we would have to examine combinations of all possible sub-graphs from each specification — an exponential computation process. The power of conceptual graphs helps us overcome some of this complexity. Using local information, e.g., a concept’s type, or the relations to which it is linked, we can greatly reduce the number of possible counterparts without resorting to comparisons with every node. We can therefore reduce complexity to manageable limits, although we still must be prepared for a large-polynomial-time algorithms. This problem is not unique to conceptual graphs or requirements analysis. Schank identifies it as a problem in any natural language processing scheme, but claims that some correspondence can always be found. …for every sentence in a given language, there is not necessarily a sentence of equal length in a second language. But for every sentence in a given language, there is a set of sentences in another language that is semantically equivalent to it. [Schank75, p.9] One solution, strictly a heuristic one, is to impose a limit on the maximum size of any sub-graph to be compared. Unfortunately, there is no evidence yet to help determine what such a limit should be. A more restricted solution, also heuristic, is to restrict the definition of a counterpart set so that one component of the set has to be a single graph node (i.e., a single concept, relation, actor, or demon). This is the approach taken in the thesis. Although restricting our definition of counterpart greatly reduces the number of sub-graphs we must examine, it also removes many possible counterparts from ever being seen. Thus, granularity is likely to remain a significant problem for a multiple-viewed approach.
9.3. Duties Of The Requirements Analyst The multiple viewed approach can benefit from some automated assistance. Bookkeeping support, such as keeping a data dictionary or drawing conceptual graphs, can clearly be automated, of course. Beyond that, there are some analysis procedures for which automation will be a benefit, such as traversing a type hierarchy to determine potential counterparts, calculating an association graph or maintaining graphical representation of relationships obtained so far. Ch. 9 115
In a methodology which includes human judgments, the role of human beings must be made explicit. Throughout the thesis, mention has been made of some human decisions. The following summarizes the duties of the requirements analyst with respect to managing multiple viewed requirements analysis: Manage translations from participants’ requirements in their chosen notations to conceptual graph form, augmenting each one’s type hierarchy as needed. Identify and communicate features of the overlap between participants’ specification graphs. The analyst may use the “B” algorithms from Appendix B. Update pre-existing universal knowledge base, such as Sowa’s conceptual catalog. The requirements analyst assumes a pre-existing general knowledge base, such as the conceptual catalog in [Sowa84, Appendix B] containing pre-defined concept types (e.g., PERSON, ENTITY, and ACT), abstractions (e.g., type INTERVAL) and relations (e.g., attribute, agent). These are asserted in an outermost context enclosing all conceptual graphs known to the analyst.
Prepare new translation schemes as more notations are added to the requirements development process.
Determine heuristic weights for various relationships between counterpart components, and weights for differing type distances.
Gather assumptions from each participant, express them as A-graphs in conceptual graphs form, and join them to R-Spec-Graphs. (The joining step may be assisted by applying the association graph technique to the A-Graph and R-Spec-Graph as two graphs to be compared).
9.4. Limitations of the Approach In this work, the term multiple-viewed approach means the philosophy of combining seemingly disparate viewpoints in order to identify their overlap. This work actually describes an instance of a multiple-viewed approach based on conceptual graphs. There may be other possible instances based on different representations. Regardless of the representation, however, any multiple-viewed approach faces the same two basic cognitive tasks: (1) capturing domain-specific semantic information from multiple participants, and (2) expressing the overlap between participants’ views so that it is understandable to all participants. Our technique is intentially conservative in seeking counterparts. Two concepts are only considered as potential counterparts if (a) they share a common subtype other than T, and (b) they are related to other counterpart pairs. Even if they have interesting common subtypes, the strength of a counterpart decreases as their similarity (estimated by their type distance) decreases. Our approach has been to only consider a counterpart that is clearly possible, while incurring the risk that we will ignore some less possible counterparts that turn out to be useful. It is always possible that some actual counterpart is made up of several small weights what we repeatedly ignore during our analysis.
Limitations of Conceptual Graphs Although conceptual graphs have been shown to be general, we must resist the temptation to believe that conceptual graphs are the perfect notation to accommodate all multiple views. Conceptual graphs form merely one step towards integrating disparate views into a coherent framework. As other multiparadigm approaches appear, we would like to pursue integration at higher levels, even combining the combination techniques. Certain aspects of conceptual graphs present problems. For example, we did not use cardinality of concepts at all. Negation is another problem — how to represent the dependencies of a conceptual graph that has negation in it. Nested contexts present yet another problem. This thesis merely ignored nested contexts as we tried to find possible counterparts in any existing context. Handling the negation of contexts can be simplified by expanding them out into logical forms without nested contexts (e.g., using DeMorgan’s law), but even then we ultimately encounter some negation which we cannot handle effectively. Ch. 9 116
Limited Support Over Life Cycle We have been interested in the preparation of better requirements using multiple views than could be obtained by current methods, so that the rest of development may proceed with a better understand of the initial requirements. Unfortunately, requirements themselves change during the life of a large-scale software project. Although several life cycle models of software development have been proposed, it is not clear how this thesis’s methodology will support software requirements in any of them. Several aspects of requirements, such as traceability and automatic generation of a rapid prototype, have not been considered at all. We note a lack of incremental change support. All views’ graphs are analyzed together as opposed to changing only some parts of the association graph to reflect changes in originating R-Specs. After assumptions are gathered, the entire association is performed from scratch. We have not attempted to identify those nodes in an association graph that are not affected by a change. Some procedures in the previous two chapters’ evaluation framework for multiple views involve examining costs and benefits at different phases of a life cycle. Perhaps during such an evaluation, we can also gain some insight into how best to support the life cycle with multiple viewed requirements.
Granularity Limitations The most serious limitation in the multiple viewed approach is its reliance on differing views being captured in similar levels of detail. If a sensor manufacturer were involved in the patient-monitoring system, he would be concerned with many details of the monitor operation that do not concern anyone else. The approach does not easily distinguish between facts that are merely different due to their multiple-viewed sources, and facts that are different due to fundamentally different levels of detail. After a substantial base of re-usable requirements knowledge has been built up, it will contain schemata for many components (hardware and software) used in development. Although tractability problems remain, it will be possible (at least in theory) to identify a set of details in one view as being manifestations of a schema invoked by say, a single part in another view. The issue of disparate granularity among views was discussed in §3.3. We must use heuristics to bring the analysis within tractable limits; however, we do not have a logical basis with which to justify the limits we choose. It will always be possible for the two views we are considering to contain counterparts just beyond our limit.
9.5. Summary This chapter briefly summarized the results of studying multiple views. The next chapter concludes the thesis by listing its major contributions and limitations, then suggests additional issues for further research. Ch. 10 117
10. Conclusion
CHAPTER SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap 4.4.2. Analyzing Overlap 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach 4.7. Summary Ch. 10 118
5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework 10.3. Speculation 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation Ch. 10 119
A.1.1. Nodes and Links A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
The future offers very little hope for those who expect that our new mechanical slaves will offer us a world in which we may rest from thinking. Help us they may, but at the cost of supreme demands upon our honesty and our intelligence. The world of the future will be an ever more demanding struggle against the limitations of our intelligence, not a comfortable hammock in which we can lie down to be waited upon by our robot slaves. Norbert Wiener, God and Golem, Inc., 1964
Now that we are at the end of this thesis, I will recapitulate the major ideas presented, outline areas for future research, and briefly speculate on the future of multiple viewed approaches.
10.1. Summary of Thesis Chapter 1 stated that one problem with current requirements is their being limited to a single method for their expression and analysis. More recent approaches were described as incorporating multiple views of software requirements, so that differing, complementary, and possibly conflicting requirements are gathered from several participants in software development. A fundamental assumption is that inclusion of these multiple requirements views will enhance the quality and usefulness of the software system built to meet those requirements. Chapter 2 discussed the role of views in previous work on software requirements, noting the distinction between a notation, a participant, and a paradigm in identifying differing requirements views. Example software requirements were introduced. An informal notion of a view was discussed, along with its relation to various existing software requirements methods. Some methods were identified that already include multiple views. Chapter 3 outlined a framework for the discussion of multiple-viewed requirements development, giving the basic components and relationships among them. The role of the requirements analyst was described, along with his major tools. Qualities of interaction and consistency between views were discussed, with counterparts and dependency introduced as our main manifestation of overlap. The association graph technique was introduced and illustrated. General issues of a multiple-viewed approach were discussed. Ch. 10 120
Chapter 4 gave the details of a formal methodology for the development and analysis of multiple viewed requirements, based on conceptual graphs. Conceptual graphs were proposed as a reasonable meta-language for the requirements analyst to use. Definitions were given for the major components of the framework, and the steps of the methodology were described, along with their justification. Limitations of the approach were also discussed. Chapter 5 illustrated the first steps of the methodology, namely obtaining conceptual graph representations of several languages used in requirements development: entity-relationship diagrams, data flow diagrams, finite state machines and R-nets (from the SREM/DCDS methodology). Translation was considered from both directions: a method’s notation to conceptual graphs (compilation) and conceptual graphs to an originating notation (extraction). Chapter 6 illustrated the subsequent steps of the methodology. It emphasized the process of examining the overlap between multiple views, showing how assumptions are gathered as a natural consequence of analysis. Chapter 7 explained a procedure by which the effectiveness and usefulness of multiple views may be validated. Its steps were: summarize aspects of the analysis, develop a cost model showing the benefits of multiple views, and finally apply human judgment about specific instances of overlap with which to compare the framework’s results. Chapter 8 applied part of the validation procedure to the patient-monitoring example treated in the thesis. Certain parts were too expensive or time-consuming to pursue. Chapter 9 presented the results of multiple viewed analysis in a concise form, and discussed some of the limitations on using such a method. Appendix A (below) describes the conceptual graph notation, and explains some extensions made to conceptual graphs for multiple viewed requirements analysis. Appendix B (below) defines translation schemes for the four notations considered in the examples from Chapter 5.
Methodology For Identifying Multiple Viewed Requirements A methodology for applying multiple viewed techniques has been described. Example requirements for a patient monitoring system have been used to illustrate the methodology. This section summarizes the important features of the methodology.
Requirements Analyst’s Framework and Knowledge Base An important prerequisite for multiple-viewed development is a requirements analyst who knows how to apply the techniques. The analyst must already have knowledge about several different requirements notations, as well as the ability to understand and express pre-existing assumptions from several participants.
Participants’ Requirements In Conceptual Graphs Participants’ requirements are translated (compiled) into conceptual graphs for purposes of analyzing their interaction with other participants’ requirements. Algorithms were presented to support this part of the methodology. Participants can produce requirements in a language of their own choosing, so that popular requirements notations can be used.
Participants’ Assumptions As Conceptual Graphs The requirements analyst gathers participant assumptions manually at present. Some automated assistance is possible (see Chapters 4 and 6) but the methodology relies on the requirements analyst’s ability to express participant assumptions as conceptual graphs, and to join each participant’s assumption graphs to his other requirements. This work has introduced conceptual graphs for purposes of representing software requirements knowledge. Since requirements development involves cognitive information, conceptual graphs are a reasonable choice for capturing its knowledge. This methodology does not by any means use all of the capabilities of conceptual graphs; see below for some proposed new features. Ch. 10 121
Determination of Overlap Between Views The heart of the methodology (and the thesis) is to determine overlapping characteristics between participants’ views. The two main ideas here are the counterpart and conceptual dependency. Determining counterparts is based on the meaning of each concept in a participant’s view with respect to its use in that view. Dependency is obtained from some pre-existing knowledge about some primitive relations, as well as participant- supplied information about his particular requirements.
10.2. Future Research This work has laid the groundwork for a multiple-viewed approach to requirements, but many issues remain. Obviously we need to incorporate more views, get more practical experience using them with actual developers, and develop new automated tools to support the development effort.
10.2.1. Exploring Overlap This section outlines some needed work in exploring more fully the notion of overlap. English paraphrases are a reasonable starting point for understanding overlap, but they are not adequate in themselves. Participants face the same difficulty with paraphrases that they would with a conventional hierarchical outline — inter-relationships among requirements may be hard to see. Extraction (“B”) algorithms from conceptual graphs (see Appendix B) provide a beginning, but more examination is needed. For the moment, human assistance may be required to make overlap understandable in the original notations of the participants. This thesis did not deal with other kinds of overlap that would be useful in exploring multiple views. The presence of actors suggests that detecting functional overlap (i.e., two views including some of the same functions) would be desirable. Demons in conceptual graphs were only briefly considered here; further work may identify ways to relate actors to demons, possibly providing some temporal overlap between two views’ inherent processes. Structural overlap between views (other than one-to-one counterparts) involves graph analysis techniques that are computationally hard. We already mentioned granularity limitations as a drawback of this approach. More work is needed to reduce this problem to a tractable one without artificially constraining the analysis with arbitrary sub-graph size limits.
10.2.2. Expanding View Coverage Since ours is a knowledge-based framework, the more knowledge it contains, the more effective it will be in capturing the requirements we want. It will therefore be useful to include as many views as practical. Many more views can be incorporated into the multiple-viewed approach. Technical views expressed via languages such as Petri nets, SADT, SREM, etc. ought to be the first choices. Managerial views, such as decision theory or economic models (á la Boehm), may also be integrated. More difficult to incorporate would be views such as customer’s reliability, and programmer’s maintenance.
10.2.3. Practical Support In order to better understand multiple viewed requirements development, more practical support for the process needs to be developed. Participants must find the techniques accessible before larger systems can be undertaken with this approach. This section outlines some of the support that is needed. Clearly, more tools and supporting techniques need to be applied before multiple views becomes a useful approach in developing real requirements. As in most other constructive endeavors, it is our ability to make tools that allows us to build large software products. Should each tool cater to many different developers, or should software requirements analysts operate the tools and summarize to other developers? Ch. 10 122
An effective way of presenting overlap is by paraphrasing it into English (or some other natural language). Since conceptual graphs are meant for this purpose, paraphrasing them ought to be a fruitful direction for the future. Understanding another’s view takes time and effort. All learned knowledge does not necessarily affect one’s understanding, however. An important question is: how much learning is reasonable among developers? If the techniques require a great deal of learning then it is less likely to appeal to a wide variety of participants. Previous chapters and sections have already alluded to multiple views’ limited usefulness in dealing with the entire lifecycle and handling requirements that address varying levels of detail. More study is needed in these areas.
10.2.4. Enhancements To Framework So far, only two general relationships have been identified to support development of software requirements using multiple views. More experience needs to be gained from practical applications of this methodology in order to identify new useful operations.
Non-Functional Requirements It is not at all clear how one might use this framework to model reliability or maintenance of software with respect to requirements. It is doubtful that either aspect is confined to any single view — they are both interleaved between the views. Further study is needed to formalize models of both activities before we can begin to incorporate them as considerations in a multiple viewed approach.
Re-Use Of Assumptions Over time, as new understanding is gained among developers, our set of assumptions will get larger. This means that maintaining consistency will become harder to achieve, as more graphs are added to each domain. One result of the effort, however, may be a deeper understanding among participants, since more participant-specific information will have been explicitly included in the requirements process. One benefit of gathering assumptions and expressing them formally is the potential for re-using the assumptions in future requirements development. Grouping assumptions by context may be one way to establish boundaries on the domains in which assumptions can be re-used. Because one requirement may have an unexpected effect on other requirements seemingly far removed, it is risky to divide up semantic information according to any classification; such a division would be based on assumptions that might cause important interactions to be ignored. Information should be placed in the most general context possible; e.g., if assumptions about a single specification can be applied to any system from that participant’s view, then we increase our chances of effectively re-using the knowledge gained. Assumptions form a crucial part of the total knowledge base for multiple views. Better heuristics, and some practical experience should greatly improve their usefulness. A fundamental issue is the allocation of assumptions among various contexts, affecting both re-usability and appropriate levels of abstraction. Different assumptions may hold only in particular domains. For example: i) a specific system requires some knowledge that is not useful for any other system, ii) a participant using one notation has assumptions not appropriate for any other notation, iii) a participant has assumptions about a specific system in a particular notation. Making participant assumptions explicit is a key goal of an effective requirements development process. Categorizing their proper context needs further investigation.
10.3. Speculation Some issues have not been directly addressed by this work. This section contains a few suggestions for exploring them, based on our current experience with multiple views. Ch. 10 123
Potential for Simulating Requirements Conceptual graph representations have the potential to be dynamically simulated. An actor node has semantics similar to a Petri-net place [Peterson81], such that an actor will fire (enabling its output concepts) when all of its input concepts are enabled. In the future, this may permit some dynamic behavior to be simulated; however, in this work, we focus entirely on the specification and translation of requirements. A natural extension of the work shown herein is to use the active qualities of actors so that some dynamic behavior of the specified requirements can be simulated. We can therefore simulate views expressed in an executable language. No easy path appears for the simulation of (passive) relations, however.
Automated Acquisition of Assumptions The requirements analyst’s job would easier if there were some automated method for obtaining new assumptions. This work assumes that assumptions are gathered manually, then expressed in conceptual graphs by the analyst; however, a directed dialog between a participant and an automated assistant might reveal some assumptions that could be automatically generated in conceptual graph form.
Convergence of Views A large question is whether views may eventually converge. If new information must always be made consistent with existing knowledge, then new counterparts should also be identified. Can multiple views eventually merge into one common domain? Perhaps the opposite is true — if enough information is added to each view, it may be that eventually they cannot ever be made consistent with one another.
10.4. Concluding Remarks This work can open up the requirements process to more developers and more existing methods. Since multiple viewed requirements development does not discard existing techniques, developers spend their time producing and examining requirements, instead of having to learn some new notation. One overriding principle in the above work is the belief that software quality is improved by increased human understanding of requirements. People deserve effective and appropriate software products to serve their needs. Exposure to others’ opinions can often lead to better coherence among design features, making software easier to understand and use. Multiple views is an exciting approach to the formal analysis of large system requirements. Eventually, these ideas will be applied to the development of an actual system. As more knowledge is captured from more views, the formal integration of multiple developers’ requirements can become a reality. Ultimately, decisions are made based on need, hope, inspiration, vision, and other aspects of human experiences. The goal of any framework is a set of techniques that allow human perspectives to be expressed, considered, and understood. App. A 124
Appendix A: Conceptual Graphs
APPENDIX SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.1.1. Purpose Of Using Views 2.1.2. Basics Of A View 2.1.3. A Participant’s View 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.4.1. Interaction Between Views 2.4.2. Support For Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.2.1. Identifying Overlap Between Views 3.2.2. Kinds Of Associations 3.2.3. Association Graph Technique 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.2.1. Domains 4.2.2. Requirements Specification 4.2.3. Requirements Specification Graph 4.2.4. Translation Scheme 4.2.5. Assumption Graphs 4.2.6. View 4.3. Analyst’s Framework 4.3.1. Analyst’s Canon 4.3.2. Analyst’s Requirements Specification Graph 4.4. Analysis of Multiple Viewed Requirements 4.4.1. Describing Overlap 4.4.2. Analyzing Overlap 4.5. A Methodology For Multiple Viewed Requirements 4.5.1. Methodology Steps 4.5.2. Products of Analysis 4.5.3. Analyst’s View 4.6. General Features Of Approach App. A 125
4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.1.1. Example Entity-Relationship Diagram 5.1.2. Discussion 5.2. Data Flow Diagrams 5.2.1. Example Data Flow Diagram 5.2.2. Discussion 5.3. State Transition Diagrams 5.3.1. Example State Transition Diagram 5.3.2. Discussion 5.4. Requirements Networks (SREM) 5.4.1. Example Requirements Network 5.4.2. Discussion 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.2.1. A Requirements Error Cost Model 7.2.2. Measuring Actual Projects 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.1.1. Counterparts in Patient-Monitoring 8.1.2. Assumptions Underlying Views in Patient-Monitoring 8.1.3. Inconsistencies/Ambiguities in Patient-Monitoring 8.1.4. Incompleteness in Single Views of Patient-Monitoring 8.2. Reasonableness of Overlap 8.2.1. Empirically Determined Overlap 8.2.2. Comparing Relative Importance in Overlap 8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.2.1. Exploring Overlap 10.2.2. Expanding View Coverage 10.2.3. Practical Support 10.2.4. Enhancements To Framework 10.3. Speculation 10.4. Concluding Remarks App. A 126
Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.1.1. Nodes and Links A.1.2. Type Hierarchy A.1.3. Contractions A.1.4. Canonical Graphs A.1.5. Canonical Transformation Rules A.1.6. Projection A.1.7. Generalization A.1.8. Lambda Abstraction A.1.9. Context A.1.10. Line of Identity A.1.11. Equivalent Representations A.2. Conceptual Graphs and Logic A.2.1. First-Order Logic with Quantification A.2.2. Functions A.3. Conceptual Graph Extensions A.3.1. Private Referent A.3.2. Demons Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
This Appendix briefly describes the theory and notation of conceptual graphs [Sowa84], and introduces some restrictions and extensions in order to express multiple viewed graphs. There are three main sections. §A.1 briefly describes the makeup and vocabulary of conceptual graphs. §A.2 discusses the relationship between conceptual graphs and formal logic. §A.3 defines some extensions and alterations to conceptual graphs for the purpose of expressing multiple views of requirements.
A.1. Conceptual Graph Notation The definitive work on conceptual graphs is [Sowa84]. The present work adheres as closely as possible to the original notation; however, some cosmetic changes to the syntax are shown, and one new node type is introduced. A brief summary is presented here; for a formal treatment with many interesting examples, the reader is referred to Sowa’s work [Sowa84]. Conceptual graphs are a descendant of previous work in semantic networks, such as [Schank75]. Certain relations in a semantic network (e.g., is_a relations) will be expressed through notational shorthands. A hierarchy of type classes allows inheritance of other concepts’ properties and provides a basis for reasoning about the meaning of a conceptual graph. As discussed in §A.1.11, three forms are available for representing conceptual graphs: 1. Display form, comprised of graphic symbols (e.g., rectangles, ovals, diamonds, arrows). 2. Linear form, comprised of text symbols (e.g., [ ], ( ), —> ). 3. Paraphrase form, consisting of English sentences. Examples of these are found throughout the following discussion. App. A 127
A.1.1. Nodes and Links This section describes the major building blocks of conceptual graphs — nodes and the edges connecting them. There are three kinds of nodes in a conceptual graph —concepts, relations, and actors — connected to other nodes by directed arcs, called links. A directed link has somewhat different meanings depending on the kind of nodes it connects; discussion is found in the description of each node type. Later, we introduce a new kind of node called a demon, not found in [Sowa84]. A concept represents a thing, a relation represents a relationship between things, and an actor represents a process or function that manipulates things. A conceptual graph can therefore contain characteristics of both data flow diagrams and entity-relationship diagrams. Its nodes can be concepts, relations, or actors, with the restriction that a node cannot be connected to a node of its own kind; furthermore, relations can only be linked to concepts, and actors can only be linked to concepts. We now explain each type of node.
Concept A fundamental notion in conceptual graphs is the concept. A concept is any distinguishable thing in the real world. In the display form, a concept is shown by a rectangular box; in the linear form, it is shown enclosed by square brackets, e.g., [ BOOK ]. In this concept, the word BOOK is called the concept’s type label, often shown with upper case letters. Type labels are partially ordered (see below, §A.1.2). Some implicit shorthand notations are employed to make graphs easier to read. In a general semantic network, an is_a line connects every instance with the type(s) to which it belongs. Conceptual graphs put the type label inside the concept box, forming an implied is_a link to its type. This is purely a shorthand to make graphs easier to read by eliminating is_a links from the picture.
PERSON: implies Harry is_a PERSON Harry
In §A.3.3 below, additional implied links in the semantic network are described. The concept [BOOK] is called a generic concept, because it represents any instance of a book. It is also a complete conceptual graph in its own right, conveying the meaning there exists some book. A type label inside a concept box may be followed by a colon and a referent, which refers to individuals. The concept [BOOK: “Moby Dick”] is an individual concept, or just an individual referring to an instance of a book called “Moby Dick”. The concept [BOOK: #98656] means an instance of some particular book whose title is not given. A referent can contain more information than just a name. An asterisk means an unspecified individual, i.e., the concept [BOOK] is equivalent to [BOOK: * ]. The concept [BOOK: { * }] indicates a set of books, [BOOK: { * } @2] indicates two books. The concept [BOOK: {"Moby Dick", "The Prince", "The Mythical Man-Month"} @2] means any two of the three books in the set. The concept [BOOK: *x] makes x a variable in that x in other concepts may mean the same individual. The concept [NUMBER: >0] is equivalent to [ NUMBER: *n ] —>(greater_than) —> [ NUMBER: 0 ] meaning some number greater than zero.
Relation A relation is shown by a labeled circle or oval connected by directed arcs to one or more concepts. In the linear form, a relation is shown in parentheses; arcs are shown by —> or <—. The relation label is usually shown in lower case letters. A relation can be monadic (directed toward a single concept), dyadic (connecting two concepts) or n-adic (connecting n concepts). Dyadic relations can link groups of concepts, since a referent captures the notion of many-to-many-ness; e.g., [BOOK: {*}] —> (author) —> [PERSON] means “a set of books authored by a single person”. It is possible to express an n-concepts to m-concepts relation by having n incoming arcs and m outgoing arcs. In the linear form, syntax rules are extended to accommodate n-adic relations (and n-connected concepts). A dash after a concept or relation indicates multiple arcs on each following line; e.g., the following graph which denotes the information “The city Nashville is between the city Knoxville and the city Memphis”: App. A 128
CITY: Knoxville CITY: between Nashville CITY: Memphis could be written in several linear forms, e.g.,:
[ CITY: Nashville ] <— (between) — [ CITY: Memphis ] —> (between) — <— [ CITY: Knoxville ], —> [ CITY: Knoxville ], <— [ CITY: Memphis ] <— [ CITY: Nashville ]
Each relation’s links are constrained by a relation definition that restricts the allowable types and directions to which it can be linked. For example, the parent_of relation definition [PERSON] —> (parent_of) —> [PERSON] constrains the relation parent_of so that it may only connect two concepts of type PERSON.
Actor Concepts and relations cannot capture some kinds of information. For example, simple procedural function is difficult to specify. The special semantics of the data flow model (and others) requires that their relations not only connect related concepts, they must also provide some facility to represent the flowing of data from process to process. Sowa has therefore extended conceptual graphs by introducing a functional node called an actor. An actor, represented by a diamond in display form or by a name enclosed in < > brackets in the linear form, has the same syntax as a relation. A conceptual graph can have all three kinds of nodes in it — concepts, relations, and actors. (Later we introduce a fourth kind of node, called a demon, with the same syntax as a relation or actor.) Actors are linked to concepts via a dashed directed arrow, to distinguish its semantics from a relation’s links. An actor’s links have the following semantics.In order for actors to operate, the notion of a control mark is introduced, so that a concept (not a relation) has a control mark: either enabled or not. The control mark’s semantics are similar to a Petri net token [Peterson81] — as soon as all of its input concepts are marked “enabled”, an actor computes new referents for its output concepts (“fires”) and then all its output concepts are marked “enabled,” etc. Computing the new referents (“firing”) is accomplished by an actor’s private algorithm, in the form of an actor definition that employs primitive functions, such as
DIVIDEND: QUOTIENT: SUM: *g *a *d D := A ÷ B; E := REMAINDER (A, B); divide plus F := SQRT (C); G := D + F; DIVISOR: REMAINDER: *b *e
NUMBER: SQUARE_ sqrt *c ROOT: *f
Figure A.1. Example Graph Containing Actors. A.1.2. Type Hierarchy Types in conceptual graphs are related to one another by a partial ordering among type labels called a type hierarchy. The ordering is denoted by the symbol £ indicating a subtype; e.g., MAN £ PERSON means that MAN is a subtype of PERSON. A subtype can be used in performing a specialization (see below). By definition, every type is a subtype of itself. The symbol < indicates a subtype that is not the type itself; it denotes a proper subtype. For example, MAN < PERSON, but MAN £ MAN. Sometimes it is convenient to show the ordering in reverse, with the symbol ‡ meaning a supertype, and > meaning a proper supertype. In order to complete the hierarchy, two pre-defined types are introduced. The universal type, shown by T, represents the concept anything. All other types are proper subtypes of the universal type. The other pre-defined type is the absurd type, shown by ; by definition, it is a proper subtype of every other type. A single type may have one or more subtypes, and/or one or more supertypes. Conceptual graphs, therefore, support multiple inheritance. The type hierarchy is always expressed in linear form separated by semicolons, although it can be shown as a structure diagram, as in Figure A.2(a): App. A 130
EVENT < T; PERSON < FRIEND; ACT < EVENT; ROBOT < ANIMATE; ENTITY < T; ROBOT < FRIEND; ANIMATE < ENTITY; MAN < PERSON; FRIEND < ENTITY; WOMAN < PERSON; PERSON < ANIMATE; CHILD < PERSON;
T
ENTITY EVENT T
ANIMATE FRIEND ACT ENTITY EVENT
ANIMATE FRIEND ACT PERSON ROBOT
PERSON ROBOT WOMAN MAN CHILD
^ WOMAN MAN CHILD
(a) (b) Figure A.2. A Type Hierarchy.
Since the absurd type is understood to be a subtype of every type, it is usually omitted from the type hierarchy, resulting in the simpler picture of Figure A.2(b). The symbol can also represent the value “false,” just as T represents the value “true”. Let r, s, and t be type labels. If r £ t and s £ t then t is called a common supertype. In Figure A.2(b), WOMAN and MAN have the following common supertypes: PERSON, ANIMATE, FRIEND, ENTITY, and T. We call t a minimal common supertype if there is no type label z such that z £ t, r £ z, and s £ z. The minimal common supertype of WOMAN and MAN is PERSON. Let r, s, and t be type labels. If t £ r and t £ s then t is called a common subtype. In Figure A.2(b), ANIMATE and FRIEND have the following common subtypes: PERSON, ROBOT, WOMAN, MAN, and CHILD. We call t a maximal common subtype if there is no type label z such that t £ z, z £ r, and z £ s. Maximal common subtypes of ANIMATE and FRIEND are PERSON and ROBOT. With each type is associated a type definition, showing its allowed relations, and the allowed type(s)/referent(s) of its related concept(s). For example, type EVENT’s definition is: type EVENT is [ EVENT ] —> (point_in_time) —> [ TIME ] end; It constrains concepts of type EVENT so that they must be connected via a point_in_time relation to a concept of type TIME.
A.1.3. Contractions A contraction is purely a syntactic shorthand for a more complicated arrangement of graph nodes. Frequently used relations between a concept and another concept, such as naming: [PERSON] —> (name) —> [WORD] —> (value) —> ["Harry"], can be enclosed within a single concept box by using the colon operator, as [PERSON: Harry]. App. A 131
Another contraction is employed when using the concept type PROPOSITION. Its referent can be an entire graph, or set of graphs; therefore, we can omit its type label. For example, the concept [PROPOSITION: [PERSON: Harry] —> (attribute) —> [AGE: 37] ] can be written as [ [PERSON: Harry] —> (attribute) —> [AGE: 37] ]. This kind of concept is also called a context (see §A.1.9 below). A contraction is different from an abstraction (see below §A.1.8) in that contractions are pre-defined, based on specific relations, e.g., (name) or (greater than). Abstractions represent user-defined conceptual graphs that can be substituted for a given concept.
A.1.4. Canonical Graphs Conceptual graphs can express many pieces of information, some of which are true and some of which are not. To ensure that a graph contains only proper arrangements of nodes, it is constrained by a set of standard form definitions, each called a canonical graph. We will introduce canonical transformation rules, which assure that a transformed canonical graph is also canonical, and therefore true. An example of a canonical graph is:
TIME point_in_time EVENT meaning the sentence: a point_in_time of an event is a time. As a canonical graph, it constrains all occurrences of the two concepts TIME and EVENT and their subtypes, as well as all occurrences of the relation point_in_time. As shown below, transformations of this canonical graph will preserve the truth of the sentence. A set of canonical graphs, combined with a type hierarchy and a set of individuals, is collectively referred to as a canon. A canon is a set of facts that represents all that is known to be true about the world it describes. Its domain is a closed-world, where an arbitrary graph is considered false unless it is assumed to be true, or derivable from a true graph. Sowa provides a preliminary canon of “common knowledge” which he calls his conceptual catalog.
A.1.5. Canonical Transformation Rules Canonical graphs can be transformed into other canonical graphs by using one or more canonical formation rules as primitive operations. These rules have the semantics that if their original graphs are true, then their resulting graphs will also be true. These rules (except copy) are specialization rules, in that they potentially decrease the number of individuals to which a canonical graph might apply, and they cannot increase the number. A graph resulting from these operations, however, is assured of being a canonical graph.
Copy An exact copy of a canonical graph is also a canonical graph.
Restrict A graph can be restricted if some concept’s type label is replaced by a sub-type, or if a generic concept is replaced by an individual concept. For example, [ENTITY] can be restricted to [PERSON] or Restricting a graph specializes it, i.e., potentially reduces the number of instances for which it is true. If a type label in a canonical graph is replaced by one of its proper subtypes, or if a generic concept is replaced by an individual concept, then the result is also a canonical graph. For example, if the following graph is declared to be canonical:
PERSON attribute AGE then it can be restricted to any of the following three graphs: App. A 132
WOMAN attribute AGE
PERSON: attribute AGE Harry
PERSON: attribute AGE: 37 Harry meaning that in each case, the new graph is also canonical.
Join Two graphs can be joined if there is at least one concept c in one which is either the same as or can be restricted to a concept d in the other. In one operation, the two concepts are combined into one, and all links to either of the two original concepts are linked to the new one. Thus two graphs become a single graph. For example, consider the two graphs u and v: u = [PERSON] —> (attribute) —> [AGE] v = [WOMAN] —> (location) —> [OFFICE] Using the example hierarchy given in §3.2.2, the graph u can be restricted to [WOMAN] —> (attribute) —> [AGE], then both [WOMAN] concepts may be combined, resulting in the joined graph w below: w = [AGE] <— (attribute) <— [WOMAN] —> (location) —> [OFFICE] meaning that if u and v are both true, then so is w.
Simplify If a sub-graph conforms to a type abstraction, then that sub-graph can be replaced by a concept box. This aspect of simplification is deferred until the section on abstractions (below §3.2.8).
A.1.6. Projection The projection operator p is related to the join operation. When two graphs u and v are joined to form graph w, that part of w which came from u is called the projection of u in w, denoted as pu. The projection may represent a restriction of the original graph, if such restriction were necessary in performing the join. In the join example in §3.2.5, the two graphs u and v: u = [PERSON] —> (attribute) —> [AGE] v = [WOMAN: Judy] —> (location) —> [OFFICE] were joined to form the graph w: w = [AGE] <— (attribute) <— [WOMAN: Judy] —> (location) —> [OFFICE] Since [PERSON] in u was restricted to [WOMAN: Judy] in w, the projection of graph u in w (shown as : u w, or simply u) is [WOMAN: Judy] —> (attribute) —> [AGE] and the projection of graph v in w (shown as : v w, or simply u) is the original v: [WOMAN: Judy] —> (location) —> [OFFICE] Below in Chapters 5 and 6, we join multiple graphs, so that each one’s projections in the combined graph represent that graph’s overlap with the other graphs.
A.1.7. Generalization Generalization is the opposite of specialization. Generalization is performed by replacing an individual concept with its generic counterpart, or replacing a generic concept’s type label with a supertype. It thus enlarges App. A 133 the space of instances which are described by a canonical graph. Generalization does not necessarily preserve universal quantifiers (i.e., its result is not necessarily a canonical graph); rather, it creates an existential truth — there exist(s) some concept(s) satisfying the constraints of the generalized graph. For example, the graph [PERSON] —> (attribute) —> [TEMPERATURE] meaning “some person’s attribute is a temperature,” can be generalized to: [ENTITY] —> (attribute) —> [TEMPERATURE] meaning “some entity’s attribute is a temperature.” If all concepts in a generalization are minimal supertypes of their originating concepts in the graph, then the generalization is called a minimal common generalization or least common generalization.
A.1.8. Lambda Abstraction A -abstraction serves much the same purpose as an abstract data type in a programming language. It is a conceptual graph whose entire contents can be represented by a single named concept, relation, or actor. If an abstraction’s projection (a sub-graph) can be isolated and identified within a conceptual graph, then the entire projection may be replaced by the abstraction’s single concept. This is a simplification operation; unfortunately, it is equal in complexity to any algorithm that must determine sub-graph isomorphism — namely, NP-hard! Abstractions are defined in terms of lambda expressions. For example, if the following type abstraction exists: type PARENT(x) is [ PERSON: *x ]; [ PARENT: *x ] <— (parent_of) <— [ PERSON: *y ]; ¬ [ [ T: *x ] <— (ident) <— [ T: *y] ]; end; then the following graph:
PERSON: PERSON: CITY: parent_of location #38656 John Memphis can be simplified to: PARENT: CITY: location John Memphis
A.1.9. Context Earlier, we said that a canonical graph constrains graphs within some domain. Different domains are denoted by grouping a set of conceptual graphs into a context. A context is represented as a rectangle enclosing a set of conceptual graphs, and may be identified by a label consisting of one or more context/name pairs. Absence of a label indicates an anonymous context. A context can be composed of one or more inner contexts. A context includes canonical graphs, type definitions, and a type hierarchy all representing some domain of knowledge in the real world. Whereas a conceptual graph represents an assertion in a global domain (the universe, or “flat” name space), when placed in a context it represents an assertion that is true within the limited domain of that context. A context is therefore analogous to a scope in a procedural programming language. A context can be used wherever a concept can be used, so that a relation can be applied to an entire graph, e.g., App. A 134
PATIENT ANIMATE possible attribute
means “it is possible that in some context, some patient is animate.” A context can be negated in order to show that that its relationships are not true. The graph below means: it is not the case that some cat has the gender attribute MALE and the gender attribute FEMALE.
GENDER: attribute CAT attribute GENDER: ¬ Male Female
Conceptual graphs can express a variety of notions through relations. For example, use of the monadic relation possible allows graphs such as:
possible PROPOSITION: CAT state SITTING location MAT meaning it is possible that some cat is sitting on some mat. Contexts can be connected to one another, through explicit relations. A context may also be of some type that is a subtype to proposition. A context may also contain a name for convenience, in addition to its referent graph(s). A context is indicated in the linear form as the referent of a concept type PROPOSITION, e.g., (possible) [PROPOSITION: [CAT] (state) [SITTING] (location) [MAT] ]. A new alternative syntax is provided, so that a context label may be indicated by enclosing a set of conceptual graphs between context_label is and end; .
A.1.10. Line of Identity A line of identity connects two or more concept boxes representing identical occurrences of the same individual. The line of identity comes from Peirce original notation connecting a single proposition that appeared in another nested context. The following formula is represented by Figure A.3: App. A 135
~ x (person(x) ~ y (age(y) attribute(x, y)) )
PERSON attribute AGE ¬ PERSON ¬
Figure A.3. A Line Of Identity Between Different Contexts.
A line of identity also is used to connect concepts within a single context. As an example, consider the following first-order logic formula, which is represented by the conceptual graph in Figure A.4:
x y z [person(x) age(y) attribute(x, y) person(z) parentOf(x, z)]
PERSON attribute AGE
PERSON parentOf PERSON
Figure A.4. Two Graphs Connected By A Line Of Identity.
In the linear form of conceptual graphs, the text “*x” (or any other variable identifier) serves the purpose of the graphical line of identity. Figure A.4 is expressed as the following graph. [ PROPOSITION: [ PERSON: *x] —> (attribute) —> [ AGE] [ PERSON: *x] —> (parent_of) —> [ PERSON: * ] ] Two concepts in the same context which are connected by a line of identity can be merged to form a single concept, thus joining the two graphs in which the concepts first appeared. The two graphs in Figure A.4 can thus be joined to form the single graph in Figure A.5:
PERSON parentOf PERSON: attribute AGE *x
Figure A.5. Line Of Identity Removed Via Join.
Lines of identity establish what are called co-reference links. A concept on a line of identity is said to be co-referent to the other concept(s) sharing the line of identity. An additional constraint upon a line of identity is that its connected concepts’ referents must not conflict — i.e., if one concept refers to a particular individual, then all its co-referent concepts must also refer to the same individual. When a line of identity connects two concepts in two different graphs, the two graphs may be joined by replacing both concepts with a single concept box connected to all links from both previous graphs. The join is only allowed if the two concepts appear at the same nesting level (i.e., in the same context box with negations App. A 136 either both present or both absent) and their referents do not conflict (i.e., they are either generic concepts or they refer to the same individual).
A.1.11. Equivalent Representations Conceptual graphs can be expressed in three forms: a display form, a textual form, and an English paraphrase. Although transformations between them are straightforward, the display form is generally the easiest to work with. This section describes all three forms and the issues involved in transforming them.
Display Form The most compact form of conceptual graphs is their visual display form, consisting of rectangles, ovals, diamonds, and arrows arranged on a flat surface. This form is easier to learn and read than the other forms, perhaps because visual formalisms in general have been shown to be quite powerful (e.g., [Harel88], [Bailin89]). With appropriate graphics tools, a conceptual graph’s picture can be manipulated and analyzed directly by human developers.
Linear Form The display form of a conceptual graph can be expressed by one or more equivalent linear forms, made up of structured text. These have the advantage of being formally manipulable by a host of existing text processing tools, such as parsers, editors, etc. Their main drawback is their lack of comprehensibility – even a modest-sized graph can become unwieldy once lines of identity (see §3.2.10) are taken into account. Another drawback is that a single conceptual graph may have several equivalent linear forms, making comparisons more difficult.
Paraphrase Form Conceptual graphs can also be expressed in English-like sentences, called a paraphrase. Unlike the other two forms, a given English form may be difficult to translate into the other two without human help; it is primarily a redundancy check for the graphical and textual representations. Using some subset of English, it may be possible to translate requirements directly from English text to conceptual graphs. Probably no automated method is (yet) as good as a human interpreter in terms of its esthetics; however, paraphrasing requirements provide a reasonable means for participants to understand and discuss them. Sowa provides a default pattern for paraphrasing [A] —> (b) —> [C] as C is b to A. This simple paraphrasing can be enhanced by allowing each definition to to have its own paraphrasing template for translating occurrences into English. Some ideas along these lines are found in the extended examples of Chapter 6.
Transformations Among Representations The table in Figure A.6 describes the various transformations possible between forms. An “easy” transformation is O(n) where n is the number of nodes and arcs. App. A 137
FROM TO Display (Graph) Linear (Text) Paraphrase (Engl.) Easy transformation into Easy transformation, Display (Graph) one of several representa- depending on selection Same tions depending on of a starting concept. selection of a starting 1 – to – many. concept. 1 – to – many. Linear (Text) Easy transformation. Easy transformation. 1 – to – 1. Same 1 – to – many. Easy, iff paraphrase is Difficult: easier to use Paraphrase constrained to known display form as Same (English) structure and concepts. intermediate form. 1 – to – 1. 1 – to – many. Figure A.6. Equivalent Forms of Conceptual Graphs. The display form is two-dimensional and visual; the linear form is one-dimensional and textual. For example, the display form for the proposition A cat is sitting on a mat is:
CAT state SITTING location MAT
An equivalent linear form for the above graph is: [CAT] —> (state) —> [SITTING] —> (location) —> [MAT] An English paraphrase can aid understanding of conceptual graphs, expressing [C1] —> (relation) —> [C2] with the default pattern: the relation of C1 is C2: There is a CAT. The state of a CAT is a SITTING. There is a SITTING. The location of a SITTING is a MAT. There is a MAT. A.2. Conceptual Graphs and Logic Because first-order logic is such a powerful and useful theory, we must know that conceptual graphs possess at least the power of first-order logic; otherwise, we could discard conceptual graphs immediately as being inadequate. Sowa defines the operator to transform a conceptual graph into a logic formula [Sowa84, p. 86], and proves that any set of concepts and relations can be expressed by a formula in first-order logic with quantification. This section summarizes his results; other forms of logic are discussed in §A.3.1. A.2.1. First-Order Logic with Quantification Graphic logic notation was introduced by C. S. Peirce’s existential graphs (1910) in which rectangles
PERSON parent PERSON represent propositions. A simple conceptual graph such as represents an existentially quantified proposition, e.g., “There exists a person who is the parent of a person.” Without any further constraints, both persons could be the same, i.e., a person could be a parent to himself! In conceptual graphs, a concept’s referent is used to distinguish individuals. Other properties of first-order logic can also be represented: disjunction, conjunction, negation, universal p q quantification and implication. In the following summary, and represent propositions, i.e., context boxes each containing a set of assertions in conceptual graph form. App. A 138
Conjunction is expressed by simply enclosing two propositions inside a single context box, creating a new p q context in which both are true. Thus represents p q. p Negation of a proposition is expressed by the symbol “¬” next to a concept or context box, so that ¬ expresses ~ p. In English, we say, “It is not the case that there exists some p.”
¬ ¬ p ¬ q Disjunction is expressed by applying deMorgan’s law with a double negation, so that , which means ~(~p ~q), or “it is not true that there does not exist some p and there does not exist some q.” Universal quantification is equivalent to the double negation of an existential quantifier, so that ¬ ¬ p , which means ~ x(~ p(x) ) or “It is not the case that there does not exist some p,” is equivalent to x (p(x) ). ¬ p ¬ q Implication is expressed by the identity p q ~(p ~q), so that , means ~ x y [p(x) ~q(y) ], or “it is not the case that there exists some p and there does not exist some q.” There is no causal relationship implied by : i.e., no temporal assumptions that p must precede q. The following example illustrates the above equivalences between first order logic propositions and conceptual graphs. Figure A.7 expresses the formula below using conceptual graphs. The dashed lines represent T: *x lines of identity (see §A.1.10), so that *x, *y, and *z are redundant. Recall that the concept means some individual denoted by *x, with no actual type specified.
( x) [F(x) ( y) [( z) [G(z) H(y)] ] ]
T: *x F: *x T: *y T: *z
¬ ¬ ¬ ¬ ¬ ¬ ¬ G: *z ¬ H: *y
Figure A.7. Logic Formula As A Conceptual Graph.
One can argue that the meaning of Figure A.7 is not immediately clear, particularly since implication ( ) is shown indirectly; however, a like argument could be made for the formula’s nested parentheses, too. Understanding Figure A.7 does not seem to be any harder than understanding the formula. In fact, recent work in App. A 139 conceptual graphs has introduced an explicit IF-THEN construct as a shorthand to show logical implication more clearly. Conceptual graphs have been extended beyond first-order logic, so that logic functions are expressed using actor nodes (see next section). Further extensions (e.g., the demon node introduced in this work) can express temporal logics and non-monotonic logics.
A.2.2. Functions Conceptual graphs have been extended by Sowa to express procedural or logical functions. Consider the actor in a conceptual graph, which serves the purpose of a function. Each of an actor’s connected concepts is given a control marker — either enabled or disabled. A concept with arcs pointing toward an actor are the actor’s input concepts; concepts with arcs pointing away are the actor’s output concepts. The actor’s semantics are that when all of its input concepts are enabled, the actor “fires” (as in a Petri net [Peterson81]) by computing the referents of its output concepts and then all of its output concepts are enabled. An input concept of one actor that is not also an output concept of another actor is called a source concept. Evaluation of a graph with actors begins by marking all source concepts as enabled. Each actor has private algorithm to compute its output concepts’ referents based on its input concepts’ referents. For example, the actor
A.3. Conceptual Graph Extensions Conceptual graphs offer an excellent representation with which to develop multiple-viewed requirements. In order to support multiple views, some special syntax and context types are needed. When placed in a context, a set of conceptual graphs forms a body of knowledge relating to some view. This section introduces some extensions to the normal conceptual graph notation so that we can better additional knowledge in the real world.
A.3.1. Private Referent Part of this work depends upon transforming requirements into conceptual graphs from some other representation that is not conceptual graphs. We must be able to represent some knowledge in the world that is outside of a conceptual graph (or at least denote its existence) so that some limited reasoning (or manipulation) can be performed using conceptual graphs. This information is in a structure we call a private referent — an informal referent contained in a formal concept, but considered an un-interpreted (and un-alterable) object. The concept may have one formal referent as its name. In display form, a private referent is shown inside a dashed bucket below a formal concept box. In the linear form, only its associated type and name are shown within underline-brackets as: [_ Q: n _]; private referents may be impossible to show in linear form, since they do not have to be text.
PERSON: *p Q : n “r”
(a) (b)
Figure A.8. Representing A Private Referent. App. A 140
The meaning of Figure A.8(a) is that the solid box [Q: n] is treated as a normal conceptual graph concept, with type Q and name n. The attached private referent "r" is something not represented by conceptual graphs. A private referent cannot be changed, either through generalization, specialization, or the computation of an actor. It is simply carried along with the concept (and the concept’s formal referent if present). The portion above the solid line contains its context/type/referent labels. In the linear form, a private referent is shown as a regular concept, except that the square brackets contain underscores, as in [_ T _]. For example, Figure A.8(b) represents the concept [PERSON: *p] with an attached private referent (the picture of a person). Its name *p is a formal (“public”?) referent, changeable by conceptual graph operations such as an actor’s computation. Private referents are used in this work to capture requirements specifications that are not in conceptual graph form, so that we can still include them in analysis. Private referents can help us refine external information, so that informal knowledge can later be shown (at least partially) in formal conceptual graph notation. A private referent can be considered to be an atomic instance. For example, a designer’s data flow specification (named pms) is shown as the private referent of an R-Spec concept. No assumptions are made as to the actual contents or meaning of a private referent. There are no syntactic restrictions on a private referent. The part below the solid line can contain anything — text, pictures, sound, or a combination, e.g., a state transition diagram or a data flow diagram. Even if its internal semantics are considered “well-defined”, however, the private referent is still considered fixed in the conceptual graph formalism, i.e., not a candidate for being altered. For example, Figure A.9 is a set of data flow requirements for a patient-monitoring system. In linear form, it is [_ DATA_FLOW_DIAGRAM: patient_monitoring _].
DATA_FLOW_DIAGRAM: patient_monitoring
factors sensor
readings
out-of-range alarm Doctor / monitor Nurse normal ranges
Figure A.9. A Referent External to Conceptual Graphs.
A.3.2. Demons First-order logic is insufficient to describe all requirements. A relation denotes a static or permanent situation, and actor denotes how referents may change or how concepts may be applied dynamically to more than one individual. But there is still no way to denote the outright creation of a concept, or more generally, the introduction of new graphs into a body of knowledge. This section introduces just such a structure. Some cognitive structures are not adequately captured by Sowa’s notation [Sowa84] with only concepts, relations, and actors. Several variations have been proposed (e.g., [Gardiner89]) that represent some structures, such as logical implication, more naturally. In many cases, the variations are shorthands for equivalent (but less elegant) representations in the standard notation. In their original form, conceptual graph nodes were one of only two classes: concepts and relations. Concepts and relations were fixed: not only were their arrangements unchanging, but their referents as well. As the need was perceived for a functional node, a third class of actors was added, providing a means to alter App. A 141 referents themselves (i.e., have them refer to different individuals). Arrangements of concepts and actors, however, were still fixed. Some useful notions, such as state transition diagrams [Aho72], require a dynamic structure. A new fourth class of node is needed that not only allows changing referents, as performed by actors, but also changing arrangements over time as well. The new class of node is called a demon in this thesis. Its syntax is similar to an actor’s, except that it is enclosed in double angle brackets, as <
The meaning of B a C is that concept B’s existence activates the demon a, creating concept C, and then retracting concept B. For the case where B is not to be retracted, the graph
B a C with an arrow back to B is allowed. As a shorthand, the pair of arcs between B and a are shown with a single two-directional arrow, as B a C . In the linear form, a demon is shown by double angle brackets, e.g., “[B] <—> <> —> [C]”. A demon’s input links must all be marked before the demon fires, much as an actor fires. By extension, the creation of a concept can mean the creation of an entire graph. Likewise destruction or retraction can involve entire graphs. What does it mean to create a concept box? Since a concept box represents an existential assertion, creating a concept box on the plane of existence is equivalent to asserting a new proposition. Erasure of a concept is the equivalent of retracting its asserted proposition — i.e., saying, “This fact (or context) is longer true.” A relation or actor is asserted when all its associated concepts are asserted; likewise, a relation or actor is retracted if any of its associated concepts are retracted. These added semantics allow the expression of dynamic logic, whereby prior truths may be subsequently falsified. We can thereby express notions of non-monotonic logic, such as discussed in [Turner84]. Two primitive demons are proposed. An initiator demon, <
T B
r
A X D s C ^
Figure A.10. Example Graph Containing Demons. App. A 142 can be envisioned as representing a series of different conceptual structures varying over time as shown in Figure A.11, with each plane representing the arrangement at a given time:
T
A r B
X
C s D
^ D
Figure A.11. Changing Conceptual Graphs Over Time.
Conceptual graphs with actors are comparable to static allocation in a conventional programming language. Adding the demon’s semantics allows one to represent dynamic allocation, whereby structures may come into being and later pass from existence. Demons were used in Chapter 5 (as described in Appendix B) to capture state transition semantics. A demon’s creation of its output concepts precedes any subsequent retraction of its input concepts; however, the operations are considered to take place simultaneously. Any intermediate states are considered undefined: there is no semantics for a demon’s incomplete activation. App. B 143
Appendix B. Translation Schemes
APPENDIX SUMMARY Table of Contents List of Figures Abbreviations and Symbols 1. Introduction 1.1. Problems With Software Requirements 1.2. Context of Work 1.3. Multiple Views 1.4. Improving Requirements Development 1.5. Outline Of Dissertation 2. Views In Software Requirements Development 2.1. Views in Requirements 2.2. Example Requirements and Assumptions 2.3. Support For A Single View 2.4. Multiple Viewed Requirements 2.5. The Multiple Viewed Approach 2.6. Summary 3. Analyzing Multiple-Viewed Requirements 3.1. Role Of the Requirements Analyst 3.2. Analyzing Overlap Between Views 3.3. General Issues For Multiple Views 3.4. Summary 4. A Framework and Methodology For Multiple-Viewed Analysis 4.1. Conceptual Graphs: An Analyst’s Meta-Language 4.2. Definition Of A View 4.3. Analyst’s Framework 4.4. Analysis of Multiple Viewed Requirements 4.5. A Methodology For Multiple Viewed Requirements 4.6. General Features Of Approach 4.7. Summary 5. Translating Requirements Into Conceptual Graphs 5.1. Entity-Relationship Diagrams 5.2. Data Flow Diagrams 5.3. State Transition Diagrams 5.4. Requirements Networks (SREM) 5.5. Summary 6. A Multiple Viewed Analysis Example 6.1. Analysis: First Association 6.2. Analysis: Second Association 6.3. Analysis: Third Association 6.4. Results of Analysis 6.5. Summary 7. Validating Multiple Viewed Analysis 7.1. Overlap Characteristics 7.2. Cost Considerations Of Multiple Views 7.3. Reasonableness of Overlap 7.4. Summary 8. Preliminary Validation Of Patient-Monitoring 8.1. Derived Overlap Characteristics 8.2. Reasonableness of Overlap App. B 144
8.3. Summary 9. Results of Multiple-Viewed Requirements Development 9.1. Major Findings 9.2. Tractability 9.3. Duties Of The Requirements Analyst 9.4. Limitations of the Approach 9.5. Summary 10. Conclusion 10.1. Summary of Thesis 10.2. Future Research 10.3. Speculation 10.4. Concluding Remarks Appendix A: Conceptual Graphs A.1. Conceptual Graph Notation A.2. Conceptual Graphs and Logic A.3. Conceptual Graph Extensions Appendix B. Translation Schemes B.1. Entity-Relationship Translation Scheme B.2. Data Flow Translation Scheme B.3. State Transition Translation Scheme B.4. Requirements Network Translation Scheme B.5. Summary References
This appendix gives detailed algorithms showing how we translate requirements specifications into conceptual graphs. The two algorithms that translate a diagram into conceptual graphs and back are called a translation scheme. One algorithm translates the notation into conceptual graph form; it is called a compilation algorithm (the “a” algorithms below). To complete the descriptions, we also provide a reverse translation algorithm for each notation that re-creates an original diagram from its conceptual graph representation; it is called an extraction algorithm (the “b” algorithms below). These terms are taken from Muehlbacher’s work [Muehlbacher90]. Each section of this appendix has the same structure: first, the notation is described, then its translation algorithms are shown. For each language, we assume we are starting from a well-formed diagram. This is for two reasons: first, it simplifies the presentation of the algorithms and second, these notations already have well- established techniques for determining their internal consistency. We therefore do not check for badly-formed originating diagrams.
B.1. Entity-Relationship Translation Scheme
An entity-relationship diagram is a bipartite, non-directed graph where every node is either an entity or relation [Chen76]. Nodes of either type may have associated attributes. Labels on arcs indicate the arity (many-to- many-ness) of a relation, e.g., one-to-one, one-to-many, etc. Our general strategy is to translate entities into conceptual graph concept boxes and relations into conceptual graph relations, where the relation’s dependency is either obtained from pre-existing relation definitions or supplied by the analyst.
Translation 1. Given an entity-relationship diagram [_ LANG era R-Spec _], a set of conceptual graphs [ LANG era R-Spec-Graph: { U } ] can be constructed that preserves all information in [_ LANG era R-Spec _]. Algorithm 1a provides a translation from [_ LANG era R-Spec _] to [ LANG era R-Spec-Graph: U ]. Algorithm 1b provides a translation back to [_ LANG era R-Spec _] from [ LANG era R-Spec-Graph: U ]. Therefore all information in [_ LANG era R-Spec _] must be contained in [ LANG era R-Spec-Graph: U ]. App. B 145
B.1.1. Compilation Algorithm 1a A compilation algorithm for translating the entity-relationship diagram [_ LANG era R-Spec _] into [ LANG era R-Spec-Graph: U ] is the following: Let [_ LANG era R-Spec _] be a non-directed bipartite graph whose vertices are a set of entities C, and a set of relations R. There are zero or more attributes associated with each vertex. The graph’s edges consist of the set E, each member having a many-to-many-ness label (default 1) in order to express one-to-one, one-to-many, or many-to-many relations. App. B 146
Begin Algorithm 1a. Let u = { }. Each node and edge in [_ LANG era R-Spec _] is initially unmarked. While r R such that r is not marked loop Put “(r)” in u. ; translates relations Mark r. Look for canonical definition of r (if any) to determine direction of links. If there are any attributes associated with r then begin Link “ [ Attrset: r ]” to (r) in u. ; kludge to account for attributes of relations since ; can’t link 2 relations: (rel) (attribute) [T] For each attribute ai such that ai is associated with r loop Link “ (attribute) [ai ]” to [ Attrset: r ] in u ; translates relation’s attributes end for end if
For each edge ei connected to r loop Let ci be the entity to which it is connected. Let mi be its many-to-many-ness label. If ck C such that: ck ci and ck is connected to r and ck has cardinality mk 1 then ; direction of arrows below (dependency) is either: ; 1. obtained from canonical definition of r, if present. ; 2. obtained through manual means. Put “[ { [ ck : { * } ] (r) [ ci : { * } @mi ] } @mk ]” around (r) in u. ; (r) is already there ; see discussion below. If ck is already marked then Join this occurrence of [ck ] to previous occurrence with same referent (see text). else begin Mark ck Put “ck < ENTITY.” into u. For each attribute akj such that akj is associated with ck loop Link “ (attribute) [akj ]” to ck in u ; translate related entity’s attributes Put “akj < ATTRIBUTE.” into u. end for end if else ; direction (dependency) of single arrow is either: ; 1. obtained from canonical definition of r, if present. ; 2. obtained from the participant through manual means. Link “ [ ci : { * } @mi ]” to (r) in u ; translate related entities end if Special case: if all mi = 1, then link “ [ci ]” to (r) in u because [ T : { * } @1] is equivalent to [ T: * ] If ci is already marked then Join this occurrence of [ci ] to a previous occurrence with same referent (see text). else begin Mark ci App. B 147
Put “ci < ENTITY.” into u. For each attribute aij such that aij is associated with ci loop Link “ (attribute) [aij ]” to ci in u ; translate related entity’s attributes Put “aij < ATTRIBUTE.” into u. end for end if end for end while
While c C such that c is not marked loop Put “[ c ]” in u. ; translate any unrelated entity Mark c. Put “c < ENTITY.” into u. For each attribute ai such that ai is associated with c loop Link “ (attribute) [ai ]” to c in u ; translate its attributes Put “ai < ATTRIBUTE.” into u. end loop end while
end Algorithm 1a. Although this algorithm will preserve a relation’s attributes, we have not yet developed any techniques for manipulating them further; our analysis will be based on entities’ attributes only. The handling of many-to-many-ness in Algorithm 1a needs further explanation. Consider the ER diagram: 1 M 1 N A d B e C
Using Algorithm 1a as given above, we obtain the following:
A : { * } B : { * } C : { * } d e @1 @ ??? @N A < ENTITY. B < ENTITY. C < ENTITY. It is clear that concept A is a set of cardinality 1, and concept C is a set of cardinality N, but what about concept B? Looking from left to right, B would be a set of cardinality N, but from right to left, it would be a set of cardinality 1. When this situation occurs, the solution is to select the entity E related to B whose many-to-many-ness is not one, then enclose B, E, and all its relations within a set referent in a context box. The context box then 1 M 1 N becomes the “entity” for further translations. In the example A d B e C , we translate the 1 N B e C portion into the conceptual graph:
B : * e C : { * } @N B < ENTITY. C < ENTITY. so the example diagram is translated into: App. B 148
A : * C : { * } d B : * e @M @N
A < ENTITY. B < ENTITY. C < ENTITY. We may omit the cardinality indication (“@M”) when it means some indeterminate cardinality as in [ T: { * } ]. Additional examples are shown above in Chapter 5. Algorithm 1b below is to demonstrate Translation 1 above. It shows how the original era R-Spec can be obtained from its corresponding conceptual graph representation. The reader may wish to look at the example in §5.1.1 above before examining Algorithm 1b.
B.1.2. Extraction Algorithm 1b The following extraction algorithm translates [ LANG era R-Spec-Graph: u ] to [_ LANG era R- Spec _]. The graph [ LANG era R-Spec-Graph ] consists of three finite sets: C, the set of all its concepts; R, the set of all its relations; and E, the set of its directed links. A link contains the identity of its two ends. Any actors or demons in [ LANG era R-Spec-Graph ] are ignored. App. B 149
Begin Algorithm 1b. Let R-Spec be blank. Each concept, relation and link in u is initially unmarked.
While c C such that c is not marked loop If c has no incoming link from relation (attribute) then begin Put “entity c” in R-Spec. ; entities preserved. Mark concept c. For each ci C such that “c (attribute) ci ” is in u loop Put “attribute ci” with entity c in R-Spec. ; entity’s attributes preserved. Mark ci . Mark (attribute). Mark both links to (attribute) relation. end loop end if end loop
For each ri R such that ri is not (attribute) loop ; attributes already preserved. Put “relation ri ” into R-Spec. ; relations preserved. Mark ri. for each c C such that link “c ( ri )” or “c ( ri )” is in u loop if c = [ Attrset ] then begin for each ai C such that “c (attribute) ai ” is in u loop Put “attribute ai” with entity c in R-Spec. ; relation’s attributes preserved. Mark ai. ; (see kludge in Algorithm 1a). Mark relation (attribute). Mark both links to (attribute) relation. end loop else begin ; normal connections from relation to entity. Connect era relation ri to entity c in R-Spec. if c C is within a nested context in u then begin Let k be the cardinality of the context. ; many-to-many-ness preserved. Put “many-to-many-ness = k” with link ri to c in R-Spec. else Put “many-to-many-ness = 1” with link ri to c in R-Spec. end if end if end loop end loop
end Algorithm 1b. This concludes the description of Translation 1.
B.2. Data Flow Translation Scheme In this section, we use data flow diagrams based on the Yourdon/de Marco variant [DeMarco80], [Yourdon79]. In order to represent data flow diagrams using conceptual graphs, we use actors, as explained in Appendix A (§A.2.2). An actor represents a data flow process that is allowed to change the referents of its App. B 150 outputs, using steps known as its private algorithm. Its arcs are classified as either input or output arcs, shown by dashed lines.
Translation 2. Given a data flow diagram [_ LANG dfd R-Spec _], a set of conceptual graphs [ LANG dfd R-Spec-Graph: U ] can be constructed that preserves all information in [ LANG dfd R-Spec _]. Method: Algorithm 2a provides a translation from [_ LANG dfd R-Spec _] to [ LANG dfd R-Spec- Graph: U ]. Algorithm 2b provides a translation back to [_ LANG dfd R-Spec _] from [ LANG dfd R-Spec- Graph: U ]. Therefore all information in [_ LANG dfd R-Spec _] must be contained in [ LANG dfd R-Spec- Graph: U ].
B.2.1. Compilation Algorithm 2a A compilation algorithm for translating the data flow diagram [_ LANG dfd R-Spec _] into [ LANG dfd R-Spec-Graph: U ] is the following: Let the private referent of [_ LANG dfd R-Spec _] be a directed connected graph consisting of a set of labeled bubbles P representing processes, and a set of labeled directed edges E representing data flows. An edge connected to only one bubble represents either a data source or data sink; it is handled by the algorithm as an incomplete arc. Every edge is connected to at least one bubble . The following algorithm translates [_ LANG dfd R-Spec _] into [ LANG dfd R-Spec-Graph: U ].
Begin Algorithm 2a. Let u = { }. Each bubble and edge in SPEC is initially unmarked.
While p P such that p is not marked loop Put “< p >” in u ; actors preserve bubbles For all ei such that ei E and ei is connected to p loop If ei is a plural noun then Let e = singular form of ei. Let c = [ e: { * } ] else Let c = [ ei ] end if If ei is directed towards p then link “ c” to < p > in u else link “ c ” to < p > in u ; concepts preserves data end if if ei is marked then Join this occurrence of [ei ] to a previous occurrence with same referent (see text). else Mark ei Put “ei < DATA.” into u. end if end loop end loop end Algorithm 2a. Since in a well-formed data flow diagram, every edge must be connected to at least one process, this algorithm terminates when every p P has been marked, and therefore every edge has been translated. Algorithm 2b below is to demonstrate Translation 2 above. It shows how the original dfd R-Spec can be obtained from its corresponding conceptual graph representation. The reader may wish to look at the example before examining Algorithm 2b. App. B 151
B.2.2. Extraction Algorithm 2b The following extraction algorithm translates [ LANG dfd R-Spec-Graph ] into [_ LANG dfd R- Spec _]. The graph [ LANG dfd R-Spec-Graph: u ] consists of three sets: A, the set of its actors; R, the set of its relations; and E, the set of its directed links. A link includes the identity of its two ends. Any relations or demons in [ LANG dfd R-Spec-Graph ] are ignored. Every concept is connected by either one link or two links to an actor; if connected by two links, one must be an incoming link, the other an outgoing link.
Begin Algorithm 2b. Let R-Spec be blank. Each concept and relation in u is initially unmarked. for each a A loop Put “process a” in R-Spec. ; bubbles preserved. Mark actor a end loop for each c C loop if c has one link ei toward actor ai then begin ; identify sources. Put “source c” on edge directed towards process ai in R-Spec. Mark c. ; preserve sources. end if if c has one link ek away from actor ak then begin ; identify sinks. Put “sink c” on edge directed from process ak in R-Spec. Mark c. ; preserve sinks. end if if c has one link ei toward actor ai and one link ek toward actor ak then begin ; identify intermediate data. Put “c” on edge directed from process ak towards process ai in R-Spec. Mark c. ; preserve intermediate flows. end if end loop
end Algorithm 2b. This concludes the description of Translation 2.
B.3. State Transition Translation Scheme We use the standard definition of state transitions based on input symbols [Aho72], although we may be able to generalize our definition to include any event as an input symbol or output symbol. In the standard definition, each event therefore means the arrival of an input symbol or the creation of an output symbol. We will translate state transition diagrams into conceptual graphs by using instances of the concept STATE to represent each state, a demon to represent each transition, and instances of DATA to represent input and output tokens. Translation 3. Given a state transition diagram [_ LANG std R-Spec _], a set of conceptual graphs [ LANG std R-Spec-Graph: U ] can be constructed that preserves all information in [_ LANG std R-Spec _]. Method: Algorithm 3a provides a translation from [_ LANG std R-Spec _] to [ LANG std R-Spec- Graph: U ]. Algorithm 3b provides a translation back to [_ LANG std R-Spec _] from [ LANG std R-Spec- Graph: U ]. Therefore all information in [_ LANG std R-Spec _] must be contained in [ LANG std R-Spec- Graph: U ]. Let the state transition diagram be denoted by a private referent of the concept [_ LANG std R-Spec: (Q, , , , q0, F) _], where the elements of the 6-tuple are: Q = finite set of states, App. B 152
= finite set of input tokens, = finite set of output tokens, = map from Q (Q, the state transition function, q0 Q the start state, and F Q the set of final (accepting) states. The state transition semantics associated with the definition assumes the following: • Every time an input token s appears, the state transition function is examined to find some Q pair (qcurrent, s) whose result is (qnext, d). The state qnext becomes the current state, and output token d is produced. • Before any action occurs, state q0 is the current state. B.3.1. Compilation Algorithm 3a A compilation algorithm for translating the state transition diagram [_ LANG std R-Spec _] into [ LANG std R-Spec-Graph: U ] is the following:
Begin Algorithm 3a. Let u = { }. All elements of all sets (Q, , , , q0, and F) are initially unmarked.
While q Q such that q is not marked begin Mark q Put “q < STATE.” into u. If q = q0 then Put “<< T >> [ q ]” into u. ; preserves initial states else Put “[ q ]” into u. ; preserves other states end if end while
While s such that s is not marked begin Put “[ s ]” into u. ; preserve input tokens Put “s < DATA.” into u. Mark s. end while
While d such that d is not marked begin Put “[ d ]” into u. ; preserve output tokens Put “d < DATA.” into u. Mark d. end while App. B 153
While f such that f is not marked begin
Let qi Q be f ’s current state. Let s be f ’s input token.
Let qj Q be f ’s next state. Let d be f ’s output token. Put “[ qi ] << transition >> — [ s ], [ qj ], [ d ]” into u. ; preserves transition functions Join this occurrence of [ qi ] to a previous occurrence with same referent. Join this occurrence of [ s ] to a previous occurrence with same referent. Join this occurrence of [ qj ] to a previous occurrence with same referent. Join this occurrence of [ d ] to a previous occurrence with same referent. Mark f. end while While f F such that f is not marked begin Put “[ f ] (final)” into u ; preserves final states. Join this occurrence of [ f ] to a previous occurrence with same referent. end while end Algorithm 3a. Since a demon denotes the creation of new concepts, and the retraction of existing ones, this representation of a state transition diagram is made simple. Only one state exists at any one time, because enabling the demon << transition >> causes the old state (and the input) to be retracted while it creates a new state (and the output). No explicit indicator of the current state is necessary; since only one state exists, it must be the current state. The start state is enabled by demon << T >> (the initiator demon, see Appendix A, §A.3.2), thus causing the start state to exist before any transitions occur. Algorithm 3b below is to demonstrate Translation 3 above. It shows how the original state transition R- Spec can be obtained from its corresponding conceptual graph representation. The reader may wish to look at the example before examining Algorithm 3b. B.3.2. Extraction Algorithm 3b The following extraction algorithm translates [ LANG std R-Spec-Graph: u ] to [_ LANG std R- Spec _]. The graph [ LANG std R-Spec-Graph: u ] consists of four finite sets: C, the set of its concepts; R, the set of its relations; D, the set of its demons; and E, the set of its directed links. Only relations named (final) are in R, and D contains only demons named << transition >> or << T >> (the initiator). Any other demons or relations, and all actors in u are ignored.
Begin Algorithm 3b.
Let R-Spec contain six sets Q, , , , q0, and F.
where Q = { }, = { }, = { }, = { }, q0 = { }, F = { } .
For each s such that “<< T >> [ s ]” and “s < STATE.” are in u loop Let q0 = q0 { s } ; preserves start state. end for
For each [ s ] C such that “<< T >> [ s ]” and “s < STATE.” are in u loop Let Q = Q { s } ; preserves set of all states. end for App. B 154
For each d D such that d = “<< transition >> ” and “[ q ] d [ s ]” and “q < STATE.” and “s < STATE.” are in u loop If “[ inp ] d” and “inp < DATA.” are in u then begin Let i = inp Let = { inp } ; preserves set of input tokens. else Let i = “—” ; case with no input token. end if If “d [ out ]” and “out < DATA.” are in u then begin Let o = out Let = { out } ; preserves set of output tokens. else Let o = “—” ; case of no output token end if Let = { f } where ; preserves transition functions. q is f’s current state, i is f’s input token, r is f’s next state, and o is f’s output token. end for For each [ s ] C such that “(final) [ s ]” is in u loop Let F = F { s } ; preserves set of final states. end for end Algorithm 3b. This concludes the description of Translation 3. B.4. Requirements Network Translation Scheme This translation scheme makes use of a component-for-component equivalence table which shows the major R-net components and their corresponding structures in conceptual graphs. The same table will be used for both algorithms. Translation 4. Given a requirements network [_ LANG Rnet R-Spec _], a set of conceptual graphs [ LANG Rnet R-Spec-Graph: U ] can be constructed that preserves all information in [_ LANG Rnet R-Spec _]. Method: Algorithm 4a provides a translation from [_ LANG Rnet R-Spec _] to [ LANG Rnet R-Spec- Graph: U ]. Algorithm 4b provides a reverse translation back to [_ LANG Rnet R-Spec _] from [ LANG Rnet R-Spec-Graph: U ]. Therefore all information in [_ LANG Rnet R-Spec _] must be contained in [ LANG Rnet R-Spec-Graph: U ]. B.4.1. Compilation Algorithm 4a A compilation algorithm for translating a requirements network diagram [_ LANG Rnet R-Spec _] into [ LANG Rnet R-Spec-Graph: U ] is the following: App. B 155
Begin Algorithm 4a. Let u = { }. All elements of [_ LANG Rnet R-Spec _] are initially unmarked. For each s such that s is a start symbol loop For each node n in the path starting with s loop Find node n in the Symbol column of Figure B.1. Re-write n in conceptual graph form as In Conceptual Graphs in Figure B.1. Mark n. end loop end loop End of Algorithm 4a. The table in Figure B.1 lists the component-for-component translations which are implemented by Algorithms 4a and 4b.
Component Symbol Example In Conceptual Graphs Start R-net Start
Message M MESSAGE: MESSAGE: M M M or or MESSAGE < DATA. Process
P P T P or
AND connector & & A B A B
Selector selector ¬ C item ITEM: ITEM: a values “a” {a,b,else} else @1 “b” ¬ ¬ ITEM: b D C D E
¬ ITEM: else E
ITEM < ATTRIBUTE End R-net No more inner contexts or end
Figure B.1. Translation Of R-net Nodes Into Conceptual Graphs. App. B 156
This algorithm relies on properties of first-order logic that are explained in §A.2.1. The selector ( ) needs some explanation. It must represent knowledge about several alternatives, even though the selector chooses only one. Translating a selector results in several conceptual graph contexts, one for each alternative. The alternatives are made mutually exclusive by placing the selector in a generic concept in the current context (e.g., [ITEM]), while placing individual selector instances (e.g., [ITEM: a], [ITEM: b], etc.) in new separate contexts. Each individual instance of a selector value is connected to the generic concept (e.g., [ITEM: {a, b, else} @1] ) by a line of identity, but is not connected to the other selector individuals; e.g., [ITEM: a] is not connected by a line of identity to [ITEM: b]; they are not compatible. Because the cardinality of [ITEM] is 1, however, only one of the individuals (values) can exist at any one time. Algorithm 4b below is to demonstrate Translation 4 above. It shows how the original requirements network R-Spec can be obtained from its corresponding conceptual graph representation. The reader may wish to look at the example before examining Algorithm 4b. B.4.2. Extraction Algorithm 4b The following extraction algorithm translates [ LANG Rnet R-Spec-Graph: u ] to [_ LANG Rnet R- Spec _]. The graph [ LANG Rnet R-Spec-Graph: u ] consists of four finite sets: C, the set of its concepts; R, the set of its relations; D, the set of its demons; and E, the set of its directed links. Begin Algorithm 4b. Let R-Spec be blank. For each context x in u, starting with outermost context loop For each component in x, loop Find a match for x in the In Conceptual Graphs column of Figure B.1. Get an R-net component c from the Symbol column of Figure B.1 Connect c to R-Spec. end for end for End of Algorithm 4b.
This concludes the description of Translation 4.
B.5. Summary This appendix gave the details of how we translate several different notations into conceptual graphs. Algorithms 1b, 2b, 3b, and 4b (the extraction algorithms) were provided primarily for a demonstration of the correctness of Algorithms 1a, 2a, 3a, and 4a respectively (the compilation algorithms). However, extraction may be useful for two purposes: (1) to show which conceptual graph structures capture the notation’s information (e.g., only concepts and relations are present in an era-based conceptual graph), and (2) to express the analyst’s graph after we have identified overlapping conceptual graphs and want to convey our results in one of the originating notations. References 157
References
[Agresti86a] William W. Agresti, “The Conventional Life-cycle Model: Its Evolution and Assumptions,” in New Paradigms for Software Development, IEEE Computer Society, William W. Agresti, ed., 1986. [Agresti86b] William W. Agresti, New Paradigms for Software Development, IEEE Computer Society, 1986. [Agresti87] William W. Agresti, “Guidelines for Applying the Composite Specification Model,” Software Engineering Laboratory, no. SEL-87-003, Greenbelt, MD, U.S.A., June 1987. [Aho72] Alfred V. Aho, The Theory of Parsing, Translation and Compiling, Prentice-Hall, Vol. I, Englewood Cliffs, NJ, 1972. [Alford77] Mack W. Alford, “A Requirements Engineering Methodology for Real-Time Processing Requirements,” IEEE Trans. Softw. Eng., Vol. SE-3, no. 1, pp. 60-69, Jan. 1977. [Alford85] Mack W. Alford, “SREM at the Age of Eight: The Distributed Computing Design System,” IEEE Computer, Vol. 18, no. 4, pp. 36-46, Apr. 1985. [Ameen89] Lisa Ameen, “CGPro: An Expandable Conceptual Graph Processing Shell,” Master’s thesis, University of Alabama in Huntsville, Department of Computer Science, Research Institute, 1989. [Bailin89] Sidney C. Bailin, “An Object-Oriented Requirements Specification Method,” Comm. ACM, Vol. 32, no. 5, pp. 608-623, May 1989. [Balzer82] Robert M. Balzer, Neil M. Goldman, and David S. Wile, “Operational Specification as the Basis for Rapid Prototyping,” ACM SIGSOFT Softw. Eng. Notes, Vol. 7, no. 5, pp. 3-16, Dec. 1982. [Basili81] Victor Basili and D. Weiss, “Evaluation of a Software Requirements Document by Analysis of Change Data,” Proc. 5th Intl. Conf. Softw. Eng., pp. 314-323, IEEE Computer Society, Washington, D.C., 1981. [Bell77] Thomas E. Bell, David C. Bixler, and Margaret E. Dyer, “An Extendable Approach to Computer-Aided Software Requirements Engineering,” IEEE Trans. Softw. Eng., Vol. SE-3, no. 1, pp. 49-59, Jan. 1977. [Borgida85] Alexander Borgida, Sol Greenspan, and John Mylopoulos, “Knowledge Representation as the Basis for Requirements Specifications,” IEEE Computer, Vol. 18, no. 4, pp. 82-91, April 1985. [Chen76] Peter Pin-Shan Chen, “The entity-relationship model — toward a unified view of data,” ACM Trans. Database Sys., Vol. 1, no. 1, pp. 9-36, 1976. [Chipman90] Laure J. Chipman, “A Graph Theoretic Approach to Scene Matching,” Ph.D. thesis, Univ. Alabama in Huntsville, Dept. of Computer Science, 1990. [Clocksin84] W. F. Clocksin and C. S. Mellish, Programming in Prolog (2e), Springer-Verlag, Berlin, 1984. [Davis90] Alan M. Davis, Software Requirements: Analysis and Specification, Prentice-Hall, Englewood Cliffs, NJ 07632, 1990. [Defense85] U.S. Department of Defense, Defense System Software Development, , Military Standard DOD- 2167, 1985. [DeMarco80] Tom DeMarco, Structured Analysis: Systems Specifications, Yourdon, Prentice-Hall, New York, 1980. [Finkelstein89] Anthony Finkelstein and Hugo Fuks, “Multiparty Specification,” Proc. 5th Intl. Wkshop, Softw. Spec. and Design, pp. 185-195, ACM SIGSOFT, 1989. [Fullerton83] James J. Fullerton, Albert H. Stone, and David A. Hartschuh, “Specifying Distributed Systems Requirements Using SREM,” in Entity-Relationship Approach to Software Engineering, North-Holland, C. G. Davis, S. Jajodia, P. A. Ng, and R. T. Yeh, eds., pp. 691-700, 1983. [Gardiner89] David A. Gardiner, Bosco Tjan, and James R. Slagle, “Extended Conceptual Structures Notation,” Proc. 4th Annual Workshop on Conceptual Structures at IJCAI-89, Janice A. Nagle and Timothy E. Nagle, eds., pp. 3.05, AAAI, Menlo Park, CA 94025, Aug. 20-21, 1989. [Harel88] David Harel, “On Visual Formalisms,” Comm. ACM, Vol. 31, no. 5, pp. 514-530, May 1988. References 158
[Heninger78] Kathryn Heninger, John W. Kallander, David L. Parnas, and John E. Shore, “Software Requirements For the A-7E Aircraft,” Naval Research Laboratory, NRL Memorandum Report, no. 3876, Washington, D.C., Nov., 1978. [Hewett89] Michael Hewett and Jr. M. Vaughan Johnson, “Representation for Communication in Distributed Systems,” Proc. 4th Annual Workshop on Conceptual Structures, Janice A. Nagle and Timothy E. Nagle, eds., pp. 4.6, IJCAI-89, Menlo Park, CA 94025, Aug. 20-21, 1989. [Hirschheim89] Rudy Hirschheim and Heinz K. Klein, “Four Paradigms of Information Systems Development,” Comm. ACM, Vol. 32, no. 10, pp. 1199-1216, Oct. 1989. [IEEE84] IEEE IEEE, Software Requirements Specifications, IEEE/ANSI Std. 830-1984, 1984. [Muehlbacher90] Robert Muehlbacher, “Using Conceptual Graphs as a Representation Language for System Analysis Methods,” Proc. of the 5th Annual Workshop on Conceptual Structures, Peter Eklund and Laurie Gerholz, eds., pp. 221-232, Linköping University, Boston & Stockholm, 1990. [Mullery79] G. P. Mullery, “CORE - A Method For Controlled Requirement Specification,” Proc. 4th Intl. Conf. Softw. Eng., pp. 126-135, IEEE Computer Society, 1979. [Peterson81] James L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, Englewood Cliffs, NJ, 1981. [Roman85] Gruia-Catalin Roman, “A Taxonomy of Current Issues in Requirements Engineering,” IEEE Computer, Vol. 18, no. 4, pp. 14-23, April 1985. [Roman90] Gruia-Catalin Roman, “Formal Specification of Geographic Data Processing Requirements,” IEEE Trans. Knowledge and Data Eng., Vol. 2, no. 4, pp. 370-380, Dec. 1990. [Ross77] Douglas T. Ross and Jr. Kenneth E. Schoman, “Structured Analysis for Requirements Definition,” IEEE Trans. Softw. Eng, Vol. SE-3, no. 1, pp. 6-15, Jan. 1977. [Ross85] Douglas T. Ross, “Applications and Extensions of SADT,” IEEE Computer, Vol. 18, no. 4, pp. 25-35, Apr. 1985. [Schank75] Roger C. Schank, Conceptual Information Processing, Elsevier Science Publishers, 1975. [Scheffer85] Paul A. Scheffer, Albert H. Stone, III, and William E. Rzepka, “A Case Study of SREM,” IEEE Computer, Vol. 18, no. 4, pp. 36-46, Apr. 1985. [Sowa84] John F. Sowa, Conceptual Structures: Information Processing in Mind and Machine, Addison-Wesley Publ. Co., Reading, Mass. U.S.A., 1984. [Swann83] T. G. Swann, “Requirements Decomposition and Other Myths,” AGARD Conf. Proc. Softw. for Avionics, No. 330, pp. 7.1-7.8, NATOAdvisory Group for Aeronautical Research and Development, 1983. [Teichroew77] Daniel Teichroew and Ernest A. Hershey, III, “PSL/PSA: A Computer-Aided Technique for Structured Documentation and Analysis of Information Processing Systems,” IEEE Trans. Softw. Eng., Vol. SE-3, no. 1, pp. 41-48, Jan. 1977. [Turner84] Raymond Turner, Logics for Artificial Intelligence, John Wiley & Sons, New York, 1984. [Wartik83] Steven P. Wartik, “A Multi-Level Approach to the Production of Requirements for Interactive Computer Systems,” Ph.D. thesis, University of California, Santa Barbara, Dec. 1983. [Wasserman82] Anthony I. Wasserman and David T. Shewmake, “Rapid Prototyping of Interactive Information Systems,” ACM SIGSOFT Softw. Eng. Notes, Vol. 7, no. 5, pp. 171-180, Dec. 1982. [Wasserman86] Anthony I. Wasserman, Peter A. Pircher, David T. Shewmake, and Martin L. Kersten, “Developing Interactive Information Systems With the User Software Engineering Methodology,” IEEE Trans. Softw. Eng, Vol. SE-12, no. 2, Feb. 1986. [Wood-Harper85] A. T. Wood-Harper, Lyn Antil, and D. E. Avison, Information Systems Definition: The Multiview Approach, Blackwell Scientific Publ., Oxford, U.K., 1985. [Yourdon79] Edward Yourdon and Larry L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Prentice-Hall, Englewood Cliffs, NJ, 1979. References 159
[Zave82] Pamela Zave, “An Operational Approach to Requirements Specification for Embedded Systems,” IEEE Trans. Softw. Eng., Vol. SE-8, no. 3, pp. 250-269, May 1982. [Zave84] Pamela Zave, “The Operational versus the Conventional Approach to Software Development,” Comm. ACM, Vol. 27, no. 2, pp. 104-118, Feb. 1984. [Zave89] Pamela Zave, “A Compositional Approach to Multiparadigm Programming,” IEEE Software, Vol. 6, no. 5, pp. 15-25, Sept. 1989.