BRPI1100224A2 - sistema para identificação de similaridade textual, sistema de análise de organização e meio legìvel por computador - Google Patents

Abstract

SISTEMA PARA IDENTIFICAçãO DE SIMILARlDADE TEXTUAL, SISTEMA DE ANáLISE DE ORGANIZAçãO E MEIO LEGìVEL POR COMPUTADOR. A presente invenção refere-se a um sistema de análise textual (100) que é configurado para comparar o conteúdo textual de declarações textuais. O sistema de análise textual (100) é configurado para pontuar o conteúdo textual de uma primeira declaração textual e uma segunda declaração textual. Com base na pontuação, o sistema de análise textual (100) pode determinar um nível de correspondência entre a primeira declaração textual e a segunda declaração textual. O sistema de análise textual é configurado para gerar uma representação visual (126) interativa dos níveis de correspondência entre a primeira declaração e a segunda declaração. A representação visual (126) pode ser transmitida para uma tela (128).

Description

Relatório Descritivo da Patente de Invenção para "SISTEMA PARA IDENTIFICAÇÃO DE SIMILARIDADE TEXTUAL, SISTEMA DE A- NÁLISE DE ORGANIZAÇÃO E MEIO LEGÍVEL POR COMPUTADOR".

REIVINDICAÇÃO DE PRIORIDADE Este pedido reivindica prioridade ao pedido de patente provisório

indiano número 435/CHE/2010, depositado em 19 de fevereiro de 2010, a totalidade deste encontra-se incorporada a título de referência no presente documento. CAMPO TÉCNICO

A presente invenção refere-se a um sistema para identificação

de relação de linguagem e, mais particularmente, a um sistema configurado para identificar relações textuais baseadas em comparações verbais e de substantivos. ANTECEDENTES

As organizações tipicamente se esforçam para se tornar mais e-

ficientes na operação independente do domínio da organização. As organi- zações tipicamente implementam diversos sistemas, tais como, sistemas de software, na realização de operações particulares. Tipicamente, estes siste- mas são inicialmente projetados com base em documentos que descrevem a operação dos sistemas. Estes documentos podem incluir listas de requisitos que a organização deseja, a fim de realizar o sistema conforme pretendido. Entretanto, a organização pode procurar aperfeiçoar os diversos sistemas com base em modelos pré-configurados que descrevem a operação de sis- temas similares. Entretanto, a organização pode ter dificuldade para deter- minar como os modelos pré-configurados se referem aos requisitos de sis- tema atuais da organização devido a diferenças de linguagem. SUMÁRIO

De acordo com um aspecto da descrição, um módulo de análise textual pode comparar declarações textuais para determinar se existe cor- respondência entre as declarações. Em um exemplo, o sistema de análise textual pode determinar a correspondência entre duas declarações com ba- se no conteúdo textual das declarações. A correspondência determinada pode indicar que as duas declarações são similares em intenção ou sentido. O conteúdo textual pode se relacionar às relações verbo-substantivo em ca- da uma das declarações. O sistema de análise textual pode determinar a correspondência com base em um sistema de pontuar. O sistema de análise textual pode analisar diversos aspectos do conteúdo textual das declara- ções, tais como, aspectos sintáticos e semânticos.

Com base nesta análise, uma pontuação pode ser gerada para cada comparação de declaração. Com base na magnitude da pontuação, o sistema de análise textual pode identificar as declarações como correspon- dentes.

O sistema de análise textual pode ser aplicado para analisar as capacidades organizacionais desejadas expressas como declarações de texto com requisitos de sistema atualmente implementados de uma organi- zação. Através do sistema de pontuação, o sistema de análise textual pode indicar quais requisitos de sistema da organização correspondem às capaci- dades desejadas e quais requisitos de sistema falham em ter uma capacida- de correspondente. O sistema de análise textual pode gerar um requisito com base na capacidade desejada. O requisito gerado pode ser armazenado para uso subsequente. De acordo com outro aspecto da descrição, o sistema de análise

textual pode gerar uma representação visual da correspondência determina- da entre as declarações. O sistema de análise textual pode recuperar múlti- plos documentos e cada documento pode conter inúmeras declarações. O sistema de análise textual pode gerar uma apresentação visual para exibir que lista as diversas declarações e a correspondência entre as declarações em relação aos documentos separados. A apresentação visual pode ser im- plementada para identificar correspondência entre capacidades organizacio- nais desejadas e requisitos de sistema atuais. A apresentação visual pode permitir a identificação de requisitos redundantes ou supérfluos ou pode permitir reconhecimento de requisitos que podem requerer geração para in- corporar uma ou mais capacidades particulares.

De acordo com outro aspecto da descrição, o sistema de análise 3/27

textual pode determinar inter-relações entre capacidades organizacionais. O sistema de análise textual pode identificar capacidades e processos organi- zacionais associados à realização de uma ou mais capacidades organiza- cionais particulares. O sistema de análise textual pode identificar capacida- des e processos organizacionais que não têm requisitos de sistema corres- pondentes quando capacidades organizacionais particulares têm requisitos de sistema correspondentes.

De acordo com outro aspecto da descrição, o sistema de análise textual pode identificar subsistemas associados aos sistemas gerais descri- tos expressos como capacidades organizacionais. A análise textual pode identificar requisitos de sistema correspondentes associados aos subsiste- mas e pode atualizar os requisitos de sistema para descrever os subsiste- mas.

Os objetivos e vantagens adicionais da presente invenção serão aparentes a partir descrição a seguir, referência sendo feita aos desenhos anexos em que as modalidades preferidas da presente invenção são clara- mente mostradas.

BREVE DESCRIÇÃO DOS DESENHOS

A inovação pode ser mais bem entendida com referência aos desenhos e descrição a seguir. Os componentes nas figuras não estão ne- cessariamente em escala, a ênfase em vez disso se situa na ilustração dos princípios da invenção. Além disso, nas figuras, as referências numéricas similares designam partes correspondentes ao longo das diferentes vistas.

A figura 1 é um diagrama em bloco de um módulo de análise textual exemplificativo executável em um dispositivo de computador.

A figura 2 é um exemplo de uma representação visual gerada pelo módulo de análise textual da figura 1.

A figura 3 é outro diagrama em bloco do módulo de análise tex- tual da figura 1.

A figura 4 é outro diagrama em bloco do módulo de análise tex- tual da figura 1.

A figura 5 é outro diagrama em bloco do módulo de análise tex- tual da figura 1.

A figura 6 é outro exemplo de uma representação visual gerada pelo módulo de análise textual da figura 1.

A figura 7 é outro exemplo de uma representação visual gerada 5 pelo módulo de análise textual da figura 1.

A figura 8 é um fluxograma operacional exemplificativo para im- plementar o módulo de análise textual da figura 1.

A figura 9 é um fluxograma operacional exemplificativo para im- plementar o módulo de análise textual da figura 1. 10 A figura 10 é um exemplo de um modelo de capacidade.

A figura 11 é um exemplo de um gráfico semântico que repre- senta uma porção do modelo de capacidade exemplificativo da figura 10.

A figura 12 é um diagrama em bloco de outro exemplo do módu- lo de análise textual da figura 1. 15 A figura 13 é um diagrama em bloco de outro exemplo do módu-

lo de análise textual da figura 1. DESCRIÇÃO DETALHADA

As organizações são tipicamente estruturadas para realizar di- versas tarefas a fim de operar de uma maneira desejada. As organizações 20 de diversos domínios, tais como bancário, comércio eletrônico, telecomuni- cações, etc., podem ter maneiras específicas de domínio de realizar estas tarefas. As organizações podem requerer estruturação e organização destas tarefas de uma maneira particular, a fim de realizar as tarefas. Por exemplo, uma instituição bancária pode ter uma rotina ou processo particular para rea- 25 Iizar uma tarefa, tal como, manipular um depósito eletrônico a partir de um cliente. Quando desenvolver a rotina ou processo particular para realizar uma tarefa particular, uma organização pode implementar um conjunto de requisitos a ser atendido. Um requisito pode ser algum evento ativo ou pas- sivo associado a um sistema de uma organização que a organização pode 30 desejar que ocorra, a fim de completar uma tarefa relacionada. Requisitos podem ser incorporados por declarações de requisito. Cada declaração de requisito pode ser uma declaração textual que descreve um aspecto deseja- do do sistema associado. Diversos aplicativos tais como aplicativos de soft- ware podem ser projetados através de declarações de requisitos. A forma textual de declarações de requisito pode ser restringida por formato particu- lar para propósitos de conformidade.

5 As organizações podem desejar efetuar rotinas e processos in-

ternos mais eficientes ao comparar rotinas de processos internos a modelos de capacidade predeterminados. Um modelo de capacidade (ou modelo de processo) pode ser definido como um modelo que contém uma ou mais ca- pacidades e/ou processos para realizar um ou mais aspectos particulares 10 que têm uma semelhança. Cada capacidade pode definir alguma habilidade que tem a capacidade para aprimoramento. Uma organização estabelecida pode usar um modelo de capacidade particular como um padrão de compa- ração com suas próprias rotinas e processos internos a fim de se parecer mais rigorosamente com o modelo de capacidade particular. Uma organiza- 15 ção pode usar declarações de requisito que incorporam as rotinas e proces- sos para realizar tal comparação.

A figura 1 é um diagrama em bloco de um sistema de análise textual ("TAS") 100. Na figura 1, o TAS 100 pode ser executado em um dis- positivo de computador 102. Em um exemplo, o TAS 100 pode incluir um ou 20 mais módulos executáveis por um processador 104 do dispositivo de compu- tador 102. O TAS 100 pode ser um ou mais módulos de software que podem ser armazenados em um dispositivo de memória, tal como a memória 106 do dispositivo de computador 102. Conforme descrito no presente documento, os módulos são definidos para incluir software, hardware ou alguma combi- 25 nação dos mesmos executável pelo processador 104. Os módulos de soft- ware podem incluir instruções armazenadas na memória 106, ou outro dis- positivo de memória, que são executáveis pelo processador 104 ou outros processadores. Os módulos de hardware podem incluir diversos dispositivos, componentes, circuitos, portas, placas de circuito e similares que são execu- 30 táveis, direcionados e/ou controlados para desempenho pelo processador 104. A memória 106 pode incluir uma ou mais memórias e pode ser meios de armazenamento ou memórias legíveis por computador, tais como, cache, buffer, RAM, meios removíveis, disco rígido ou outros meios de armazena- mento legíveis por computador. Meios de armazenamento legíveis por com- putador podem incluir diversos tipos de meios de armazenamento voláteis e não voláteis. Diversas técnicas de processamento podem ser implementa- 5 das pelo processador 104, tais como, multiprocessamento, multitarefa, pro- cessamento paralelo, e similares, por exemplo. O processador 104 pode in- cluir um ou mais processadores.

Em um exemplo, o TAS 100 pode ter acesso a um ou mais ban- co de dados que armazenam informações que se referem às listas de requi- 10 sito e modelos de capacidade. Em um exemplo, um banco de dados 108 pode armazenar um conjunto de dados de modelo de capacidade 110. O conjunto de dados de modelo de capacidade 110 pode incluir uma pluralida- de de modelos de capacidade 112 individualmente designados como CMx, em que "X" é o índice de um modelo de capacidade particular CM1 a CMa, 15 em que "A" é o número de modelos de capacidade. Cada modelo de capaci- dade 112 pode incluir uma ou mais capacidades. Em um exemplo, cada mo- delo de capacidade 112 pode ser um ou mais documentos eletrônicos que descrevem diversos aspectos do modelo de capacidade. Cada capacidade pode ser expressa como uma declaração textual em um documento eletrôni- 20 co.

Um banco de dados 114 pode armazenar um conjunto de dados de requisitos 116. O conjunto de dados de requisitos 116 pode incluir uma pluralidade de listas de requisito 118. Cada lista de requisito 118 é individu- almente designada como RLY, em que "Y" é o índice de uma lista de requisi- 25 to particular 118 RLi a RLb, em que "B" é o número de listas de requisito 118. Cada lista de requisito 118 pode incluir um ou mais requisitos ("R"). Em um exemplo, cada lista de requisito 118 pode ser um ou mais documentos eletrônicos que descreve diversos aspectos de um sistema. Cada requisito na lista de requisito 118 pode ser expresso como uma declaração textual em 30 um documento eletrônico.

Durante a operação, o TAS 100 pode mapear automaticamente um modelo de capacidade particular em uma lista de requisito particular. O mapeamento do modelo de capacidade particular 112 na lista de requisito particular 118 pode indicar capacidades do modelo de capacidade particular 112 que têm um ou mais requisitos correspondentes da lista de requisito par- ticular 118. Deste modo, o mapeamento pode identificar requisitos na lista de 5 requisito 118 que podem endereçar as capacidades correspondentes no modelo de capacidade 112. O TAS 100 pode receber entrada(s) relaciona- das ao modelo de capacidade particular 112 e à lista de requisito particular 118. Por exemplo, o TAS 100 pode receber entrada(s) de usuário através de uma interface gráfica de usuário (GUI) 120. A GUI 120 pode incluir diversos 10 dispositivos, tais como, uma tela, teclado(s), mouse, microfone, e qualquer outro dispositivo adequado que permite uma interação de usuário com o TAS 100. A GUI 120 pode ser remotamente conectada ao TAS 100, tal co- mo, através de uma conexão de Internet, Rede Privada Virtual, rede direta, ou qualquer outra implementação de rede adequada. Em outros exemplos, a 15 GUI 120 pode ser diretamente conectada ao dispositivo de computador 102, tal como, em uma configuração de computador pessoal. O TAS 100 pode receber uma entrada 122 da GUI 120. A entrada 122 pode incluir uma sele- ção baseada em usuário de um modelo de capacidade CMx do conjunto de dados de modelo de capacidade 110. Mediante o recebimento da entrada 20 122, o TAS 100 pode recuperar o modelo de capacidade CMx do conjunto de dados de modelo de capacidade 110. De maneira similar, o TAS 100 po- de receber uma entrada 124 que inclui uma seleção baseada em usuário de uma lista de requisito RLY. Mediante o recebimento da entrada 124, o TAS 100 pode recuperar a lista de requisito RLy do conjunto de dados de lista de 25 requisito 116.

Mediante o recebimento do modelo de capacidade CMx e da lis- ta de requisito RSY, o TAS 100 pode mapear cada capacidade do modelo de capacidade CMx em um ou mais requisitos correspondentes na lista de re- quisitos RSy com base em uma comparação (figura 3) de uma ou mais de- 30 clarações textuais que expressam cada respectiva capacidade e requisito. A correspondência pode ser considerada existente quando o conteúdo textual de um requisito inclui um ou mais aspectos similares com relação ao conte- údo textual de uma capacidade. Deste modo, a correspondência entre uma capacidade e um requisito pode indicar que o requisito descreve um aspecto similar àquele da capacidade.

Em um exemplo, o TAS 100 pode implementar material fonte 5 armazenado na memória 106 ou acessado através de uma conexão 125 pa- ra suportar uma comparação de capacidade-requisito. A conexão 125 pode ser um link para recursos conectados de maneira direta ou indireta, ou pode ser uma conexão de rede, ou conexão de Internet que permite que fontes "online" sejam acessadas. O TAS 100 pode, mediante a conclusão do ma- 10 peamento, gerar uma representação visual 126 do mapeamento. A repre- sentação visual 126 pode ser transmitida para um ou mais telas, tal como, a tela 128. A tela 128 pode ser parte da GUI 120 ou pode ser independente.

A figura 2 é um exemplo da representação visual 126 gerada na tela 128. A representação visual 126 pode ser interativa permitindo que uma 15 entrada recebida a partir da GUI 120 seja implementada para editar a repre- sentação visual 126. Na figura 2, o modelo de capacidade selecionado 110 refere-se a um domínio de organização de comércio eletrônico. Em particu- lar, o modelo de capacidade 110 refere-se ao preenhimento de ordens no comércio eletrônico. A representação visual 126 pode incluir uma listagem 20 de capacidade 200 de inúmeras capacidades e uma listagem de requisito 202 de inúmeros requisitos. As capacidades e requisitos listados podem ser de natureza hierárquica. Em outras palavras, uma capacidade particular po- de ser uma capacidade "pai" de diversas capacidades "filho". De maneira similar, cada requisito pode incluir diversos requisitos filho, pode ser um re- 25 quisito filho, ou ambos. Cada capacidade e requisito listados podem incluir um índice 203 para indicar a associação hierárquica. O índice 203 também pode indicar a organização de cada modelo de capacidade 112 em um gru- po de modelos de capacidade 112.

A representação visual 126 pode permitir interação para expan- 30 dir uma capacidade para mostrar as capacidades filho ou para colapsar as capacidades filho, de modo que elas sejam escondidas. No exemplo da figu- ra 2, um sinal de mais ("+") próximo a uma capacidade ou requisito indica 9/27

que a capacidade ou requisito particular pode ser expandida para mostrar visualmente as capacidades filho e os requisitos filho, respectivamente. Um sinal de menos ("-") indica que a capacidade ou requisito particular pode ser colapsada para esconder visualmente as respectivas capacidades filho e requisitos filho.

Na figura 2, um indicador de nível de correspondência 204 pode ser gerado próximo a cada capacidade e requisito nas respectivas listagens 200, 202. O indicador de nível de correspondência 204 pode indicar um nível de correspondência entre as capacidades e requisitos. Em um exemplo, o indicador de nível de correspondência 204 pode incluir uma caixa que pode ser vazia, incluir uma barra ou incluir um "x". Uma caixa vazia próxima a uma capacidade pode indicar que não existe correspondência com um requisito na listagem de requisito 202. De maneira similar, uma caixa vazia próxima a um requisito pode indicar que não existe correspondência com uma capaci- dade na listagem de capacidade (200). Uma barra ("/") pode indicar algum nível menor do que uma correspondência completa e um "x" indica corres- pondência completa ou direta.

Por exemplo, na figura 2, a capacidade "criar ordem de aquisi- ção" inclui um "x" no indicador de nível de correspondência respectivo 204. Esta capacidade não tem nenhuma capacidade filho e tem pelo menos um requisito de correspondência. Assim, a capacidade possui correspondência total com a lista de requisito. A capacidade "capturar ordem de cliente" tem uma barra T como um indicador de nível de correspondência 204. A subca- pacidade "abrir ordem e iniciar entrada de ordem" tem um sentido "x" que ele tem pelo menos um requisito correspondente e, sem quaisquer capacidades filho a considerar, tem correspondência completa. Assim, uma vez que "abrir ordem e inicar entrada de ordem" é uma capacidade filho da capacidade "capturar ordem de cliente", mas outras capacidades filho de "capturar or- dem de cliente" não possuem requisitos correspondentes, com a capacidade "capturar ordem de cliente", tem alguma correspondência, mas não comple- ta.

Deste modo, a representação visual 126 indica uma correspon- dência bidirecional de capacidades e requisitos. A correspondência bidire- cional permite uma seleção de tanto uma capacidade particular da listagem 200 quanto um requisito particular da listagem 202 a fim de identificar as ca- pacidades ou requisitos de correspondência. Por exemplo, na figura 2, a ca- 5 pacidade "capturar ordem de cliente" foi selecionada conforme indicado pelo indicador de seleção de capacidade 206. O indicador de seleção de capaci- dade 206 pode ser uma caixa que envolve a capacidade selecionada. A se- leção de uma capacidade ou requisito pode ser realizada através de intera- ção de usuário através da GUI 120, tal como através de uma interface de 10 mouse apontar e clicar. Em um exemplo, a seleção de uma capacidade pode também selecionar automaticamente quaisquer capacidades filho, tal como aquela mostrada na figura 2.

Mediante a seleção da capacidade, os requisitos corresponden- tes podem ser selecionados automaticamente ou através de entrada adicio- 15 nal. A seleção dos requisitos é indicada por indicadores de seleção de requi- sito 208. Na figura 2, os indicadores de seleção de requisito 208 são cada um uma caixa que delineia o requisito selecionado. Conforme mostrado na figura 2, a seleção da capacidade "Capturar Ordem de Cliente" permite a seleção de diversos requisitos na listagem de requisitos 202. Dois requisitos 20 que têm correspondência direta são ambos capacidades filho de um requisi- to "Ordenar Requisitos de Entrada". "Ordenar Requisitos de Entrada" é uma capacidade filho de "Ordem para Descontar Requisitos". Ambas estas capa- cidades pai terão algum nível de correspondência conforme indicado pela barra Τ. A seleção de um requisito particular permite a indicação similar de 25 capacidades correspondentes na listagem de capacidade 200. Nas modali- dades alternativas, diversos indicadores de nível de correspondência e indi- cadores de seleção podem ser implementados.

A representação visual 126 pode permitir que diferentes modelos de capacidade 112 sejam carregados enquanto a representação visual 126 30 está sendo exibida. O seletor "Abrir Documento de Modelo de Capacidade" 210 pode ser selecionado e um ou mais conjuntos de dados de modelo de capacidade podem ser navegados para seleção de um modelo de capacida- de particular 112. De maneira similar, o seletor "Abrir Documento de Requisi- to" 212 pode ser um ou mais conjuntos de dados de lista de requisito e pode ser navegado para a seleção de uma listagem de requisitos particular. O se- letor "Gerar Relatório" 214 pode ser selecionado para direcionar o TAS 100 para gerar o mapeamento entre um modelo de capacidade selecionado 112 e uma lista de requisito selecionada 118. A representação visual 126 tam- bém pode incluir informações estatísticas. Na figura 2, as informações esta- tísticas de capacidade 216 podem ser exibidas abaixo da listagem de capa- cidade 200 e as informações estatísticas de requisito 218 podem ser exibi- das abaixo da listagem de requisito 202. As informações estatísticas 216 podem proporcionar informações que se referem ao número de capacidades e requisitos e ao número de capacidades e requisitos correspondentes, por exemplo.

O esboço da representação visual 126, conforme mostrado na figura 2 é de natureza ilustrativa. Diversos esboços podem ser usados além da disposição lado a lado mostrada na figura 2. Por exemplo, a representa- ção visual 126 pode ser configurada para proporcionar uma "disposição de busca detalhada", de modo que a representação visual permita que um ou mais níveis hierárquicos particulares sejam exibidos de uma vez permitindo o movimento entre os níveis. Tais esboços alternativos podem ser oferecidos simultaneamente com aquele mostrado na figura 2 que permite alternar en- tre os esboços durante o uso.

A figura 3 é um diagrama em bloco detalhado de um exemplo do TAS 100. O TAS 100 pode incluir um módulo de mapeamento 300 configu- rado para determinar a correspondência entre um modelo de capacidade selecionado 110 e uma lista de requisitos 116. Em um exemplo, o TAS 100 pode recuperar um conjunto de dados de modelo de capacidade desejado CMx e um conjunto de dados de lista de requisitos RLy conforme descrito em relação à figura 1. O TAS 100 pode usar um sistema de pontuação com ba- se na comparação do conteúdo textual de cada capacidade no modelo de capacidade CMx e cada requisito na lista de requisito RLy. Em um exemplo, o TAS 100 pode comparar cada par exclusivo de uma capacidade a partir do 12/27

conjunto de dados de modelo de capacidade CMx e um requisito R a partir do conjunto de dados de lista de requisito RLY.

O módulo de mapeamento 300 pode incluir um módulo de identi- ficação de verbo-entidade 302. O módulo de identificação de verbo-entidade ("V-E ID") 302 pode ser configurado para identificar um ou mais pares de verbo-entidade em cada capacidade do conjunto de dados de modelo de capacidade CMx e em cada requisito do conjunto de dados de lista de requi- sito RLy- Os pares de verbo-entidade podem se referir a uma relação de verbo-substantivo em uma declaração textual, e o substantivo pode ser con- siderado uma entidade para propósitos de interação com um sistema. A en- tidade pode ser um usuário de sistema ou o próprio sistema, por exemplo. Em um exemplo, o módulo de identificação de verbo-entidade 302 pode usar uma ferramenta de processamento de linguagem natural. As ferramentas de fonte aberto, tal como, uma ferramenta de processamento de linguagem na- tural, podem ser implementadas pelo TAS 100, tal como, OpenNLP, por e- xemplo. O TAS 100 pode acessar ferramentas de fonte aberto através da conexão 125.

O módulo de identificação de verbo-entidade 302 pode gerar conjunto de dados verbo-entidade ("V-E") 304 que inclui cada um dos pares de verbo-entidade identificados para cada capacidade do conjunto de dados de módulo de capacidade CMx e cada requisito do conjunto de dados de lista de requisito RLY. Um módulo de pontuação ("SCR") 306 pode receber o conjunto de dados de verbo-entidade 304. O módulo de pontuação 306 pode calcular uma pontuação com base em uma comparação de cada um dos pares de verbo-entidade com cada par de capacidade-requisito único. Em outros exemplos, o módulo de pontuação 306 pode calcular a pontuação para cada par de capacidade-requisito único que atende a critérios prede- terminados. Em um exemplo, a pontuação compatível para uma comparação de verbo-entidade para cada par de capacidade-requisito exclusivo pode ser determinada por:

(Eqn. 1) Match(R,C)=max(VEPSynMatch(R,C), SemVEPMat- ch(R,C), WM (R,C)), onde a função Match(R1C) pode gerar uma pontuação compatível de uma comparação de verbo-entidade para um par de capaci- dade-requisito. A Eqn. 1 indica que o máximo das três pontuações diferentes pode ser usado para Match(R1C). A função VEPMatch(RjC) pode ser defini- da pela Eqn. 2 como: (Eqn. 2) VEPMatch(R,C)=max(SynVEPMatch(R,C), SemVEP-

Match(RjC)), onde, conforme posteriormente descrito, SynVEPMatch(R1C) é uma função que pode gerar uma pontuação com base em uma compatibili- dade sintática que usa técnicas de compatibilidade de cadeia, assim como, técnicas de lematização de palavras. As técnicas de compatibilidade de ca- deia podem ser referir às cadeias de caracteres compatíveis para determinar a similaridade entre as cadeias. SemVEPMatch(R1C) é uma função que po- de gerar uma pontuação baseada em uma compatibilidade semântica que usa compatibilidade de sinônimo e compatibilidade de relação semântica, conforme posteriormente descrito. Em um exemplo, SynVEPMatch(R1C) po- de ser definida como:

(Eqn. 3) SynVEPMatch(R,C)=

stringCompare(stem(VR),stem(Vc))*stringCompare (stem

(ER),stem (Ec)) em que:

Vr= verbo do requisito; Vc= verbo da capacidade;

Er= entidade do requisito; e

Ec= entidade da capacidade.

A função "stem(w)" pode gerar a base da palavra (verbo, entida- de, ou outro tipo de palavra) identificada através de uma técnica de Iemati- zação particular, tal como, o Algoritmo de Lematização de Porter. Por exem- plo, uma técnica de lematização pode determinar que a palavra "conectada" tem uma base de "conexão". Isto é útil para determinar que "conectar" e "co- nectado" são uma compatibilidade. A função "stringCompare" da Eqn. 3 po- de ser definida como:

(Eqn. 4)stringCompare (w1, w2) = 1 se w 1=w2

0 de outro modo

Deste modo, a função SynVEPMatch(R1C) pode gerar um ("1") ou zero ("0"). Por exemplo, uma comparação dos termos "relatório" e "relato- rio de lucros" pode retornar uma pontuação ("1"), uma vez que a base do "relatório de lucros" pode ser considerada como "relatório". Em outros e- xemplos, outras escalas de pontuação podem ser implementadas, tal como, uma escala deslizante.

5 Referindo-se agora a SemVEPMatch(R1C), a função pode ser

definida como: (Eqn. 5) SemVEPMatch(R, C)= max (lex( VR, Vc), ont(VR, Vc))*

max (lex( Er, Ec), ont(ER, Ec))

em que a função "lex" é definida por:

10<formula>formula see original document page 15</formula>

Para determinar se os verbos ou entidades são sinônimos, o

TAS 100 pode implementar diversos fontes, tais como, léxicos internamente armazenados, ou pode se conectar em locais remotos, tal como, através da Internet. Em um exemplo, os serviços online, tal como, Wordnet podem ser 15 utilizados pelo módulo de mapeamento através da conexão 125. Com base na fonte utilizada, a compatibilidade de sinônimo pode ser pontuada de a- cordo com a Eqn. 6. Em outros exemplos, outros sistemas de pontuação podem ser usados. A diferença entre a pontuação 0,9 e 0,8 pode ser ilustra- da através de um exemplo. O Wordnet pode identificar sinônimos de "criar" 20 como "efetuar" e "produzir" e identificar sinônimos de "desenvolver" como "originar", "gerar" e "produzir". Deste modo, uma comparação do par de ver- bos (criar, produzir) pode gerar uma pontuação de 0,9 de acordo com a Eqn. 6, uma vez que "produzir" é um sinônimo direto de "criar". Entretanto, uma comparação do par de verbos (criar, desenvolver) pode gerar uma pontua- 25 ção de 0,8 de acordo com a Eqn. 6 uma vez que criar e desenvolver não são sinônimos diretos, porém, compartilham pelo menos um sinônimo comum "produzir".

A função "ont" pode gerar uma pontuação baseada em uma compatibilidade semântica entre os pares de verbo-entidade. Tal compatibi- 30 Iidade semântica pode ser implementada usando qualquer forma de ferra- menta usada para combinar significados de termos, tais como: 1) ontologias; .2) um mecanismo de raciocínio de fonte aberto; e/ou 3) linguagem de con- sulta de web semântica. As ontologias podem ser consideradas como uma representação do significado dos termos nos vocabulários e as relações en- tre estes termos. As ontologias podem ser usadas para apresentar os signifi- cados e relações de linguagem, palavra e termo para os aplicativos de com- putador. Os mecanismos de raciocínio de fonte aberto, tal como, Jena, por exemplo, podem proporcionar inferências baseadas em regra entre as pala- vras para proporcionar uma base para as comparações semânticas. Em um exemplo, as ontologias que usam quaisquer fontes de

repositório de documento ou baseadas em conhecimento disponíveis, tal como, a base de conhecimento de intranet de fonte aberto OWL pode ser usada para representar explicitamente o significado de termos em vocabulá- rios e as relações entre estes termos. Esta representação de termos e suas inter-relações é chamada de ontologia.

Em um exemplo, a função "ont" pode ser definida como (Eqn. 7)

<formula>formula see original document page 16</formula> A Eqn. 7 pode indicar um nível de compatibilidade semântica en- tre os termos "w1" e "w2". Em outros exemplos, outras faixas de pontuação ou mecanismos podem ser implementadas para realizar a compatibilidade semântica.

A função "WM(R1C)" da Eqn. 1 pode ser definida como:

(Eqn. 8) WordMatch (R, C)=max(0,7, Eargmaxij relacionado

(wRj, wCj)) em que:

wRj = um conjunto de entidades e verbos extraídos de um requi- sito R;

WCi é um conjunto de entidades e verbos extraídos de a capaci- dade C;

argmax é uma função para determinar o ponto máximo para ca-

ont(w1 ,w2) (Eqn. 9) (w1, w2) relacionado =

da conjunto de "(wRj, wCj) relacionado" e em que: <formula>formula see original document page 17</formula>

A função WM(R1C) pode ser utilizada quando as outras funções de pontuação de MatchScore(RjC) falham para identificar uma compatibili- dade com base nas Eqns. 2-7 entre os pares de verbo-entidade. Deste mo- 5 do, a cada par de verbo-entidade para cada par de capacidade-requisito úni- co pode ser fornecida uma pontuação compatível gerada pelo módulo de pontuação 306. Uma pontuação pode ser gerada para uma única capacida- de quando comparada a cada único requisito. 0 módulo de pontuação 306 pode proporcionar um par de conjunto de dados de capacidade-requisito 10 pontuado ("C-R SCR") 307 para um módulo de detector de limite ("THRE- SH") 308. O detector de limite 308 pode filtrar o conjunto de dados de par de capacidade-requisito pontuado 307 com base em um limite de pontuação predeterminado, tal como, 0,7, por exemplo. Se uma pontuação compatível (MatchScore(R1C)) for maior que o limite predeterminado, o par de capaci- 15 dade-requisito pode ser considerado como uma compatibilidade e um con- junto de dados de pontuação de par de capacidade-requisito filtrado ("FIL C- R SCR") 309 pode ser transmitido pelo detector de limite 308 para um módu- lo de determinação de nível de correspondência ("CLD") 310. O módulo de determinação de nível de correspondência 310 pode receber a lista de capa- 20 cidade CMx e a lista de requisito RLy, e junto com o conjunto de dados pon- tuado de par de capacidade-requisito filtrado 310, determinar os níveis de correspondência baseados nas intra-relações hierárquicas entre as capaci- dades e requisitos. As determinações realizadas pelo módulo de determina- ção de nível de correspondência 310 podem ser usadas para gerar os indi- 25 cadores de nível de correspondência 204. O módulo de determinação de nível de correspondência 309 pode gerar um conjunto de dados mapeamen- to ("MAP") 311 a ser recebido por um gerador de representação visual 312. O conjunto de dados de mapeamento 311 pode incluir a correspondência determinada entre cada capacidade e requisito. O gerador de representação 30 visual 312 pode gerar a representação visual 126 conforme descrito em rela- ção à figura 1 que usa o conjunto de dados de mapeamento 311 para gerar a indicação visual da correspondência de capacidade-requisito onde apro- priado.

Mediante a conclusão do mapeamento realizado pelo TAS 100, 5 a representação visual 126 pode ser editada por diversas razões. Em um exemplo, o mapeamento realizado pelo TAS 100 pode indicar que múltiplos requisitos correspondem à mesma capacidade. Tais instâncias podem indi- car que alguns requisitos podem ser eliminados devido à redundância se um ou mais outros requisitos puderem cobrir uma capacidade particular. Em tais 10 instâncias, conforme mostrado na figura 4, o TAS 100 pode incluir um módu- lo de edição 313 para receber uma entrada baseada em usuário 400 para editar a representação visual 126. Em outros exemplos, uma entrada 400 pode ser automaticamente gerada com base nos critérios predeterminados. A entrada 400 pode incluir um requisito Rz a ser eliminado da listagem de 15 requisitos. A entrada 400 pode ser recebida pelo módulo de edição 313 a partir da GUI 120 ou outra interface conectada. O módulo de edição 313 po- de processar a entrada 400 e gerar um conjunto de dados de informação de edição ("EDIT INFO") 402. O conjunto de dados de informação de edição 402 pode ser transmitido pelo módulo de edição 313 para a tela 128. O ge- 20 rador de representação visual 312 pode receber o conjunto de dados de in- formação de edição 402 e gerar uma apresentação visual atualizada ("UVR") 404 para transmitir para a tela 128. Em um exemplo, o módulo de edição 313 pode avisar um usuário para indicar a permanência da edição. Por e- xemplo, os requisitos para remoção podem ser permanentemente removidos 25 do conjunto de dados de lista de requisitos 116 ou podem ser armazenados separadamente.

A operação do TAS 100 pode ser aplicada a diversos dados tex- tuais para identificar relações textuais. Por exemplo, duas listas de declara- ções textuais podem ser comparadas usando o TAS 100 e o TAS 100 pode 30 identificar as relações de conteúdo textual entre as duas listas, tal como na maneira descrita. A representação visual 126 pode indicar que declarações textuais comparadas entre as duas listas contém conteúdo similar à exten- são em que cada declaração textual pode conter pelo menos um par de ver- bo-entidade conforme previamente descrito. Em outros exemplos, o TAS 100 pode determinar outros tipos de relações textuais.

O TAS 100 também pode incluir um gerador de requisitos ("REQ GEN") módulo 314. O módulo gerador de requisitos 314 pode gerar um re- quisito a ser incluído em uma lista de requisito particular RLy baseada em uma capacidade a partir de um modelo de capacidade particular CMx. Por exemplo, a apresentação visual 126 pode indicar que uma capacidade parti- cular na listagem de capacidade 200 não tem requisito correspondente. O módulo gerador de requisitos 314 pode receber uma entrada baseada em usuário indicativa da seleção de uma capacidade particular. Conforme mos- trado na figura 5, o módulo gerador de requisito 314 pode receber uma en- trada 500 que inclui uma seleção de capacidade do modelo de capacidade atualmente exibido CMx que indica uma capacidade selecionada "C" a partir da listagem de capacidade 200. A figura 6 mostra uma capacidade selecio- nada a partir da listagem de capacidade 200 a partir da figura 2. Na figura 6, a seleção de uma capacidade particular gera um indicador de seleção 600 que solicita que a entrada determine um requisito a ser gerado.

Se o requisito está para ser gerado, o módulo gerador de requi- sito 314 pode extrair um par de verbo-entidade da capacidade selecionada de uma maneira, tal como aquela descrita em relação à figura 3. O módulo gerador de requisito 314 pode gerar um requisito que inclui o par de verbo- entidade extraído. Em outro exemplo, o gerador de requisito 314 pode adi- cionar um prefixo selecionado para a capacidade selecionada. O módulo gerador de requisitos 314 pode gerar uma solicitação de prefixo ("PR") 502 para pedir a um usuário que determine um prefixo preferido para o requisito. Em um exemplo, uma opção de prefixo de requisito pode ser "o sistema de- ve proporcionar suporte para" ou "o sistema deve permitir o usuário "depen- dendo de como o requisito deve ser manipulado. Em exemplos alternativos, as escolhas de prefixo podem ser expandidas para incluir outros aspectos desejados de um sistema coberto pela listagem de requisito 202. Outros e- xemplos podem incluir a geração automática de requisitos através do módu- Io de geração de requisito 314 que corresponde às capacidades que não têm inicialmente requisitos correspondentes. Outros exemplos também po- dem incluir um requisito criado por usuário.

Mediante o recebimento do prefixo desejado, o módulo gerador de requisito 502 pode gerar um novo requisito Rnew. O novo requisito Rnew pode ser transmitido para o gerador de representação visual 312. O gerador de representação visual 312 pode gerar uma representação visual atualizada ("UVR") 504 e transmitir a mesma para a tela 128 para exibição. O gerador de requisito 314 também pode atualizar a lista de requisito 118 com o nono requisito Rnew.

No exemplo da figura 6, a capacidade de "Verificar Crédito de Cliente" é escolhida para a geração de requisito. Mediante a execução, o gerador de requisito 314 pode gerar a solicitação de prefixo 502. Mediante o recebimento de uma resposta para a solicitação de prefixo, o gerador de re- quisito 314 pode gerar o requisito. "O sistema deve proporcionar suporte para Verificar Crédito de Cliente". O requisito pode ser colocado no fundo da listagem de requisito 202. Em outros exemplos, o requisito pode ser automa- ticamente posicionado em um local diferente daquele mostrado na figura 7. O requisito também pode ser posicionado por um usuário em um local dese- jado dentro da listagem de requisito 202. A figura 7 mostra a listagem de re- quisito atualizada 202 com o requisito recentemente criado 702.

As figuras 8 e 9 mostram um fluxograma operacional exemplifi- cativo para o TAS 100. O TAS 100 pode receber a entrada partir da GUI 120 ou outro dispositivo de entrada conectado (bloco 800). A entrada pode ser representativa de um ou mais modelos de capacidade desejados 112 e uma ou mais listas de requisito desejadas 118. O TAS 100 pode recuperar a lista de requisito RLy a partir da lista de requisito 118 (bloco 802). O TAS 100 po- de recuperar o conjunto de dados de modelo de capacidade CMx (bloco .804). O TAS 100 pode selecionar um primeiro par de capacidade-requisito, ou par de declaração, que usa o módulo de identificação de verbo-entidade .302 (bloco 806) que inclui uma única capacidade e um único requisito. O módulo de identificação de verbo-entidade 302 pode identificar pares de ver- bo-entidade no primeiro par de capacidade-requisito (bloco 808). O módulo de pontuação 306 pode gerar uma pontuação baseada em um nível de simi- laridade de par de verbo-entidade para o primeiro par de capacidade- requisito (bloco 810). A pontuação pode ser realizada de uma maneira des- 5 crita em relação à figura 3. As pontuações geradas podem ser armazenadas para uso subsequente (bloco 812).

Após o armazenamento das pontuações, o TAS 100 pode de- terminar se todas as pontuações de capacidade-requisito foram geradas (bloco 814). Se as pontuações não foram geradas para todas as combina- 10 ções de capacidade-requisito exclusivas, o próximo par de capacidade- requisito pode ser selecionado (bloco 815). A pontuação pode ser realizada para cada combinação de capacidade-requisito exclusiva de uma única ca- pacidade e um único requisito. Mediante a conclusão da pontuação de todos os pares de capacidade-requisito, o TAS 100 pode filtrar as pontuações ba- 15 seadas no limite de pontuação predeterminado (bloco 816). Com base nas pontuações filtradas, o modelo de capacidade selecionado e a lista de requi- sitos selecionada, o nível particular de correspondência ou nível de similari- dade entre as capacidades e requisitos pode ser determinado (bloco 817). O TAS 100 pode gerar a representação visual 126 (bloco 818) com base no 20 nível determinado de correspondência entre o modelo de capacidade sele- cionado e a lista de requisito. A representação visual 126 pode ser transmiti- da para uma tela, tal como, a tela 128 (bloco 820).

O TAS 100 pode determinar se qualquer entrada de usuário vol- tada para a edição da apresentação visual foi recebida (bloco 822). Se ne- 25 nhuma entrada tiver sido recebida, o TAS 100 pode terminar a operação ou pode permanecer em um estado pausado até o recebimento de entrada adi- cional. Se a edição for desejada, conforme mostrado na figura 9, a informa- ção de edição pode ser recebida pelo TAS 100 (bloco 900). Mediante o re- cebimento da informação, o TAS 100 pode determinar se a informação é 30 relacionada à geração de um novo requisito (bloco 902). Se a informação for relacionada à geração de um novo requisito, o módulo gerador de requisito 314 pode receber a entrada que se refere a uma capacidade a ser usada para a geração do novo requisito (bloco 904). Mediante o recebimento da capacidade, o módulo gerador de requisito 314 pode avisar a seleção de um prefixo predeterminado (bloco 906). Mediante o recebimento do prefixo pre- determinado (bloco 908), o módulo gerador de requisito 314 pode gerar o 5 novo requisito com base no prefixo selecionado, na extração de verbo- entidade da capacidade ou através do uso do texto da capacidade, conforme descrito com relação às figuras 5 a 7 (bloco 910).

O requisito gerado pode ser transmitido para o gerador de apre- sentação visual 312 (bloco 912) e pode gerar uma representação visual a- 10 tualizada 504 (bloco 914). O gerador de apresentação visual 312 pode transmitir a representação visual atualizada 504 para a tela 128 (bloco 916). Se a informação de edição não for relacionada à geração de um novo requi- sito, a entrada de edição 400 pode ser processada pelo módulo de edição 313 (bloco 917). O módulo de edição 313 pode transmitir a informação de 15 edição 402 para o gerador de representação visual 312 (bloco 912). O gera- dor de representação visual 312 pode gerar uma representação visual atua- lizada 404 (bloco 914) e transmitir a representação visual atualizada 404 pa- ra a tela 128 (bloco 916). Mediante a atualização da representação visual, o TAS 100 pode determinar se outra edição é desejada (bloco 918). Se outra 20 edição for desejada, o TAS 100 pode receber a informação de edição adi- cional (bloco 900). Se nenhuma edição adicional for desejada, nenhuma o- peração adicional pode ser adotada pelo TAS 100 até a informação adicional ser recebida.

Os modelos de capacidade 112 podem incluir capacidades que 25 podem requerer que outras capacidades sejam realizadas a fim de serem realizadas. Por exemplo, a figura 10 é um exemplo de um modelo de capa- cidade 1000. O modelo de capacidade 1000 é associado ao domínio de va- rejo e, em particular, é um "Modelo de Processo de Varejo" na figura 10. O modelo de capacidade 1000 inclui inúmeros níveis hierárquicos, níveis 1 a 4, 30 cada um que inclui diversas capacidades 1002 e/ou processos 1004. O nível 4 inclui processos que podem requerer existência para realizar uma capaci- dade particular. Por exemplo, na figura 2 os processos 1004 "Receber Or- dem", "Verificar Inventário" e "Verificar Crédito de Cliente" podem ser todos requeridos a fim de que a capacidade de "Processar Ordem de Vendas" seja realizada. Em outras palavras, a fim de que a capacidade 1002 de "Proces- sar Ordem de Vendas" seja implementada no modelo de capacidade 1000, 5 também pode ser requerido que aqueles processos de nível 4 sejam imple- mentados.

Tal relação entre as capacidades e/ou processos pode causar problemas quando determinar a correspondência entre as capacidades de um modelo de capacidade e requisitos de uma lista de requisito. Por exem- 10 pio, uma capacidade particular pode ser encontrada para corresponder a um requisito em uma lista de requisitos. Entretanto, pode não existir nenhum requisito correspondente para as capacidades ou processos que podem ser requeridos a fim de implementar a capacidade particular. Conforme posteri- ormente descrito em detalhes, o RAS 100 pode indicar quando tais condi- 15 ções existem.

Cada modelo de capacidade 112 pode incluir a informação hie- rárquica usada para determinar as hierarquias, conforme ilustrado na figura 10 ou informações adicionais podem ser fornecidas por um usuário através da GUI 120. Por exemplo, a natureza hierárquica do modelo de capacidade 20 1000 pode ser expressa como um gráfico semântico. A figura 11 é um gráfi- co semântico parcialmente desenvolvido 1100 que representa o modelo de capacidade 1000. O gráfico semântico 1100 expressa a relação geral entre as capacidades (caixa 1102), requisitos (caixa 1104) e entidades (caixa 1106). Em um exemplo, o modelo de capacidade 1000 pode ser analisado 25 pelo TAS 100 para extrair as capacidades e entidades contidas no modelo de capacidade 1000 que usa recursos, tal como, OpenNLP. O TAS 100, com base na entrada de usuário, pode determinar as relações entre as capacida- des e processos presentes em um modelo de capacidade 112. Por exemplo, o TAS 100 pode receber a entrada de usuário através da GUI 120 indicada 30 pelas relações mostradas entre as diversas capacidades e requisitos do mo- delo de capacidade 100. A porção 1108 do gráfico semântico 1100 pode ser criada pelo TAS 100 com base na entrada de usuário, que indica as relações entre as capacidades e processos específicos. Na figura 11, as capacidades específicas no modelo de capacidade 1000 podem ser designadas como uma caixa 1110 e os processos específicos como uma caixa 1112. As capa- cidades e processos podem ser posicionados abaixo da caixa "Capacidade" 5 1102.

As linhas de seta cheias 1114 no gráfico semântico 1000 indi- cam uma relação hierárquica entre as capacidades e as linhas de seta ponti- Ihadas 1116 indicam que a capacidade ou processo conectado à extremida- de a jusante da seta pode ser requerido a fim de conectar a capacidade à 10 extremidade a montante da seta. O termo "req 1" indica que a capacidade pode requerer o processo associado 1112, porém, outros processos 1112 também podem ser requeridos. O termo "req" (não mostrado) pode indicar que a capacidade ou processo associado é o único requerido para realizar uma capacidade particular. 15 Com base na porção 1108 do gráfico semântico, o TAS 100 po-

de criar a porção 1118 do gráfico semântico 1100. O TAS 100 pode extrair as entidades designadas como caixas 1120 no modelo de capacidade (não mostrado) para determinar diversas entidades relacionadas às capacidades do modelo de capacidade 1000, que podem se originar no gráfico semântico 20 1100 a partir da caixa "entidade" 1106. Na figura 11, as entidades podem ter subentidades. Por exemplo, a entidade "fatura" pode ter subentidades, tais como, "fatura intercompanhia" e "fatura pró-forma". O TAS 100 pode gerar os termos e relações indicadas pelas setas 1122. No desenvolvimento adi- cional do gráfico semântico, os requisitos (não mostrados) podem ser adi- 25 cionados e podem ser expressos originando-se na caixa de requisito 1104 e ramificando-se conforme mostrado com relação às porções 1108 e 1118. O desenvolvimento adicional do gráfico semântico 1100 também pode expres- sar relações diretas entre capacidades e processos que têm entidades asso- ciadas. As relações mapeadas entre requisitos, capacidades e processos 30 também podem ser expressas no gráfico semântico 1100.

Conforme previamente descrito, ao determinar correspondência entre capacidades e requisitos, correspondência entre uma capacidade par- ticular e um requisito pode existir, porém, a realização da capacidade parti- cular pode requerer outras capacidades ou processos que não têm requisi- tos correspondentes. Deste modo, a identificação destas outras capacidades ou processos pode permitir uma resposta subsequente, tal como, a geração 5 de requisitos que correspondam às outras capacidades.

Na figura 12, o módulo de mapeamento 300 pode incluir um mó- dulo identificador de relação de capacidade ("CRI") 1200. O módulo CRI 1200 pode receber o modelo de capacidade CMx e a lista de requisitos RLy para determinar as inter-relações entre capacidades e processos incluídos 10 no modelo de capacidade CMx, assim como entre requisitos e as capacida- des e processos. As inter-relações podem incluir exclusividade mútua ou capacidades para estas que podem requerer outras capacidades para seu cumprimento com base em restrições predeterminadas. As inter-relações determinadas pelo módulo CRI 1200 também podem ser baseadas na en- 15 trada baseada em usuário 1202 recebida através da GUI 120. Com base na informação recebida, o módulo CRI 1200 pode gerar inter-relações entre as capacidades do modelo de capacidade CMx, tais como aquelas mostradas no gráfico semântico da figura 11.

O módulo CRI 1200 pode gerar um conjunto de dados de inter- 20 relação ("IRR") 1204 que contém a informação que se refere às inter- relações entre as capacidades e processos. O conjunto de dados de inter- relação 1204 pode ser recebido pelo detector de nível de correspondência 310. Conforme previamente discutido, o detector de nível de correspondên- cia 310 pode determinar os níveis de correspondência entre as capacidades 25 (e processos) do modelo de capacidade CMx e os requisitos da lista de re- quisito RLy. Com base no conjunto de dados de inter-relação 1204, o módulo CRI 1200 pode determinar os níveis de correspondência que envolvem as inter-relações entre a capacidades do modelo de capacidade CMx. Por e- xemplo, o detector de nível de correspondência 307 pode determinar que 30 embora uma capacidade particular corresponda um requisito particular, ou- tras capacidades ou processos necessários para realizar a capacidade parti- cular não têm requisitos correspondentes. O detector de nível de correspondência 310 pode gerar um con- junto de dados de mapeamento ("MAP") 1206 similar ao conjunto de dados de mapeamento 311. O conjunto de dados de mapeamento 1206 também pode incluir informações que se referem às inter-relações de capacidade. O 5 módulo gerador de representação visual 312 pode gerar uma representação visual 1208 a ser transmitida para a tela 128. A representação visual 1210 pode ser similar à representação visual 126 e também pode incluir informa- ções para a indicação visual das inter-relações de capacidade. Por exemplo, a representação visual 1208 pode indicar visualmente as capacidades que 10 requerem que outras capacidades ou processos sejam realizados a fim de serem realizadas, em que as outras capacidades não têm outros processos ou capacidades. Referindo-se à figura 8, tal atividade conforme descrito com relação à figura 12 que envolve o módulo CRI 1200 e o módulo detector de nível de correspondência 310 pode ser realizada durante a determinação de 15 correspondência (bloco 817).

O TAS 100 também pode determinar as dependências entre os sistemas e capacidades. Em um exemplo, uma organização pode desejar usar um sistema particular a fim de realizar alguma ação ou tarefa. Entretan- to, alguns sistemas desejados podem não incluir toda capacidade requerida 20 para a implementação. Deste modo, um modelo de capacidade que corres- ponde substancialmente a um conjunto de requisitos particular que descreve o sistema desejado pode ser desconsiderado pela organização pela falha de incluir todas as capacidades desejadas. Por exemplo, se uma solução de software com base em um modelo de capacidade particular não tiver suporte 25 embutido para rastrear materiais perigosos, então, algum outro sistema que proporcione estas capacidades pode ser requerido. O TAS 100 pode usar dependências entre sistemas e capacidades dos modelos de capacidade para permitir a criação de declarações de requisito mais focalizadas.

Um sistema pode ser formalmente descrito com base nas capa- 30 cidades de núcleo do sistema. Por exemplo, um sistema de faturamento po- de ser definido como o sistema que precisa realizar todas as seguintes ca- pacidades: 1) Criar fatura; 2) Criar memorando de crédito; 3) Criar demons- trativo; e 4) Processar itens retornados. A descrição formal de sistemas, tal como, o sistema de faturamento descrito, pode ser inicialmente caracteriza- da por uma organização simplesmente como "o sistema", como o assunto (isto é, "o sistema deve permitir que o usuário crie faturas") quando desen- volver requisitos. O TAS 100 pode implementar um mecanismo de raciocí- nio, tal como, Jena para guiar uma organização para alterar o "sistema" para o "sistema de faturamento", para um conjunto de requisitos. Tal ação permite que o TAS mapeie o conjunto de requisitos para as capacidades acima que envolvem o sistema de faturamento que proporciona um conjunto de requisi- tos mais focalizado. Deste modo, se uma organização indica um desejo de usar o sistema de faturamento, porém, não todas as capacidades requeridas têm os requisitos mapeados para estas, o TAS 100 identifica quais capaci- dades que podem precisar ser incluídas.

Em um exemplo, o TAS pode selecionar o modelo de capacida- de baseado no conjunto de requisitos. Na figura 13, o TAS 100 pode incluir o módulo de modelo de seleção de capacidade ("CMS") 1300. O módulo CMS .1300 pode identificar um modelo de capacidade particular ou grupo de capa- cidades e um modelo de capacidade particular baseado em uma lista de re- quisitos pré-selecionada. Na figura 13, o módulo CMS 1300 pode ser confi- gurado para receber uma lista de requisitos particular RLY, tal como, através da entrada de usuário através da GUI 120. O módulo CMS 1300 pode pro- porcionar uma escolha de modo 1302 que permite que um usuário selecione o modelo de capacidade 112 para comparação ou permitir que o CMS 1300 selecione o modelo de capacidade. Se o CMS 1300 for escolhido para sele- cionar o modelo de capacidade, o CMS 1300 pode analisar a lista de requisi- tos RLy. O CMS 1300 também pode recuperar um conjunto de dados de de- finição de sistema 1304 armazenado em um ou mais bancos de dados, tais como, os bancos de dados 108 e 114 ou armazenados na memória 106. O conjunto de dados de definição de sistema ("SD") 1304 pode incluir a termi- nologia associada aos tipos de sistema conhecidos. Por exemplo, um requi- sito da lista de requisitos RLy pode proporcionar "o sistema deve permitir que o usuário crie faturas". O conjunto de dados de definições de sistema 1304 pode incluir informações que referem as "faturas" a outros tipos de sis- tema, tal como um sistema de faturamento. O módulo CMS 1300 pode pro- porcionar ao usuário uma escolha de sistema 1306 que indica os modelos de capacidade 112 disponíveis para a seleção que corresponde a um ou 5 mais requisitos na lista de requisitos RLY. Mediante o recebimento da sele- ção 1308 através da GU1120, o módulo CMS 1300 pode recuperar o modelo de capacidade selecionado CMx. A lista de requisitos RLy e o modelo de capacidade selecionado CMx podem ser proporcionados para o módulo de mapeamento 300.

10 O módulo de mapeamento 300 pode permitir a geração da re-

presentação visual 126, conforme descrito em relação às figuras 1-7. O RAS 100 pode permitir que um usuário atualize os requisitos da lista de requisito RLY, tal como através do módulo de edição 313, para refletir o tipo de siste- ma particular associado ao modelo de capacidade selecionado CMx, que 15 pode ser visualmente indicado na apresentação visual 126.

Em outros exemplos, um modelo de capacidade CMx que inclui diversas capacidades ou grupos de capacidade que descrevem tipos de sis- tema particulares. Mediante a seleção do modelo de capacidade CMx, o mó- dulo CMS 1300 pode identificar os sistemas particulares descritos pelas ca- 20 pacidades no modelo de capacidade selecionado 1300. O módulo CMS 1300 pode receber uma seleção com base em usuário de um tipo de sistema particular descrito no modo de capacidade para permitir que o tipo de siste- ma possa ser selecionado com base na entrada de usuário. Mediante a se- leção, o módulo CMS 1300 pode analisar o sistema particular escolhido e 25 pode atualizar os requisitos da lista de requisito RLY para refletir o tipo de sistema particular escolhido.

Embora diversas modalidades da inovação tenham sido descri- tas, será aparente para aqueles de conhecimento comum na técnica que muito mais modalidades e implementações são possíveis dentro do escopo 30 da inovação. Consequentemente, a inovação não deve ser restrita exceto à luz das reivindicações em anexo e seus equivalentes.

Claims (25)

REIVINDICAÇÕES

1. Sistema para identificação de similaridade textual, caracteri- zado pelo fato de que compreende: um banco de dados (108, 114) configurado para armazenar um primeiro conjunto de declarações textuais e um segundo conjunto de decla- rações textuais; um sistema de análise textual (100) armazenado em uma memó- ria (106) e executável em um processador (104) para: recuperar o primeiro conjunto de declarações textuais (110) e o segundo conjunto de declarações textuais (116) a partir do banco de dados; gerar uma pluralidade de pares de declaração, em que cada par de declaração da pluralidade de pares de declaração inclui uma declaração textual a partir do primeiro conjunto (110) e uma declaração textual a partir do segundo conjunto (116); determinar uma respectiva pontuação para cada par de declara- ção, em que a respectiva pontuação é indicativa de um nível de similaridade entre o conteúdo textual da declaração textual do primeiro conjunto e o con- teúdo textual da declaração textual do segundo conjunto; comparar cada respectiva pontuação a um limite de pontuação predeterminado; e gerar uma representação visual (126) configurada para ser visu- alizada em uma tela (128), em que a representação visual é configurada pa- ra indicar visualmente quando cada par de declaração tem uma respectiva pontuação maior que o limite de pontuação predeterminado.

2. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o módulo de análise textual é adicionalmente executável para: determinar uma pluralidade de subpontuações para cada par de declaração, em que cada subpontuação é baseada no conteúdo textual da declaração textual do primeiro conjunto e o conteúdo textual da declaração textual do segundo conjunto de um respectivo par de declaração; determinar uma primeira respectiva pontuação, para cada par de declaração, em que a primeira respectiva pontuação é selecionada como uma pontuação máxima da pluralidade de subpontuações do respectivo par de declaração; determinar uma segunda respectiva pontuação para cada par de declaração, em que a segunda respectiva pontuação é baseada na plurali- dade de subpontuações; e selecionar uma respectiva pontuação final para cada par de de- claração baseado na primeira respectiva pontuação e na segunda respectiva pontuação.

3. Sistema, de acordo com a reivindicação 2, caracterizado pelo fato de que o módulo de análise textual é adicionalmente executável para comparar a respectiva pontuação final selecionada para o limite de pontua- ção predeterminado, e em que a representação visual (126) é configurada para indicar visualmente cada par de declaração que tem uma respectiva pontuação final maior que o limite de pontuação predeterminado.

4. Sistema, de acordo com a reivindicação 2, caracterizado pelo fato de que para cada par de declaração, uma primeira pluralidade de sub- pontuações é baseada na similaridade de sintaxe entre o conteúdo textual da declaração textual do primeiro conjunto e o conteúdo textual da declara- ção textual do segundo conjunto, e uma segunda da pluralidade de subpon- tuações é baseada em uma presença de conteúdo textual de sinônimo da declaração textual do primeiro conjunto com respeito ao conteúdo textual da declaração textual do segundo conjunto para cada respectivo par de decla- ração e similaridade semântica entre o conteúdo textual da declaração tex- tual do primeiro conjunto e o conteúdo textual da declaração textual do se- gundo conjunto para cada respectivo par de declaração.

5. Sistema, de acordo com a reivindicação 4, caracterizado pelo fato de que a primeira respectiva pontuação para cada respectivo par de de- claração é maior que uma terceira respectiva pontuação e uma quarta res- pectiva pontuação para o respectivo par de declaração.

6. Sistema, de acordo com a reivindicação 5, caracterizado pelo fato de que a terceira respectiva pontuação, para cada par de declaração, é baseada em uma comparação entre uma base de pelo menos uma palavra da declaração textual do primeiro conjunto e pelo menos uma palavra da declaração textual do segundo conjunto.

7. Sistema, de acordo com a reivindicação 5, caracterizado pelo fato de que a quarta respectiva pontuação, para cada par de declaração, é 5 baseada em uma similaridade semântica entre a declaração textual do pri- meiro conjunto e a declaração textual do segundo conjunto.

8. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o módulo de análise textual é adicionalmente executável para identificar, para cada par de declaração, um primeiro par de verbo-entidade 10 a partir do conteúdo textual da declaração textual do primeiro conjunto e um segundo par de verbo-entidade a partir do conteúdo textual da declaração textual do segundo conjunto, em que a respectiva pontuação é indicativa da similaridade entre o primeiro par de verbo-entidade e o segundo par de ver- bo-entidade. 15

9. Sistema de análise de organização, caracterizado pelo fato de que compreende: um banco de dados (108, 114) configurado para armazenar: uma pluralidade de modelos de capacidade (112), em que cada pluralidade de modelos de capacidade compreende uma pluralidade de ca- .20 pacidades, em que cada uma das capacidades define um aspecto particular associado a um aspecto operacional de uma organização; uma pluralidade de listas de requisito (118), em que cada lista de requisito da pluralidade de listas de requisito compreende uma pluralidade de requisitos, em que os requisitos definem um aspecto operacional da or- .25 ganização; um sistema de análise textual (100) armazenado em uma memó- ria (106) e executável por um processador (104), o sistema de análise textu- al configurado para: recuperar um modelo de capacidade a partir da pluralidade de .30 modelos de capacidade; recuperar uma lista de requisito a partir da pluralidade de listas de requisito; determinar um nível de similaridade entre cada combinação ex- clusiva de uma única capacidade do modelo de capacidade recuperado e um único requisito da lista de requisito recuperada; e gerar pelo menos uma apresentação visual, em que pelo menos .5 uma representação visual (126) é gerada para indicar visualmente cada nível determinado de similaridade entre a única capacidade e o único requisito de cada combinação exclusiva.

10. Sistema de análise de organização, de acordo com a reivin- dicação 9, caracterizado pelo fato de que o sistema de análise textual (100) 10 é adicionalmente configurado para: gerar uma respectiva pontuação, para cada combinação exclusi- va, baseada no nível de similaridade entre a única capacidade e o único re- quisito; comparar a respectiva pontuação para cada combinação exclu- 15 siva a um limite de pontuação predeterminado; e determinar, para cada combinação exclusiva, um nível respecti- vo da correspondência entre a única capacidade e o único requisito baseado na comparação da respectiva pontuação ao limite de pontuação predetermi- nado, em que pelo menos uma apresentação visual é gerada para indicar 20 visualmente o respectivo nível de correspondência para cada combinação exclusiva.

11. Sistema de análise de organização, de acordo com a reivin- dicação 10, caracterizado pelo fato de que o sistema de análise textual (100) é adicionalmente configurado para determinar a correspondência direta ba- 25 seada no respectivo nível de correspondência para cada combinação exclu- siva, em que a apresentação visual é configurada para indicar visualmente a correspondência direta entre a única capacidade e o único requisito de cada combinação exclusiva.

12. Sistema de análise de organização, de acordo com a reivin- .30 dicação 10, caracterizado pelo fato de que o sistema de análise textual (100) é adicionalmente configurado para identificar uma primeira hierarquia asso- ciada à pluralidade de capacidades do modelo de capacidade recuperado e uma segunda hierarquia associada à pluralidade de requisitos da lista de requisito recuperada, em que o respectivo nível de correspondência está entre a única capacidade e o único requisito de cada combinação exclusiva é determinado com base na primeira hierarquia e na segunda hierarquia.

13. Sistema de análise de organização, de acordo com a reivin- dicação 9, caracterizado pelo fato de que o sistema de análise textual (100) é adicionalmente configurado para gerar um novo requisito baseado na sele- ção de uma capacidade a partir do modelo de capacidade recuperado.

14. Sistema de análise de organização, de acordo com a reivin- dicação 13, caracterizado pelo fato de que o sistema de análise textual (100) é configurado para atualizar a representação visual para indicar visualmente a geração do novo requisito.

15. Sistema de análise de organização, de acordo com a reivin- dicação 14, caracterizado pelo fato de que o sistema de análise textual (100) é configurado para adicionar o novo requisito a pelo menos uma pluralidade de listas de requisito.

16. Sistema de análise de organização, de acordo com a reivin- dicação 9, caracterizado pelo fato de que o sistema de análise textual (100) é configurado para identificar, para cada combinação exclusiva, uma primei- ra relação de verbo-entidade na única capacidade e uma segunda relação de verbo-entidade no único requisito, em que o nível de similaridade para cada combinação exclusiva é baseado em um nível de similaridade entre a primeira relação de verbo-entidade e a segunda relação de verbo-entidade.

17. Sistema de análise de organização, de acordo com a reivin- dicação 9, caracterizado pelo fato de que o sistema de análise de organiza- ção é adicionalmente executável para: eliminar pelo menos um requisito a partir da lista de requisito re- cuperada para gerar uma nova lista de requisito; e armazenar a nova lista de requisito no banco de dados.

18. Meio legível por computador que compreende uma pluralida- de de instruções executáveis por um processador (104), caracterizado pelo fato de que compreende: instruções para recuperar um primeiro documento eletrônico que contém uma primeira pluralidade de declarações; instruções para recuperar um segundo documento eletrônico que contém uma segunda pluralidade de declarações; .5 instruções para gerar uma pluralidade de pares de declaração, em que cada par de declaração inclui uma primeira respectiva declaração a partir da primeira pluralidade de declarações e uma segunda respectiva de- claração a partir da segunda pluralidade de declarações; instruções para identificar, para cada par de declaração, uma re- .10 lação de verbo-entidade a partir da primeira respectiva declaração e uma relação de verbo-entidade a partir da segunda respectiva declaração; instruções para determinar, para cada par de declaração, um ní- vel de similaridade entre a relação de verbo-entidade a partir da primeira respectiva declaração e a relação de verbo-entidade a partir da segunda .15 respectiva declaração; e instruções para gerar uma representação visual configurada pa- ra ser gerada em pelo menos uma tela, em que a representação visual é gerada para indicar visualmente o nível de similaridade para cada respectivo par de declaração. .20

19. Meio legível por computador, de acordo com a reivindicação .18, caracterizado pelo fato de que adicionalmente compreende instruções para comparar a relação de verbo-entidade a partir da primeira respectiva declaração e a relação de verbo-entidade da segunda respectiva declaração, .25 em que as instruções para determinar um nível de similaridade para cada um dos pares de declaração compreendem instruções para gerar uma pontuação baseada na comparação da relação de verbo-entidade a partir da primeira respectiva declaração e a relação de verbo-entidade a par- tir da segunda respectiva declaração, em que a pontuação é indicativa de .30 um nível de similaridade entre a relação de verbo-entidade a partir da primei- ra respectiva declaração e a relação de verbo-entidade a partir da segunda respectiva declaração.

20. Meio legível por computador, de acordo com a reivindicação .19, caracterizado pelo fato de que as instruções para gerar uma pontuação compreendem gerar uma pontuação baseada em: uma comparação entre um verbo da relação de verbo-entidade da primeira respectiva declaração e um verbo da relação de verbo-entidade da segunda respectiva declaração; e uma comparação entre uma entidade da relação de verbo- entidade da primeira respectiva declaração e uma entidade da relação de verbo-entidade da segunda respectiva declaração.

21. Meio legível por computador, de acordo com a reivindicação .20, caracterizado pelo fato de que as instruções para gerar uma pontuação compreendem adicionalmente gerar uma pontuação com base no verbo da relação de verbo-entidade da primeira respectiva declaração e no verbo da relação de verbo-entidade da segunda respectiva declaração que são sinô- nimos.

22. Meio legível por computador, de acordo com a reivindicação .20, caracterizado pelo fato de que as instruções para gerar uma pontuação compreendem adicionalmente gerar uma pontuação com base na entidade da relação de verbo-entidade da primeira respectiva declaração e a entidade da relação de verbo-entidade da segunda respectiva declaração que são sinônimos.

23. Meio legível por computador, de acordo com a reivindicação .20, caracterizado pelo fato de que as instruções para gerar uma pontuação compreendem adicionalmente gerar uma pontuação com base no verbo da relação de verbo-entidade da primeira respectiva declaração e no verbo da relação de verbo-entidade da segunda respectiva declaração que comparti- lham uma palavra base comum.

24. Meio legível por computador, de acordo com a reivindicação .20, caracterizado pelo fato de que as instruções para gerar uma pontuação compreendem adicionalmente gerar uma pontuação com base na entidade da relação de verbo-entidade da primeira respectiva declaração e na entida- de da relação de verbo-entidade da segunda respectiva declaração que compartilha uma palavra base comum.

25. Sistema de análise de organização, caracterizado pelo fato de que compreende: um banco de dados configurado para armazenar: .5 uma pluralidade de modelos de capacidade, em que cada plura- lidade de modelos de capacidade compreende uma pluralidade de capaci- dades organizada em uma respectiva hierarquia, em que cada uma das ca- pacidades define um aspecto particular associado a um aspecto operacional desejado de uma organização, e em que a respectiva hierarquia compreen- .10 de uma pluralidade de níveis onde cada uma das capacidades corresponde a uma pluralidade de níveis; uma pluralidade de listas de requisito, em que cada lista de re- quisito da pluralidade de listas de requisito compreende uma pluralidade de requisitos, em que os requisitos definem um aspecto operacional da organi- .15 zação; um sistema de análise textual armazenado em uma memória e executável por um processador, o sistema de análise textual configurado para: recuperar um modelo de capacidade a partir da pluralidade de .20 modelos de capacidade; recuperar uma lista de requisito a partir da pluralidade de listas de requisito; determinar, para cada capacidade no modelo de capacidade, quando um requisito correspondente existe a partir da lista de requisito recu- .25 perada; para cada capacidade que tem um requisito correspondente, i- dentificar cada capacidade associada que não tem um requisito correspon- dente e que tem um nível relativo mais baixo da pluralidade de níveis; e gerar pelo menos uma apresentação visual, em que pelo menos .30 uma representação visual é gerada para indicar visualmente cada capacida- de que tem um requisito correspondente e cada capacidade associada iden- tificada.