ObasCId-Tool
A partir dos resultados apresentados na Seção 5.8, todos os demais requisitos da ferramenta ObasCId-Tool, disponíveis no Quadro A.8.1 do Apêndice A desta tese, foram cadastrados.
Conforme explicado na Seção 5.8, para executar uma unidade de identificação, o pesquisador deve ter, no mínimo, um catálogo de interesses de software e um documento de requisitos cadastrados. Contudo, a maneira como o pesquisador realiza o cadastramento dos elementos desses artefatos pode facilitar seu entendimento sobre possíveis situações de erro durante o processo de identificação e classificação de interesses. Assim, recomenda-se não realizar o cadastramento dos relacionamentos de dependência entre requisitos na primeira execução da unidade de identificação.
De acordo com a descrição dos elementos e axiomas da ontologia O4C (Capítulo 3) e com a descrição da abordagem ObasCId (Capítulo 4), os relacionamentos de dependência entre requisitos permitem com que um requisito herde os interesses identificados para outro requisito como seus interesses transversais. Assim, cadastrando esses relacionamentos logo no início do processo de identificação de interesses, pode-se omitir as situações em que não foram identificados interesses para um determinado requisito do software, por meio de palavras-chave. Essas situações são importantes pois podem evidenciar a necessidade de um refinamento da descrição do documento de requisitos ou do catálogo de interesses.
Dessa forma, na primeira execução da unidade de identificação sobre o documento de requisitos completo da ferramenta ObasCId-Tool, não foram incluídos os relacionamentos de dependência existentes entre esses requisitos. A Figura 5.44 apresenta o resumo do processo de identificação, bem como a lista de ocorrências gerada.
Figura 5.44. Saída do processo de identificação de interesses com os requisitos da ferramenta ObasCId-Tool.
Como pode ser visto, uma cobertura satisfatória dos requisitos da ferramenta foi obtida, pois aproximadamente 87% dos requisitos foram contemplados por algum tipo de interesse. Além disso, dos 13 (treze) interesses existentes no catálogo de interesses utilizado, 10 (dez) foram identificados. Com relação às ocorrências, a maioria está relacionada à não-especificação dos interesses principais dos requisitos do software (ocorrência do tipo I). Há ainda três ocorrências do tipo IV, que diz respeito à identificação
de interesses não funcionais que não entrecortam requisitos funcionais do software. A resolução destas ocorrências será discutida mais adiante nesta seção.
Quanto à lista de requisitos e interesses identificados, há algumas situações interessantes a serem discutidas. Os quatro requisitos para os quais não houve interesses identificados são “RF-10”, “RF-15”, “RF-16” e “RF-27”. O requisito “RF-27” diz respeito à filtragem de requisitos da lista de requisitos e interesses identificados. Esse requisito está relacionado ao interesse “Identificação e Classificação de Interesses”, contudo, não havia palavras no catálogo de interesse que fosse capaz de capturá-lo. Para resolver essa situação, a palavra-chave “lista de requisitos e interesses identificados”, que é um artefato da fase de identificação e classificação de interesses, foi adicionada ao catálogo.
Os requisitos “RF-15” e “RF-16” estão relacionados ao interesse “Gerenciamento de Catálogos de Interesses”. No catálogo de interesses utilizado, a palavra-chave “catálogos de interesse” foi cadastrada, porém na descrição destes requisitos, a expressão “catálogo de interesses” aparece. Esse erro poderia ter sido evitado por meio do uso de recursos como
wildcards ou “busca por similaridade”, durante o cadastramento das palavras-chave do catálogo. Para resolver esse problema, a palavra-chave anterior foi substituída por “catálogo* AND interesses”.
O último requisito a ser considerado é o “RF-10”, que diz respeito à importação/exportação de palavras-chave de um interesse, ou seja, também está relacionado ao “Gerenciamento de Catálogos de Interesse”. Esse requisito não foi contemplado por esse interesse, pois faltam palavras-chave no catálogo de interesses capazes de identificar outros tipos de elementos relacionados aos catálogos de interesses de software. Para resolver esse problema, novas palavras-chave foram cadastradas para o interesse “Gerenciamento de Catálogos de Interesse”, tais como “palavras-chave”, “fontes”, entre outros.
Quanto às ocorrências do tipo IV, os três interesses funcionais do catálogo, a saber, “Responsividade”, “Usabilidade” e “Segurança” foram identificados, porém eles estão relacionados apenas a requisitos não funcionais do software. Esse problema foi solucionado após o cadastramento dos relacionamentos de dependências entre os requisitos do software, conforme especificado no Quadro A.8.1. Assim, restaram apenas as ocorrências que dizem respeito à não-especificação do interesse principal de cada requisito.
Com o auxílio de especialistas sobre o domínio da ferramenta ObasCId-Tool, os requisitos dessa ferramenta foram classificados quanto ao seu interesse principal, conforme pode ser visto no Quadro 5.5. Para isso, tais especialistas tiveram acesso à lista de requisitos e interesses identificados pela ferramenta ObasCId-Tool.
Quadro 5.5. Lista de requisitos da ferramenta ObasCId-Tool e seus interesses principais.
Requisito do
software Interesse Principal
RF-01 Gerenciamento de Catálogos de Interesses
RF-02 Gerenciamento de Pesquisadores
RF-03 Gerenciamento de Pesquisadores
RF-04 Gerenciamento de Pesquisadores
RF-05 Gerenciamento de Pesquisadores
RF-06 Gerenciamento de Documentos de Requisitos
RF-07 Gerenciamento de Catálogos de Interesses
RF-08 Gerenciamento de Catálogos de Interesses
RF-09 Gerenciamento de Catálogos de Interesses
RF-10 Gerenciamento de Catálogos de Interesses
RF-11 Gerenciamento de Catálogos de Interesses
RF-12 Gerenciamento de Documentos de Requisitos
RF-13 Gerenciamento de Documentos de Requisitos
RF-14 Identificação e Classificação de Interesses
RF-15 Gerenciamento de Catálogos de Interesses
RF-16 Gerenciamento de Catálogos de Interesses
RF-17 Gerenciamento de Documentos de Requisitos
RF-18 Identificação e Classificação de Interesses
RF-19 Identificação e Classificação de Interesses
RF-20 Identificação e Classificação de Interesses
RF-21 Identificação e Classificação de Interesses
RF-22 Consulta aos Repositórios
RF-23 Consulta aos Repositórios
RF-24 Consulta aos Repositórios
RF-25 Consulta aos Repositórios
RF-26 Gerenciamento de Catálogos de Interesses
RF-27 Identificação e Classificação de Interesses
RNF-01 Responsividade
RNF-02 Segurança
RNF-03 Usabilidade
Uma vez cadastrados os interesses principais de cada requisito do software, as ocorrência do tipo I foram todas resolvidas e como resultado, tem-se a matriz de entrelaçamentos da Figura 5.45.
Algumas observações a respeito da matriz da Figura 5.45 são:
i) a natureza transversal dos interesses não funcionais existentes no software foi evidenciada, uma vez que dos quatro interesses não funcionais identificados (“Persistência”, “Segurança”, “Responsividade” e “Usabilidade”), apenas “Segurança” não está entrelaçado com todos os interesses funcionais identificados no software. Isso ocorreu porque as funções especificadas pelos requisitos do módulo “Consulta aos Repositórios” não exigem que os usuários estejam autenticado na ferramenta, tornando os interesse “Consulta aos Repositórios” e “Segurança” não entrelaçados;
ii) a existência de interesses funcionais transversais também é evidenciada. Dos cinco interesses funcionais identificados, apenas os interesses “Identificação e
Classificação de Interesses” e “Consulta aos Repositórios” não entrecortam outros interesses do software. Conforme pode ser visto no diagrama de arquitetura da Figura 5.1, esses são os únicos módulos dos quais nenhum outro módulo depende, ou seja, a chance de haver entrelaçamentos de outros módulos com esses é realmente pequena; e
iii) dos nove interesses identificados, sete podem ser considerados candidatos a interesses transversais. Apenas os interesses não funcionais “Identificação e Classificação de Interesses” e “Consulta aos Repositórios” podem ser considerados interesses base.
Figura 5.45. Matriz de entrelaçamentos do processo de identificação e classificação de interesses da ferramenta ObasCId-Tool.
Contudo, há um ponto que merece a atenção do pesquisador, que é o entrelaçamento do interesse “3: Padronização” com o interesse “6: Gerenciamento de Pesquisadores”. Utilizando o “filtro de requisitos” com a opção “Gerenciamento de Pesquisadores” como interesse principal e “Padronização” como interesse transversal, o pesquisador terá acesso ao requisito onde tal entrelaçamento ocorre. Trata-se do requisito “RF-05”, que diz respeito ao cadastramento de opções padrão (default) para entrada de dados na ferramenta ObasCId-Tool. A palavra-chave “padr*” do interesse “Padronização” foi a responsável pela identificação desse interesse. Contudo, trata-se de um falso positivo, pois o termo “opções padrão” desse requisito possui um significado diferente do que se entende por “padronização”. Para remover esse falso positivo, o engenheiro de software pode refinar a lista de palavras-chave desse interesse ou reescrever o requisito em questão. Neste caso, optou-se por remover o termo “padrão” da descrição dos requisitos, deixando apenas o seu equivalente em inglês “default”. Outra opção seria especificar melhor o termo
“padrão” no catálogo de interesses, informando palavras-chave como “padrões AND codificação” e “padrões AND projeto”, entre outras.
A matriz de contribuição gerada para a ferramenta ObasCId-Tool pode ser visualizada na Figura 5.46. O único ponto de atenção é a contribuição positiva exercida pelo interesse “5: Responsividade” sobre o interesse “13: Usabilidade”, no contexto dos interesses 4, 6, 7, 8 e 9, ou seja, todos os cinco interesses funcionais do software. Isso quer dizer que, ao implementar mecanismos de responsividade para as telas relacionadas com essas funcionalidades, a usabilidade do software estará sendo aprimorada.
Figura 5.46. Matriz de contribuição do processo de identificação e classificação de interesses da ferramenta ObasCId-Tool.