• Nenhum resultado encontrado

Módulo de Gerenciamento de Documentos de Requisitos

CAPÍTULO 5 OBASCID-TOOL: UMA FERRAMENTA DE APOIO À EROA

5.7 Módulo de Gerenciamento de Documentos de Requisitos

O enfoque da ferramenta ObasCId-Tool está na identificação de interesses a partir de requisitos de software. Sendo assim, uma importante função dessa ferramenta é o gerenciamento de documentos de requisitos. Essa funcionalidade pode ser utilizada por qualquer pesquisador cadastrado e autenticado na ferramenta.

Como pode ser visto na Figura 5.25, para adicionar um novo documento de requisitos, o pesquisador deve informar, obrigatoriamente, o nome do documento (que deve ser único) e o seu tipo de licença, que pode ser “Pública” ou “Privada”. O uso de tipos de licença para documentos de requisitos segue os mesmos princípios do uso de tipos de licença para catálogos de interesses de software e por isso não será comentado novamente.

Opcionalmente, o usuário poderá cadastrar uma descrição para seu documento de requisitos.

Figura 5.25. Cadastro de documentos de requisitos.

A listagem de documentos de requisitos segue a mesma estrutura da listagem de catálogos de interesses (Figura 5.8) e por isso não será apresentada. Os elementos que podem ser gerenciados para um documento de requisitos são “Requisitos”, “Dependências entre requisitos”, “Unidades de Identificação” e “Relatório”, que correspondem respectivamente à: (i) tela para gerenciamento de requisitos relacionados com o documento de requisitos ativo no momento; (ii) tela para gerenciamento dos relacionamentos de dependência existentes entre diferentes requisitos do documento de requisitos ativo no momento; (iii) tela para gerenciamento de unidades de identificação relacionadas ao documento de requisitos ativo no momento; e (iv) tela com o relatório geral do documento de requisitos ativo no momento.

5.7.1 Gerenciamento de requisitos

Para cadastrar um requisito, o pesquisador deve informar, obrigatoriamente, o nome do requisito, a descrição e o tipo do mesmo, que pode ser “Funcional” ou “Não funcional” (Figura 5.26). O nome do requisito é útil para facilitar sua identificação nas demais telas da ferramenta.

Uma vez cadastrado, o requisito aparecerá na listagem de requisitos do documento ativo. A Figura 5.27 apresenta os requisitos “RF-01” e “RNF-01”, do Quadro 5.1, cadastrados na ferramenta ObasCId-Tool.

De forma análoga ao que foi feito para as palavras-chave, a ferramenta ObasCId-

No caso dos requisitos, esse arquivo de texto deve conter a descrição dos requisitos e de seus tipos, conforme ilustrado no Quadro 5.2.

Figura 5.26. Cadastro de um requisito de software.

Figura 5.27. Listagem de requisitos do software. Quadro 5.2. Modelo de entrada para importação de requisitos.

<tipo_do_requisito1: FR ou NFR>, <nome do requisito> <descrição_do_requisito1>

<tipo_do_requisito2: FR ou NFR>, <nome do requisito> <descrição_do_requisito2>

...

<tipo_do_requisitoN: FR ou NFR>, <nome do requisito> <descrição_do_requisitoN>

Cada requisito é composto por duas ou mais linhas. A primeira linha refere-se ao tipo do requisito, representado pela sigla FR (Functional Requirement) ou NFR (Non-Functional

Requirement) e pelo seu nome. O tipo e o nome do requisito devem ser separados por uma

vírgula (,). As próximas N linhas não nulas correspondem à descrição desse requisito. Assim que for encontrada uma linha nula (em branco), considera-se que a descrição desse requisito terminou. O exemplo do Quadro 5.3 apresenta um arquivo com a descrição dos dois requisitos apresentados na Figura 5.27.

Quadro 5.3. Exemplo de arquivo para importação de requisitos.

FR, RF-01

O software deve permitir o cadastramento, alteração e exclusão de catálogos de interesses de software. Cada catálogo deve conter nome, descrição (opcional) e tipo de licença, que pode ser pública ou privada.

NFR, RNF-01

A interface de todas as funções do software deve ser responsiva, de forma que os elementos da mesma se adaptem a dispositivos com telas menores (tais como, smartphones e tablets) com no mínimo 5 polegadas.

Opcionalmente, o pesquisador pode especificar a dependência entre requisitos previamente cadastrados na ferramenta. Para isso, ele deve especificar obrigatoriamente o requisito fonte e o requisito alvo do relacionamento, sendo que o requisito fonte depende do requisito alvo. Por exemplo, de acordo com o Quadro 5.1, o requisito “RF-01” depende do requisito “RNF-01”. A Figura 5.28 apresenta a especificação dessa dependência.

Figura 5.28. Gerenciamento dos relacionamentos de dependência entre requisitos do software.

Analogamente aos relacionamentos entre interesses, cada dependência entre requisitos é apresentada na listagem de dependências da seguinte forma: nome_do_requisito_fonte >> nome_do_requisito_alvo. Para simplificar o processo de gerenciamento de dependências entre requisitos, o pesquisador também pode importar/exportar tais relacionamentos para arquivos de texto. Neste caso, o formato desse arquivo segue o que está ilustrado no Quadro 5.4.

Quadro 5.4. Modelo de entrada para importação de relacionamentos de dependência entre requisitos.

<nome_requisito_fonte1>, <nome_requisito_alvo1>, ..., <nome_requisito_alvo2> ...

<nome_requisito_fonteN>, <nome_requisito_alvo1>, ..., <nome_requisito_alvo2>

Cada linha desse arquivo representa um conjunto de relacionamentos de dependência entre um requisito fonte e um ou mais requisitos alvo, cujos nomes são separados por vírgula.

Com a finalidade de evidenciar um tipo de ocorrência que pode ocorrer durante o processo de identificação de interesses com a ferramenta ObasCId-Tool, o relacionamento de dependência entre os requisitos “RF-01” e “RNF-01” não será efetivado neste momento.

5.7.2 Relatório de um documento de requisitos

Um relatório geral de um documento de requisitos previamente cadastrado pode ser gerado. Na Figura 5.29 pode ser visualizado um relatório que contém as seguintes informações: (i) o nome e a descrição do documento de requisitos; (ii) a lista de requisitos com seus respectivos nome, descrições e tipo; (iii) a lista de requisitos dos quais ele depende.

Figura 5.29. Exemplo de um relatório geral de um documento de requisitos.