(UML) Artifacts

Download PDF
0 downloads 0 Views 96KB Size Report
Comment
Previous work by the authors [2, 3] showed how the translation of .... 3 MAPPING USE-CASE MODELS TO ..... [9] Forsberg, K. and Mooz, H. “System Engineering.
Breaking the Knowledge Bottleneck for Bayesian Networks Using Language (UML) Artifacts Kathryn Blackmond Laskey Dept. of Systems Engineering George Mason University Fairfax, VA 22032-4444 [email protected]

Philip S. Barry The MITRE Corporation 1820 Dolley Madison Blvd. McLean, VA 22102-3481 [email protected]

Abstract Effective requirements management has been recognized as a key element in the creation of systems. This exercise involves a significant amount of uncertainty, as the requirements analyst is often unsure if the system requirements specified actually provide the functionality the user wants. Previous work demonstrated how system functionality within a given domain could be modeled as a library of Bayesian network fragments. These fragments can be combined into larger networks to model dependencies between the system requirements. By introducing evidence and examining the posterior probabilities, an assessment can be made as which of the system requirements in the network is needed and to what degree. While promising, this approach required the manual generation of the numerous Bayesian network fragments necessitating a significant and often prohibitive investment of time. This paper specifically addresses this problem by proposing a method for the automated generation of Bayesian network fragments from Use-Case models and collaboration diagrams, both of which are created as a natural part of the software development process within the Unified Modeling Language.

1. Introduction In software engineering it is commonly accepted that effective requirements engineering is a key element in the design and development of systems as well as a measure of organizational maturity [4, 5, 8, 9 16]. Requirements engineering describes what is to be built and is the necessary precursor to design and implementation. Effective translation of user requirements into system requirements can mean the difference between success and failure in system development. To accurately come up with an eventual system design, functional as well as nonfunctional requirements must be translated into system requirements. While user requirements describe the functionality of the system

Peggy S. Brouse Dept. of Systems Engineering George Mason University Fairfax, VA 22032-4444 [email protected]

from a black box perspective, system requirements begin to state how that functionality may be accomplished. Previous work by the authors [2, 3] showed how the translation of user requirements to system requirements has an explicit element of uncertainty, as the requirements analyst may have doubt as to whether a given user requirement actually implies a system requirement. This uncertainty can be explicitly represented using Bayesian Network fragments to both quantitatively model the interaction between the requirements as well as the relative importance to the users. Especially important in requirements engineering is the ability to identify and adjudicate conflicts among requirements. This is facilitated by the use of Bayesian Networks. Evidence accumulation generates an error condition when the pattern of evidence is logically impossible according to the model. When inconsistencies are discovered, this means the associated requirements are incompatible given the constraints represented in the Bayesian network. If this condition occurs, the software engineer can explore ways to adjudicate the conflict by the use of soft evidence. Soft evidence allows the engineer to declare varying degrees of strength that a given user requirement is implied. Requirements deemed essential can be declared as hard evidence; requirements deemed less than essential can be declared as soft evidence with strengths related to their perceived importance. If outright conflicts are discovered, the offending declarations can be relaxed to soft evidence. Varying the strengths of the soft evidence declarations can be used be an important sensitivity analysis tool in the design process. Conflict metrics [12, 14] can be used to identify conflicts that fall short of outright inconsistencies and to find clusters of requirements responsible for the conflict. Our initial efforts focused on manually creating Bayesian Network fragments from atomic shall statements (e.g., “The system shall be capable of downloading files at a rate of 10 megabytes per second.”). This recognized that fact that often requirement elicitation activities produce long lists of unconnected statements of need. However, the sheer number of initially unconnected requirements

caused the creation of Bayesian Network fragments to be time consuming and require significant domain expertise. This practical consideration has posed a significant challenge to employment of Bayesian Networks in requirements engineering. An approach to resolving this knowledge engineering bottleneck can be found in artifacts created during objectoriented analysis and design. The Unified Modeling Language (UML) [6] and the overarching Unified Software Development Process [11] have become the de facto standard within the object-oriented software development community. As such, these paradigms are being widely used by software developers for both documenting user requirements as well as system requirements. By exploiting the inherent relationships created by software documentation activities within UML, we see a tremendous opportunity to create Bayesian Network fragments from UML artifacts without significant additional user intervention. This allows us to abstract the initial creation of the fragments from the software user and subsequently embed their usage within the existing process to quantitatively model system requirement interactions and their overall importance to the proposed system.

2

USE CASES AND ANALYSIS MODELS

This research focuses on two artifacts within UML, the use-case model and the analysis model. These models are used to both specify external functionality as well generic system functionality. This section provides background information useful in understanding how these models can be exploited to automatically generate Bayesian Network fragments which can prioritize functionality as well as relate functional requirements. 2.1 USE CASES: THE REQUIREMENTS SIDE OF UML According to Ivar Jacobson [11] “it is absurd to believe that the human mind can come up with a consistent and relevant list of thousands of requirements of the form “The system shall…”. The futility of direct specification has led to a search for more human-friendly ways to develop system requirements. A highly promising and popular approach is to develop requirements from a set of Use-Cases. Use-Cases represent functionality of the system in terms of prototypical problems or processes the system is expected to execute. Thus, a Use-Case represents one distinct way of using the system from a given external agent or actor’s view. Use-Cases are generally specified using a graphically based methodology for defining the actions the system is to perform. Analyzing the functionality needed for successful execution of the Use-Case then derives system requirements.

A Use-Case specifies a primary sequence of actions the system is to perform, and may also include excursions from the main sequence. Use-Cases have operations and attributes. Thus, a Use-Case description can include state chart diagrams, collaborations and sequence diagrams. Use-Case attributes represent the values that a Use-Case instance uses and manipulates. Use-Case instances do not interact with other Use-Case instances because by design Use-Case models should be simple and intuitive. The flow of events and special requirements are captured in special textual descriptions. 2.1.1 Structuring the Use-Case Model System designers can specify relationships between UseCases. These relationships can be used to form interesting structures that can provide evidence to the importance of requirements based upon their relationships to other requirements. Specifically, Use-Cases can be related by generalization, extension and inclusion. §

Generalization is a kind of inheritance in that UseCases can perform all behavior described in the generalizing Use-Case. If a generalized Use-Case is specialized a significant number of times there is evidence that the functionality described is important.

§

Extension models additions to a Use-Case’s sequence of actions. These additions are contingent upon some conditions being satisfied. Extend relationships are use to model exceptional behavior for the Use-Case.

§

Inclusion models the situation where one Use-Case comprises vital behavior for a high-level Use-Case. The higher level or including Use-Case cannot function without the included Use-Case.

2.2 ANALYSIS MODELS: SPECIFYING SYSTEM REQUIREMENTS Within the Unified Software Development Methodology, analysis is used to address previously unresolved issues by analyzing the requirements in depth. Key to analysis is the development of the analysis model, which yields a more precise specification of the requirements than resulted from the Use-Case model. As the analysis model is described in the language of the developers it can introduce more formalism and can be used to reason about the internal workings of the system. The analysis model can be considered a first cut at a design model and is an essential input to system design and implementation. The analysis model makes use of a number of diagrams. Of particular interest is the collaboration diagram, which describes how a specific Use-Case is realized and performed. The diagram is drawn in terms of stereotypical analysis classes and their instantiated analysis objects. These objects focus on handling functional requirements and postpone the consideration of

nonfunctional requirements by designating them as special requirements. There are three stereotypical classes used in collaboration diagrams during the analysis phase: boundary classes, entity classes and control classes. Stereotypical classes represent generic functionality, described at a system level but in a much coarser fashion than design classes. The stereotypical classes are instantiated as objects that can perform broad categories of functionality. Boundary Classes are used to model interaction between the system and its actors, e.g., information input and output. . Boundary classes model parts of the system that interface directly with actors and therefore can be used to clarify system boundaries. The boundary classes should be kept at a reasonably high level. For example, boundary classes are often used to represent printer interfaces, terminals, APIs, etc. Each boundary class should be related to one actor and vice versa. Entity Classes are used to model information that is longlived and persistent. Instantiated entity classes often represent objects handled by the system and may have associated behaviors and a logical data structure. Entity objects can have attributes, but the attributes are conceptual and may not map directly to physical attributes specified in the design phase. Control Classes are used to model coordination, sequencing, transactions and control of other objects. Control classes specifically model the dynamics of the system. Behaviors that are related to interactions with the actors and other objects are represented with control classes. Behaviors that modify changes to control, coordination, sequencing, transactions and business logic are generally not represented as control classes and delayed until the design phase.

3

MAPPING USE-CASE MODELS TO BAYESIAN NETWORKS

Three operations, generalization, inclusion and extension can relate Use-Cases. This section examines how these relationships can be used to create Bayesian network fragments. 3.1

GENERALIZATION

A generalized Use-Case contains common functionality that is allocated to all specializing Use-Cases. Mapping the generalization relationship to Bayesian network fragments is straightforward. Consider the situation where Use-Case A is a generalization of Use-Case A1 and Use-Case A2. We view this as functional requirements A1 and A2 being specializations of functional requirement A. This translates into a Bayesian network with an analogous structure. The direction of implication flows from A to A1

and A2 reflecting a top-down decomposition. This indicates that one is more likely to encounter the general case than the specific requirement. Thus: P(A) = prior P(A1 | A) = P(A |A1)P(A1) / P(A) P(A2 | A) = P(A |A21)P(A2) / P(A)

3.2 INCLUSION Inclusion models the situation in which a Use-Case is composed of a number of sub-Use-Cases. In the case of inclusion, the top-level Use-Case cannot execute without the execution of one of the sub-Use-Cases. To see how this can be translated to Bayesian Network fragments, consider the situation where Use-Case A is related to UseCase A1 and Use-Case A2 by an inclusion relationship. It is more likely that the need for Use-Case A would be elicited in a requirements generation activity, so we draw the implication arrow from Use-Case A to Use-Case A1 and Use-Case A2. Thus, the probability assignments for the nodes are as before: P(A) = prior P(A1 | A) = P(A |A1)P(A1) / P(A) P(A2 | A) = P(A |A21)P(A2) / P(A)

3.3 EXTENSION Extension models the case where a given Use-Case will branch into additional behavior given the satisfaction of some condition or conditions. In the case of extension, the first Use-Case does not need the additional Use-Case to execute. The second Use-Case represents exceptional behavior if conditions are met. Consider the general case where Use-Case A is extended by Use-Case A1. In this case some additional criterion Stereotypical Analysis Model Classes Entity Class Boundary Class Control Class

Represent as a requirement (node in the BN) for persistent storage Represent as a requirement for interface to a specific actor Represent as a requirement for high level functionality - usually represents internal business logic this can be broken down into lower level control classes

Figure 5.1: Stereotypical Analysis Classes

triggers Use-Case A1 after Use-Case A executes. The additional criterion is described in the textual flow of events write-up and modeled as Requirement A1 implied by Requirement A. The additional criterion is modeled as

another requirement node. The direction of implication is from the additional criteria (AC) to requirement A1. Thus: P(A1 | A, AC) = P(A|A1, AC)P(A1|AC) P(A|AC)

4 EXPLOITING ARTIFACTS

THE

ANALYSIS

The analysis process is a refinement and a specification of the Use-Cases into a more formal language. For each Use-Case, an individual analysis model can be created which specifies in generic terms the system functionality. Analysis models are formed from the instantiation of the stereotypical classes as indicated in Figure 5.1. 4.1 ANALYSIS CLASSES AND OBJECTS Analysis classes represent particular system functionality, broadly categorized into one of three stereotypical classes. These classes can be instantiated as objects and specialized with more specific functionality. These objects can be described as follows. §

§

§

Boundary objects can be mapped directly to a requirement for a user interface, and thus a node in the Bayesian Network. Each boundary object is associated with an actor. Thus the requirement for the interface can be specified for the given actor. The relationship between the boundary object and the other object is instantiated in the collaboration diagram and shown as messages passed between the classes. The entity object represents a persistent information store, such as a database. The entity object is represented as a requirement to store a particular type of information, often with the capability to read and write information to and from the store. Control objects are used to describe internal logic for the system. Control objects typically act upon some input from either the actors or the entity objects and initiate some additional action. Control objects often can be decomposed into lower objects to indicate lower level functionality.

4.2 COLLABORATION DIAGRAM MAPPINGS A collaboration diagram is the functional specification of an individual Use-Case using instantiated objects from the stereotypical classes. The collaboration diagram relates the objects by links that represent messages sent between the objects. The links are numbered, representing a rough ordering. The messages model requests for services from the sending object to the receiving object. These messages provide a finer view of the functionality offered by a given object. Collaboration diagrams are readily mapped into network fragments. Let a collaboration diagram D consists of

three stereotypical classes B, C and E for Boundary, Control and Entity. Let function I be an instantiator, which can create objects instantiated from these classes. For example, I(B, d) = B would indicate that a boundary object has been created in a way that depends on additional data d. Let O consist of all of the objects in the collaboration diagram that have been instantiated. Thus, O = {I(B, d ), I(E, d ), I(C, d) } where d = {d1, d 2, d3…dn} and ∃O ∉ O. With these assumptions, several mapping rules can be readily written. Rule 1: If I(B, di) = B, we write a requirement for actor interface of type B which interacts with the actor for data of type di. This is represented as a like named node in network fragment N. Rule 1.1: If Actor A sends a message of type mi to B, we write a requirement for functionality mi from object B. This is represented as a like named node M in the Bayesian Network with an arc drawn from B to M. We assume that the importance of the node M is directly related to the likelihood that it will be called. Rule 1.2: We model the Actor A as evidence for requirement M. Rule 2: If I(E, di) = E, we write a requirement for persistent storage of type E containing information di. This is represented as a like named node in N. Rule 2.1: If a message mi is sent to an entity object E from another object O, we write a requirement for functionality M from object E. This is represented as a like named node M in the Bayesian Network with an arc drawn from E to M. We further draw an arc from the like named node in the Bayesian Network that represents O to M. Rule 3: If I(C, di) = C, we write a requirement for functionality of type C acting on information di. This is represented as a like named node in N. Rule 3.1: If a message mi is sent to a control object C from another object O, we write a requirement for functionality M from object C. This is represented as a like named node M in the Bayesian Network with an arc drawn from C to M. We further draw an arc from the like named node in the Bayesian Network, which represents O to M. 4.3 GLUING FRAGMENTS TOGETHER The process for combining the various network fragments is referred to as gluing. Fragments are combined by unifying nodes common to the two fragments and assigning as parents to the resulting node the union of the parent nodes in the two input fragments. The conditional probabilities are subsequently reallocated according to a heuristic influence combination method. Laskey and Mahoney took a similar approach by using network fragments to model military situation assessment [15].

There are three two types of gluing situations, common fragments (i.e., both fragments are collaboration diagrams or Use-Cases) and heterogeneous gluing (fragments are of different types). The following rules provide are used for gluing: The Fragments Have Common Nodes – If the fragment or fragments share common nodes with other fragments or a target network, the fragments are overlayed on the common nodes and the arcs are redrawn. The conditional probabilities are subsequently reallocated. The Fragments Have A Common Actor – If two network fragments share a common actor, a proxy node representing the actor is created in the glued fragment if it does not already exist. In the use-case model, there is an association arc between each use-case and one or more actors. Using this as a guide, arcs are drawn in the glued Bayesian Network fragment from the proxy node to the nodes representing the use-cases. The conditional probabilities are subsequently reallocated. If the fragment represents a collaboration diagram, an arc is drawn from the proxy node to the boundary object. If a prior probability has not been assigned to the proxy node, a prior probability is assigned that reflects the likelihood that that actor will be using the system. The Fragments Have No Common Nodes or Common Actors – For the Use-Case model, if two fragments have no common nodes or actors the criteria for gluing is not met. Fragments sharing no common nodes and having no common actors cannot be directly connected. Gluing collaboration diagrams is somewhat different in that all collaboration diagrams share a common boundary object instantiated from the boundary class. Therefore, in theory all collaboration diagrams could be glued using the boundary object as the common node. However, approaching the gluing in this fashion merely models the fact that all functionality is common within the system boundary. With this in mind, it is suggested that gluing be contingent upon common entity or control classes, or that gluing be contingent upon common actors. With this dependency, we can be sure that the relationship between modeled requirements is dependent upon shared functionality or user need. 4.3.1

Explicitly Modeling the Relationship Between User Requirements and System Requirements

In our earlier work we created models of user requirements distinct from the models of the system requirements. We chose this approach because user requirements were assumed to be generated as natural language atomic statements of need. System Requirements Webs were created from a domain analysis based on existing systems and expert interviews. Individual fragments could be tailored to effectively model specific niche functionality, such as server

requirements, etc. By gluing individual fragments together, a larger network could be created which related cross-domain system requirements. A population of agents interpreted the atomic user requirements and introduced evidence into the glued Bayesian Network, interpreting the likelihood that individual system requirements were indicated. Within the Unified Development Process, the relationships between the user requirements (represented as Use-Cases) and the system requirements (represented as collaboration diagrams) is specified. Each use-case has a collaboration diagram that is created from stereotypical classes. Thus, the relationship between user requirements and system requirements is determined at a high level. However, what is not specified is how likely it is that each of the system requirements will actually be needed based on the importance of the use-case and the actors. Further, since the elements of collaboration diagrams (i.e., the stereotypical classes) can be related to more than one usecase, it is quite likely that the importance of a given requirement for system functionality, while only moderately implied by individual use-cases, may be very important when all use cases are considered. With this in mind, we can now state the guidelines for gluing fragments created from collaboration diagrams into a network of use-cases and other collaboration diagrams. First, the node representing the use-case from which the collaboration diagram is removed from the network. The fragment derived from the collaboration diagram is glued as follows:

5

A MAPPING EXAMPLE

As an illustration, consider the following example. Suppose a requirement elicitation activity has determined that there is a need to develop an application that allows an individual to purchase products over the Internet. A number of functional requirements have been defined, such as log on to the site, browse products, select products, etc. Table 5.1 shows the list of requirements necessary for this system. • • • • • • •

Provide Index Help • Remove Selected Products Log on • Provide On-line Help Browse Products • Provide FAQs Browse with Search Criteria • Purchase Products Select Products • Purchase using Credit Card Display Selected Products • Purchase Products Add Selected Products Table 5.1: On-Line Product Purchase Functionality List

The decision is made to refine the textual descriptions of functional requirements by creating a top-level UseCase model, provided as Figure 5.1. In the figure, two actors are identified, namely the buyer of the product and the company computer, named pbdog.com. The figure shows the association between the Use-Cases

Browse Products Log on

Browse w/ Search Criteria



Select Products

Display Selected Products

Buyer

Remove Selected Products

pbdog.com

Add Selected Products ProvideFAQs

Provide Index Help Provide On-Line Help Purchase Products

Figure 5.3: Bayesian Network from Use-Case Model

Purchase Using Credit Card

Figure 5.1: Top-Level Use-Case Model

and the actors, as well as the relationships of generalization and inclusion. In particular, well as the relationships of generalization and inclusion. In particular, the requirement of Browse w/ Search Criteria has been identified as a generalization of Browse Products, Provide On-Line Help generalizes Provide FAQs and Provide Index Help and Purchase Product is a generalization of Purchase Using Credit Card. The inclusion relationship is illustrated by the functionality of Select Products requiring Display Selected Products, Add Selected Products and Remove Selected Products. Figure 5.2 represents a collaboration diagram developed with stereotypical analysis classes. Notice the addition of messages from the actor, as well as between the stereotypical classes. These will form the basis for the functionality specified in the Bayesian network. While a loose temporal ordering is suggested by the numbering of the messages, sequencing requirements are not explicitly modeled with this diagrammatic technique but rather are shown by interaction diagrams that are not examined here. Once the Use-Case models and the collaboration diagrams

have been created, it is straightforward to create the structure of the Bayesian Network using the rules described in Sections 3 and 4 above. Figure 5.3 represents the Bayesian Network constructed from the Use-Case model shown in Figure 5.1. Notice how the conditional independence has been directly modeled by application of the rules as stated. For example, Add_Selected_Products is conditionally independent of Remove_Selected Product given the requirement for Select_Product. This is reasonable from a requirements standpoint, for if it is known that functionality Select_Product is definitely not needed, any evidence for Add_Select_Products provided by Remove_Selected_Product can be reasonably discounted. Similarly, if Select_Product is definitely indicated, it is reasonable to state that the evidence for Add_Select_Products is compelling and we can reasonably disregard information from Remove_Selected_Product. Figure 5.4 represents a Bayesian network fragment developed to represent the collaboration diagram shown in Figure 5.3. For each Use-Case represented in Figure 5.1, a collaboration diagram was developed. The collaboration diagrams are built using generic functionality from stereotypical classes. The stereotypical classes are instantiated with specific functionality contingent upon the

3. Get :Order Total

4. Get

:Credit Card Validation

5. New 2. Send credit card info 1. Input order information

:Request Handler

8. Get

7. Request Purchase 6. Purchase : Buyer Request

:Purchase UI

:Financial Data Document 10. New

9. Get :Order Handler

: Dog Food Order

:Order Details

Figure 5.2: Collaboration Diagram for Purchase Using Credit Card

Figure 5.4: Bayesian Network Fragment from Collaboration Diagram for Purchase_w/_Credit_Card

messages sent to them by other stereotypical classes and actors.

outputs text files in XML Bayesian Interchange Format (BIF) which represent Bayesian Network fragments.

Figure 5.5 illustrates the results of gluing the fragment from the use-case model and the collaboration diagram. The first step was identifying common nodes and actors between the two fragments. In the example shown, the only common node was that representing the actor buyer. Consistent with the rules discussed earlier, an arc was drawn from the Buyer node to the Purchase_UI node, which is the node representing the boundary class.

Java Bayes [7] is used to visually inspect and debug the network fragments. Once all of the fragments have been developed, the BOSH prototype is used to glue the network fragments together as well as interpret the effect of nonfunctional requirements and other evidence on the glued network. BOSH, introduced in [1], is a prototype agent-based expert system that infers system requirements given evidence from a user requirements specification. BOSH uses APIs from both Java Bayes and JESS.

In Figure 5.5, the node which represented the use-case Purchase_w_Credit_Card has been replaced by the entire fragment created from the collaboration diagram, thus the node that represented that particular use-case has been deleted from the network. In the use-case model, an arc appears from Purchase_Product to Purchase_w_Credit_Card, which we can interpret as a causal relationship. This arc is redrawn from Purchase_Product to the Purchase_UI node.

Figure 5.5: Bayesian Network Consisting of Glued Fragments from Use-Case Model and Collaboration Diagram

6

Current Work

We are completing the mechanics of a seamless prototype that will take files that represent the Use-Case model and collaboration diagrams and create a Bayesian Network composed of its associated fragments. The inherent structure of the Use-Case model provides a basis for network creation that is easily automated in a rule based system. Additional rules can be specified which allow the collaboration diagrams to be translated and integrated into the network created from the Use-Case model. Rational Rose [18] is used to develop the Use-Case models and collaboration diagrams in UML. The export format of Rational Rose is human readable text. A parser has been written which extracts the relevant information and sends it to an expert system that applies rules discussed in Sections 4 and 5. The expert system, written using JESS [10],

7

CONCLUSIONS DIRECTIONS

AND

FUTURE

This paper showed how to resolve the knowledge bottleneck by exploiting work that is usually accomplished as part of the Unified Software Development Process. The Use-Case Model and collaboration diagrams are created for other reasons, and can be used to create Bayesian Networks which relate use cases to one another, to generic descriptions of system functionality, as well as to relate instances of system functionality to one another. The Bayesian Network provides a computational model to decide how likely it is that the specific system requirements actually describe what the user wants. Differing views of system functionality are provided contingent user profiles and other information. A prototype has been developed to demonstrate the feasibility of the mapping from UML artifacts to Bayesian Networks. A Bayesian network can be used to explicitly model the uncertainty between the requirements as represented by Use-Cases and elements of collaboration diagrams. Contingent upon the introduction of evidence such as the importance of a given actor, a quantitative assessment can be made as to how strongly we believe the requirement is indicated or implied. We see the ability to translate UseCase models and their associated collaboration diagrams into Bayesian networks as an important potential advance in software engineering. Specifically, this approach provides a way of understanding the degree to which each of the specified requirements is implied by the information encoded in the user requirements. This ability to represent degrees of implication is key to the identification and effective management of conflicts among requirements. Replacing one node in a Bayesian Network with a more detailed fragment consisting of a number of other nodes is reminiscent of hierarchical decomposition of system requirements [4]. However, we are plowing new ground from a modeling standpoint as we creating a computational structure that directly relates system requirements to each other as well as their source user requirements. With this structure, we can directly test the applicability of the system requirements to the problem at

hand. This work is also consistent with research in object oriented Bayesian networks [13, 17]. Now that the initial ground has been broken, other issues remain in the effort to use Bayesian Networks to more fully understand the requirement space. Of primary importance is that fact that the work described here has focused on analyzing functional requirements. To fully understand the requirements of a system, one must examine the temporal aspects as well as the nonfunctional requirements of the system. UML has artifacts that examine these other types of requirements, namely in the form of sequence diagrams, statecharts and textual narrative for use-cases. It will be an interesting research challenge to try to cleanly and automatically map these additional types of requirements types into Bayesian Network fragments. References [1] Barry, P., An Agile Approach to Requirements Modeling, Ph.D. Dissertation, George Mason University, Fairfax, Virginia, May 1999. [2] Barry, P. and Laskey, K. “An Application of Uncertain Reasoning to Requirements Engineering”. "Proceedings of the Fifteenth Conference on Uncertainty in Artificial Intelligence," Kathryn Blackmond Laskey and Henri Prade (editors), Morgan Kaufmann Publishers, Inc., San Francisco, 1999. [3] Barry, P., Laskey, K. and Brouse, P. “Modeling the Requirements for Enterprise Control Systems”, Proceedings of the DARPA-JFACC Symposium on Advances in Enterprise Control, November 1999. [4] Blanchard, B. and Fabrycky, W., Systems Engineering and Analysis, Third Edition. Prentice Hall, Upper Saddle River, NJ, 1998. [5] Boehm, B.W., “A Spiral Model of Software Development and Enhancement, “ Computer, Vol. 21, No. 4, May 1988. [6] Booch, G., Rumbaugh, J. and Jacobson, I. The Unified Modeling Language User Guide. AddisonWesley Publishing Company, Reading, MA, 1999. [7] Cozman, Fabio. JavaBayes source code and documentation available http://www.cs.cmu.edu/~javaBayes/index.html/. [8] Dorfman, M. “Requirements Engineering”, in Software Requirements Engineering, 2nd Edition, Thayer, R. and Dorfman, M. editors, IEEE Press, Los Alamitos, CA, 1997.

[9] Forsberg, K. and Mooz, H. “System Engineering Overview”, ”, in Software Requirements Engineering, 2nd Edition, Thayer, R. and Dorfman, M. editors, IEEE Press, Los Alamitos, CA, 1997. [10] Friedman-Hill, Ernest. JESS source code and documentation available at http://herzberg.ca.sandia.gov/. [11] Jacobson, I., Booch, G. and Rumbaugh, J. The Unified Software Development Process. Addison-Wesley Publishing Company, Reading, MA, 1999. [12] Jensen, F.V., Chamberlain, B., Nordahl, T. and Jensen, F. “Analysis in HUGIN of Data Conflict” . "Proceedings of the Sixth Conference on Uncertainty in Artificial Intelligence", P. P. Bonissone, M. Henrion, L. N. Kanal and J. F. Lemmer (editors), Elsevier Science Publishing Company Inc., New York, NY 1991. [13] Koller, D. and Pfeffer, A. “Object-Oriented Bayesian Networks”. "Proceedings of the Thirteenth Conference on Uncertainty in Artificial Intelligence," Dan Geiger and Prakash Shenoy (editors), Morgan Kaufmann Publishers, Inc., San Francisco, 1997. [14] Laskey, K. “Conflict and Surprise: Heuristics for Model Revision "Proceedings of the Seventh Conference on Uncertainty in Artificial Intelligence". Bruce D. D'Ambrosio and Philippe Smets Piero P. Bonissone (editors), Morgan Kaufmann Publishers, Inc., San Mateo,California 1991. [15] Laskey, K. and Mahoney, S., “Network Fragments: Representing Knowledge for Constructing Probabilistic Models”. "Proceedings of the Thirteenth Conference on Uncertainty in Artificial Intelligence," Dan Geiger and Prakash Shenoy (editors), Morgan Kaufmann Publishers, Inc., San Francisco, 1997 [16] Paulk, M., et.al., The Capability Maturity Model Guidelines for Improving the Software Process. AddisonWesley Publishing Company, Reading, MA, 1995. [17] Pfeffer, A., Koller, D., Milch, B. and Takusagawa, K. “SPOOK: A System for Probabilistic Object-Oriented Knowledge Representation”. "Proceedings of the Fifteenth Conference on Uncertainty in Artificial Intelligence," Kathryn Blackmond Laskey and Henri Prade (editors), Morgan Kaufmann Publishers, Inc., San Francisco, 1999. [18] Rational Rose. Technical Papers and sample executable code available at http://www.rational.com/.