TWIST: Managing Requirements in PAT

Requirements Management for the TWIST Standard Using PAT (Project Assistance Toolkit)

by Mike Bennett

London Market Systems Limited

Abstract

This paper describes the requirements management system that has been set up for the TWIST Treasury XML standard, using the PAT project management toolkit.

The basic principles are outlined with illustrations. Information is given on the detailed navigation of the PAT system showing how to create new entities in this system, how to edit the Terms and Conversations and what happens in the design process.

This paper is intended to cover everything that people should need to know in order to contribute to TWIST requirements management activities using this tool. It is written at a time when this application of PAT is still partly under development and therefore describes something which is of necessity a work in progress.

of 33 Managing TWIST Requirements in PAT

Table of Contents

Abstract...... 2 Background...... 5 Theory...... 5 Entities...... 6 PAT Structure...... 6 Goals...... 6 Original goals...... 6 Subsequent Goals...... 7 Restructuring Goals...... 7 Requirements...... 8 Conversations...... 8 Terms...... 9 Schema elements...... 9 Practical Example...... 10 Where the Example Came From...... 10 Tenor Changes Impact Analysis...... 11 Detailed Impact...... 11 Requirements Impact...... 12 Putting the Above into PAT...... 13 Summary...... 15 Using PAT...... 16 Logging In...... 16 Screens...... 16 Navigating the Requirements Hierarchy...... 17 Navigating...... 18 Managing and Editing the Hierarchy...... 19 Editing...... 20 Adding Entities...... 20 Creating Links...... 22 Review...... 23 Editing the Terms and Conversations Screens...... 24 Intention and Background...... 24 The Terms Screen...... 24 Name, Definition and Synonyms...... 24 Equivalent Industry Terms...... 25 Content Information...... 25 Terms containing Data...... 26 Terms containing Terms...... 26 Implementation Area...... 27 History and Notes...... 27 Parents...... 27 Issues Management...... 27

Conversations...... 27 Name and Description...... 28 Equivalent Industry Messages...... 29 Message Information...... 29 Associated Terms...... 29 Implementation...... 29 Design and Change Management...... 30 Adding New Requirements...... 30 Requirements corresponding to existing Process Goals...... 30 New Business Process...... 30 Formal Reviews...... 31 Requirements Gathering...... 31 Design reviews...... 32 Impact Assessment...... 32

Background The TWIST technical team have created a requirements repository and change management system using a freely configurable web-based tool called Project Assistance Toolkit (PAT) from Ninth Wave in London.

Because this has been introduced after the initial TWIST schema implementation the material in the repository is not complete. Instead, parts of the existing schema are being reverse engineered to create requirements material, while new work is to be entered in a top down approach beginning with business requirements. The first area where this happens is to be a pilot for future implementations, assuming it goes well.

This paper describes how to use PAT to populate the relevant parts of the XML schema requirements. Examples are given with reference to a current change request showing how this affects the hierarchy and therefore the XML schema itself.

The PAT based Requirements Management itself is still under development and in particular users should be aware that the screens for the individual entities (Requirements, Terms etc.) are not as complete as they could be. Most work so far has been on the relations between these. It is hoped that detailed layout and design can be completed using feedback from this next stage of user involvement. If you are reading this that probably includes your feedback.

Theory Requirements for an XML standard are not the same as the requirements for a product or other compiled code. Put simply, the requirements for an XML standard need to be defined in terms of the semantics of the schema. This defines the content of the messages that are going to be transmitted using that XML schema.

For a workflow related standard such as TWIST, the semantics of the schema breaks down into two types: "View" and "Do" or reference versus workflow data.

The purpose of the PAT-based requirements repository (or any other repository) is to define the requirements to be met by the standard. These are defined in several ways, ranging from business requirements (stated in plain English) to the required terms in the schema. An additional layer of requirements has been added at the top of the hierarchy, defined as "Goals". This is to define and therefore manage the overall intentions and work areas that TWIST is embarking on. Full details are given below.

Before we look at the screens then we will look at the entities defined within this PAT application.

Entities Most of the words for "thing" in the IT world are taken. In this paper, "Entity" means the kinds of thing set up for requirements management in TWIST.

The PAT Entities are:

 Goal  Requirement  Conversation  Term

These are configured in a kind of top-down pyramid, with one Goal connecting to several Requirements, each Requirement breaking down into more detailed requirements or into a number of Terms and Conversations, and so on.

In addition, Schema Elements are represented in the PAT system to define how they link in to requirements. These are primarily defined in the XML schema itself and only secondarily in PAT. The other entities are defined primarily in PAT.

The above entities are all forms of Requirement in the broader sense.

PAT Structure The Requirements entities are set up in a hierarchy. These are defined as follows:

Goals Goals are broadly defined business definitions of what TWIST sets out to achieve. In a more vertical standard, there would be one Goal (e.g. "to represent market data"). TWIST started life with five stated goals, and has extended these.

The purpose of Goals is to define and manage the business area in which TWIST is operating. This helps to manage the co-ordination with other standards in that space, to identify systems vendors in that space, and to manage the PR and marketing of TWIST in that market place.

For those areas where the TWIST Schema is still being developed, the Goal should correspond to a Working Group (for example the working Group for "Working Capital Management" will have a stated overall Goal, to which all the Requirements will contribute).

Original goals The original five Goals were:

1. Relationship Management 2. Trade origination 3. Trade Execution and Confirmation 4. Settlement and Reconciliation 5. Reporting and Accounting

This formed the basis for Version One of TWIST (currently embodied as 20031414, formal revisions numbers are still to be implemented as part of this phase of works).

Note that in this Version One, the instrument types to be supported were limited to foreign Exchange and Money Markets (FX and MM).

Subsequent Goals The following Goals have been added since Version One and have therefore not been implemented in the Schema yet:

Control and Security Goals to manage the security of the messages regardless of content or business process

Working Capital Management New business application area, to provide messaging capabilities for aspects of working capital management.

New instrument types Following FX and MM implementation, the Goals of the TWIST standard have been extended to include:

 Fixed Income and Commercial Paper  Interest Rate Derivatives

Restructuring Goals From the above it becomes clear there are two kinds of Goals:

1. Process Goals 2. Instrument Goals

Hence when a new instrument is to be represented in TWIST, most or all of the existing processes (as defined for FX and MM) may be used. They may have to be adapted to be general enough to cater for all the required instrument types, but the same basic business activities (the same Requirements) are to be supported.

The PAT system supports multiple linking between entities. The structure of the original "Pyramid" changes subtly so that each Process Goal and each Instrument Goal link down the pyramid to a sets of Requirements which embody both Goals. This is illustrated in Figure 1.

Goal: Trade Execution Goal: FX and MM and Confirmation

Requirement: Modify a Trade

Figure 1: Multiple Goals relating to a Requirement

Requirements These are what you would expect to find in a requirements management system: plain, business level descriptions of the tasks which are to be supported.

It is important to remember that the Requirements stated here are not requirements for a System, but descriptions of all systems that have to be supported using the proposed XML schema in their messages.

The Requirements do not describe on "ideal" system, but a universe of all possible systems that need to exchange messages using the TWIST XML format. Unlike conventional requirements statements, these do not need to define a single consistent set of requirements, and in fact they should not.

These Requirements themselves are mechanised in two ways:

1. Conversations - the dynamic, workflow requirements of messages 2. Terms - the individual terms for the schema elements.

These two things between them defined the detailed content needed in the XML schema.

Conversations Workflow or "Do" requirements are broken down into the smallest indivisible components of conversations between systems. In PAT these are called Conversations (note that some schema elements also have "conversation" in their names).

Again recall that we are not defining a single system but the universe of all possible systems that are to use TWIST. If any systems are missed out, they will not be able to use TWIST. The Conversation atoms should correspond to all candidate systems.

Conversations are atomised into the smallest practical units of exchange of messages for stated purposes. These are effectively conversation atoms, but are called "Conversations" in the PAT system. They can be grouped into whole conversations in the conventional sense.

The next section gives examples of how these fit together.

Terms Complementary to the Conversation atoms are the Terms used in messages.

The intention of the Terms part of the hierarchy is to define, independently of the actual XML, all the elements that will need to be implemented in XML.

Hence the Terms look very like the final XML schema Elements. They differ only in as much as there are design decisions which optimise the way in which Terms are mechanised by Elements. The default, "no brainer" design choice is to define one Element per Term.

Schema elements Finally there are the schema elements themselves. By definition there is some design exercise between the definition of the Conversations and Terms (in the business domain) and the implementation of these as XML Schema Elements.

The simplest and most common relationship between Terms and Elements is a one to one mapping: FX Single Leg Request (in English) being mechanised by as an element. In many cases there will be a one to many mapping in which one Term is implemented by one unique combination of Elements.

For the technically inclined, note that there are other aspects of the XML design such as "Complex Types" (in this example, the FX Single Leg Request Term will be represented as Complex Type - with the same name as the Element but with a leading capital letter instead of lower case). Complex Types define general data models which may be used by different Elements, for example a Block Trade will be defined in the same terms as any other Trade so it will use the "Trade Request" complex type rather than having a special but identical complex type for Block Trade.

Users of PAT do not need to be aware of the above design aspects unless they are on the Technical Team.

Practical Example

Where the Example Came From To understand how the denizens of the PAT Requirements Management system fit together, it will help to look at an example.

One of the early decisions in implementing PAT was not to reverse engineer the whole of Version One into Requirements but to start with the Change Requests which have been filed and reverse engineer the bits of the Requirements hierarchy relevant to those.

The received Change Request documents have been processed into a Word file which currently does duty as a Change Register. This will soon be implemented within PAT (separate instructions to follow). Meanwhile all the received change information has been broken down into individual Change Requests and these have been numbered. The Impact of each change has been determined, starting with whether it is a "Technical" change (relating to the design and implementation of the XML) or a change to Requirements needing review by business domain experts. Any change to an element even at design level will potentially impact those elements of the schema that use it. The Requirements hierarchy should reliably point to these, allowing impact assessment to be carried out.

Change Requests CR1 to 4 are typographical and conventioning changes in the design of the XML Schema (or DTD in one case) and have no impact beyond this. They are effectively defect reports. These need to be reviewed for impact by the Technical Committee only and so they won't affect our Requirements Hierarchy. These Change Requests CR1 through 4 have been implemented in the current version.

CR5 and 6 are raised against this version. CR5 and CR6 relate to the element "tenor" and the data model around it. We will focus on CR5.

The Requirements, Terms and Conversations which use Tenor in any way have been reverse engineered in PAT to define the whole of that part of the hierarchy. This is described in detail below.

The reverse engineering has been achieved with extensive reference to the Visual Model provided by Bill Specht in June 2003. It would not have been possible without this. This has also been checked against the raw Schema itself. In these exercises, Schema Version 20030414 has been used.

Recommendations for Source Control: 20030414 should be defined in the new Source Control system as Version 1.00.01 when this is set up This will allow the previous version (currently known as 20030320) to be 1.00.00 without CR1 - 4 implemented. Note the use of US date conventions in the current version - 20030320 is earlier than 20030414.

Tenor Changes Impact Analysis CR5 states: "Change Tenor to be a simple enumeration" Detail: The current model of Tenor is a choice of either a named tenor (e.g. SP for spot) or a general interval defined as a number plus W, M or Y.

This pattern is unnecessarily general. We suggest that the type be simplified to an enumeration of the tenor names which is the standard used by most existing systems. Using the general framework is particularly complicated when processing the XML through stylesheets.

Detailed Impact The design change involves changing the "Complex Type" called "Tenor" in terms of how this relates to the element . We don't need to look into this as we are interested in the impact not the design.

In terms of the TWIST Schema, the pieces impacted by any changes to Tenor are:

Element Complex Type

Elements which use this Complex Type are:

These are used in:

} Used in

} Used in }

} Used in and in

In technical terms the above are all Complex Types but they also correspond to Elements with the same names but with leading lower case (known as camelCase) e.g..

Requirements Impact So where do the above elements fit into the Requirement hierarchy and how is this to be defined?

Let's revert to English. We have:

1. Tenor - used as part of how an FX Single Leg Request is set up; 2. Far Tenor and Near Tenor - used in FX Swap requests; 3. Quoted Tenor - used for Interval Quotes and also for a thing called "Quoted As"; 4. "Quoted As" is used, optionally in both cases, in FX Barrier Option and FX Simple Option (in the definition of these as Products not in the "Requests" for them as above).

Looking at a couple of these:

(3) Quoted Tenor fits in with the "Set-up Conversation" required for Trade Origination (our second Goal). In the schema hierarchy Quoted Tenor comes under :

Goal P2: Trade Origination Market Data Price Feed Market Quotes Interval Quote Quoted Tenor

We will ignore this part of the hierarchy for now in order to concentrate on the FX Single Leg Request and other Trade related Requirements. However this will have to form part of the impact analysis for the proposed Change since it is potentially affected by it.

(1 & 2) FX Single Leg Request and FX Swap request: these, alongside Term Deposit Request, form part of the "Financial Terms" of a Trade Request. (Term Deposit Request does not use Tenor, instead it uses specific dates). The Financial terms also appear in a couple of other places relating to trades.

The "Financial Terms" are used in these places:

Trade Request - this is the definition of a requested trade, whether this is in terms of a pricing request, credit request, or the definition of an actual Order as it goes through.

Order Request - forms the subject of an Order Conversation.

Create Trade - the creation of a new Trade is also defined in terms of Trade Request using Financial Terms as above.

The general data model for Trade Request is also used in Block Orders and some other post-trade Conversations.

This all fits into conversations about Trade Execution and Confirmation - our third process related Goal.

In the design of the existing Schema, Create Trade forms part of the Trade Modification Conversation, along with Modify Trade, Cancel Trade, Closeout and Block Trade. It should be clear that this overarching "Trade Modification conversation" is an aspect of the schema design, not of the requirements. In the world of English language Requirements, we simply say that we need to be able to:

 Create a trade  Modify it  Cancel it  Close it out  Create a Block Trade (this replaces a previously quoted / agreed trade with a set of blocks, each of which is to be defined, priced, accepted or rejected, and potentially cancelled).

These are Requirements. This is where we start.

Putting the Above into PAT In business terms we have the following requirements:

 Create Trade  Modify Trade  Cancel Trade And so on.

Using Modify Trade as a simple example to begin with, there is a clear distinction between the Conversation and the Terms. These are shown below: "Requirement" Modify Trade

"Conversation" "Term"

Modify Trade Trade Modification Conversation Terms

Figure 2: Conversations and Terms to implement a Requirement

The conversation then breaks down as follows:

 Request Modification  Accept Modification  Reject Modification

These are conversational atoms and need to be defined in the XML.

The Terms break down into the terms of the proposed modification. These need to be referred to at each stage in the conversation. In the schema (and therefore in the assumed but undocumented requirements) these are:

 Modification details  Defined Field (for users to use as they see fit)

Modification details break down into:  FX Single Leg Modification  FX Swap Modification  Term Deposit Modification

And for example FX Single Leg Modification breaks down into a set of Terms:

 Dealt Currency Amount  Requester buys / Requester sells  Value Date  Exchange Rate

Putting all these together gives us:

Modify Trade

Modify Trade Trade Modification conversation Terms

Request Modification Defined Field (option)

Accept Modification Modification

Reject Modification FX Single Leg Mod

FX Swap Mod

Term Deposit Mod

Figure 3: Structure of Requirements for a Trade Modification

This defines the basic principles. Our "Tenor" example is not here. This is in the more complex model presented by "Create a trade" among other requirements. This is shown on the next page.

Figure 4: Requirements Structure for Trade Creation

Create Trade

Trade Execution and Trade Terms Confirmation conversation

Trade Request Party / trade identifier

Trade Response Requester reference

Credit Request Financial Terms

Credit Response FX Single Leg Request

Price Accept / Reject FX Swap Request

Trade Acknowledge Term Deposit Request

Etc. Pending Action

Trade comment

This Trade is a block Dotted outlines show terms which are optional User Defined Field

For each of the items above there should then be a schema implementation whether as a unique schema element or a novel combination of existing elements.

Summary The above describes the principles and requirements for formal Requirements Management of the TWIST schema, as well as perhaps highlighting some of the reasons this is needed. The next section describes the details of navigation and editing within the TWIST application in PAT.

Using PAT Users need to be using MS Internet Explorer version 5.5 or above. In addition it is strongly recommended that they use a high bandwidth connection (domestic broadband is also adequate) due to the high data rates involved.

Logging In Go to the following address. Note that this does not begin with "www" and that the "http://" has to be put in (since without a "www" Microsoft Internet Explorer doesn't insert it automatically).

http://twist.ninthwave.co.uk

This will bring up a login screen. Enter your login name (generally your surname) and your password (generally blank at this time).

If for any reason the login fails you will be redirected to a more generic Ninth Wave login screen. You can login from here as long as you first select "TWIST" from the drop down list of possible applications.

The Login takes you to your own "Home Page". You can return to this Home Page at any time using the "Home Page" button at the top of the PAT screen (not to be confused with your own Microsoft Internet Explorer Home Page).

Screens The main screen is divided into two main parts (Fig. 5). We'll call these the Selection Pane and the View Pane. In addition there are areas at the top of the screen for administrative functions. The whole "screen" as defined here is in fact the contents of an Internet Explorer window.

The selection pane allows the user to select the different views that are available to view in the View Pane.

Available views cover two things: 1. Schema requirements management 2. Project management tools

The project management tools are a basic part of PAT and have not been greatly adapted for the TWIST project at this time. Features include diary management, user management and so on. PAT makes use of user information to provide document handling and sharing, configurable levels of user access to different areas and facilities and so on. Users can also be given different selection areas on the Selection Pane.

Also included among the project management tools is the Change Control subsystem. This follows a fairly standard model and will be described elsewhere.

Figure 5: PAT Home Page for a Typical User

The Requirements Management system is selected under the heading "TWIST Schema" on the Selection Pane. There are a number of entities in this system, namely:  Goals  Requirements  Conversations  Terms  Schema elements Each of these can be viewed as a list apart from Goals.

More usefully there is also a Tree View. This starts with a display of Goals (as shown) and can be expanded indefinitely to show the remaining items.

Navigating the Requirements Hierarchy The place to start is the Tree.

At the top of the Tree are the Goals. These define the areas of work that TWIST has undertaken to cover. These are distinguished as two basic types: 1. Process Goals 2. Instrument Goals

Conceptually these Goals actually form a matrix as shown in Fig. 6, though this is not yet illustrated as a graphic in the system. So far the process goals and underlying requirements have been defined for FX and MM, though not all of this hierarchy has been populated. New instrument types will have many of the same requirements and use much of the same material, with some of it being adapted to those instruments.

Foreign Exchange & Money Markets

Fixed Income & Commercial Paper

Interest Rate Derivatives

More?...

Relationship Trade Execution & Settlement & Reporting & Management Origination Confirmation Reconciliation Accounting

Figure 6: Process Goals and Instrument Goals

Below the Goals are Requirements, plain language statements of what is to be achieved. Under the Requirements are the Conversations and Terms. These can all be seen by expanding the tree.

Navigating It is possible to expand the Tree view all the way down to the lowest Terms and Conversations. Each of these has its own view screen. This can be accessed by double clicking on the name of the entity.

Within the view screen for any entity there is an area showing the items below it in the tree. It is possible to drill down to the view screens of these entities. It is thus possible to drill all the way down through the hierarchy via the view screens.

Some entities also have a facility in their view screens to drill back up through "Parent" terms. It should be noted that this item is depicted the opposite way round to the normal Tree.

Managing and Editing the Hierarchy The way that items are connected together in the hierarchy is by associating them. The determination of what can be associated with what has been defined as part of the design of this TWIST PAT application and is as follows:

 Goals can have Requirements below them  Requirements can fulfil more than one goal (they should cover one Process Goal and any number of Instrument Goals but this has not been hard coded)  Requirements can include other Requirements  Requirements can include Terms and Conversations (this should only be done at the bottom of any Requirements branch)  Terms can include other Terms  Conversations are really conversational atoms. They can contain other conversations. They can refer to Terms.

These relationships are shown in Fig. 7.

Requirement

Conversation

Schema elements

Figure 7: Relations between Entities

Editing There are two areas where edit and other options appear. These appear when the mouse is hovered over them. The first such area is at the upper right of the View Pane (below the Home and related buttons - see figure 8). The second is within the different View Panes themselves.

Figure 8: Edit and other controls appear when you hover on this area

To edit an entity, click "Edit" and "Edit Record". This opens a new copy of the View Pane, this time in edit mode.

Be aware that any wording in the textual fields may seemingly disappear - this does not mean that the saved item will now have blank text there, but that no changes will be made to that text.

To finish editing a record click "Save".

Adding Entities Within the view screen of any entity there is a space for each kind of entity below it in the tree, e.g. a Requirement can have Requirements, Terms and Conversations under it. These can be added by editing the entity.

To add new entities, go into the edit screen for the parent entity (e.g. Requirement) as above. There will be a set of controls (including Edit) just above the area where the subservient entities are shown (see Figure 9). Click on "Edit" to get a drop down menu. Click on either "add" or "Link to" and a sub menu will appear showing all the types of entity that can be added at this point. Select one of these to either create a brand new entity of that type, or to link to one that already exists.

Figure 9: Adding Subservient Entities (Conversation shown)

If the record was being created as an addition to something above it in the tree, the "Save" button will give an option to "Save and add". This allows you to create a number of new entities under the same item, for instance defining all the terms under a particular requirement. When the last "Save and Add" is completed (i.e. when you select "Save" alone) you are returned to the screen of the item to which you were adding these items. This also must be saved.

In this way it is possible to edit items down several levels in the hierarchy. This is a powerful feature though users should be aware that from time to time this may reach a breaking point so that a new item cannot be added. If this happens, back out and save the items further up the tree - nothing else should break and you can go back and continue safely.

Creating Links To add a link to any entity, go into the view screen for that entity. Using the "Edit" function, click "Add item".

This is where the user needs to be careful. There is a choice between adding an item and linking to a new one. If an entity already exists you must select "Link To". Otherwise the system will try to create a new entity as described below. You may end up multiplying entities needlessly.

At this point it will help to refer to the existing lists of Requirements, Terms and Conversations to determine if the required item already exists and also to avoid using duplicate names for different entities.

Each entity can be viewed as a list by selecting it from the Selection Pane. This list is alphabetical by default but the listing criteria can be changed by clicking on the column headings (much as you would with emails). Filters are also available to simplify searching of long lists.

If for some reason not all the entities are shown, there may be a "filter" in operation. To check this, select "Filter" and click on "No Filter". This guarantees a complete list.

Review You should now have been able to define, edit and link any number of Requirements, Terms and Conversations. The next section gives more detail on what to put in the Terms and Conversations screens.

Figure 10 shows a typical part of the Requirements Hierarchy in Tree View. Note how the "Block" term appears twice - it exists once but is linked from both points in this instance.

Figure 10: Sample piece of Tree under "Block Trade"

Note that each kind of entity in the PAT universe has a different icon. These are: Goal

Requirement

Conversation

Schema element

Editing the Terms and Conversations Screens And so to the core of the whole system, the pages for the Terms themselves, and the screens for the related "Conversations" entity.

Intention and Background The intention with this system was to replicate and improve upon the method used to facilitate the requirements gathering for the Fixed Income component of MDDL (a task carried out by London Market Systems).

In MDDL a spreadsheet was used in which each line entry represented a semantically unique concept - in other words a term. As the spreadsheet got wider and wider it was clear that although one line doesn't sound like much, if we were to do this again we should change this to a single page or screen. This is the nature of the "Terms" pane in the TWIST PAT Requirements Hierarchy.

The MDDL Terms spreadsheet on which this is based had the following functional areas, each of which was intended for a different audience and purpose:

1. Hierarchical Terms listing 2. Contents information 3. Definition 4. Columns for names, alternative names etc. 5. Other equivalent industry terms (BMA and FIX/ISO15022) 6. Implementation Information and review notes

The Terms Screen In the TWIST PAT system, these functional requirements are shown as different areas on the Terms screen with the exception of the hierarchy aspect which is already implemented in the tree structure itself. These are now described with reference to the screen shot in Figure 11.

The screen areas are:

1. Name, Definition and Synonyms 2. Equivalent Industry Terms 3. Content Information 4. Implementation 5. History and Notes 6. Parents 7. Issues Management

Name, Definition and Synonyms The primary name for the Term should go here along with any other terms which may be different but mean exactly the same thing - i.e. have exactly the same content, intentions and usage. Multilingual terms will also go here.

Initially all that is needed here is the name and definition of the term.

Figure 11: Screenshot of Terms Page

Equivalent Industry Terms This area is intended for identifying terms (or elements names) in other standards, where these fulfil the same function as the Term on this screen.

To edit this, users simply drill down into the "Industry Equivalent" field using the small drill down arrow, and then choose "Edit" on the screen which follows to put in the term name, standard name, standards body and version quoted.

This area may be enhanced in the near future to allow more of this information to display on the Terms screen and to structure the named standards as a selectable list rather than free text as at present.

Content Information This is the core of the Terms requirements management. The schema designer needs to know what sort of contents a Term may take in order that the Schema model can reflect this.

There are broadly two kinds of terms: 1. Terms which contain other terms 2. Terms which contain data

In some standards (e.g. MDDL) this is constrained in the design to be an "either / or". In most Terms screens the user will see either a set of sub terms (on the right hand side of this area) or a set of details about the contents (left side).

Terms containing Data Contents may be a binary "yes / no" (e.g. the "requester buys" term in FX Single Leg Request), free text, a date, a list of terms or one of a number other data types.

The W3C Consortium (the caretakers of the XML standard) have defined a number of other data types which might be used, and the standard may have defined its own as part of the design and architecture - this will be defined in the Functional Specification for the standard.

One common type of content is the "Enumerated list". Many financial industry terms may contain one of a list of contents. Examples are a list of possible tenors for an FX deal, a list of currencies (using the standard ISO lists) or an open ended list of possible contents. The schema designer needs to know about this, and needs to know if the list is exhaustive, whether it is exclusive (only one of the list is permissible) and so on. This industry information enables the schema designer to make the right choices when defining the schema. It is therefore important that this information is accurate and future proof. For example if there is a currently complete list but it is feasible that a new instrument or industry may add to it, this should be made clear. A new market may introduce a new default settlement convention for example, but no- one is going to introduce a new day of the week.

Note that PAT won't provide the contents of the enumerated lists - this would be wrong (the PAT data model is not the TWIST data model). These should be defined in plain text along with the above information.

Note that the screen and data design of this part is still being improved.

Terms containing Terms For a term containing other terms, enter "Sub Terms" in the contents Type (this is not vital but tells other viewers why the data model entries are blank) .

To add the sub terms, hover over the menu area to the top right of the "Sub Terms" area. Click on the pen icon to bring up the Edit menu and select either "Add" or "Link To".

CAUTION: If the Term already exists, don't click "Add" click "Link To". Otherwise you will be induced to create a new term identical to the existing one. A term may already exist if it is a term of another Requirement or it has been set up while editing a Conversation. If in doubt, go to your "Home Page" using the "Home" icon in the top of the PAT screen and look at the alphabetical listing of Terms. Ensure any filters are turned off first.

When adding Terms, the process can be completed by clicking either "Save" or "Save and Add" under the save icon. "Save and Add" allows you to keep adding sub terms to the Term you are now editing. It may help to have a list of these handy to speed the process. The last "Save" brings you back to the current Term - remember to then "Save" that as well to complete the process or to return to the Term above it if this is also being edited.

Implementation Area This area is to define how the Term has been implemented in the Schema. This would be completed by the Schema designer as it does not form part of the Requirements definition process. For existing schema material some of these have been filled in to support current Change Requests (see e.g. "FX single Leg Request")

There should only be one Schema element per term.

There are also fields to define which version of TWIST the term will be (or was) implemented in, and any QA notes. If the Term changes this will need to be reflected also.

History and Notes This is a standard PAT project management function. It shows who has edited the record and when. It updates automatically so no action is needed.

This should give an audit trail into the design process as well as the implementation of any change requests.

Parents This area also appears automatically. Use it to click back up the tree to other Terms, Requirements and Conversations which use this Term. It is visually the inverse of the main Tree.

Issues Management This is a standard PAT project management feature. It can be used to put in any issues, comments and so on. Rather than have several areas for different review comments they should all o here - e.g. questions left outstanding which the designer needs answered from the business, problems encountered in the field and so on. The History feature should automatically provide some level of control over this.

Conversations Conversations do not have a precedent in the MDDL "Terms" spreadsheet described in the preceding section. This is because there is a distinction between "View" and "Do" standards in relation to the kind of information they carry. TWIST is a "Do" standard, that is it fits into part of a process workflow. This means that there need to be elements of the schema dealing with dynamic interchange of information, intentions, commitments and so on supporting the FX dealing process workflow. Terms alone will not do.

Further information on these theoretical aspects of the thinking are available from London Market Systems and are beyond the scope of this document.

A screen shot of the conversations screen is shown in Figure 12.

Figure 12: Conversation Screen

This is broadly similar in intent and layout to the Terms screen. The functional areas are as follows:

1. Name and Description 2. Equivalent Industry Messages 3. Message Information 4. Associated Terms 5. Implementation

Name and Description As for Terms, the Conversations need to be given a name. This is usually self- defining.

Most Conversation screens will relate to small conversation atoms which form part of a larger "conversation" in the conventional sense. For example, "Create Block", "Accept Block", "Reject Block" are all atoms of a conversation around the process of setting up a block trade.

Equivalent Industry Messages Since TWIST XML is intended to fulfil many of the business processes currently supported by proprietary messaging systems such as SWIFT, it may help to put these here. There will also be TWIST conversations which are novel and do not have an equivalent elsewhere.

Also message-related elements to the other "Do" or process related XML standards (FIX, FpML) will have a place here.

As noted for the "Equivalent Terms" on the Terms screen, there is scope for improving what is currently on this screen. Use plain text for now.

Message Information This section is intended to put forward the main features of the conversation. Fill in whatever is relevant here, as information to the schema designer.

Most conversations have a primary or instigating party, a secondary party and subject (such as a Block, for block trade). The subject will generally translate to a Term.

Alternatively the conversation may be an overall conversation which has individual conversation atoms under it. In that case, enter the sub conversations following the same method as described above for Sub Terms (i.e.. hover over the edit controls local to the "conversation" area of the screen and select "Add" or "Link To" as required).

Associated Terms Most or all conversations will relate to a specific Term as noted above. Link to this from there. In most cases the Term should already have been created as part of the Terms hierarchy so this should be "Linked to" at this point not "Added".

Implementation In TWIST most or all Conversations are defined as schema elements just like Terms. This includes the overall processes ("block trade" and so on) as well as the smaller conversation atoms. These are defined hierarchically in the Schema and this is now reflected in parts of this Requirements hierarchy. All being well this should carry through to the new instruments required for the Trade Lifecycle. For new business requirements (like Working capital Management) there may be a whole new set of Conversations to define or there may be existing Schema elements to be reused.

This area is to be filled in by the Designer. It should show where and how existing schema elements are reused. It may need to include "How to" information (as shown on the Website) as well as direct Element naming. This facility is not in place yet.

If an existing schema element needs to be changed to meet new conversation requirements then a Change Request should also be raised, followed by impact analysis across the affected parts of the existing schema and its usage.

Design and Change Management The Design of the schema should be unaffected by this Requirements Management system. However there is space under each Term and Conversation for information about the schema element used to mechanise that requirement. These are quite tightly coupled at present since the few requirements that have been populated have been reverse engineered from the existing schema.

Readers are reminded that the primary function of this system is to allow future changes of the standard to be managed safely and transparently and with reduced risk of existing functionality being broken.

Changes to the Schema must be accompanied by review by the appropriate technical and / or business teams as defined elsewhere in the formal change management process flows. It should be clear from that process where the different parts of the PAT system fit in.

Detailed use of the Change Management features provided in PAT will be described in a separate document.

Adding New Requirements These will either correspond to existing Process Goals or relate to whole new business processes.

Requirements corresponding to existing Process Goals Add the Requirements in the Requirements hierarchy as described in this document. When it comes time to design the schema, the schema designer should be able to identify from the requirements hierarchy exactly what is needed.

At the lowest level of requirements it should be possible to identify Terms (static data items) and conversations (dynamic exchanges between parties) and define these as described. The information on content types is needed by the Schema designer. Some information about the Conversation may also be needed by them - follow their guidance on how much to put in the Conversations screens.

Schema designers may need to ask detailed questioned based on the information received, at which point an on line Design Review may need to be held as described in the next section.

New Business Process Where a new goal is being pursued by TWIST which does not impact on the existing trade related processes, this will presumably be implemented by fresh schema elements. These need to be defined with reference to requirements defined around the new Goal(s).

At this point there needs to be information available on any local data types defined within the design, and any general data models which can be reused beyond the areas

of 33 Managing TWIST Requirements in PAT already implemented. This requires detailed communication from the schema designer in the form of a formal Functional Specification or equivalent repository based information. At present there is no provision in the PAT system for design information since none has been presented, however this can be added easily.

The business domain experts will need to add the Requirements information into the system as it stands. Each requirement should be a statement in plain business English of what is to be achieved.

There will also be a facility to enable diagrams to be linked to the Requirements statements. These may be UML diagrams, ordinary CAD diagrams or anything else that takes the form of a graphical file or document. Arrangements for this are still being put into place.

PAT also supports detailed document management features which should link into this.

Formal Reviews The way in which people's knowledge is accessed and input into a working product or standard is by way of formal reviews. The use of an on-line tool automatically facilitates the holding of teleconference based reviews in which knowledge is shared and the relevant repository elements may be updated in real time. The main kinds of review in most industry processes are:

 Requirements Gathering  Design Reviews  Impact Assessment

Requirements Gathering In the MDDL FI Requirements Gathering exercise this was achieved by on line reviews of the Terms spreadsheet, using a tool which enabled the spreadsheet to be updated in real time over the Internet while people discussed the requirements structure over the phone. This was done by industry experts in the absence of the schema designers. The same can be achieved using the PAT structure.

An important consideration is to consciously engineer the knowledge inputs required for the standard to be right first time, and then invite people with that knowledge to participate.

One person should facilitate the meeting (generally the head of the relevant Working Group).

Reviewers may also need to refresh their screens from time to time as changes are implemented by the facilitator.

Design reviews Schema designers may need to ask detailed questions based on the information received, at which point an on line Design Review will need to be held. This would take the form of a teleconference with everyone looking at the Design screens. Changes can be carried out in real time during these reviews.

This is a necessary part of the process in order to close the loop between defining the requirements and realising these in the working Schema.

Impact Assessment Any new Change Request will affect one of two things: the design of the Schema, or the Requirements that this seeks to implement. In TWIST we have kept to a single set of Change Requests which may therefore include defects as well as every kind of change. Sometimes a defect in behaviour is a change in design.

Changes which affect the requirements need to be reviewed by industry domain experts. Changes which affect the design may not impact on the business side, however there needs to be a review of all the parts of the schema which use the affected elements (identified by the related Terms or Conversations) in order to ensure that there are no regression problems. This Review should identify relevant regression test cases which should in turn be satisfied either by formal testing or (for budget reasons) by identifying successful implementations which have used the updated version of the Schema in those areas without finding faults in their own testing.