Técnica TUCCA (Technique for Use Case Construction and construction-based

Uma outra técnica de leitura que também inspeciona DR é a TUCCA, que foi proposta por Belgamo [2004]. O objetivo dessa técnica foi definir diretrizes para a construção de Modelos de Casos de Uso (MCU) (Diagrama e Especificação de Casos de Uso) e ao mesmo tempo auxiliar na inspeção tanto desse Modelo quanto do DR. A detecção de defeitos é realizada à medida que a técnica é aplicada na construção do MCU, pois suas diretrizes de construção possuem instruções para inspecionar o DR. Assim, as técnicas TUCCA agregam atividades de construção do MCU e análise do DR. Uma comparação feita entre as técnicas TUCCA e PBR-Usuário quanto à identificação de defeitos em DR pode ser vista em Belgamo & Fabbri [2004b].

Essas técnicas são compostas de duas leituras: AGRT (Actor Goal Reading

Techniques) e UCRT (Use Case Reading Techniques), as quais basearam-se nas técnicas de

leitura PBR com perspectiva do usuário, que utiliza o MCU como apoio para fazer a inspeção do DR, e ER1, da família de técnicas de leitura OORTs/ProDeS descrita anteriormente, que foi definida para fazer a validação do MCU em comparação com o DR. Tanto os aspectos da ER1 quanto da PBR-Usuário foram utilizados e transformados em diretrizes para as técnicas TUCCA, sendo a sua apresentação e formato similares ao da ER1.

O propósito da leitura AGRT é entender o DR para que se possa identificar os possíveis atores e seus objetivos dentro do sistema, além de identificar defeitos no DR. Já a leitura UCRT tem por objetivo construir o MCU (Diagrama de Casos de Uso e suas Especificações) além de também identificar defeitos no DR. A Figura 4.3 mostra como essas técnicas devem ser aplicadas.

181lvii

6

Figura 4.3 Ordem de aplicação das técnicas TUCCA [Belgamo, 2004]

O primeiro passo da técnica TUCCA começa pela aplicação da leitura AGRT, recebendo como entrada o DR, o qual deve estar no padrão IEEE [1998b] ou possuir, ao menos, seções equivalentes às seções Definições, Funções do Produto, Características do Usuário, Requisitos Funcionais e Requisitos Não-Funcionais desse padrão. Essa leitura consiste de várias etapas para se obter o Formulário Ator x Objetivo (FAO), no qual são identificados os atores do sistema, as funcionalidades relacionadas a cada ator e a referência onde estas funcionalidades são encontradas no DR. Para isso, são feitos as marcações dos substantivos com traço para identificar os atores, dos verbos com círculos para descobrir a funcionalidade e das restrições com retângulo. A saída gerada por essa técnica é o FAO e o Relatório de Discrepância, que contém os defeitos encontrados. O segundo passo é a leitura UCRT que recebe como entrada o FAO, gerado anteriormente, e o DR. Nessa leitura, o Formulário de Casos de Uso Preliminares (FCUP), é elaborado a partir do FAO para construir o MCU. Assim, os casos de usos que devem existir são determinados e os relacionamentos entre ele são identificados para que possam ser agrupados, gerando um único caso de uso. As especificações dos casos de uso são descritas e as relações de include e extend são identificadas. A leitura UCRT gera como saída o MCU e outro Relatório de Discrepâncias contendo as discrepâncias decorrentes da mesma.

Seguindo as diretrizes desses passos tem-se então que a TUCCA, além de facilitar a construção de MCU através de um procedimento mais sistemático, também incorpora em sua

AGRT

1. Para cada Requisito... A. Leia o requisito...

UCRT

1. Utilize o Formulário... A. Para cada objetivo...

Formulário de especificação de Casos de Uso entrada UCRT – Relatório de Discrepância AGRT – Relatório de Discrepância Documento de Requisitos

Entrada _TUCCA Saída

Formulário Ator/Objetivo

técnica a inspeção do DR. O estudo de viabilidade dessa técnica de inspeção mostrou que a TUCCA torna mais fácil a identificação dos casos de uso que compõem o sistema, aumenta a efetividade em identificar casos de uso e ajuda na tomada de decisão quanto ao agrupamento ou separação de funcionalidade, e os casos de uso identificados fornecem uma representação mais precisa do DR [Belgamo & Fabbri, 2004c].

Como puderam ser observadas pelas abordagens de inspeção mostradas, várias propostas têm surgido para auxiliar essas atividades, sendo que muitas delas apóiam a revisão do DR a fim de que este se apresente de forma mais adequada para dar continuidade ao processo de desenvolvimento de software. O DR é o artefato que dá início a todo esse processo e que, portanto deve receber maior atenção por parte dos desenvolvedores quanto à sua clareza, consistência, completitude, corretitude, enfim, quanto à sua qualidade como um todo.

Ressalta-se que na técnica TUCCA, o DR é de grande importância, visto que os MCU´s gerados baseiam-se nesse documento e a sua elaboração pode ser dificultada pelos inúmeros defeitos encontrados no tal documento. Assim, um DR melhor escrito, que apresente um determinado formato pode facilitar a aplicação e automatização das técnicas TUCCA.

4.8

Considerações Finais

Neste capítulo foram apresentadas as principais técnicas de inspeção voltadas para a validação do DR.

Uma breve descrição do que seria inspeção foi descrita além de cinco técnicas que auxiliam essa atividade, sendo elas: Ckecklist, PBR, OORTs, OORTs/ProDeS e TUCCA.

Exceto a abordagem Checklist, as demais técnicas são consideradas Técnicas de Leitura, cujos procedimentos específicos e bem definidos para se realizar a leitura de um documento as classificam como sistemática.

É com relação à técnica TUCCA que a definição deste trabalho teve início. Como esta técnica baseia-se no DR como entrada para a sua aplicação, a forma apresentada por esse documento exerce forte influência para a aplicação de seus passos. Assim, as Diretrizes propostas por este trabalho, as quais são apresentadas no capítulo seguinte, fornecem instruções que tornam mais prática a aplicação da TUCCA e provê um padrão que facilita a implementação da ferramenta que está sendo desenvolvida para a automatização da mesma.

5. Diretrizes para elaboração de

Documento de Requisitos com ênfase

nos Requisitos Funcionais

5.1

Considerações Iniciais

Embora haja padrões para elaboração de DR, como pode ser visto no Capítulo 3, Seção 3.2, nenhum deles explica o que realmente deve ser escrito na seção que especifica um requisito funcional, mas apenas cita que o DR deve conter tal seção. Visto que esta é geralmente considerada uma das partes mais importantes de um DR, pois descreve como o sistema de software deve funcionar [Pozgaj et al., 2003], um mínimo de detalhe deve ser exigido para que seja possível entender melhor o que está sendo solicitado para o sistema a ser desenvolvido. Muitas vezes, cada requisito é exposto de uma forma diferente num mesmo DR, alguns abordando mais detalhes que outros ou com as informações agrupadas em um único parágrafo. Desta forma, partes do requisito funcional ficam subentendidas, tendo o desenvolvedor que fazer suposições sobre o que está sendo requisitado.

Outra questão é que o fato de os Requisitos Funcionais estarem descritos de maneiras diferentes dificulta a aplicação da técnica TUCCA [Belgamo, 2004], tornando-a mais demorada, pois seus passos exigem que sejam localizadas e destacadas determinadas características dos requisitos funcionais.

Sendo assim, este capítulo apresenta as Diretrizes para elaboração de DR com enfoque em Requisitos Funcionais, as quais procuram contribuir para a qualidade do DR, evitando muitos dos problemas decorrentes de especificações de software mal escritas, e reduzir o esforço dedicado ao trabalho de inspeção. Além disso, o objetivo principal dessas Diretrizes é facilitar a aplicação da técnica TUCCA [Belgamo, 2004], tornando seus passos mais fáceis de serem seguidos. Essas Diretrizes são compostas de um Formato para especificação de Requisitos Funcionais, de algumas Recomendações de Escrita e de um Checklist Pré-Inspeção que antecede o processo de inspeção do DR.

O capítulo está organizado da seguinte maneira: na Seção 5.2, apresentam-se as Diretrizes propostas, sendo esta subdividida nas Seções: 5.2.1, na qual se apresenta o Formato para especificação de um Requisito Funcional; 5.2.2, Seção em que as Recomendações de Escrita são apresentadas e 5.2.3, na qual o Checklist Pré-Inspeção está descrito. Por fim, na Seção 5.3 são apresentadas as Considerações Finais.