Today we are going to understand how to manage technical requirements in the contract acquisition process. This process includes the analysis of the tender, the quotation of the technical and economic offer and the treatment of all contractual and legal implications.
Let’s start from the definition of tender! Tenders are documents developed by a company or institution containing a large quantity of technical, legal, managerial information about a required product/system/service and are used for inviting potential suppliers to submit their offers.
For supplier companies, extracting technical and design information from this kind of documents is not a trivial task. In fact, the technical documentation attached to tenders is typically huge in size and complexity. For large engineering systems it may easily exceed 10,000 technical requirements, not necessarily organized in a clear and unambiguous way, or drafted following international standards.
These requirements must be extracted and classified by an expert (an activity requiring 20–30 man-days for large tenders), allocated to design subsystems and assigned to the responsible design units within the company. After the allocation of requirements to units, the offer preparation takes place with preliminary technical design activity needed to produce cost, quality, and delivery estimations.
These activities take place under severe time pressure. In fact, the time span between a public request of quotation, with the emission of the “contract terms“ and the bid can be as short as a few weeks, while the design and manufacturing can require several months (usually between 18 and 36, with some cases of even longer time periods). The consequences of winning a bid with a wrong estimation of technical issues, costs, and times, reflect on the engineering phase and later on the entire lifecycle of the system. Requirement analysis is critical to the success of the development of all products, especially in case of big projects.
For these reasons, there is the clear need of a tool able to automatically analyze technical documentation for supporting human expert in the hard task of tender analysis! This implies two categories of challenges. The first is common to the processing of all documents written in natural language. In fact, natural language is complex and ambiguous, and it should be processed by machines that “speak” through artificial, simpler, highly predictable, unambiguous languages. The second issue is related to technical nature of tenders, characterized by a specific technical jargon and by the presence of normative references to be applied.
To reach our goal, we build a software module for the identification and splitting of candidate requirements through syntactic and morphological rules. These rules are based on the expert knowledge we have about tenders’ typical structure.
The software application detects:
- if each string of the tender text is a requirement
- to which subsystem assigning each requirement to be processed by the most suitable functional subsystem of the company.
For these two tasks each requirement is compared with a Knowledge Base of systems, subsystems, components, etc., built using linguistic tools for domain terminology extraction and classification. Examples of keywords belonging to the Knowledge Base are those in red in Figure 1.
Figure 1 – Examples of keywords identification: the keywords of the Knowledge Base are in red, the non-relevant words are in violet.
Finally, using a tailored function it is possible to compare each candidate requirement and to assess both its completeness and the reliability of the assignment to the correct system/subsystem.
To validate the entire process AnsaldoBreda S.p.A. (now Hitachi Rail Europe) choses as a test bed the terms of contract related to the tender for a high-speed train. The entire document was 245 pages long, contained 97,320 words and had a size of 1.27 MB. In 2 min and 12 sec the software application extracted 8269 strings of text: 6169 of them have been identified as technical requirements. All of them have been assigned to the subsystems of the company.
The tool usability is one of the most relevant aspects: a simple graphical interface that allows the use of the tool without accessing the operating system of the company has been designed. The tool gives as output a RIF file that stores the extracted information allowing the human expert an easy verification, correction and management of the information extracted by the system.
Figure 2 – Sample of graphical interface of the tool.
In the extract of Figure 2 you can see in the first column the strings of the tender, in the second column if in the string there is a standard or not, in third column if the string is classified as a requirement or not, in the fourth one a score of completeness of the requirement from 0 to 1, in the fifth one the subsystem(s) to which the requirement processing should be allocated and in the last one a score of reliability of this allocation from 0 to 100.
Moreover, the tool gives as output the enriched tagged tender text. It focuses on readability, a clear separation of requirements, visual tag on significance score, the text highlights keywords and key-phrases, norms, etc. Subsystem assignation is present in the comments field.
To test the reliability of the software, three different validations have been carried out:
- for standards identification, the precision and the recall are both 98%;
- for technical requirements identification, the tool correctly identifies them, associating them with a higher value as their content becomes more specific. It also allows to focus attention on requirements with low scores, which may contain important information for design purposes;
- for requirements assignment to subsystems, verifying the three most probable assignment options of the tool, the percentage of reliability reaches 84%.
The tool allows a significant reduction of the time needed to read the text of a tender and to decompose it into the requirements in the first stage of preparation. Moreover, since each requirement is immediately assigned to the three most likely subsystems and associated to a score that defines its completeness and non-ambiguity, the reading process of the human expert is more effective and can focus on details.
Now…we leave the floor to you! What are the opportunities for applying the developed methodology to different systems? Are there some interesting applications that come to your mind? Do you have any suggestion to improve the tool?
We are waiting for your comments!!! b4ds.unipi@gmail.com
By Elena Coli e Giovanni Puccetti
Commenti recenti