6. ESTUDO DE CASO
6.3 Aplicação de Técnicas de inspeção nos DROs
6.3.1 Inspeção no DRO do PG
I. Aplicação da PBR-Usuário no DRO do PG
Os defeitos encontrados com essa técnica são listados abaixo.
• Omissão:
1) Alguns Requisitos Funcionais não continham informações suficientes para
especificar o caso de uso, tornando-os incompletos. Os defeitos assinalados foram:
¾ No Requisito Funcional 14 não foi especificado o que fazer quando na entrada do estacionamento o ingresso mensal é inválido.
¾ Nos Requisitos Funcionais 20 e 21 não foram especificados o que fazer quando na saída do estacionamento os ingressos são inválidos.
¾ No Requisito Funcional 22 não havia informações sobre os eventos que aconteciam quando vários carros deixavam o estacionamento ao mesmo tempo.
2) Averiguou-se que havia Requisitos Funcionais que alteravam os valores de algumas
variáveis, mas não atualizavam as que estavam relacionadas. Os defeitos assinalados foram: ¾ No Requisito Funcional 8, no item Saída, não é descrito qual o novo valor da
variável a.
¾ No Requisito Funcional 10 faltou atualizar o valor da variável a ao alterar o valor da variável r.
¾ No Requisito Funcional 11 faltou atualizar o valor da variável a ao alterar o valor da variável k.
¾ No Requisito Funcional 13, no item Saída, não é descrito qual o novo valor da variável a.
¾ No Requisito Funcional 16 faltou decrementar ‘a’ no item Processamento e incrementar ‘o’ no item Descrição.
3) O documento apresenta Requisitos Funcionais com o item Processamento
incompleto. Os defeitos assinalados foram:
¾ No Requisito Funcional 10 faltou verificar se a variável r <= 0.4*k ao fixar o seu novo valor.
¾ No Requisito Funcional 11 faltou verificar se a variável k <= 1000 ao fixar o seu novo valor.
4) No Documento não fica claro como o sistema de controle de estacionamento
(PGCS) interage com dispositivos de hardware. O defeito assinalado foi:
¾ Interação com a máquina de ingresso, os leitores de cartão, os portões, os sensores de passagem e a unidade de controle. Tem-se apenas que o PGCS receberá e enviará sinais para estes dispositivos.
• Ambigüidade:
1) Havia Requisito Funcional com termo ambíguo. O defeito assinalado foi:
¾ Requisito Funcional 17: - Descrição: “será dado no máximo um ingresso de entrada a cada motorista”.
O termo “máximo” causa ambigüidade, pois significa que pode não dar nenhum ingresso ao motorista.
• Informação Inconsistente:
1) No documento havia várias palavras que semanticamente apresentavam o mesmo
significado, mas estavam designadas por termos diferentes, gerando defeitos de inconsistência de informação. O defeito assinalado foi:
¾ Botão e tecla; sensor de passagem, loop de indução e sensor de indução; leitor de cartão e leitor de ingresso; painel de controle e unidade de controle;
2) Havia contradições entre o que estava descrito na Descrição e no Processamento.
Os defeitos assinalados foram:
¾ No Requisito Funcional 16, no item Descrição era descrito para diminuir o número de vagas disponíveis, que seria a variável a, mas no item Processamento era descrito para incrementar o valor de o por 1.
¾ No Requisito Funcional 8, no item Descrição era descrito para aumentar de um o valor da variável r, mas no item Processamento era descrito para decrementar o valor de r por 1.
• Fato Incorreto:
1) Havia Requisito de Desempenho considerado como tal, mas que não era um
¾ Requisito de Desempenho 4: - Descrição: “só um carro deve atravessar o portão a cada vez”.
¾ Requisito de Desempenho 7: - Descrição: “para cada carro que entra no estacionamento há uma vaga disponível”.
2) Havia Requisito Funcional considerado como tal, mas que não era um Requisito
Funcional. Os defeitos assinalados foram:
¾ Requisito Funcional 3: - Descrição: “O valor default para k é 1000”.
¾ Requisito Funcional 4: - Descrição: “k é dividido em r vagas reservadas e a vagas não reservadas”.
¾ Requisito Funcional 7: - Descrição: “ingressos mensais são válidos durante 30 dias”.
• Miscelânea:
1) Não estava claro os atores que interagiam com o sistema, pois não estavam
explícitos. Além disso, por se tratar de um documento para um sistema embutido, o qual não se tem experiência, a identificação dos atores foi dificultada.
2 ) Havia Requisitos Funcionais que eram melhores explicados por outros requisitos e,
portanto deveriam ser desconsiderados. Os defeitos assinalados foram:
¾ Requisito Funcional 1: - Descrição: “O PGCS deve controlar as entradas e saídas de um estacionamento”.
¾ Requisito Funcional 5: - Descrição: “O PGCS deve apoiar n entradas e m saídas, eventualmente simultâneas”.
II. Aplicação do Checklist no DRO do PG
• Questões Gerais:
1) Por causa do fato de o Checklist consistir de perguntas que verificam o documento
como um todo, onde são checados alguns pontos, não foram percebidas a falta de determinadas informações que seriam necessárias para o MCU. Suas questões foram sendo respondidas com base no entendimento do DR, não prendendo a atenção a detalhes importantes para a modelagem.
2) Verificou-se que a forma apresentada por alguns Requisitos Funcionais não era
informações, confundindo ou dificultando o entendimento do requisito. Outros apresentavam os itens Descrição, Entrada, Processamento e Saída.
3) Verificou-se que o documento não especificava o software e o hardware
necessários.
• Omissão:
1) No quesito desempenho, não foi especificado o volume de entrada e saída de carros
simultaneamente.
2) Nem todos os defeitos do tipo omissão que foram encontrados na inspeção PBR-
Usuário foram descobertos pelo Checklist, pois alguns são mais percebíveis durante a modelagem.
• Ambigüidade, Informação Inconsistente e Fato Incorreto:
1) Os mesmos defeitos do tipo ambigüidade, fato incorreto e informação inconsistente
que foram encontrados na inspeção PBR-Usuário também foram identificados pelo Checklist.
III. Aplicação da TUCCA no DRO do PG
Leitura AGRT
• Omissão:
1) Alguns Requisitos Funcionais descritos na seção “2.3 Funções do Produto” não
foram especificados na seção “3.1 Requisitos Funcionais”. Os defeitos assinalados foram: ¾ Controlar painel de status.
¾ Controlar os portões.
¾ Controlar as máquinas de ingresso. ¾ Controlar os leitores de ingresso.
2) Havia funcionalidades na Lista de Objetivos Não Associados que foram
desconsideradas pela técnica TUCCA, pois a mesma não trata os casos em que o ator é o próprio Sistema. Porém eram funcionalidades que deveriam ser executadas. Os defeitos assinalados foram:
¾ A funcionalidade “Garantir que não mais que k carros estejam no estacionamento” tem associado o ator PGCS.
¾ A funcionalidade “Liberar vagas reservadas quando ingressos mensais expiram” tem associado o ator Sistema.
• Ambigüidade:
1) Os mesmos defeitos do tipo ambigüidade que foram encontrados na inspeção PBR-
Usuário também foram identificados aqui.
• Informação Inconsistente:
1) Os mesmos defeitos do tipo informação inconsistente que foram encontrados na
inspeção PBR-Usuário também foram identificados aqui.
2) Funcionalidades idênticas, porém com sintaxes diferentes foram encontradas na
coluna “Objetivo” do FAO. Os defeitos assinalados foram:
¾ “Fixar um valor novo de r” (Requisito Funcional 10) e “Entrar o número de vagas reservadas” (Seção 2.3 Funções do Produto).
¾ “Escrever o número total de vagas” (Requisito Funcional 11) e “Entrar o número total de vagas” (Seção 2.3 Funções do Produto).
• Fato Incorreto:
1) O defeito do tipo fato incorreto 2 que foi encontrado na inspeção PBR-Usuário
também foi identificado aqui.
• Miscelânea:
1) O mesmo defeito do tipo miscelânea 1 que foi encontrado na inspeção PBR-
Usuário também foi identificado aqui.
2) O item 2 das Questões Gerais do Checklist também foi verificado aqui.
3) Percebeu-se que havia Requisito Funcional que apresentava determinada descrição
que confundia a associação do ator com a funcionalidade. Os defeitos assinalados foram: ¾ Requisito Funcional 10: - Descrição: “a unidade de controle pode fixar um
valor novo de r”.
Da forma que foi expressa a sentença dá a entender que o ator é a unidade de controle, quando o correto seria ator funcionário.
• Omissão:
1) Todos os defeitos do tipo omissão que foram encontrados na inspeção PBR-
Usuário também foram identificados aqui.
• Fato Incorreto:
1) O mesmo defeito do tipo fato incorreto 1 que foi encontrado na inspeção PBR-
Usuário também foi identificado aqui.
• Miscelânea:
1) O mesmo defeito do tipo miscelânea 2 que foi encontrado na inspeção PBR-
Usuário também foi identificado aqui.