Revisões técnicas formais

II.2 ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS

II.2.1 ATIVIDADES FUNDAMENTAIS, O ANALISTA DE SISTEMA E CAUSAS DE PROBLEMAS [PRESSMAN-95]

A seguir são apresentadas as atividades consideradas fundamentais na análise e especificação de requisitos: reconhecimento do problema, avaliação e síntese, modelagem e especificação.

1. 
   Reconhecimento do problema:
   

• 
  O analista estuda a Especificação do Sistema (caso exista) e o Plano do Projeto.
  
• 
  O analista estabelece contato com todos aqueles que estão relacionados ao projeto.
  

• 
  A meta do analista é o reconhecimento dos elementos problemáticos básicos, conforme percebidos pelo usuário/cliente.
  

2. 
   Avaliação e síntese:
   

O analista deve:

• 
  Avaliar o fluxo e o conteúdo da informação
  
• 
  Definir e elaborar todas as funções do software
  
• 
  Entender o comportamento do software no contexto dos eventos que afetam o sistema
  
• 
  Estabelecer as características de interface com o sistema
  
• 
  Descobrir restrições de projeto.
  

• 
  Depois de avaliar os problemas atuais e as informações desejadas (entrada e saída), o analista começa a sintetizar uma ou mais soluções.
  

3. 
   Modelagem:
   

• 
  Durante a atividade de avaliação e síntese o analista cria modelos do sistema num esforço para compreender melhor o fluxo de dados e de controle, o processamento funcional, etc. O modelo serve como um fundamento para o projeto de software e como base para a criação de sua especificação.
  

• 
  O foco principal desta atividade deve ser “o que” e não “como”.
  

4. 
   Especificação:
   

As técnicas de análise podem levar a uma especificação em papel ou baseada em computador que contenha descrições em linguagem natural e gráfica dos requisitos de software.

Há várias propostas de formatos de especificações, como os propostos pelo National Bureau of Standards, o IEEE e o Departamento de Defesa Americano.

Alguns dos itens que deveriam constar de uma especificação são:

• 
  Objetivos e restrições do projeto
  
• 
  Descrição dos dados
  
• 
  Descrição das funções
  
• 
  Descrição comportamental
  
• 
  Exigências de desempenho
  
• 
  Descrição da interface
  
• 
  Critérios de validação (Descrição dos testes a serem realizados para validar a função, o desempenho e as restrições especificadas).
  
• 
  Bibliografia
  
• 
  Apêndices
  

Para facilitar a geração de especificações são utilizados métodos. Atualmente os métodos mais utilizados com este objetivo são os baseados na Análise Estruturada e na Análise Orientada a Objetos [Pressman-95] . Na apostila Análise Essencial deste curso é apresentado um método baseado na Análise Estruturada e no próximo curso (Engenharia de Software II) é apresentada a abordagem orientada a objetos.
O analista de sistemas tem como função definir os elementos para um sistema específico baseado em computador. Para optar por uma solução o analista faz considerações dos seguintes tipos:

• 
  Considerações de projeto (prazo, custo, etc)
  
• 
  Considerações de negócios
  
• 
  Análise técnica
  
• 
  Avaliação da manufatura
  
• 
  Questões humanas
  
• 
  Interfaces ambientais
  
• 
  Considerações jurídicas
  

Algumas das causas apontadas pelas dificuldades nesta área são:

• 
  Dificuldade de comunicação
  
• 
  Tendência a se realizar esta atividade o mais rápido possível, iniciando-se logo a codificação
  
• 
  Uso de técnicas e ferramentas inadequadas, resultando em especificações imprecisas
  

II.2.2 COMO OBTER REQUISITOS [Yourdon-90] [Pressman-95]

Podemos obter requisitos através de:

• 
  Entrevistas
  
• 
  FAST ( Facilitaded Application Specification Techniques) Ex: JAD (Joint Application Development)
  
• 
  Questionários
  
• 
  Observação de aplicações semelhantes
  
• 
  Coleta de formulários, relatórios, manuais, imagens de telas, listagens de programas, etc, que contenham dados sobre o sistema
  
• 
  Pesquisa em livros e relatórios de pesquisa
  

Entrevistas:
Diretrizes:

• 
  Desenvolva um plano geral de entrevistas
  
• 
  Obtenha prévia autorização para entrevistar as pessoas
  
• 
  Planeje cada contato com o entrevistado
  
• 
  Certifique-se que a pessoa selecionada conhece o assunto da entrevista
  
• 
  Colete, antecipadamente, tantos dados quanto possível
  
• 
  Prepare as perguntas antecipadamente
  
• 
  Utilize ferramentas automatizadas quando adequado. Por exemplo para a prototipagem.
  
• 
  Obtenha informações dos vários participantes do projeto.
  

• 
  Utilize um estilo adequado:
  

• 
  Relacionamentos – pede-se ao entrevistado que explique o relacionamento entre o que está em discussão e as demais partes do sistema
  
• 
  Pontos de vista alternativos – pede-se ao entrevistado que descreva o ponto de vista de outros em relação ao item que está sendo discutido
  
• 
  Detalhamento
  
• 
  Confirmação
  
• 
  Dependências
  

Problemas que podem surgir:

• 
  Pessoas que não conseguem descrever seu conhecimento
  
• 
  Pessoas que não desejam passar seu conhecimento para outros
  
• 
  Pessoas que dão palpites sobre assuntos dos quais não têm conhecimento
  
• 
  Confusão entre o que pertence ao sistema e o que é externo a ele
  
• 
  Dificuldade de se chegar a um consenso quando várias pessoas são entrevistadas separadamente
  

FAST (Facilitaded Application Specification Techniques)
Muitas abordagens de FAST têm sido propostas com as seguintes diretrizes básicas:

• 
  No encontro inicial entre o desenvolvedor e o cliente surgem perguntas e respostas básicas que ajudam a estabelecer o escopo do problema e a percepção de uma solução.
  
• 
  Após esses encontros iniciais, o desenvolvedor e o cliente escrevem uma requisição de produto de uma ou duas páginas.
  
• 
  Um lugar, uma data e um horário para a FAST são escolhidos e um moderador é designado.
  
• 
  Integrantes das organizações tanto do desenvolvedor como do cliente são convidados a participar.
  
• 
  A requisição do produto é distribuída a todos os participantes antes da data do encontro.
  
• 
  A cada participante é solicitada uma descrição de sua visão do sistema.
  

• 
  Regras para a preparação e participação são estabelecidas
  
• 
  Uma agenda que seja formal o bastante para cobrir todos os pontos importantes, mas informal o suficiente para encorajar o livre fluxo de idéias é sugerida.
  
• 
  Um encontro é realizado num local neutro e conta com a participação tanto de desenvolvedores como de clientes.
  
• 
  Um mecanismo de apresentação (planilha, cartazes, etc) é usado.
  
• 
  A meta é identificar o problema, propor elementos de solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos de solução num clima que facilite a realização da atividade.
  

Exemplo de FAST: JAD (Joint Application Development)

• 
  Método desenvolvido e utilizado na IBM
  
• 
  Criado na década de 70 no Canadá e introduzido no Brasil em 85, com adaptações.
  
• 
  Reúne os vários participantes do projeto num encontro longo e previamente planejado.
  

• 
  Encontros do JAD:
  

• 
  Reunião Inicial: A sessão de design é planejada
  
• 
  Reunião de Revisão: É revisto o que foi combinado na reunião inicial.
  
• 
  Sessão de Design: A atividade planejada é realizada.
  

II.2.3 REVISÃO DA ESPECIFICAÇÃO

A revisão é conduzida tanto pelo desenvolvedor como pelo cliente para garantir que:

• 
  O escopo do projeto foi corretamente delineado
  
• 
  As funções, o desempenho e as interfaces foram adequadamente definidas
  
• 
  A análise do ambiente e dos riscos de desenvolvimento justificam o sistema
  
• 
  O desenvolvedor do sistema e o cliente têm a mesma percepção dos objetivos do sistema
  

Podem ser realizadas desde revisões informais até as revisões técnicas formais. Podemos realizar revisões informais, através por exemplo de uma solicitação para que um colega de trabalho verifique rapidamente o que acha de algum aspecto de um dos produtos do processo de desenvolvimento. Há, no entanto, revisões mais formais que requerem mais tempo e dedicação para serem realizadas, como o “walkthrough” e a inspeção.

As revisões técnicas formais (RTFs) atuam como filtros, purificando os produtos ao longo do processo de desenvolvimento.
Através das RTFs pode-se verificar se o que está sendo revisto atende a requisitos já estabelecidos e a padrões previamente definidos.
Há dois tipos de revisões:

• 
  “Ad hoc”: Todos os revisores utilizam técnicas não sistemáticas e a eles são atribuídas as mesmas responsabilidades.
  
• 
  Com uso de “checklist”: É utilizada uma lista de verificação com o objetivo de sugerir formas dos revisores identificarem falhas.
  

As RTFs são realizadas através de reuniões. Independente do tipo da revisão toda reunião deve seguir os seguintes preceitos:

• 
  Deve envolver entre 3 e 5 pessoas.
  
• 
  Deve haver uma preparação antes da reunião. No entanto, não se deve requerer de cada pessoa um trabalho de mais de 2 horas.
  
• 
  A duração da reunião não deve ultrapassar duas horas.
  

Antes da reunião de revisão são realizadas as seguintes atividades:

• 
  A pessoa que está desenvolvendo o produto deve comunicar ao líder do projeto que está no momento de submeter o produto à revisão.
  
• 
  O líder do projeto entra em contato com o líder de revisão que avalia o produto quanto a sua facilidade de leitura, gera cópias e distribui para os revisores.
  
• 
  O líder de revisão estabelece uma agenda para a reunião.
  

Durante a reunião é importante que sejam observados os seguintes aspectos:

• 
  Devem estar presentes o líder da revisão, os revisores e aquele que desenvolveu o produto.
  
• 
  A reunião começa com uma explicação da agenda e aquele que desenvolveu o produto explica o material, enquanto os revisores interrompem quando necessário para dar suas sugestões e criticar.
  
• 
  Cada erro ou problema detectado é anotado por um dos revisores que assume o papel de redator.
  

Ao fim da reunião o grupo presente deve decidir se:

• 
  Aceitam o produto sem modificações.
  

• 
  Rejeitam o produto devido a erros sérios (quando esses erros tiverem sido corrigidos outra reunião deverá ser realizada).
  
• 
  Aceitam o produto provisoriamente. Os erros que foram encontrados deverão ser corrigidos mas não é necessária uma nova reunião.
  

Algumas das vantagens das RTFs são as seguintes:

• 
  São úteis para o treinamento, já que permitem aos novos profissionais um contato com o que está sendo usado na Empresa.
  
• 
  Possibilitam que várias pessoas tenham contato com partes do sistema, disseminando informações.
  
• 
  A revisão realizada nas fases iniciais do desenvolvimento possibilita que determinados erros sejam logo descobertos.