AES-T04-LevantamentoRequisitos

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Disciplina:
Análise Estruturada de Sistemas
Levantamento de Requisitos
Profa. Tânia Mara Paiva de Oliveira
2
“Coletar requisitos é o processo de
definir e documentar as necessidades das 
partes interessadas (stakeholders) para alcançar
os objetivos do projeto e do produto, necessárias
para atender as necessidades e expectativas das partes interessadas. ”
“Os requisitos incluem as necessidades quantificadas
e documentadas, além das expectativas do patrocinador, cliente e outras partes interessadas. Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem medidos uma vez em que a execução do projeto se inicie”
Levantamento de Requisitos
3
usuários e partes interessadas
Levantamento e Análise de Requisitos
4
Dificuldades no levantamento de requisitos
S. Pompilho (2002) cita um exemplo do relatório produzido por McKinsey, onde se afirmava que dois terços das empresas ali estudadas estavam desapontadas com o atendimento recebido em sistemas de informação.
Causas prováveis:
Na fase de levantamento de requisitos do projeto não é utilizada uma técnica adequada para extrair os requisitos do sistema;
Falha do analista em não descrever os requisitos do sistema de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto;
5
Dificuldades no levantamento de requisitos
Entre as dificuldades encontradas na fase de
 levantamento de requisitos estão:
o usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e não consegue transmitir para o analista;
requisitos identificados, mas que não são realistas e não identificam os requisitos similares informados por pessoas diferentes.
Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.
6
Nesta fase do projeto os analistas de sistemas, fazem reuniões em conjunto com o cliente, usuários e outras partes interessadas (stakeholders) com os seguintes objetivos, a saber:
Entender o domínio do negócio.
Definir quais os serviços e funcionalidades o sistema deverá fornecer.
Definir qual será o 
desempenho do sistema.
Definir as restrições de 
hardware, ambiente e do 
negócio.
Levantamento de Requisitos
7
Figura 1. Processo de levantamento e análise de requisitos (SOMMERVILLE, 2003)
1
2
3
4
5
6
Sommerville (2003) propõe um processo genérico de levantamen-to e análise que contém as seguintes atividades:
Levantamento de Requisitos
8
 Levantamento de Requisitos 
Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;
Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
Resolução de conflitos: Quando múltiplos  stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos.
9
Analista de Negócios
Comercial
Financeiro
Produção
Exportação
Jurídico
CONCILIADOR
Levantamento de Requisitos
10
O levantamento de Requisitos de Software
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
Especificação final de requisitos;
Geração do documento formal de requisitos, segundo os padrões da empresa.
O levantamento e análise de requisitos é um processo iterativo, com uma continua validação de uma atividade para outra.
11
Exemplo de Requisitos:
Uma funcionalidade do sistema Emitir relatório dos cargos com os salários mais altos da empresa
Uma restrição do sistema  os funcionários devem ter acesso restrito aos dados de salário e endereço
Uma premissa  o banco de dados a ser utilizado será o Oracle
Mensurável tempo médio de resposta clique do cliente: 5 seg.
Avaliado subjetivamente qualidade da documentação
Levantamento de Requisitos
Analista de Sistemas
Usuário
Análise de Requisitos
Um cliente solicita a fabricação de um automóvel com os seguintes requisitos:
Número de pessoas  duas
Porta malas  pequeno
Cor do carro  vermelho
Função  andar pelo centro da cidade
Premissa  não tem restrição no orçamento
A fábrica de automóveis
entrega este produto...
SMART Fortwo
Análise de Requisitos
14
O cliente queria o seguinte produto...
Análise de Requisitos
Ferrari Four
(FF)
16
Análise de Requisitos
A Casa Maluca
17
Requisitos
Os requisitos podem ser a base para o contrato entre fornecedor e cliente, portanto deve ser definido detalhadamente para que não ocorra mal entendidos entre as partes.
No contrato podemos ter uma lista de requisitos
E
18
Requisitos Funcionais
Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
Exemplos:
O sistema deverá cancelar automaticamente um orçamento que tenha sido feito há mais de 30 dias e não tenha sido transformado em venda.
O sistema deve ser capaz de armazenar todas as informações sobre seus clientes (RG, CPF, Nome, data de nascimento e endereço) no banco de dados.
O sistema deverá atribuir um identificador único (código) para cada pedido de produtos.
Exemplos
Lista de Requisitos Funcionais
Manter cadastro de Cursos
Consultar Cursos oferecidos
Emitir Relatório de Cursos oferecidos
Manter cadastro de Alunos
Manter cadastro de Turmas
Cadastrar Salas de Aula
Exibir uma função para seleção Salas x Turmas
Exibir uma função para calcular os juros compostos à taxa de 14% ano, de um depósito fixo, por um período de três anos.
Emitir relatório de Turmas x Alunos
Emitir relatório de Faltas e Notas.
Emitir relatório de ICMS mensal.
O “manter” de um determinado requisito é composto pelas funções: inclusão, alteração, exclusão e consulta.
Exemplos
20
Requisitos Não Funcionais
São requisitos não diretamente relacionados às funções do sistema, que mapeiam os aspectos qualitativos e técnicos de um sistema.
Os requisitos não funcionais são definidos principalmente na fase de projeto, quando são tomadas as decisões sobre a interface com o usuário, o hardware e o software e a arquitetura subjacente do sistema.
21
Requisitos Não Funcionais
Podem ser classificados em: 
Requisitos de produto: relacionados ao comportamento do produto tais como facilidade de uso, eficiência (desempenho, recursos exigidos), confiabilidade, portabilidade
Requisitos organizacionais: relacionados às organizações do cliente e do fornecedor tais como práticas, padrões e restrições contratuais e de projeto.
Requisitos externos: relacionados a restrições impostas por fatores externos ao sistema tais como restrições de interoperabilidade, éticas e governamentais.
Performance (tempo de resposta) .
Segurança (restrições de acesso, privilégios) .
Perspectiva do usuário (padrão das cores, disposição dos objetivos na tela); 
Comunicabilidade (e-mail, VoIP, Browser).
Usabilidade e portabilidade (a aplicação deve rodar em vários tipos de aplicativos: móveis, desktop, note). 
Linguagem de desenvolvimento.
Banco de dados.
Requisitos Não Funcionais
Exemplos
Desenvolvimento em Java.
Banco de dados MySQL.
Alta performance do sistema frente de caixa.
Segurança máxima na venda pela Internet.
Manutenabilidade.
Usabilidade no sistema de frente de caixa.
Precisão.
Disponibilidade 24 horas por dia, 7 dias na semana
Alto volume de transações.
Reutilização de código
Requisitos Não Funcionais
Exemplos
As técnicas
de levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. 
Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas pelos analistas de sistemas. 
Técnicas de Levantamento de Requisitos
25
Técnicas de Levantamento de Requisitos
Técnicas a serem estudadas:
Entrevistas
Questionários
Workshop
BrainStorming
Levantamento orientado a pontos de vista
Prototipagem
Etnografia
JAD
 
Técnica de levantamento de requisitos tradicional 
O entrevistador deve permitir que o entrevistado exponha suas idéias. 
Diretrizes para entrevistas bem sucedidas:
Desenvolver um plano geral de entrevistas:
Relacionar os tópicos a serem levantados
Elaborar um questionário com as perguntas que serão feitas ao usuário
É importante que o analista se integre com as funções e a rotina do usuário para ajudar na elaboração das questões
Enviar com antecedência ao usuário os tópicos que serão levantados na entrevista
1 - Entrevistas
Diretrizes para entrevistas bem sucedidas:
Planejar a entrevista para fazer uso eficiente do tempo.
Certificar-se da autorização para falar com o usuário
Tentar descobrir que informação o usuário está mais interessado.
Utilizar uma linguagem e postura adequadas ao entrevistar. 
Ao solicitar a entrevista adequar o dia, hora, local, horário de início e de término às necessidades do usuário. 
As entrevistas devem ser toda documentada através de atas de reunião.
1 - Entrevistas
A atitude do analista em relação à entrevista 
determina seu fracasso ou sucesso. 
Uma entrevista não é uma competição
Deve-se evitar o uso excessivo de termos técnicos.
Não conduzir a entrevista em uma tentativa de persuasão. 
O modo como o analista fala não deve ser muito alto, nem muito baixo.
As opiniões devem ser perguntadas diretamente, por exemplo: “Jose vê a solução para o projeto dessa forma. Qual é a sua opinião?”
Nunca deve criticar a credibilidade do entrevistado.
O analista deve ter em mente que o entrevistado é o perito no assunto e fornecerá as informações necessárias ao sistema.
1 - Entrevistas
Para elaborar perguntas detalhadas 
é necessário solicitar que o usuário:
Explique o relacionamento entre o 
que está em discussão e as demais partes do sistema.
Descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido.
Descreva informalmente a narrativa do item em que o analista deseja obter informações.
Perguntar ao usuário se o item em discussão depende para a sua existência de alguma 
outra coisa, para assim poder 
juntar os requisitos comuns do 
sistema, formando assim um 
escopo conciso.
1 - Entrevistas
O uso de questionário é indicado, 
quando há diversos grupos de usuários 
que podem estar em locais diferentes 
do país ou que os acessos as pessoas 
são difíceis, por causa do tempo ou localização. Neste caso, elaboram-se pesquisas específicas com usuários selecionados, cuja contribuição em potencial pareça mais importante.
Existem vários tipos de questionários que podem ser utilizados:
Múltipla escolha
Lista de verificação 
Questões com espaços em branco. 
O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta.
2 - Questionários
A lista de verificação é uma lista de itens pré estabelecidos onde o entrevistador deverá marcar com um “X” ao lado de cada item com as colunas, por exemplo: nunca, algumas vezes, sempre.
2 - Questionários – Lista de Verificação
Lista de Verificação
Questão
Nunca
Algumas Vezes
Sempre
Você importadados de outro setor da empresa.
Você utiliza a tabela de clientes do banco dados corporativo (DB2).
Aperformance do sistema é um requisito importante no seu setor.
O questionário deve ser acompanhado por uma carta explicativa, para enfatizar a importância dessa pesquisa para a organização.
Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. 
A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. 
Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas.
 Esta documentação deve ser validada com os usuários.
2 - Questionários
Técnica de levantamento de requisitos em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos.
3 - Workshops
Ao contrário das reuniões, onde existe pouca interação entre todos os elementos presentes, o workshop tem o objetivo de acionar o trabalho em equipe. 
Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador.
3 - Workshops
Uma técnica utilizada em workshops é o brainstorming (Tempestade cerebral  Tempestade de idéias). 
Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido.
3 - Workshops: Brainstorming
Alguns aspectos importantes a serem 
considerados no brainstorming
Postura do condutor do seminário 
deve ser de mediador e observador
A convocação deve possuir dia, hora, local, horário de início e de término e o assunto a ser discutido. 
A reunião deve ser toda documentada através de atas de reunião.
Todos tem liberdade de trazer novas idéias para o sistema que será desenvolvido. Devido a esta total liberdade, deve haver um elevado comportamento ético de respeito ao outro.
3 - Workshops: Brainstorming
Enfatizar a quantidade e não a qualidade 
das idéias.
Evitar críticas, avaliações ou julgamentos 
sobre as idéias.
Apresentar as idéias tais como elas surgem 
na cabeça, sem rodeios, elaborações ou 
maiores considerações. Não deve haver medo 
de “dizer bobagem”. As idéias consideradas “loucas” podem oferecer conexões para outras mais criativas.
Estimular todas as idéias, por mais “malucas” que possam parecer.
“Pegar carona” nas idéias dos outros, criando a partir delas.
Escrever as palavras do participante. Não interpretá-las.
Regras do Brainstorming
Independente do tamanho do sistema, os stakeholders têm algum tipo de interesse nos requisitos do sistema. Assim existem diferentes pontos de vista que devem ser considerados. 
Os diferentes pontos de vista a respeito de um problema ‘vêem’ o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas em 
geral apresentam alguma 
duplicidade, de modo que 
apresentam requisitos 
comuns.
4 - Levantamento orientado a pontos de vista
O método VORD (viewpoint-oriented requirements definition – definição de requisitos orientada a ponto de vista) foi projetado como um framework orientado a serviço para o levantamento e análise de requisitos.
4- Levantamento orientado a pontos de vista
Identificação de pontos de vista
 - Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema.
Estruturação de pontos de vista
 - Agrupar pontos de vista relacionados, segundo uma hierarquia. Serviços comuns são fornecidos nos níveis mais altos da hierarquia. 
Documentação do ponto de vista 
 - Refinar a descrição dos pontos de vista e serviços identificados.
Mapeamento de sistema conforme pontos de vista
 - Identificar objetos através das informações de serviços que estão encapsulados nos pontos de vista.
4 - Levantamento orientado a pontos de vista
4 - Hierarquia de pontos de vista
Consultar saldo
Retirar dinheiro
Solicitar cheque
Transferência
A prototipação
pode ser utilizada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários.
O uso de protótipo auxilia na elicitação e validação dos requisitos de sistema.
O protótipo é indicado para:
Estudar as alternativas de interface do usuário.
Problemas de comunicação com outros produtos.
Viabilidade de atendimento dos requisitos de desempenho. 
5 - Prototipação
Problemas de comunicação com outros produtos.
5 - Prototipação
Balança
Leitor de cartão
Leitor código barra
Pára!
Que negócio é esse de problemas de comunicação com outros produtos?
Sistema
Problemas de comunicação com outros produtos.
5 - Prototipação
Sistema Faturamento
Sistema de Contabilidade
Sistema de Vendas
Problemas de comunicação com outros produtos.
5 - Prototipação
Cadastro de Clientes
IBM DB2
Sistema 
Cálculo Seguro Automóvel
MS SQL Server
Cadastro Tempo sem Sinistro
Oracle
As técnicas utilizadas na elaboração do protótipo são: interface de usuário, relatórios textuais, relatórios gráficos e outros.
Benefícios do protótipo são as reduções dos riscos na construção do sistema
Para ter sucesso na elaboração dos protótipos é necessária:
Escolha do ambiente de desenvolvimento do protótipo.
Entendimento dos objetivos do protótipo por parte de todos os interessados no projeto.
Foco em todas as áreas compreendidas
Rapidez na construção.
5 - Prototipação
47
6 - Etnografia
A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história. 
Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um entendimento completo e detalhado de culturas particulares.
Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado.
48
6 - Etnografia
O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado. 
O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.
49
6 - Etnografia
Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:
Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;
Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.
50
6 - Etnografia
Alguns itens importantes que devem ser executados antes, durante e depois do estudo de observação:
Antes, é necessário identificar as áreas de usuário a serem observadas; 
obter a aprovação das gerências apropriadas para executar as observações; 
obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; 
e explicar a finalidade do estudo;
51
6 - Etnografia
Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado.
 para isso é preciso observar os agrupamentos organizacionais atuais; 
as facilidades manuais e automatizadas; 
coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; 
acumular informações estatísticas a respeito das tarefas, como: frequência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada.
52
6 - Etnografia
Além de observar as operações normais de negócios acima é importante observar as exceções;
Depois, é necessário documentar as descobertas resultantes das observações feitas. 
Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.
A análise de observação tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido a erros em suas observações.
 Mas em geral a técnica de observação é muito útil e frequente/ usada para complementar descobertas obtidas por outras técnicas.
53
7 – JAD - Joint Application Development
JAD - Joint Application Development - Desenvolvimento de Aplicação Conjunta - é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores.
O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser.
Através da sua utilização os desenvolvedores ajudam os usuários a formular problemas e explorar soluções.
Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
54
7 - JAD
A técnica JAD tem quatro princípios básicos:
Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. 
O resultado final será a determinação dos objetivos e requisitos do sistema;
Uso de técnicas visuais: para aumentar a comunicação e o entendimento;
Manutenção do processo organizado e racional: o JAD emprega a análise top-down e atividades bem definidas. 
Possibilita assim, a garantia de uma análise completa, reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção;
55
7 - JAD
Utilização de documentação padrão: preenchida e assinada por todos os participantes.
Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes.
A técnica JAD é composta de duas etapas principais: 
planejamento, que tem por objetivo elicitar e especificar os requisitos; e
projeto, em que se lida com o projeto de software.
56
7 - JAD
Cada etapa consiste em três fases: adaptação, sessão e finalização. 
A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material.
Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados.
A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).
57
7 - JAD
Há seis tipos de participantes, embora nem todos participem de todas as fases:
Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança;
Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar ideias e expressá-las com clareza;
58
7 - JAD
Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto;
Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas-chave dentro da empresa que tem uma visão melhor do todo e de como ele será usado;
59
7 - JAD
Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça;
Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.
O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para diversas finalidades, como: planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos.
60
Grupos
de Técnicas 
61
A Escolha
Não existe uma técnica padrão para o processo de levantamento de requisitos. 
Para alcançar um levantamento de requisitos mais preciso é importante o conhecimento de diversas técnicas para saber que técnica de levantamento aplicar em cada situação.
62
 O Perfil do Analista
É primordial que o analista possua perfil adequado. O analista de sistemas precisa de mais do que apenas a capacidade de desenhar fluxogramas e outros diagramas técnicos.
O analista de sistemas tem a função de projetar e analisar sistemas de ótimo desempenho.
Para que esse objetivo seja alcançado, é necessário o analista de sistema possuir a capacidade de:
Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
Absorver fatos pertinentes de fontes conflitantes ou confusas;
Entender os ambientes do usuário/cliente;
63
O Perfil do Analista
Aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente;
Comunicar bem nas formas escrita e verbal e entender o objetivo global do software. 
64
 O Perfil do Analista
É primordial que o analista possua perfil adequado. O analista de sistemas precisa de mais do que apenas a capacidade de desenhar fluxogramas e outros diagramas técnicos.
O analista de sistemas tem a função de projetar e analisar sistemas de ótimo desempenho.
Para que esse objetivo seja alcançado, é necessário o analista de sistema possuir a capacidade de:
Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
Absorver fatos pertinentes de fontes conflitantes ou confusas;
Entender os ambientes do usuário/cliente;
65
O Perfil do Analista
Aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente;
Comunicar bem nas formas escrita e verbal e entender o objetivo global do software. 
Bibliografia Complementar
Sommerville, Ian. Engenharia de Software. 
6ª Ed. São Paulo: Addison Wesley, 2003.
Pompilho, S. Análise Essencial: Guia Prático de Análise de Sistemas, 2ª. Ed., Rio de Janeiro: Ciência Moderna, 2002.
 
Muito Obrigado!
tania.paiva@aedu.com