-1 Regulation 3.2 AUSTRALIA PATENTS ACT, 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT ORIGINAL Name of Applicant: JOHANNES WIJNINCKX Actual Inventor: JOHANNES WIJNINCKX Address for service in A J PARK, Level 11, 60 Marcus Clarke Street, Canberra ACT Australia: 2601, Australia Invention Title: Method And System For Linking Electronic Artefacts Thc following statement is a full description of this invention, including the best method of performing it known to me. ,4.Orzs_.twOC 2 FIELD OF INVENTION The invention relates to a method and system for linking electronic artefacts to each other and / or to statements of condition or capability. 5 BACKGROUND A typical software development project involves the creation and maintenance of many different types of electronic Artefacts such as documents, source code or other files. 10 Software developers use Requirements to state the condition or capability to which the software to be built must conform. The general accepted principle in the software industry is that Requirements should be identified through a unique identifier. Requirements should also be traceable to each other, and to artefacts in which they are referenced. 15 Software development also involves the creation of work products also referred to as Artefacts. Artefacts include items such as specification, design, test-design, code and test-script. Specification, design and test-design atefacts have the potential to involve tens of Artefacts depending on project size. Code and test-scripts have the potential to involve tens, hundreds or 20 more instances depending on project size. Requirements should not only be traceable to each other but should also be traceable to Artefacts to enable change impact assessment and scope control. 25 It is an object of at least preferred embodiments of the present invention to provide a method and system of linking electronic artefacts in a user controllable and efficient manner, or to at least provide the public with a useful alternative. SUMMARY OF THE INVENTION 30 In one embodiment the invention provides a method of linking electronic artefacts comprising identifying an Item common to a first electronic artefact and a second electronic artefact; defining an Item Identifier, the Item Identifier comprising an Item Type, a Separator and a unique whole Number; storing the Item Identifier in an item database maintained on one or 14Ml "g-LI 3 more computer readable media; defining a Tag by encapsulating the item identifier within a pair of tag Delimiters; and inserting the Tag representing the Item into the first electronic artefact and the second electronic artefact. 5 The term 'comprising' as used in this specification and claims means 'consisting at least in part of', that is to say when interpreting statements in this specification and claims which include that term, the features, prefaced by that term in each statement, all need to be present but other features can also be present. Related terms such as 'comprise' and 'comprised' are to be interpreted in similar manner, 10 As used herein "(s)" following a noun means the plural and/or singular forms of the noun. As used herein the term "and/or" means "and" or "or", or both. To those skilled in the art to which the invention relates, many changes in construction and 15 widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the invention as defined in the appended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting. The invention consists in the foregoing and also envisages constructions of which the following 20 gives examples only. BRIEF DESCRIPTION OF THE FIGURES The present invention will now be described with reference to the accompanying figures which: 25 Figure 1 is a block diagram of a preferred form system in which the invention operates; Figure 2 shows preferred form electronic artefacts that are linked by a method of the invention; 30 Figure 3 shows a preferred form item database in accordance with the invention; and Figure 4 shows items marked within individual artefacts in accordance with the invention. 1004)49-1 4 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Artefact and Storage descriptions Figure 1 shows at 100 a preferred form system for linking electronic artefacts. The system 5 includes computing device 105. This computing device includes any portable or desk top computing device. A portable computing device includes a laptop or PDA. Computing device includes as shown a display 110 and user input device 11$. Computing device further includes secondary storage 120. Secondary storage is typically integral within computing device 105. It is also expected that computing device 105 has one or more docking ports to allow connection of 10 one or more portable memories 125. Portable memory includes any computer-readable media that is able to be removably connected to computing device 105. Portable memory for example includes static RAM devices as well as compact disc and tape devices accessible through appropriate readers/writers. 15 It is also envisaged that computer device 105 has one or more network ports to allow transfer of data through one or more networks 130. It is envisaged that further computing devices for example 140 and 145 are able to transmit and receive data from computing device 105 through networks 130. It is envisaged that networks 130 include wireless, wire line as well as a combination of wireless and wire line networks. 20 It is envisaged that one or more artefacts for example 150 are maintained on computer-readable media. It is envisaged that these artefacts 150 are stored for example on secondary storage 120, portable memory 125 and/or computer-readable media interfaced to one or more further computing devices 140, 145. Artefacts are further described below. 25 System 100 further includes an item database 160. Item database 160 is shown as being stored on secondary storage 120. It is envisaged that item database 160 or at least part of item database 160 could additionally or alternatively be located on portable memory 125 and/or memory interfaced to further computing devices 140 and 145. 30 Figure 2 shows preferred form electronic artefacts that are linked by the techniques described below. 14PA)n4D)- I 5 Business requirements 205 include for example a vision document, a glossary document and a UseCase list. Business requirements are associated with business process specifications 210 and software 5 specifications 215. Business process specifications include swim-Iane models and one or more electronic documents described as BUC(s), BPRS and others. Software specification electronic artefacts 215 include one or mote UseCase descriptions, one or more SRS requirements, one or more strategy and STP documents and one or more IRS(s) 10 interfaces/UI/reports. Software specification 215 further includes logical models, HLD, RFC and applicable standards. Further types of artefacts that are linked to business process specifications 210 and software specifications 215 include end user material 220, test sets 225 and development sets 230. 15 End user materials 220 include one or more user manuals documents and one or more training material and evaluation records documents as well as procedural input notes. Test sets 225 include STD documents and STR documents as well as one or more test 20 suite/scripts documents and test data documents. Test sets 225 further includes test execution/results. Development set 230 includes one or more SAD(s)/IDD(s) documents, data migration documents and installation and release notes (RFR) documents. Development set 230 further 25 includes physical models, code and unit tests, and operation notes documents. Electronic artefacts further include management documents 235. These management documents include right sizing tool/plan documents as well as DAR records, review records, metrics records, sizing and estimation records, incidents records and T-notes records. Management 235 30 further includes configuration management (code and test). 145 i149-1 6 Method Definitions An item is any item that needs tracing. Items that need tracing are statements of condition or capability such as change requests, assumption/constraints, to be resolved aspects, requirements 5 and so on. All items are identified by a unique identification referred to as an item identifier. An item identifier comprises an Item type, a Separator and a unique whole number. In one preferred embodiment the item type is selected as a character string that is indicative to a human reader of the item type. The length of the character string is 2, 3 or 4 characters. The full 10 set of the item types is configured by the user. Item type is a character string that contains characters in the range A-Z and a-z. For example a change request may be represented by the item type "CR". An item type of assumption/constraint may include an item type of "AC". An item of the type "to be resolved" 15 includes the item type "TBR". Furthermore, items that represent software requirement, business requirement and validation rule include item types of "SR", "BR" and "VR" respectively. Item identifier further includes a separator. The separator is preferably a single character that is not an alphabet character in the range A-Z, a-z and is not a digit in the range 0-9. The" " 20 character is a preferred form of separator but it is envisaged that the particular character selected can be changed by the user, as long as this character is not an A-Z, a-z, digit 0-9 or character in use as Tag deliniter. The purpose of the separator is to enable the software to search for a unique distinct pattern in the Artefacts. 25 Item identifier further includes a unique whole number. The whole number can be any number from I to N, so long as it is unique in combination with the associated Item Type. Examples of item identifiers include: 30 CR_6 (change request) AC_5 (assumption/constraint) TBR1 6 (to be resolved) SR-12 (software requirement) BR_18 (business requirement) 7 VR_25 (validation rule). It is envisaged that individual item identifiers are maintained in item database 160. In one form, system 100 generates new item identifiers at a user request that are unique within the item 5 database 160. In another form the user defines new item identifiers and these are checked for uniqueness against item identifiers already stored in item database 160. Associated data such as description text and attributes are also stored in item database 160. This data is entered and maintained by the user. The item database 160 holds a definitive list of all 10 item identifiers that exist in any of the artefacts. As described above the item database 160 is also used for completeness checking. Figure 3 shows an example item database. In this figure the database shows the definitive text making up the statement of condition or capability for each of the captured Item Identifiers. The 15 figure depicts how the statement of condition or capability for each item identifier is maintained in the item database. The item database may also record attributes, values and labels for each item identifier. Items are categorised as either derived, allocated or implicit. Derived items originate from or are 20 present in a body of text. Allocated items are allocated to a test statement, design, code file fragment and so on. Implicit items are typically implicitly linked to other items. Tags are created by encapsulating item identifiers within a pair of tag delimiters. Tag delimiters are selected so that one type of tag delimiter indicates that the encapsulated item is derived. 25 Another type of tag delimiter indicates that the item is allocated and a further type of tag delimiter indicates that the item is implicit. The pair of tag delimiters include a delimiter start character and a delimiter end character. The delimiter start and delimiter end characters are different to each other. Suitable tag delimiter pairs 30 include: 0 t4A"1049-1 DS The tag delimiter pairs could include any other combination as long as the characters are not one 5 of A-Z, a-z, 0-9 or the selected separator, e.g. underscore"_". In one preferred form "{}" represents a derived item, "B" represents an allocated item and " t " indicates an implicit item. 10 It is expected that the delimiter start and delimiter end characters are selected from a set of symbols that does not include alpha numeric characters- The main requirement is that the delimiter pairs yield a unique search criteria. Any selection of characters is suitable as long as there is a unique start delimiter and unique end delimiter of single character tokens that can be searched. 15 The tag formed from the item identifier encapsulated by the tag delimiter pair is then inserted into a first electronic artefact and a second electronic artefact. The tags that comprise an encapsulated item identifier are inserted manually by the user into any of the artefacts that are tracked by the system. The location where the tag is inserted typically signifies the end of the 20 content to which the tag is applicable. The location within an arrefact only has meaning to the user not to the system. All the system does in one prepared form is to track that there are tags in the artefacts, and in another form that the Item Identifiers embedded in the Tag match the Item Identifiers recorded in the Item database. 25 Method definition examples Figure 4 shows how items are marked within individual artefacts using tags made up of item identifiers encapsulated by tag delimiters. 30 The artefact "UC List" provides an example of software requirements being derived. In this example, from this text two software requirements can be derived, which are shown as {SR_55} and {SR_58} at the end of the description they apply to. 11& 4')4- 1 9 The precise text of the statement of condition or capability for each of these items SR_55 and SR 58 is captured in the Item Database. An example of such text for say Item SR_58 could read: "The system shall calculate GST for all non-GST exempt goods, at the rate configured in the system.". 5 The Item (software requirement) SR.58 is then allocated in the artefacts "Test Cases 1" and SAD (software architecture document) and, in accordance with the tag definition, are shown as [SR_58]. 10 Similarly when the code and actual test script artefacts are created, the User will indicate that these artefacts implement Item SR_58, by marking the point at which the test or the code has fully tested or implemented the GST calculation, using the Tag notation [SR_58]. Finally, an example of implicit linking can be found in the artefact "IRS", where the Item 15 identifier UC1 is shown in the implicit tag notation (UC_1). The items VR_6 and VRJ2 are derived {) from the specification following (UC_1) and the software will thus recognise these items as being implicitly linked to UC_1. Metbod use 20 Due to the unique character pattern of each tag, the system is able to search any electronic artefact or file for the occurrence of such tags. Each electronic artefact or file is treated as a sequence of bytes. Knowledge of individual file structures is not required. The search engine establishes a list of tags that each electronic artefact contains- The frequency of occurrences of 25 derived, allocated and implicit tags is preferably also maintained. Using the above function, the system can determine whether links are complete. For example, using the tags recorded in item database 160 and the artefact type, the system can determine if all items or tags in the item database 160 are derived at least once in the collection of artefacts 30 making up a specification set of artefacts. If not all items are derived then a report can be generated showing which items are missing. %4i47-l 10 The system further ensures that the items in the item database 160 are complete. This is performed by comparing the items in the item database 160 to the unique set of derived and allocated item identifiers found in all artefacts. 5 All derived items that must exist as a result of the above checking can be checked to see that they have been allocated at least once in any one of the artefacts. If not all derived items have been allocated then a report can be generated showing which items ate missing as allocated in which artefact type. 10 A check can also be performed to ensure that all allocated items in any of the artefacts have at least been derived once. The above information is useful for early software defect prevention. Items that have been specified (derived) but that do not exist (allocated) in the design will not be coded and will 15 therefore result in defects at the end of the project. Any iterns specified (derived) but that do not exist (allocated) in test designs will not be scripted and therefore will not be tested for, other than by the user at the end of the project which is too late. 20 These defects are preventable using the above techniques and associated software thereby significantly reducing rework. Using the derived and allocated info.trnation it can be proven that the entire set of items specified and signed off by the client is actually delivered both in code and test. 25 The above techniques permit bi-directional traceability between artefacts. If a user being any person in a development team wants to know where a particular requirement originates in the documentation, it is possible to produce the list of files in which this tag occurs with tag delimiters indicating a derived item. 30 If a user wants to know where a requirement is allocated then the tool provides the list of files where this requirement occurs with an allocated notation. 1481W)J L 11 The system permits implicit links. Tag delimiters representing implicit items are recognised and are implicitly linked to all derived or allocated tags that follow this implicit tag until another implicit tag or the end of file is found. The Implicit links found between Items in the Artefacts, are recorded in the Item database. This functionality ensures that the user is able to maintain 5 essential links between tags in the artefacts themselves where it is most visible by adding tags in the artefacts as required. Therefore the above techniques are used to find and track relationships between say UseCases and requirements or identified components and requirements. The above techniques further provide for suspect items. On changing a file the system can work 10 out if any of the tags has been affected by the changes made in that file. The system determines if a tag is suspect on the basis of the number of bytes (Offset) between a tag and the predecessor of a tag or start of file. A further basis for suspect checking is the sum of byte values of all the bytes between a tag and the predecessor of the tag or start of file. By 15 recording the Offset and Checksum for each tag for each scan of a changed artefact, the system can determine which Item Identifier is suspect. Using the tags marked as suspect the system is able to present to the user on display 110 the files where each of these tags occur. Using the tag the system can find for the user any of the derived 20 allocated or implicit occurrences in any of the files (artefacts) where the tag occurs. The user is able to use the suspect item checking feature to assess impacts of changes. If for example a code file has changed, the system will find which tags have become suspect. For each tag occurrence the system finds for the user where else this tag occurs as derived, allocated or 25 implicit. This helps the user for example to analyse if the code was changed in accordance to the specification (derived) and which tests should be rerun (allocated to test scripts). The above techniques provide a unique "wrapper" around a requirement identifier whereby it is possible to find where in the artefact set a requirement originates/is derived and where it is 30 allocated. The above techniques have the potential to provide a facility to establish the completeness of the requirements. Furthermore the system aUows a user to find in which artefacts an item is derived or allocated. The system allows the user to establish implicit relationships between requirements. For suspect tags the user is able to find where they occur as derived, allocated or implicit. 14ROf149-1 12 The foregoing describes the invention including preferred forms thereof. Modifications and improvements as would be obvious to those skilled in the art are intended to be incorporated in the scope hereof as defined in the accompanying claims. 5