Fase 1 - Levantamento e Análise de Requisitos

Prévia do material em texto

3 - Fase 1: levantamento e análise de requisitos 
 
Antes de podermos efetivamente projetar um banco de dados, devemos 
conhecer e analisar as expectativas dos usuários e os usos intencionados do 
banco de dados com o máximo de detalhe passível, Esse processo é chamado 
de levantamento e análise de requisitos. Para especificar os requisitos, primeiro 
identificamos as outras partes do sistema de informação que interagirão com o 
sistema de banco de dados. Estas incluem usuários e aplicações novas e 
existentes, cujos requisitos são então coletados e analisados. Normalmente, as 
seguintes atividades fazem parte dessa fase: 
 1 - As principais áreas de aplicação e grupos de usuário que utilizarão o 
banco de dados ou cujo trabalho será afetado por ele são identificados. Os 
principais indivíduos e comitês dentro de cada grupo são escolhidos para 
executar etapas subseqüentes do levantamento e especificação de requisitos. 
 2 - A documentação existente referente às aplicações é estudada e 
analisada. Outra documentação — manuais de política, formulários, relatórios e 
gráficos de organização — é revista para determinar se tem qualquer influência 
sobre o processo de levantamento e especificação de requisitos. 
 3 - O ambiente operacional atual e o uso planejado da informação são 
estudados, Isso inclui a análise dos tipos de transações e sua freqüência, bem 
como o fluxo de informações dentro do sistema. Características geográficas 
com relação a usuários, origem de transações, destino de relatórios, e assim 
por diante, são estudados. Os dados de entrada e saída para as transações 
são especificados. 
 4 - Respostas escritas aos conjuntos de perguntas às vezes são 
coletadas de usuários de banco de dados em potencial ou grupos de usuários. 
Essas perguntas envolvem as prioridades dos usuários e a importância que 
eles dão as várias aplicações. Os principais indivíduos podem ser entrevistados 
para ajudar na avaliação do valor da informação e no estabelecimento de 
prioridades. 
A análise de requisitos é executada para os usuários finais, ou clientes, do 
sistema de banco de dados, por uma equipe de analistas de sistemas ou 
especialistas em requisitos. É provável que os requisitos iniciais sejam 
informais, incompletos, inconsistentes e parcialmente incorretos. Portanto, 
muito trabalho precisa ser feito para transformar esses requisitos iniciais em 
uma especificação da aplicação, que pode ser usada por desenvolvedores e 
testadores como ponto de partida para escrever a implementação e os casos 
de teste. Como os requisitos refletem o conhecimento inicial de um sistema que 
ainda não existe, eles inevitavelmente mudarão. Portanto, é importante usar 
técnicas que ajudem os clientes a convergir rapidamente nos requisitos da 
implementação. 
Existe evidência de que a participação do cliente no processo de 
desenvolvimento aumenta sua satisfação com o sistema entregue. Por esse 
motivo, muitos profissionais usam reuniões e workshops envolvendo todos os 
participantes. Uma metodologia para detalhar os requisitos iniciais do sistema é 
chamada de Joint Application Design (JAD). Mais recentemente, foram 
desenvolvidas técnicas, como o Projeto Contextual (Contextual Design), que 
envolvem projetistas inseridos no local de trabalho em que a aplicação deverá 
ser usada. Para ajudar os representantes dos clientes a entenderem melhor o 
sistema proposto, é comum percorrer o fluxo de trabalho, os cenários de 
transação ou criar um protótipo rápido da aplicação. 
Os modos anteriores ajudam a estruturar e detalhar requisitos, mas ainda os 
deixam em um estado informal. Para transformar os requisitos, em uma 
representação mais bem estruturada, as técnicas de especificação de 
requisitos são usadas. Estes incluem análise orientada a objeto (AOO), 
diagramas de fluxo de dados (DFD) e o detalhamento dos objetivos da 
aplicação. Esses métodos usam técnicas diagramáticas para organizar e 
apresentar requisitos de processamento de informação. A documentação 
adicional, na forma de texto, tabelas, gráficos e requisitos de decisão, costuma 
acompanhar os diagramas. Existem técnicas que produzem uma especificação 
formal que pode ser verificada matematicamente pela consistência e análise 
simbólica hipotética. Esses métodos podem se tornar padrão no futuro para as 
partes dos sistemas de informação que atendem às funções de missão crítica e 
que, assim, precisam atuar conforme o planejado. Os métodos de 
especificação formal baseados em modelo, dos quais a notação e metodologia 
Z é um exemplo proeminente, podem ser considerados extensões do modelo 
ER e, portanto, são os mais aplicáveis ao projeto do sistema de informação. 
Algumas técnicas auxiliadas por computador — chamadas de ferramentas 
Upper CASE — foram propostas para ajudar a verificar a consistência e a 
integridade das especificações, que normalmente são armazenadas em um 
único repositório e podem ser exibidas e atualizadas enquanto o projeto 
prossegue. Outras ferramentas são usadas para rastrear as ligações entre 
requisitos e outras entidades de projeto, como módulos de código e casos de 
teste. Esses bancos de dados de rastreabilidade são especialmente 
importantes em conjunto com os procedimentos impostos de gerenciamento de 
mudança para sistemas onde os requisitos mudam com freqüência. Eles 
também são usados em projetos contratuais onde a organização de 
desenvolvimento precisa fornecer evidência documental ao cliente de que 
todos os requisitos foram implementados. 
A fase de levantamento e análise de requisitos pode ser bastante demorada, 
mas é crucial para o sucesso do sistema de informação. A correção de um erro 
de requisitos é mais dispendiosa do que a correção de um erro cometido 
durante a implementação, porque os efeitos de um erro de requisito 
normalmente são difundidos e, como resultado, é preciso reimplementar muito 
mais trabalho adiante. Não corrigir um erro significativo quer dizer que o 
sistema não satisfará o cliente e pode nem sequer ser utilizado.