ࡱ; R F 3CompObj\WordDocument VObjectPoolF_3F_3 v  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuwxyz{|}~ SummaryInformation( @Microsoft Word 6.0.14ࡱ; v FMicrosoft Word 6.0 DocumentNB6WWord.Document.6;  Oh+'0   ) 5AI Q]z H-J!=_')BP*' M-HCAAQ5WJ2>6O),=Q/9M<313PEMMacintosh HD:Applications:Microsoft Office:Microsoft Word 6:Templates:Normal"Informations System Collaboratory'@v@v@*3U SgUa cSgUa c Sga cga c ga c bjkM]^bbbbbbbbbbbbbbjk M ] ^ eeeeeeeeeeenMTimes New RomanTimes Symbol"MArialHelvetica MTimesMNew YorkMHelvetica"!+5!Informations System Collaboratoryࡱ; ܥhO ,eeVb'$dddd| d[nkkkkkkkk޳&ɵX!5Ukkkkkkkkkkkkk޳28Tk޳ksk An Exception Handling Approach to Enhancing Consistency, Completeness and Correctness in Collaborative Requirements Capture Mark Klein Research Associate Applied Research Lab PO Box 30 Pennsylvania State University State College PA 16804-0030 klein@quark.arl.psu.edu (814) 863-5381 (tel) (814) 865-7097 (fax) http://quark.arl.psu.edu/klein-vita.html Abstract Current requirements capture approaches often involve high costs and long flow times due to the largely manual, serial and highly iterative requirements capture and review cycle. This paper describes C-ReCS (the Collaborative requirements Capture System), an implemented WWW-based system that addresses these problem by: supporting virtual multi-functional requirements definition teams. Multiple usort for anticipating/detecting exceptions as well as helping stakeholders to resolve them effectively. 2. Contributions and Limitations of Existing Work While computer systems to support requirements capture do exist (e.g. The Requirements Manager from Cimflex Teknowledge (Fiksel-91) and RDD-100 from Ascent Logic Inc.), they are designed for single users. One of the key lessons of empirical studies of requirements capture, however, is that the inputs of multiple stakeholders need to be integrated to produce a satisfactory requirements document (Macaulay-93). Existing work on collaborative requirements capture has focused largely on defining normative requirements capture processes (Macaulay-90) or on social rather than substantive elements of the interaction between team members (e.g. Viller-91; Macaulay-94). C-ReCS focuses by contrast on identifying miscoordination-caused problems with the content of the requirements themselves and then intervening to resolve these problems. There has been a relatively large body of work on dealing with the subclass of exceptions known as design conflicts (see, for example, the September 1994 CERA Journal Special Issue on Conflict Management in Concurrent Engineering, Volume II, Number 3) as well as some preliminary work on requirements capture (e.g. Sinha-95; Easterbrook-94; Heitmeyer-95). C-ReCS, however, the first system to provide a comprehensive approach to detecting and resolving the full range of collaborative requirements capture exceptions. 3. The C-ReCS System C-ReCS (the Collaborative Requirements Capture System) is a computer tool for supporting collaborative capture of design decisions, in particular from the early (i.e. requirements definition) phases of the product life cycle. Its functional architecture consists of a centralized shared requirements database accessed by standard World Wide Web browsers plus exception management services. C-Recs thus supports "virtual" multi-functional requirements definition teams. Anyone who needs to add to or critique a set of requirements can do so using a Web browser at a time and place convenient for them, concurrently with other users. Requirements and their rationale are captured using a formal language that integrates previous work on requirements (Kott-95; Nirenburg-94) and rationale (Klein-93a; Klein-92) representations. The C-ReCS language, in brief, captures requirements and their rationale as a semantic net consisting of pre-defined entity (e.g. module, interface, resource, attribute) and relation (e.g. is-supported-by, has-submodule, has-value) types. The C-ReCS language is too large to cover adequately here and will be described in detail in a companion paper. This paper will focus on the C-ReCS exception management services, which consist of three major functional components: - A suite of exception detecting tools that attempt to anticipate/detect symptoms of underlying consistency, completeness and correctness problems in the requirements database. - A diagnosis procedure that attempts to identify one or more candidate diagnosis (i.e. underlying causes) for detected exceptions by examining a knowledge base of generic requirements problem diagnoses. - A resolution procedure that attempts to identify one or more potential resolutions for the diagnosed problems by examining a knowledge base of generic exception resolution strategies associated with the diagnoses knowledge base. C-ReCS is currently implemented in Common Lisp using the cl-http server developed at MIT (Mallery-94), and builds upon previous systems developed by the author for design conflict management (Klein-91; Klein-93b), rationale capture (Klein-93a) and workflow management (Faragher-Horwell-92). The following sections will describe the exception detection, diagnosis and resolution components of C-ReCS in turn, followed by an example of C-ReCS in operation. 3.1. Exception Detection Exceptions can manifest themselves in many ways, and can be usefully organized into a taxonomy of exception types. C-ReCS currentl;y recognizes 30 exception types including different kinds of inconsistency (e.g. constraint violations, variations in terminology usage), incorrectness (e.g. unachievable requirements or circular justifications) and incompletness (e.g. requirements without rationale, dangling attributes). Each type of exception manifestation has associated methods for detecting it. While details differ, all the methods are instantiations of three basic mechanisms - graph matching, constraint checking and case-based comparison - described in the sections below. Graph Matching: This approach detects exceptions by looking for characteristic patterns in the semantic net representing the current set of requirements. It is well-suited for detecting incompleteness exceptions and as a building block for detecting other kinds of exceptions. This approach works by specifying a pattern to search for and then potentially applying some additional predicates to the retrieved patterns to determine if they represent exceptions. Patterns can be specified using a simple language built up of the following primitive elements:  Each such element matches a relationship of a given type between two entities of the given types. If the relation-type is preceded by a "NOT", then the pattern searches for an entity of type source-entity-type on which no relations of the given type exist. If the relation-type is followed by a *, then the pattern is matched if one or more links of the given type exist between the source and target . Entities and relations can be preceded by variables (with the format ?) that are bound to the matching entities and relations. These bindings can be passed to predicates to do further checking. More complex patterns can be built up by concatenations of these basic elements. Constraint Consistency Checking: This approach detects exceptions by looking for unsatisfiable (i.e. inconsistent) sets of decisions concerning a given design parameter. It is well-suited to detecting violations of both absolute constraints (e.g. datatype and range constraints on a given parameter) as well as dependencies across different design parameters. In the former case, the constraints on the parameter are combined with each other to produce their simplest expression, which is then examined to see if it is satisfiable. For example, if we have the constraints (from 1 to 100) and (from 200 to 300) on a design parameter, they can be combined straightforwardly to infer that they can't both be satisfied. Violations of dependencies across multiple design parameters are uncovered using a constraint propagation approach. A commitment for a given design parameter is "propagated" through a relational constraint representing that dependency to produce an inferred constraint on a related design parameter. If one parameter is required to be twice the value of another, for example, then the constraint (> 4) on the first parameter becomes (> 8) when propagated to the second parameter. Once all the constraints on a given design parameter have been determined by this propagation step, we can use the constraint consistency checking methods described above to determine if a conflict exception has occurred. Case-Based Comparisons: This approach detects exceptions by comparing the current requirements set with similar cases and/or with generic requirements templates appropriate for the system of interest (Sinha-95). It is useful for finding "incorrectness" type exceptions wherein one checks, for example, if a requirement (e.g. maximum speed for a land vehicle) has a value radically different than that in similar cases or applicable templates. Two key components of this approach are a library of cases and/or templates, as well as a retrieval mechanism that is effective at finding applicable cases. The case retrieval mechanism must incorporate a "similarity" metric that accounts for attribute value differences, relative importance of different attributes in calculating the similarity value, and perhaps even the structural similarity of the graph structures in the two cases. C-ReCS currently only implements a simple template retrieval mechanism wherein generic templates are indexed by the modules they define requirements for. It is often not appropriate to do all kinds of exception detection at all times. Checking for completeness of the requirements set in the early phases of requirements definition could, for example, overwhelm the user with a long list of incompletely specified requirements. It would probably be more appropriate to do this kind of checking much later on. Inconsistency and incorrectness detection, however, may be appropriate throughout the requirements capture process. C-ReCS accordingly allows the user to select what kinds of exception manifestations to look for. 3.2. Exception Diagnosis C-ReCS uses a heuristic classification approach for diagnosing exceptions (Clancey-84; Gomez-81). Potential diagnoses are arranged into a taxonomy ranging from the very abstract at the top to the very specific at the bottom. The diagnosis mechanism works in a top-down way by iteratively increasing the specificity of a diagnosis based on the symptoms, underlying decision rationale and other factors as well. This is essentially a "shallow model" approach (Chandrasekaran-83) because it is based on compiled empirical and heuristic expertise rather than first principles. This approach is appropriate for domains, such as medical diagnosis (and requirements definition as well), where complete and consistent first-principle-based behavioral models do not exist (in contrast, for example, to computer hardware fault diagnosis where such models do exist and fault causes can be inferred deductively; see for example Genesereth-82 and Kleer-90). An important characteristic of heuristic classification is that the diagnoses represent hypotheses rather than guaranteed deductions: multiple diagnoses may be suggested by the same symptoms, and often the only way to verify a diagnosis is to see if the associated prescriptions are effective. The diagnosis hierarchy is structured as follows:  Diagnosis works by a decision-tree-like traversal of this structure wherein the system starts at the top most abstract diagnosis and attempts to refine it to more specific diagnoses. Diagnoses have preconditions attached to them that represent the characteristics that distinguish that class from its direct superclass. The complete defining characteristics for a diagnosis will thus be the conditions for that class plus for all of its superclasses. The diagnosis taxonomy also allows one to define "question" nodes, that make some query, followed by "answer" arcs, one or more of which are traversed based on the result of the query. Question nodes and answer arcs are optional but they have proved useful as a way of making the structure of the diagnosis taxonomy more understandable. Multiple alternative paths may lead to the same diagnosis or question, so the default semantics for multiple parents is disjunctive. One can specify conjunctive semantics using a "join" node. Traversal proceeds recursively and can result in more than one candidate diagnosis, since multiple causes may be suggested by the same symptoms. 3.3. Exception Resolution Once one or more candidate diagnoses for an exception have been identified, the next step is for C-ReCS to generate, using its knowledge base of generic exception resolution strategies, specific suggestions for resolving the diagnoses. A diagnosis class will often have several potential resolution strategies available. Since they may not all be applicable for a particular exception, a decision tree procedure identical to that used to select diagnoses is used to find the generic strategies for a given diagnosis. Strategies are represented as natural language text templates with a number of "slots". These slots are filled with context-specific values, found using the query language, to produce specific suggestions. Imagine for example that C-ReCS has made the diagnosis "Poor plan choice". The associated generic resolution strategy ("Try alternate plan for goal ") can be instantiated into specific suggestion by finding the goals underlying the exception as well as the untried plans for the goal; we then can instantiate the strategy template into specific suggestions like "Try alternate plan use-hybrid-power-system for goal refine-power-system-design". A suggested resolution strategy once instantiated is annotated with rationale capturing the goal the strategy is designed to achieve. 3.4. An Example Imagine we are performing some preliminary requirements definition for a car. So far we have specified the initial component decomposition (e.g that the car consists of a fuel tank and engine) and have defined some requirements for these components. The engine, for example, is required to have a fuel line interface as well as prescribed ranges on its fuel consumption and power. A typical efficiency value as well as a mathematical expression describing the relationship between efficiency, fuel consumption and power has also been added. The C-ReCS user can at any time elect to invoke the exception detection procedure. When invoked, C-ReCS allows users to select the subset of the available exception detection methods they want to use and then presents a summary of the exceptions detected:  In this case C-ReCS finds, based on propagation of the design constraints, that the requirements on engine fuel consumption are inconsistent. It also notes that the "power" attribute has been placed on both the engine component and its sub-component (a potential inconsistency or incorrectness exception), that there is an attribute with no constraints (an incompleteness exception) and that there are two module interfaces that are not connected to anything (also incompleteness exceptions). Exception assertions are all annotated automatically with their rationale. C-ReCS users can of course attempt to resolve exceptions on their own, but this can be a tedious and error-prone process. Exceptions typically represent symptoms of some underlying problem that may not be obvious on first inspection. A single symptom can derive from many possible causes. Conversely, multiple exception symptoms can be caused by a single underlying problem. One will typically be forced to do extensive browsing of a complex requirements database to fully understand the exceptions, and it is of course possible that one will not hit upon the correct diagnoses and effective resolutions for these diagnoses. The C-ReCS exception diagnosis and resolution suggestion procedures address this problem by providing suggesting diagnoses and resolutions for exceptions. In this example, C-ReCS makes the following suggestions:  C-ReCS suggests that the constraint violation conflict is due to over-ambitious design constraints, traces back through the exception rationale to find the two potentially changeable design requirements underlying the conflict, and suggests that one (or both) of them be relaxed. C-ReCS also suggests that the replicated attribute exception is due to the same attribute appearing in two places by mistake, and suggests that the user consolidate them. Finally, the system hypothesizes that the dangling interfaces exceptions are due to the users forgetting to connect two interfaces, verifies that they are of compatible types, and suggests that they should be connected. The five exceptions in this case appear to have stemmed from three underlying problems. C-ReCS automatically records the rationale for any suggested diagnosis (i.e. in terms of the exceptions it covers) and associated strategies (i.e. in terms of the goal of resolving the diagnosed problem). If a user decides to implement a suggested resolution strategy, any resulting changes to the requirements set will be captured as the outcomes of this strategy so it will be clear for later reference why they were made. C-ReCS can not guarantee that any given proposed diagnosis or resolution is appropriate. The constraint conflict above, for example, may only be resolvable by selecting a radically different design configuration with greater potential engine efficiency. It's added-value stems, rather, from using its' exception handling expertise to quickly generate a rich set of ideas for the users to consider when dealing with their particular problems. Even if none of the proposed diagnoses or strategies are accepted as is, they often can serve as a starting point for creating effective responses to these problems. 4. Contributions The C-ReCS system addresses some central issues in requirements capture (Lubars-93) by providing a tool by which multiple stake-holders can become aware of the affects of their requirements decisions and be guided through a resolution process when problems arise, for both initial requirements decisions as well as changes in original requirements. The unique contribution of this work is that it represents not a single exception management algorithm but rather a generic structure for utilizing an extensible knowledge base of exception management strategies applicable to a wide range of domains. As noted earlier, other work has presented either just a small specialized set of exception handling strategies and/or has been limited to a single domain. This exception management procedure is a generalization of previous work by the author (Klein-93b; Klein-91) on managing conflicts in collaborative design, and differs from that work in a number of important ways including the inclusion of a much more expressive requirements and rationale capture language, a broader range of exception detection mechanisms, a rationalized structure for the exception cause taxonomy as well as a knowledge base that was significantly extended to handle requirements domain exceptions, not just collaborative design conflicts. 5. References [Chandrasekaran-83] Chandrasekaran, B. and Mittal, S., Deep Versus Compiled Knowledge Approaches To Diagnostic Problem Solving, Int. J. Man-Machine Studies, 425-436, 1983 [Clancey-84] Clancey, W.J., Classification Problem Solving, AAAI, 49-55, 1984. [Easterbrook-94] Easterbrook, S., Coordinating Distributed Viewpoints: the anatomy of a consistency check, Concurrent Engineering Research and Applications: Special Issue on Conflict Management in Concurrent Engineering, vol. II, no. 3, 209-222, September 1994. [Faragher-Horwell-92] Faragher-Horwell, R., Klein, M., and Zarley, D., Overview and Functional Specifications for TCAPS Task Coordination And Planning System: A Computer-Supported Workflow Management System, Tech. Rep., Boeing Computer Services Technical Report BCS-G2010-130, December 1992. [Fiksel-91] Fiksel, J., The Requirements Manager: A Tool for Coordination of Multiple Engineering Disciplines, in Proceedings of CALS & CE '91, 1991. [Genesereth-82] Genesereth, M.R., Diagnosis Using Hierarchical Design Models, in AAAI-82, 1982, pp. 278. [Gomez-81] Gomez, F. and Chandrasekaran, B., Knowledge Organisation And Distribution For Medical Diagnosis, IEEE Transactions on Systems, Man, and Cybernetics, vol. SMC-11, no. 1, 34-42, January 1981 [Heitmeyer-95] Heitmeyer, O., Labaw, B., and Kiskis, D., Consistency Checking of SCR-Style Requirements Specifications, in Proceedings of the International Symposium on Requirements Engineering, 1995. [Kleer-90] de Kleer, J., Macworth, A.K., and Reiter, R., Characterizing Diagnoses, in AAAI-90, vol. 1AAAI, AAAI, 1990, pp. 324-330. [Klein-91] Klein, M., Supporting Conflict Resolution in Cooperative Design Systems, IEEE Systems Man and Cybernetics, vol. 21, no. 6, , Special Issue on Distributed Artificial Intelligence. [Klein-92] Klein, M., DRCS: An Integrated System for Capture of Designs and Their Rationale, in Proceedings of Second International Conference on Artificial Intelligence in Design, Pittsburgh, Pennsylvania, 1992. [Klein-93a] Klein, M., Capturing Design Rationale in Concurrent Engineering Teams, IEEE Computer, , Special Issue on Computer Support for Concurrent Engineering.. [Klein-93b] Klein, M., Supporting Conflict Management in Cooperative Design Teams, Journal on Group Decision and Negotiation, vol. 2, 259-278, 1993, Special Issue on the 1992 Distributed AI Workshop. [Kott-95] Kott, A. and Peasant, J., Representation and Management of Requirements: The RAPID-WS Project, Concurrent Engineering Research and Applications (CERA), vol. 3, no. 2, 93-106, 1995. [Lubars-93] Lubars, M., Potts, C., and R., C.R., Developing Initial OOA Models, in Proceedings of the International Conference on Software Engineering, IEEE CS Press, 1993. [Macaulay-90] Macaulay, L., F., C.H.F., K., M.K., and H., A.F.H., USTM: A New Approach to Requirements Specification, Interacting with Computers, vol. 2, no. 1, 92-117, 1990. [Macaulay-93] Macaulay, L., Requirements Capture as a Cooperative Activity, in Proceedings of the IEEE International Symposium on Requirements Engineering, IEEE, 1993. [Macaulay-94] Macaulay, L., O'Hare, G., Dongha, P., and Viller, S., Cooperative Requirements Capture: Prototype Evaluation. John Wiley & Sons, June 1994. [Mallery-94] Mallery, J.C., A Common LISP Hypermedia Server, in Proceedings of the First International Conference on the World Wide Web, CERN, May 1994. [Nirenburg-94] Nirenburg, I. and Kott, A., RSL Syntax/Semantics, Tech. Rep., Technical Report, , Five PPG Place, Pittsburg PA 15222, , CDRL A012, August 1994. [Sinha-95] Sinha, A.P. and Popken, D., Completeness and Consistency Checking of System Requirements: An Expert Agent Approach, 1995. [Viller-91] Viller, S., The Group Facilitator: A CSCW Perspective, in Proceedings of the Second European Conference on Computer-Supported Cooperative Work, 1991. Exception Handling Mark Klein  h88|HH(FG(HH(d'` q h88|HH(FG(HH(d'` qi:. S&WordMicrosoft Word&Word   2 @@$Use Word 6.0c or later to 2 @$view Macintosh picture. 0Ud WORD0U  0U,Times .+/source * entity * type (5target * entity * type ([] ([]t    T 4 +relation-type [*] (h4c ( i[NOT]of :!8  S&WordMicrosoft Word&Word D  2 @@$Use Word 6.0c or later to 2 @$view Macintosh picture. Dd WORD  ,Times .+i Diagnosis +2Question ( Join + Diagnosist*|99*|**9"t%,(%(,("( (... ( ... (...d WORD t"dWORDd WORD t"dWORD t-6640-6"G (E Diagnosis"21  t".*79795*1,.-79.-ɠ t".)787)5816.57).5"} (CQuestionaf#=%0"G~)ah50"G((ak0"J(af<0"G& +i?Question (\Answer )\Answerai0"HL+ (\DAnswer +]Answer:[<8" S&WordMicrosoft Word&Word B  2 @@$Use Word 6.0c or later to 2 @$view Macintosh picture. BS S SlSHHr|XSS cccc ccccHcccccccc(qc(qc(qc(qccMcccccccc(qc(qc(qc(qccccDc ccccccccccccccccccccccccccccccccc cccccccccccc(qc(qc(q(qc(qcc(q(qc(qc(qc(q(qcc(qc(q(qc(qc(q(qcc(qcc(qc(q(qccpcccccccccccccccccccc cccccccc#ccccccccccccccccccccccccccccccccccccccccccccccc(qc (qcc(qc(qcc(qc(qcc(qc(qc(qc(qcc(qcc(qcc(qcc(qcc(qc(qc(qcc(qcc(qcc@cccccc cccccccccc cccccccccccccccccccccccccccccccccccccccc(qc(qc(qcc(q(qcc(qc(qc(qc(qcc(qc(q(qc(qc(qc(qcc(qcc(qcc*ccccc cccccccccccccccccccccccccccccccccccccccccccccc(qc(qcc(qcc(qc(qc(qc(qc(qc(qc(qcc(qc(qc(qcc(qcc(qcctcccccccccccccccccccccc cccccccc#cccccccccccccccccccccccccccccccccccccccccccccc(qc(qcc(qcc(qc(qcc(qc(qcc(qc(qc(qcc(qcc(qcc(qcc(qcc(qc(qc(qcc(qcc(qcccc cccccccccccccccccccccccccccccccccc(qc(q(qc(qc(q(qc(qc(q(qcc(qc(qcc(qc(qcc(qc(q(qccccccccc(qcc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc ccccccccccccccccmccccccccccccccccc\ccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccc,ccccccccccccccccccccccccccccc ccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccc  cccccccccc cccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccc ccccccccccccccccccccc ccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccc~c ccccccccdcccccc!cccccccccccccccccccccccccccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc ccccccccccccccccccccccccccccccccccccccccccAcccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccc(cccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc cccccccccccc(cccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccc cccc ccccccccccccccccccccccccccccccccccccccccccccqccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccc#c ccccccccc$cccccccccccccccccccccccccccc(cccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccc cccccccc cccccccccccccccccccc cccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc ccccccccccccccc cccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccc ccccccccc$cccccccccccccccccccccccccccc(cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc*ccccccccc cccc cccc.ccccccccccCcccccccccccccccCcccccccccccccccCcccccccccccccc>ccccccccccccc=ccccccccccccc?cccccccccccccc5ccccccccccccccccccccc cccc ccccccccccccccccccccccccccccccccccccc9cccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccc ccccccccccccccccccccccccc7cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccc cccccccc&ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccCcccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccc cccc cccc[ccc(qccccccccccWccccccccccccccccc cccccccccccccccccccc(q(qcc(qc(q(qc (q(qc(qc(q(qc(qc(q(qc(q(qccccccccccccccccccccccccccccccc ccccccccccc ccccc cccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccc(qcc(qcc(qcc(qc(qcc(qc (qcc(qcc(qc(qcc(qc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccc ccccccccc cccccccc cccccccccccccccccccccccccccccccc3cc ccccccccccccccccccccccccccc(q cc(qcc(qc(qcc(qc(qcc(qcc(qc(qcccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccc9cccccccccccc ccccccccccccccccccccc(qc(qcc(qcc(q(qc(qcc(qcc(qc(qccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccc (qcc(qcc(qcc(qc(qc (qcc(qcc(qc(qcc(qc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccc ccccccccc cccccccc cccccccccccccccccccccccccccccccccccccccccccccc cccccc(q(qcc(qc(q(qc(qcc(qc(q(qc(q(qccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc(qc(qcccc7c(qcc(qcc(qcccccc cccc ccccccccccccccc(ccccccccc/ccc cccccccccc+cccccccccccc)ccccccccccc+ccc ccccccccc'ccccccccc cccc cccc cccc cccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccc cccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccc cccccccc ccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccc ccccccccc cccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccc cccccccccccccccc cccc ccccccccccccc@ccccccccccccccSccccccccccccccc cccccccccDccccccccccccccccAcccccccccccccccSccccccccccccccc cccccccccFccccccccccccccc cccc cccc cccc ccccccccccccccccccccccccccccccccccccccccc(qcc cccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccc cccccccc(q(qcc(qc(q(qc (q(qc(qc(q(qc(qc(q(qc(q(qccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccc cccccccc(qcc(qcc(qcc(qc(qcc(qc (qcc(qcc(qc(qcc(qcccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccc(q cc(qcc(qc(qcc(qc(qcc(qcc(qc(qccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccc(qc(qcc(qcc(q(qc(qcc(qcc(qc(qcccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccc cccccccc (qcc(qcc(qcc(qc(qc (qcc(qcc(qc(qcc(qccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccc(q(qcc(qc(q(qc(qcc(qc(q(qc(q(qccccccccc(qc(qc(ccc(qcc(qcc(qc cccc cccccers can concurrently browse and update a shared requirements database using standard WWW browsers. capturing both requirements and their rationale using an intuitive but computer-interpretable formalism. The rationale allows one to understand requirements and the consequences of changing them, and supports negotiating resolutions to conflicting requirements. providing automated tools for identifying inconsistency, incompleteness and incorrectness in the requirements set. suggesting ways to reccccc'cccccccccccc cccccccccccccc ccccccccccccccccccccc#cccccccccccccccccccccccccc ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccc#cccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccc cccccccccccccccccccccccccccccccccccccccccc#cccccccccccccccc ccccccccccccccccccccccccccccccccccccccAccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccc ccccccccccccccccccccc cccccccc ccccccccccccccccccccc>cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccc ccccccccc cccccccccccccccccccccccccccccc:ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccaccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccc ccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccc cccc cccccccccc'cccccccccccc cccccccccccccc ccccccccccccccccccccc#cccccccccccccccccccccccccc ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccc#cccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc:;!  S&WordMicrosoft Word&Word   2 @@$Use Word 6.0c or later to 2 @$view Macintosh picture. 6~ ~6 6~d6~HHNN`6~6~ cccc cccc ccccTcccccccccc(qc(qc(qc(qccBccccccc(qc(qc(qc(qccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc cccccccccccc(qc(qc(q(qc(qcc(q(qc(qc(qc(q(qcc(qc(q(qc(qc(q(qcc(qcc(qc(q(qc+cc ccccccccccccccccccccccccccccccccc'cccccccccccccccccccccccccc cccccccccccccc!cccccccccccccccccccccc cccccccccccccccccccccccccccccccc(qc (qcc(qc(qcc(qc(qcc(qc(qc(qc(qcc(qcc(qcc(qcc(qcc(qc(qc(qcc(qcc(qcccccccccccccccccccccc ccccccccccccccccccccccccccc cccccccccccccccc cccccccccc cccccccccccccccccccccccccc(qc(qc(qcc(q(qcc(qc(qc(qc(qcc(qc(q(qc(qc(qc(qcc(qcc(qccc cccccccccccccccccccccccccc ccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccc(qc(qcc(qcc(qc(qc(qc(qc(qc(qc(qcc(qc(qc(qcc(qcc(qccccccccccccccccccccccccccccccccc cccccccccccccccccccc cccccccccccccc!cccccccccccccccccccccc ccccccccccccccccccccccccccccccc(qc(qcc(qcc(qc(qcc(qc(qcc(qc(qc(qcc(qcc(qcc(qcc(qcc(qc(qc(qcc(qcc(qccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccc(qc(q(qc(qc(q(qc(qc(q(qcc(qc(qcc(qc(qcc(qc(q(qc1cccccccccc!ccccc(qc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc cccctcccccccccccccccccccccccccccccccccccccccccccccc?ccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccNccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccc(ccccccccccccccccccccccccccccMcccccccccc ccccccccccccccccccccccccccccccccccccccccccccc ccccccccc ccccccccccccccccccccccCccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc\cccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccc(ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccc cccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc cccccccccccccc ccccccccccccc ccccccc cccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccc cccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccc ccccccccccccccc cccccccccccccccccccc cccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccc ccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc+ccccccccc=ccccccccccccc cccc ccccccccc!cccccccccccccccccccccccccccccccccccccccc cccccccccccccc ccccccccccccccccccccccccc cccccccc&cccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc cccccccc ccccccccccccccccccccccccccc ccccccccccccccccccc cccccccccccccccccccccccccccc ccccccccccccc ccccccccc cccccccc&cccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccc cccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc]ccccccccccccccccc ccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccc+cccccccccccccccccccccccccccccccccccccccccccccc cccccccccccc#ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccc.ccccccccccccccccccccccccccccc cccccccc ccccccc ccccccccccccccccccccc cccccccccc cccccccccc cccccccccccccccc cccccccccccccccccccccccccccccccc1cccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccSccccccccccccccccccccccccccccccccc cccccccc+ccccccccccccccccccccccccccccccccccccccccccccccccccccccc#ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc9ccccccccccQccccccccccccccccc cccc ccccccccc!cccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccc cccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccFccccccccccccccccc ccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccSccccccccccccccccccccccccccccccccc cccccccc+cccccccccccccccccccccccccccccccccccccccccccccc cccccccccccc#ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccc ccccccc ccccccccccccccccccccc cccccccccc cccccccccc cccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccc9ccccccccccccccccccccccccccccccccc cccccccc+ccccccccccccccccccccccccccccccccccccccccccccccccccccccc#cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc9ccccccccccQccccccccccccccccc cccc cccc+cccccccc3ccccccccccccccccccccccc cccccccccccccccccccccccccccccc cccccccccccccccccccccccc cccccccccccc(ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccc cccccccccccc(cccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccc cccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccc ccccccc cccccccccccccccccccccQcccccccccccccccccccc)ccccccccccccccccccccccccccc cccccccccccccccccccccccccccccc cccccccccccccccccccccccccc ccccccccc ccccccccccccccccccccccccccccccc&ccccccccccccccccccccccccccccccccccc cccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc$ccccccccccccccccccccccccccc ccccccccccccccccc cccccccccccccccccccccccccc cccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccgccccccccccccccccccccccccc)ccccccccccccccccccccccccccc cccccccccccccccccccccccccccccc cccccccccccccccccccccccccc ccccccccc ccccccccccccccccccccccccccccccc&ccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccc cccccccccccccccccccc cccccccccccccccccccccccccccccccc ccccccccccccccccccc cccc cccckccccccccccccccc(qcccccccccccccccccccccccccccccccc8ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc(q(qcc(qc(q(qc (q(qc(qc(q(qc(qc(q(qc(q(qcccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccc cccccccccccccccccccccccccc cccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc(qcc(qcc(qcc(qc(qcc(qc (qcc(qcc(qc(qcc(qc cccccccccccccccccccccccCccccccccccccccccc ccccccccc ccccccccccccccccccccccccccccccccc cccccccccccccccccccc ccccccccccccccccccccccccccc cccccccccccc(q cc(qcc(qc(qcc(qc(qcc(qcc(qc(qccccccccccccccccccccCcccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc ccccccccccccc ccccccccccccccccccccccccccccccccc ccccccccc(qc(qcc(qcc(q(qc(qcc(qcc(qc(qc ccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc (qcc(qcc(qcc(qc(qc (qcc(qcc(qc(qcc(qc ccccccccccccccccccccccc cccc ccccccccccccccccc cccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccc(q(qcc(qc(q(qc(qcc(qc(q(qc(q(qcccccccccc ccccc*cccccc(qc(qc=ccccccccc(qcc(qcc(qc cccc ccccJccccccccccc`ccccccccccccccccccccccccccccccccccccc ccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccc cccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc cccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccc cccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccc ccccccccc cccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccc$ccccccc cccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccc cccccccccccccccccc ccccccccc cccccccccccccc cccccccccccccccccccccccccccc?cccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccc cccccccccccccc ccccccccccccccccccccccccccccccc ccccccccccccccccc ccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccCcccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccc!ccccccc"cccccccc cccc ccccmccccccccccccccccc}cccccccccccccccccccccccccScccccccccccccccc ccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccc cccccccccccccccc cccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc'ccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccc0ccccccccccccccccc cccccccccccc cccccccccccccccccccccc ccccccccccccccccccccc ccccccccccccccccccccccc cccccccc ccccccccccccccccc cccccccsolve exceptions, using a knowledge base of generic exception resolution strategies. Keywords collaboration requirements rationale conflict consistency completeness correctness resolution 1. The Challenge The current DoD requirements definition process typically consists of multiple iterations of increasingly broader reviews, centered around an action officer, with flow times of 400 days or even more. The process thus operates like traditional throw over the wall manufacturing, where one function completes its job and only then sends it to the next function for review, with all the attendant problems of excessive iteration and rework, communication delays, misunderstandings between different functions and limited concurrency. While details differ, this kind of serial requirements definition process is also characteristic of much of industry. Concurrent engineering ideas, which have proven highly successful in manufacturing settings, also appear applicable to the requirements definition process. This approach involves flattening a serial cycle into concurrent activity by a members of a multi-functional team. Team members can get quick feedback from other functions as they explore alternatives, as opposed to only after they have created a complete requirements definition document. This greatly reduces the time and cost needed to produce a final satisfactory requirements set. A critical challenge to the effectiveness of multi-functional teams, however, is the frequency and impact of coordination problems like inconsistency (for example from differing terminology), incompleteness (for example from dropped balls, unclear responsibilities) and incorrectness (for example from one function creating requirements that prove unviable from the perspective of another function. These exceptions often require a tedious and resource-intensive process to detect them, but can have a severe impact on the cost, schedule and quality if left unaddressed for too long. This paper describes how one can provide computer suppccccccccc5cccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccc ccccccccc ccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc$ccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc cccccccccccccccccc ccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccc*cccccccc;cccccccccccc cccc cccc cccc cccc cccc ࡱ; }~a_`! "+$,$$$&&m,,666777=<><DD/J0JzVVWeWiWWUXZ8ZZZ[K[[:\\\]>]]?^^^Z__<`s``,aaaEbbbc|ccGeeeeeuV uD] uDLo] uDi] uDf]]^U]V]]^c]I}~ #8abklefpqUV_`^ _ ~  g`'`',`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`''ghuv q89R!!##+$-$&&l,m,x0y022277777=<><X<{A|A`'`'`'(|AACCDDDDFFYIZI.J/J1J2JNN5QFQGQlVzV'WxWXY?ZZu[A\\]`^__`Baab9ccvd*vddeeeeeeeeeee`'`'333!$K(`(Normal  ]a c&@& Heading 1U]^(`( Heading 2xU]c@ Heading 3U@ Heading 4^&@& Heading 5U]c(@( Heading 6<V]c$@$ Heading 7V]$@$ Heading 8V]"A@"Default Paragraph Font @ Footer ! @ Header !$&@$Footnote Referencece(@"( Footnote Textc$O2$bulletLOBpara h(OR(main0c(Ob(figurehc$Or$in,hc$O$indent hc$O$Table hc0O0text|L  x c O heading2Z(O(caption U]cOfigt (O(bib0]KR F0S3CompObj\WordDocumentTObjectPoolF_3F_3  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuwxyz{|}~SummaryInformation( @Microsoft Word 6.0.13ࡱ; v FMicrosoft Word 6.0 DocumentNB6WWord.Document.6;  Oh+'0   ) 5AI Q]z H-J!=_')BP*' M-HCAAQ5WJ2>6O),=Q/9M<313PEMMacintosh HD:Applications:Microsoft Office:Microsoft Word 6:Templates:Normal"Informations System Collaboratory'@v@v@ng3eYfkf        v%4A2G?Wbl}abklUV`^ h uv q89R +!-!##l)m)x-y-///44444=9>9X9{>|>>@@AAAACCYFZF.G/G1G2GKK5NFNGNlSzS'TxTUV?WWuXAYYZ`[\\]B^^_9``vaab`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' `'`'`'`'`' `'`'`'`' `' `'`'`' `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' `' `'`'`'`'`' `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'$&)g|AvdUnknownXORDGovernment User/David S. Dobya valued microsoft customer% /David S. Dobya valued microsoft customer% AF/XORJFREDERICK H. ZEITZ Janet PeasantJoe UserPSE s!Informations System CollaboratoryNMacintosh HD:Documents:Publications:AI in Design '96:Web Design WS paper.final@U SgUa cSgUa c Sga cga c ga cbjkM]^bbbbbbbbbbbbbjk M ] ^ eeeeeeeeeenMTimes New RomanTimes Symbol"MArialHelvetica MTimesMNew YorkMHelvetica"!+5!Informations System Collaboratoryࡱ; ܥhO eeTb'$nnnn nYnuuuuuuuu&DZX5Iuuuuuuuuuuuuu2BTuusu An Exception Handling Approach to Enhancing Consistency, Completeness and Correctness in Collaborative Requirements Capture Mark Klein Research Associate Applied Research Lab PO Box 30 Pennsylvania State University State College PA 16804-0030 klein@quark.arl.psu.edu (814) 863-5381 (tel) (814) 865-7097 (fax) http://quark.arl.psu.edu/klein-vita.html Abstract Current requirements capture approaches often involve high costs and long flow times due to the largely manual, serial and highly iterative requirements capture and review cycle. This paper describes C-ReCS (the Collaborative requirements Capture System), an implemented WWW-based system that addresses these problem by: supporting virtual multi-functional requirements definition teams. Multiple users can concurrently browse and update a shared requirements database using standard WWW browsers. capturing both requirements and their rationale using an intuitive but computer-interpretable formalism. The rationale allows one to understand requirements and the consequences of changing them, and supports negotiating resolutions to conflicting requirements. providing automated tools for identifying inconsistency, incompleteness and incorrectness in the requirements set. suggesting ways to resolve exceptions, using a knowledge base of generic exception resolution strategies. Keywords collaboration requirements rationale conflict consistency completeness correctness resolution 1. The Challenge The current DoD requirements definition process typically consists of multiple iterations of increasingly broader reviews, centered around an action officer, with flow times of 400 days or even more. The process thus operates like traditional throw over the wall manufacturing, where one function completes its job and only then sends it to the next function for review, with all the attendant problems of excessive iteration and rework, communication delays, misunderstandings between different functions and limited concurrency. While details differ, this kind of serial requirements definition process is also characteristic of much of industry. Concurrent engineering ideas, which have proven highly successful in manufacturing settings, also appear applicable to the requirements definition process. This approach involves flattening a serial cycle into concurrent activity by a members of a multi-functional team. Team members can get quick feedback from other functions as they explore alternatives, as opposed to only after they have created a complete requirements definition document. This greatly reduces the time and cost needed to produce a final satisfactory requirements set. A critical challenge to the effectiveness of multi-functional teams, however, is the frequency and impact of coordination problems like inconsistency (for example from differing terminology), incompleteness (for example from dropped balls, unclear responsibilities) and incorrectness (for example from one function creating requirements that prove unviable from the perspective of another function. These exceptions often require a tedious and resource-intensive process to detect them, but can have a severe impact on the cost, schedule and quality if left unaddressed for too long. This paper describes how one can provide computer suppccccccccc5cccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccc ccccccccc ccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc$ccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccc cccccccccccccccccc ccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccc*cccccccc;cccccccccccc cccc cccc cccc cccc cccc ࡱ; }~a_`! "+$,$$$&&m,,666777=<><DD/J0JzVVWeWiWWUXZ8ZZZ[K[[:\\\]>]]?^^^Z__<`s``,aaaEbbbc|ccGeeeeeuV uD] uDLo] uDi] uDf]]^U]V]]^c]H}~ #8abklefpqUV_`^ _ ~  g`'`',`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`''ghuv q89R!!##+$-$&&l,m,x0y022277777=<><X<{A|A`'`'`'(|AACCDDDDFFYIZI.J/J1J2JNN5QFQGQlVzV'WxWXY?ZZu[A\\]`^__`Baab9ccvd*vddeeeeeeeeeee`'`'333!$ K(`(Normal  ]a c&@& Heading 1U]^(`( Heading 2xU]c@ Heading 3U@ Heading 4^&@& Heading 5U]c(@( Heading 6<V]c$@$ Heading 7V]$@$ Heading 8V]"A@"Default Paragraph Font @ Footer ! @ Header !$&@$Footnote Referencece(@"( Footnote Textc$O2$bulletLOBpara h(OR(main0c(Ob(figurehc$Or$in,hc$O$indent hc$O$Table hc0O0text|L  x c O heading2Z(O(caption U]cOfigt (O(bib0]K(`(Normal  ]a c&@& Heading 1U]^(`( Heading 2xU]c@ Heading 3U@ Heading 4^&@& Heading 5U]c(@( Heading 6<V]c$@$ Heading 7V]$@$ Heading 8V]"A@"Default Paragraph Font @ Footer ! @ Header !$&@$Footnote Referencece(@"( Footnote Textc$O2$bulletLOBpara h(OR(main0c(Ob(figurehc$Or$in,hc$O$indent hc$O$Table hc0O0text|L  x c O heading2Z(O(caption U]cOfigt (O(bib0]be(`(Normal  ]a c&@& Heading 1U]^(`( Heading 2xU]c@ Heading 3U@ Heading 4^&@& Heading 5U]c(@( Heading 6<V]c$@$ Heading 7V]$@$ Heading 8V]"A@"Default Paragraph Font @ Footer ! @ Header !$&@$Footnote Referencece(@"( Footnote Textc$O2$bulletLOBpara h(OR(main0c(Ob(figurehc$Or$in,hc$O$indent hc$O$Table hc0O0text|L  x c O heading2Z(O(caption U]cOfigt (O(bib0]K(`(Normal  ]a c&@& Heading 1U]^(`( Heading 2xU]c@ Heading 3U@ Heading 4^&@& Heading 5U]c(@( Heading 6<V]c$@$ Heading 7V]$@$ Heading 8V]"A@"Default Paragraph Font @ Footer ! @ Header !$&@$Footnote Referencece(@"( Footnote Textc$O2$bulletLOBpara h(OR(main0c(Ob(figurehc$Or$in,hc$O$indent hc$O$Table hc0O0text|L  x c O heading2Z(O(caption U]cOfigt (O(bib0]beeYfkf        v%4A2G?Wbl}abklUV`^ h uv q89R +!-!##l)m)x-y-///44444=9>9X9{>|>>@@AAAACCYFZF.G/G1G2GKK5NFNGNlSzS'TxTUV?WWuXAYYZ`[\\]B^^_9``vaab`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' `'`'`'`'`' `'`'`'`' `' `'`'`' `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' `' `'`'`'`'`' `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'$&)g|AvdUnknownXORDGovernment User/David S. Dobya valued microsoft customer% /David S. Dobya valued microsoft customer% AF/XORJFREDERICK H. ZEITZ Janet PeasantJoe UserPSE s!Informations System CollaboratoryNMacintosh HD:Documents:Publications:AI in Design '96:Web Design WS paper.final@WWWW