May 10, 2002 - engineering process for an electronic clearinghouse that connects ... ments engineers with automated migration of the existing business .... for complex systems. ... oping and transferring this technology to the clearinghouse.
(IEEE Joint Int’l Requirements Engineering Conf., Essen, Germany, Sept 2002)
May 10, 2002
Improving the Requirements Engineering Process for an Electronic Clearinghouse ∗ Mariusz A. Fecko, Christopher M. Lott Applied Research Area, Telcordia Technologies, Inc., Morristown, New Jersey, USA {mfecko,lott} at research dot telcordia dot com At the outset of this project, clearinghouse requirements engineers wrote message specifications (called “business rules”) in MS Word 1 files using a semi-structured tabular format. To get a sense of the size of the requirements, one ILEC trading partner may accept 30+ messages, any one of which may require 200+ pages in an MS Word document. The users of the requirements documents are developers (who implement the clearinghouse services), testers (who ensure message processing conforms to the requirements), systems engineers (who generate various downstream documents), and customers (e.g., CLECs). One of the challenges facing the project was a high degree of variation in the requirements documents; there was no standardized way of specifying the intricacies of messages. Staff turnover only exacerbated the situation. As a result, users of the requirements documents needed many clarifications, and often made mistakes while translating the requirements to code. Thus, inconsistencies and errors in the requirements resulted in software failures and faults, which contributed to a high rate of modification requests (MRs, essentially bug reports), and significantly eroded the profitability of the service. Another challenge was the high change rate in the requirements resulting from frequent (sometimes daily) modifications to business rules published by ILECs. Since the unstructured requirements were not amenable to machine processing, producing various downstream data (e.g., test cases, configuration of the customers’ GUIs for entering orders, order entry interfaces) required an enormous amount of tedious and error-prone work. To remedy these problems, we first developed a highly structured representation of the essential information. By focusing on requirements in the much narrower form of business rules, we managed to formalize the clearinghouse specifications without using a general-purpose requirements engineering language (such as [4, 5, 6, 10]). Despite a more rigorous and broader definition offered by these languages, adopting them would have required extensive training of the requirements engineers beyond the core of their expertise (also see Section 5.2), or hiring new staff.
Abstract We present experience with improving the requirements engineering process for an electronic clearinghouse that connects multiple trading partners in the telecommunications area. Software failures and faults were traced back to problems in the semi-structured requirements, which were written as message specifications (called “business rules”) in a non-standardized format using MS Word. To remedy these problems, we first developed a highly structured representation of the essential information in eXtensible Markup Language (XML), supported by XML Schema for precisely defining the requirements structure. Second, to edit this information in a friendly way while preserving its structure, we developed XLEdit—a custom graphical user interface for editing the XML documents. Third, to assist the requirements engineers with automated migration of the existing business rules, we developed a converter for translating from MS Word to the target XML format. The investment in the technology for structured requirements editing and validation is expected to increase customer satisfaction and dramatically improve the efficiency of providing the clearinghouse service.
1. Introduction We present experience with improving the requirements engineering process for an electronic clearinghouse. The clearinghouse [14] connects multiple trading partners in the telecommunications area. Competitive local exchange carriers (CLECs) use the clearinghouse to communicate information about their customers and orders to wholesale telecom suppliers, the incumbent local exchange carriers (ILECs). This information is passed between trading partners using intricately structured messages. The primary benefit to CLECs of using the clearinghouse is that they have to conform only to the clearinghouse’s interface specification; they are shielded from the wide variation among their wholesale trading partners’ interfaces. ∗ c
1 MS
2002 Telcordia Technologies, Inc.
1
Word is a trademark of Microsoft Corporation.
Second, to maintain the information and still preserve the structuredness of that information, we could not use a free-form editor such as a general word processor—a new interface was clearly needed. And third, perhaps obviously, to preserve the project’s investment in their existing requirements artifacts, we needed a technique for migrating them to the new format. The rest of the paper is organized as follows. Section 2 discusses the original, semi-structured requirements and some inherent issues. Section 3 presents our approach to structuring the requirements as one way of addressing these issues. Section 4 describes the tools developed to support our approach. Section 5 discusses opportunities for evolution as well as implementation options using commercially available products. Related work is presented in Section 6.
An example validation in a business rule may involve checking that the telephone number supplied in a message conforms to the format of “NPA-XXX-XXXX” (a threedigit Numbering Plan Area followed by a seven-digit local phone number), or that a query about a residential service availability contains an ADDRESS aggregate including the tags StreetNumber, ZipCode, and StateID. ILEC ILEC ILECs
CLECs order
order error
CLEC Tags
valid order ILEC
Tags
Clearinghouse
2. Existing semi-structured requirements
Business rules: translation and validation
This section describes the original requirements structure and some issues encountered by the clearinghouse project. To get a sense of the size of the problem, the full set of requirements for one release of the clearinghouse software entails approximately 4,500 pages of printed documentation. Of this, 75% is dedicated to message specifications (business rules). Further, as many as three releases may be in parallel development and operation. In short, issues in the message-specification portion of the requirements were a significant area of concern.
Figure 1. The clearinghouse architecture.
2.2. Requirements vs. specifications According to the classification discussed in [8, 17], the nature of business-rule requirements (essentially sequences of “if-then-else” statements) places them more correctly in the specification category. Message specifications are more amenable to our approach than general requirements for complex systems. These specifications deal exclusively with messages exchanged through the interfaces of the clearinghouse software and the external input/output systems, and thus satisfy the definition of a specification as describing “the behavior of the machine at its interface with the environment” [8]. In particular, we are not concerned with the requirements for the distributed, networking system in which the clearinghouse software operates. Nor are the telecom requirements engineers expected to supply the requirements for the internals of the clearinghouse that are not shared with the environment. As a result, they can focus on the logic captured in business rules, independent of the implementation details of the clearinghouse [18]. By leaving out unnecessary details, we were thus able to develop a technology that is tailor-made for the specification of business rules. Since the project calls their work product “requirements,” throughout the paper we use the term requirements to refer to the specifications of business rules.
2.1. Requirements format The original requirements in MS Word files had a semistructured tabular format. The requirements capture the structure and contents of messages. To give a sense for the requirements content, Figure 1 shows the architecture of message processing in the core clearinghouse software. A message sent by a CLEC to the clearinghouse is represented as a collection of fields (called “tags”), which are embedded in an enclosing field (called “aggregate”). The aggregates can be nested several levels up to the root aggregate (called “form”), as illustrated in this example message: aggregate (form) { aggregate { tag1 =value1; tag2 =value2;}} In the MS Word table, the business rules typically define how every incoming CLEC tag and its values are translated into the corresponding ILEC tag and values. (Other columns in the MS Word table give the list of valid values and the admissible length for this ILEC tag.) The business rules also specify certain invalid combination of various pieces of data (often associated with several ILEC tags) that trigger the clearinghouse to return an appropriate error message back to the CLEC. Valid orders are forwarded to the ILEC.
2.3. Errors and inconsistencies The most common problems in the MS Word documents were typographical errors, duplicate information, malformed statements such as unmatched parentheses, errors due to ambiguity and different styles, missing boolean 2
connectors in conditions, etc. To illustrate these problems, we present two specific samples from the semi-structured requirements: • Information from one column is often unnecessarily repeated in other columns, e.g., LSR.ADMIN.RECTYP valid values may be ‘N’, ‘C’, ‘D’, ‘T’, with the corresponding validation column if LSR.ADMIN.RECTYP is
for the structured format such as enforcing precise syntax and eliminating data redundancies. • Migration of the existing requirements to the new format. The existing requirements could not be manually rewritten to the target format in a cost-effective manner. Since the clearinghouse service needs to run without interruptions, requirements engineers could not embark on such a labor-intensive effort. In particular, the following factors prompted us to semi-automate this process: 1. The sheer volume of requirements data: the files to be converted comprise about 10,000 business rules in 1000’s of MS Word pages, which would require writing a few hundred thousands lines anew. 2. The necessity to disambiguate the existing requirements, to resolve inconsistencies, and to remove errors should become the focus rather than mere retyping. The above issues were resolved as described in the following sections.
not ‘N’, ‘C’, ‘D’, ‘T’, return error message. Thus there is a need to refer to each column in a
standardized manner to avoid duplication of information. • Since the vocabulary in MS Word documents is not standardized, different words often mean different things to the requirements engineers. Examples are the description of data type (we discovered that there was no agreement on the exact meaning of keywords numeric or alphanumeric) and ambiguous keywords such as position 2 (interpreted as either the 2nd occurrence of a tag or the 2nd character within a tag’s data field). We addressed these problems by suitable changes in methods and procedures, with appropriate, relatively modest technology support. Other problems included cases of identical requirements being implemented differently, and discrepancies between the requirements and the code. As discussed later, these problems could be addressed by advanced technology such as automatic cross-validation of the specifications against downstream artifacts, or generation of code directly from the specifications.
3.1. Requirements data representation, storage, and display We chose eXtensible Markup Language (XML) [7] as the highly structured representation. This data format is receiving growing support in the e-commerce community, and offered many immediate benefits. An XML document is a plain-text file: it can be stored on any PC, sent easily in email, deciphered easily by technical people, and managed by a conventional version control system. Libraries for manipulating XML documents are available for many programming languages. An XML-based repository of the requirements offers features of database technology such as queries and report generation. The goals of making the requirements conform to a precise standard, and making them viewable in a friendly manner, were achieved by using associated XML technologies. • Schema for the requirements structure definition. The developed XML schema precisely defines the structure of requirements in XML, including the nesting of aggregates and tags, and various types of business rules involving “ifthen-else” statements. Our timing was lucky: XML Schema technology became generally available in time for us to use it for defining the structure of the intricate message specifications. The key feature of the schema is that any requirements data can be easily validated against it by freely available technologies. • Data and presentation format separation. Presenting raw XML in a text editor, or even assisted editing with a commercial general-purpose XML editor, were not viable options for our user community. Instead, XML requirements data conforming to the defined schema XML is displayed as viewer-friendly HTML [12] through the customized eXtensible Stylesheet Language (XSLT) [9] transform. This transform can be used by various tools, thus of-
3. Towards structured requirements Having recognized the problems in the existing requirements process, we decided to develop technology for the structured representation and editing of the requirements as well as the migration of the existing requirements to the new format. All requirements data can be kept in one repository that can be edited, queried, and reused. In the future, this structured requirements repository is expected to drive the clearinghouse code and generate code test cases. The following issues had to be addressed while developing and transferring this technology to the clearinghouse requirements organization: • Requirements data representation and storage. The format should break down the requirements into precisely defined components in such a way that they could become machine-processable, and yet remain readable by the humans. The candidate representations were a relational database and a file-based data representation format. • Requirements data editing. After the requirements are converted to a structured representation, they must necessarily be presented to the requirements writers in some friendly way. A new edit tool should preserve the desirable features of the old one (i.e., MS Word) such as data copying, searching, comparison, file loading and saving, etc. At the same time, a new tool could introduce features customized 3
similar results for textual requirements used to fill out the specially designed structured forms. This process forces those performing the transformation to consider aspects that may have previously been overlooked [2]. In our case, the requirements engineers were able to move away from various descriptive statements thanks to the use of nested business rules, worked out common vocabulary, tightened the definition of data types (e.g., alphanumeric), etc.
fering a human readable display of the requirements during editing, comparison, and report generation.
4. Tool support We developed the migration process and the following software tools to support the introduced structured format: • XML editing tool (see Section 4.2) • XML “diff” tool (see Section 4.3) • converter from MS Word to XML (see Section 4.4)
4.2. XML editing tool
4.1. Migration to new requirements process
The new interface for editing and presenting the XML documents is a custom graphical user interface (GUI), called XLEdit. Requirements are actually displayed in a highly readable HTML-based format after applying a suitable XSLT transformation. Unlike general-purpose XML editors, XLEdit shields the requirements engineers from both the raw XML and the underlying schema. The tool encourages the user to follow a standard style of writing business rule information, and validates the edited requirements using XML Schema validation and extensive additional checks. The editor thereby ensures that all requirements documents are highly consistent and (to the extent possible) free of all the common problems we identified with the requirements documents at the outset of the project. Any edited requirements document conforms to the defined schema at all times. Figure 3 shows the main editing interface of the XML editing tool for tag NAME. A user can proceed from this interface to edit specific parts of the requirements for this tag: CLEC tag information, ILEC tag information, valid values, length, and business rules (translations and validations). An example screen shot of the requirements document in the XML editing tool is shown in Figure 4. As can be seen, to minimize disruption to the users, the view provided by the tool closely follows the familiar view offered by MS Word shown in Figure 5. The XLEdit tool reuses two large COM components from Microsoft: MSXML 4.0 and Internet Explorer 5.0+ 2 . These components are currently glued together using VisualBasic version 6, although the glue code can be easily reimplemented using another programming language. Reuse of these controls gained us access to an enormous amount of functionality. The MSXML 4.0 component includes an XML parser, a DOM library, and XSLT functionality [1]. This component is used to read, parse, and write XML files, to manipulate the XML document in memory, and to transform the internal XML representation into viewable HTML using an XSLT stylesheet. The advantage of using XML is that it serves as a light-weight database. A component that is installed with Internet Explorer 4.0 and above is the WebBrowser control. This component is used to display a HTML document, and includes features
The process of migrating towards the new format and its support tools started well before all the existing requirements documents had been analyzed. As a result, new constructs that needed to be supported were being added to the schema as the tools entered the pre-production phase. The underlying schema was evolving accordingly, as were the tools coupled to it. (This effort involved analyzing hundreds of pages in the existing requirements documents in MS Word.) To enable a seamless transition for the requirements engineers, the XML files that were obtained from MS Word in accordance with some version of the schema need to be automatically upgraded by the special-purpose XML processing scripts rather then be regenerated from the original MS Word files. This is to preserve any changes made to these files by the requirements engineers.
XL Edit (reviewers)
Project Library
Business Rule Repository (XML)
ILEC/CLEC Requirements Docs
Parser/Converter MS Word
Web Browser
Submit Document Web Server Retrieve analysis results
(requirements engineers)
Figure 2. Migration to structured requirements storing and editing. Figure 2 shows an overview of the requirements engineers adopting the new process. The adoption procedure provides them with an option to transition to the new process incrementally. In the meantime, the clearinghouse service can function using both MS Word and XML files. The process of cleaning the requirements in MS Word to make them parseable improves the requirements even before a full conversion. Cunning and Rosenblit [2] report
2 MSXML
4
and Internet Explorer are trademarks of Microsoft Corp.
is not provided. A condition statement allows boolean connectors “and” and “or”, as well as nesting using parentheses. Condition selectors “if”, “else if”, “else”, and “otherwise” are also accepted in the specification of a condition. A condition section allows clauses including (but not limited to) the following list, which tests: • that an aggregate is (not) present; • that a tag is (not) populated; • that a tag’s data is (not) equal to some literal value; • that a tag’s data appears (or not) in a list of literal values; • that a tag’s data appears (or not) in a stored table; • that a tag’s data is (not) in a range of literal values; • that a tag’s data is (not) equal to another tag’s data; • values of specific data or portions of data, such as: length of a tag’s data, specific character(s), field(s), or word(s) within a tag’s data, specific occurrence(s) of an aggregate or tag, number of occurrences of an aggregate or tag; and • other useful tests, including combinations of the above.
4.3. XML “diff” feature The document comparison feature performs intelligent comparison of documents based on the XML structure, and generates reports that pinpoint the changes. This so-called “diff” tool is embedded in the XML editor. Change reports help requirements engineers identify changes in the edited XML documents so they can be communicated to all interested parties. Previously, identification of changes to documents depended on the MS Word document-comparison feature, which in practice meant skimming through a long document looking for bits of text colored red and marked with strike-through symbols. An additional benefit of this tool is the ability to generate highly customized change reports. For example, a system engineer can easily produce and share with a specific customer only the customer-relevant changes.
Figure 3. XLEdit main editing interface. like scrolling, printing, searching, etc. In short, it’s a web browser without the menu bar (see Figure 4). The XLEdit tool has well defined functionalities that offer maximum flexibility to the users, and yet preserve the underlying XML structure of the requirements documents. The tool makes it possible to eliminate redundancy (such as repeated listing of literals) as much as possible. In practice, this means that a condition statement within some aggregate or tag entry may make reference to elements in that entry, such as a list of valid values. The tool is also developed for the particular domain of the requirements, and is thus enhanced with some specialized features such as integrated editing and reuse of XML files with error messages among multiple forms, hooks to assemble and view textual contents of messages crossing the customer interfaces, short cuts to quickly specify common types of business rules, different views of the requirements to facilitate working with large files, etc. A large portion of the message specifications, perhaps 90%, is devoted to business rules. Most business rules define a condition on which an error message and an order are returned to a CLEC. To illustrate the supported functionalities, we present an example for editing conditions. A condition section allows the user to specify a boolean condition by making statements about aggregates and tags in the input presented at the interface being defined. Editing of the condition section is heavily assisted using GUI controls such as drop-downs; free-form entry of statements
4.4. Converter from MS Word to XML We developed a converter for translating business rules information from MS Word to the target XML format. To assist the requirements engineers in automated migration, we developed a methodology to help engineers clean the original requirements. A special-purpose parser identifies constructs that cannot be parsed; the engineer is then responsible for modifying the document to eliminate common errors and ambiguities. Once the document is clean, the converter tool produces an XML representation of the original MS Word data. During the conversion, a significant amount of data redundancy is eliminated. As an added benefit, labels that enable requirements traceability are supplied automatically. Any remaining unparseable segments (e.g., ambiguous constructs or overly complicated rules) are identified and clearly marked up as such in the XML file. These 5
Figure 4. An ILEC’s requirements in XLEdit (tag: LSR.ADMIN.CCNA).
Figure 5. An ILEC’s requirements in MS Word (tag: LSR.ADMIN.CCNA). 6
opaque segments must later be rewritten to a structured format using the XML editing tool. As might be guessed from Figure 2, the migration procedure is iterative. A requirements engineer first rewrites an MS Word document according to our guidelines, and submits the document for parsing through a self-service Web front-end. In return, a list of error messages are displayed to guide the requirements engineer to entries requiring further rewrites. Second, if necessary, extensions are made to the parser’s grammar, the guidelines mentioned above, and the underlying XML schema so that as many constructs as possible can be parsed. Third, the requirements engineer resubmits the document for parsing. The whole process is repeated until an acceptable pass rate is achieved. In practice, acceptable rates ranged from 86% to 99%. Although a steep learning curve was involved, we found that most requirements engineers were able to clean up their requirements with only modest assistance. A major conversion difficulty is handling constructs with a large number of variations. In certain cases, it makes sense to accommodate different syntactical expressions with the same semantics. For example, to refer to the contents of the current ILEC tag, requirements engineers use data, data in this field, this field, values, or the tag name. The parser handles all these variations, and then eliminates the redundancies by translating them into a single reference to the current ILEC tag. In other cases, trying to extend the parser to handle such constructs reaches the point of diminishing returns. Either the MS Word expressions are very rare and thus the benefits of bulk conversion are questionable, or there are simply too many possibilities. For example, to write the condition based on the number of occurrences of a given tag in a message (e.g., if LQI{OUT{LOOP MLT occurs more than twice), handling all syntactical variations (e.g., more than, at least, more than or equal to, twice, thirteen times) is not cost effective. The grammar for such constructs must be made more restrictive, and some effort is needed to modify them in MS Word, e.g., as number of occurrences of LQI{OUT{LOOP MLT > 2, to ensure successful parsing.
(e.g., using XLEdit), any downstream generation from business rules that include these segments is either unreliable or, even if the reliable generation can be attempted, isolated parts of the downstream data must be supplied manually.
5.1. Unstructured elements in XML documents The first category of unstructured elements is large XML fields that clearly need to be broken down. For example, in a business rule, a tag’s contents may be subject to various kinds of string manipulation operations (e.g., fill with zeros, left justify, concatenate). Currently just one XML element per business rule holds the data representing these operations. A full structuring of this part of the business rules is equivalent to inventing a programming language; it is unclear if it can be done without committing too many resources, or if the requirements engineers can learn to use what would be essentially a library of string processing functions. We will tackle this problem after we have gained sufficient experience. The second category includes small XML fields that get filled out with content that does not quite match what the field was designed for. For example, occasionally an XML element that should hold a simple value (e.g., ‘A’ or 10), instead gets a description of a value (e.g., a holiday or next business day). Such descriptions make sense to people but probably not to a code or test generation tool. The XLEdit’s editing capabilities and the underlying XML schema must be extended to handle this category. The third category includes XML fields that are created from composite pieces identified by the parser (e.g., a value 10 and its unit numeric), but the defined XML schema stores those pieces in a single XML element (i.e., as 10 numeric). This occurs when the schema lags behind the parser in granularity, but the migration cannot be held back. Unlike the second category, breaking down such elements into smaller ones is relatively easy to do by some specialpurpose scripts run on the existing XML documents.
5.2. Burdens on requirements engineers During the development of the technology presented here, we needed to balance a need for precision of requirements against placing additional burdens on the requirements engineers or overly constraining their ongoing work. Writing requirements for telecom software requires the ability to use editing tools (possibly specialized), and a knowledge of the requirements domain. The telecom requirements engineers are intimately familiar with the semantics of the requirements, and can easily edit them with a specialized user-friendly tool (such as XLEdit). This applies to most business rules that were successfully parsed and converted. In this way it is possible to ensure the desired precision of the requirements without placing additional burdens on their writers.
5. Technology evolution Recall from Section 4.4 that any unparseable segments are migrated to XML as opaque strings. Besides those due to errors in the semi-structured requirements, some of these segments are created because of the evolutionary nature of the adopted migration process. The evolving XML schema cannot be guaranteed to precisely define 100% of encountered rules, nor can it predict what kind of constructs are yet to be discovered in the remaining MS Word documents. Until such segments are fully structured further in the process
7
The problem appears with the remaining business rules, whose precise structuring requires changing their syntax closer to that of a programming language. Since the requirements engineers are not (and in most cases do not want to be) trained programmers, these requirements are typically left unstructured without the ability to generate downstream data from them. An alternative is to encourage the requirements engineers to make an extra effort, with the understanding that writing these rules in XLEdit will most likely be harder than previously in MS Word. This will certainly require learning new specification skills, following an informal principle that “a formal specification should be as simple as possible, but no simpler” [18]. Fortunately, these remaining rules account for less than 5% of the total.
fers a declarative description of mapping between the informal statements provided to the customers onto formal statements expressed in the language. To write the so-called system requirements documents in Albert II , a requirements engineer produces an informal specification, whereas an analyst skillful in the formal notation of Albert II supplies the corresponding formal counterpart. The key difference of our approach is that the complexity of formal description does not need to be managed by an analyst; instead, it is hidden from a requirements engineer by XLEdit, which produces the formal specification in XML. The gap between informal (user-friendly) and formal (machine-processable) requirements is thus bridged by the separation of presentation format, i.e., HTML display, and its data counterpart, i.e., structured XML. The penalty for doing so is a small percentage of the requirements that may be left in an informal, unstructured format (see Section 5.1). Another approach bridging the gap between imprecise requirements (i.e, informal ones) and formal specification is introduced by Yen and Tiao [16]. In a developed formal framework, imprecise requirements are represented by fuzzy logic so that the flexibility of informal requirements can be captured and then automatically analyzed. A relaxation of the rigidity of formal description allows otherwise conflicting requirements to be satisfied simultaneously. This approach can be explored and potentially used to enhance our structured requirements, e.g., by modeling fuzzy logic expressions in XML Schema. Although useful in validity and consistency checks between the requirements, it is questionable if reliable, bug-free code can be generated from the imprecise requirements. Day and Joyce [3] propose a framework for integrating notations from four distinct categories: models, events, actions, and expressions, implemented as types in higherorder logic. The categories allow the independent viewing of the notations, in a manner whereby they can be combined to create a specification. This way a potential mismatch between the expressiveness of the readable requirements notation and an analysis tool’s formal notation is avoided. Overall, using the notations introduced in [3] requires a significant amount of formal specification skills, which makes it unrealistic to use by requirements engineers having only the domain expertise (see Section 5.2). Cunning and Rosenblit [2] present a semi-formal method to structure the behavioral requirements for real-time embedded systems. This method is based on a set of forms (called Structured Requirements Specifications (SRSs)) that contain both informal text-based descriptions and formally defined language constructs. The information needed to produce transaction-oriented test scenarios is automatically extracted from the SRSs forms. The process to get from text-based requirements to the SRSs forms is a manual one, which may need to be repeated when the requirements
5.3. Implementation options Keeping in mind the technology status described in Sections 5.1 and 5.2, automated code generation from the structured requirements is emerging as a viable path. In the present mode of operation, the clearinghouse’s business rules are implemented as Programmable Validations (PV) Rules. The rules are edited with the PV Edit tool, and executed by a specialized high-performance PV engine. There exist other commercial business rule engines on the market, which usually process Java-based validation rules. These engines may also offer a rule language with support for business rules, and tools for the development of business rule applications. The requirements engineering technology presented in this paper is not limited to a particular implementation language, and is general enough to attempt the generation of implementation code targeted towards PV Rules or Java-based rules. Moreover, if a business rule engine is capable of direct processing of the requirements in XML, the clearinghouse requirements in XML can be transformed through an appropriate XSLT script to an XML conforming to the schema understood by the engine. An additional enhancement is the generation of more specific instances of the XML schema for different forms (essentially instances of the clearinghouse interface). This feature may enable the customers to validate their messages against each interface instance specified as XML Schema. A part of the currently implemented business rules could thus be embedded in the structure of the schema rather than implemented as programmable rules, at a potential savings on the development and testing cost.
6. Related work Du Bois et al. [4] present the specification language Albert II . This formal language is based on an ontology of concepts used for capturing requirements of real-time, distributed systems. Being as expressive as pioneering RE languages [5], the language is reported to be natural: it of-
8
BizTalk 3 [11]) can offer an enormous benefit by the automating of exchange, validation, and downstream generation from structured message specifications.
evolve. This feature makes it less suitable for the telecom clearinghouse system, where changes to the requirements occur on a daily basis. In this case, the automated synchronization between the visual requirements and their structured form, as provided by XLEdit, seems a better option.
Acknowledgments We would like to thank the clearinghouse management team, the Applied Research management team, and our colleagues for their support and encouragement: B. Brennan, Y. Chen, J. Choe, D. Christopher, N. Conant, S. Dunlavey, D. Egan, T. Gean, W. Grant, W. Grebe, S. Hillis, R. Jacowleff, A. Jain, M. Katz, M. Kret, J. Leaton, A. Omary, L. Ozimek, D. Payette, B. Pleasant, M. Ruiz, M. Smith, R. Straughter, M. Tallman, N. Thompson, and M. Young.
7. Conclusion Our technology entered general use on the project in January 2002. The investment in the technology for structured requirements editing and validation is expected to increase customer satisfaction and improve the efficiency of providing the clearinghouse service. Storing all the relevant data in one place has already contributed to a significant drop in the MR rate. We anticipate further drops in the MR rate, and are working closely with the project to quantify the benefits that accrue from the improved requirements process. Future work will strive toward the goal of generating clearinghouse code directly from the requirements. In the final architecture, all requirements will be entered through the XML editor, and then drive the code and configure the customers’ GUIs for entering orders. We will also explore a promising path of moving a subset of logic validations into the ones based on validating an XML message against the corresponding instance of XML Schema, which can eliminate a significant portion of the clearinghouse code. Other future work will address automated generation of tests from the XML requirements documents. The migration of the clearinghouse requirements to the highly structured format also allowed us to identify an overlap between the requirements for the clearinghouse and other interconnection systems used by the company such as telecommunication access gateways. One of the current efforts is to promote a reuse of this common set of requirements among a broader set of intra-company systems, potentially reducing their maintenance cost to a significant extent. An obstacle to this task is a frequent mixture of descriptive (i.e., free text with large variations) and non-descriptive (e.g., following the if-then-else pattern) requirements information. In such cases, there is a need to clearly identify parts that will be subject to structuring, such as requirements data that is expressible as programmable rules. This step requires a clear understanding of the anticipated use of structured requirements to design a proper XML schema, whose granularity is of special importance. The approach presented in this paper is particularly wellsuited to the specifications describing inter-system, intercompany message exchanges. These exchanges usually occur during e-commerce transactions and flow-through order processing, where large numbers of highly repetitive messages are crossing the boundaries of heterogeneous systems. XML and associated technologies (see emerging ecommerce standards and products such as ebXML [15] and
References [1] D. Ayers, S. Livingstone, S. Mohr, and D. Singh. XML Application Development with MSXML 4.0. Wrox Press Inc., 1st ed., 2002. [2] S.J. Cunning and J.W. Rozenblit. Test scenario generation from a structured requirements specification. In Proc. IEEE CWECS: Conf. Wksp Eng. Comput.-Based Syst., 1998. [3] N. A. Day and J. J. Joyce. A framework for multi-notation requirements specification and analysis. In Proc. IEEE ICRE: Int’l Conf. Require. Eng., Schaumburg, IL, 2000. [4] P. Du Bois, E. Dubois, and J.-M. Zeippen. On the use of a formal RE language: The generalized railroad crossing problem. In RE’97 [13]. [5] S. J. Greenspan, A. Borgida, and J. Mylopoulos. A requirements modeling language. (Elsevier) Inform. Syst., 11(1):9–23, 1986. [6] C. Heitmeyer, J. Kirby, B. Labaw, and R. Bharadwaj. SCR*: A toolset for specifying and analyzing software requirements. In Proc. CAV: Int’l Conf. Comput.-Aided Verif., Vancouver, Canada, 1998. [7] S. Holzner. Inside XML. New Riders Pub., 1st ed., 2000. [8] M. Jackson and P. Zave. Deriving specifications from requirements: An example. In Proc. IEEE ICSE: Int’l Conf. Softw. Eng., pp. 15–24, Seattle, WA, 1995. [9] M. Kay. XSLT Programmer’s Reference. Wrox Press Inc., 2nd ed., 2001. [10] S. Liu, A. J. Offutt, C. Ho-Stuart, Y. Sun, and M. Ohba. SOFL: A formal engineering methodology for industrial applications. IEEE Trans. Softw. Eng., 24(1):24–45, 1998. [11] Microsoft Corp., Redmond, WA. MicrosoftTM BizTalk Server. (http://www.microsoft.com/biztalk). [12] C. Musciano and B. Kennedy. HTML & XHTML: The Definitive Guide. O’Reilly & Assoc., 4th ed., 2000. [13] Proc. IEEE RE: Int’l Symp. Require. Eng., Annapolis, MD, 1997. [14] Telcordia Technologies, Inc., Piscataway, NJ. TelcordiaTM Exchange Link—The Electronic Clearinghouse Service for Complete Interconnection. (http://www.exchangelink.net). [15] UN/CEFAST and OASIS. Electronic Business Extensible Markup Language (ebXML). (http://www.ebxml.org). [16] J. Yen and W. A. Tao. A systematic tradeoff analysis for conflicting imprecise requirements. In RE’97 [13]. [17] P. Zave and M. Jackson. Four dark corners of requirements engineering. ACM Trans. Softw. Eng. Method., 6(1):1–30, 1997. [18] P. Zave and M. Jackson. Requirements for telecommunications services: An attack on complexity. In RE’97 [13].
3 BizTalk
9
is a trademark of Microsoft Corporation.
