ESGP

Prévia do material em texto

ANHANGUERA EDUCACIONAL
FACULDADE DE NEGÓCIOS E TECNOLOGIAS DA INFORMAÇÃO - FACNET
CURSO:		Bacharelado em Sistemas de Informação - BSI
DISCIPLINA:	Engenharia de Software e Gerência de Projetos
Relatório 01: Projeto – Indenticação
Relatório 02: Escopo do Projeto
Relatório 03: Cronograma de Atividades do Projeto.
Relatório 04: Gerência de Riscos do Projeto
Relatório 05: Requisitos do Sistema.
Relatório 06: Projeto de Interface com o Usuário.
Michelle de Oliveira Paz Sousa	RA: 1299.107.560
Professor: Fernando Gonçalves de Oliveira
Engenharia de Software e Gerência de Projetos
TAGUATINGA/DF
2017
Michelle de Oliveira Paz Sousa	RA: 1299.107.560
Relatório 01: Projeto – Indenticação
Relatório 02: Escopo do Projeto
Relatório 03: Cronograma de Atividades do Projeto.
Relatório 04: Gerência de Riscos do Projeto
Relatório 05: Requisitos do Sistema.
Relatório 06: Projeto de Interface com o Usuário.
Atividades Práticas Supervisionadas - ATPS, desenvolvidas durante a disciplina de Engenharia de Software e Gerência de Projetos, como parte do aprendizado e avaliação.
Professor: Fernando Gonçalves de Oliveira.
TAGUATINGA/DF
2017
SUMÁRIO
Project Charter – Termo de Abertura do Projeto	03
Plano de Projeto	11
EAP - Estrutura Analítica do Projeto	18
Dicionário da EAP	19
Cronograma	21
O que é “Levantamento de Requisitos”?	25
Tipos de Requisitos	26
 Requisitos Funcionais	26
 Requisitos Não Funcionais	26
Técnicas de Levantamento de Requisitos	27
 Entrevistas (Interviews)	27
 WorkShop	28
 BrainStorming	29
 Questionário	29
Prototipação	30
Questionário de Ambiente	30
Técnicas Utilizadas no Projeto CNTB	31
Telas de Prototipação do Sistema abordadas no Projeto CNTB	32
Conclusão	36
Referências	37
Project Charter – Termo de Abertura do Projeto
	Título do Projeto
	Data de Início
	Nº
	CNTB - Conecta Brasil
	05/02/2017
	001/2017
	Histórico de Revisões
	Data
	Versão
	Responsável
	Descrição
	05/02/2017
	1.00
	Michelle de Oliveira Paz Sousa
	Gerenciar a definição do escopo, prover mecanismos e métodos para que todas as etapas sejam cumpridas de acordo com as restrições do projeto.
	1. Identificação
	ID
	Nome
	Organização
	Cargo
	Papel no Projeto
	Contato (Tel - e-Mail)
	Patrocinador
	Anhanguera – Facnet
	Educacional
	Patrocinador
	Cliente
	(61) 3037-0063
	Gerente do Projeto
	Michelle de O. Paz Sousa
	Desafio
	Gerente de Projeto
	Gerenciamento
	michellepaz.fp@gmail.com
	Equipe Inicial
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellepaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellepaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Gerente de Projeto
	Gerenciamento
	michellepaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Analista
	Análise
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellepaz.fp@gmail.com
	Membros do CCM
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellepaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellepaz.fp@gmail.com arts@hotmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Gerente de Projeto
	Gerenciamento
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Analista
	Análise
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellypaz.fp@gmail.com
	Membros do PMO
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Desenvolvimento
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Gerente de Projeto
	Gerenciamento
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Analista
	Desenvolvimento
	michellypaz.fp@gmail.com
	
	Michelle de O. Paz Sousa
	Desafio
	Desenvolvedor
	Análise
	michellypaz.fp@gmail.com
	Principais Fornecedores
	Anhanguera – Facnet
	Educacional
	Patrocinador
	Cliente
	(61) 3037-0063
	
	Professor Fernando Gonçalves de Oliveira
	Representante
	Patrocinador
	Cliente
	 fernando.infinite@gmail.com
	1 - Resumo do Projeto
	Elaboração de uma solução online que permita uma melhora na distribuição de recursos voltada para a inclusão digital de jovens, apoiada em informações obtidas a partir de um cadastro.
	2 - Objetivos Mensuráveis do Projeto
	O sistema deverá servir como apoio a decisão para indicar quais regiões deverão receber os recursos destinados aos programas sociais que serão implantados.
	3 - Demanda - (justificativa para o projeto)
	O Grupo participará de um Prova de Conceito (Poc) de um edital do Governo Federal para construção de uma solução online para gerir o cadastro de beneficiários e as respectivas regiões, com suporte ao apoio de decisões denominado CNTB - Conecta Brasil.
	4 - Escopo
	Planejar e gerir uma solução online para cadastro de pessoas e as respectivas regiões;
Gerenciar as informações referentes a:
 Nome, RG e CPF;
 Idade pré-definida entre 15 e 21 anos;
 Renda familiar - (Menor renda);
 Escolaridade - (Melhor grau de escolaridade);
 Endereço completo - (Rua, quadra, conjunto, cidade, estado);
 Condições de moradia - (Alugada, própria, cedida);
 Tipo de moradia - (Alvenaria, madeira, taipa) e,
 Emissão de relatórios gerenciais que abranjam as informações dos beneficiários e suas
 regiões.
	5 - Não é Escopo
	Sistema de classificação;
Manutenção dos cronogramas e,
Gerenciamento de vagas.
	6 - Responsáveis pelas Informações dos Requisitos
		Nome
	Contato
	Michelle de Oliveira Paz de Sousa
	e-mail: michellypaz.fp@gmail.com
	7 - Requisitos de Alto Nível do Projeto e Critérios de Aceitação
	Funcionais:
7.1.1. O sistema será uma aplicação web;
7.1.2. O sistema será gerido por um usuário certificado e autenticado com login e
 senha;
7.1.3. Os beneficiários poderão fazer os cadastros via web mediante cadastro de
 nome, RG e CPF e cadastro de um e-mail e senha.
7.1.4. Todos os beneficiários deverão estar registrados no sistema.
7.1.5. O sistema disponibilizará relatórios sintético e analítico, com os dados
 solicitados de acordo com a demanda especificada no escopo e,
7.1.6. E-mail de retorno, (feedback), ao beneficiário com confirmação de cadastro.
Não Funcionais:
7.1.7. Manutenção de disponibilidade de vagas;
7.1.8. Disponibilização de acesso por meio de plataforma móvel (smartphone e/ou
 tablet);
7.1.9. O beneficiário terá acesso para consultar e alterar dados e,
7.1.10. A efetivação do cadastro do beneficiário será liberada apenas se o usuário
 estiver logado no sistema com o uso de usuário e senha.
	8 - Riscos de Alto Nível do Projeto
	Alterações do escopo do projeto a critério do patrocinador.
Extensão ou retração de prazos a critério do patrocinador.
Disponibilidade de membros da equipe de desenvolvimento.
Eventuais falhas no levantamento de requisitos que foram aprovadas em etapas posteriores.
Variações cambiais que podem modificar as premissas orçamentárias do projeto.
	9 - Stakeholders
		Nome
	Papel no projeto
	Descrição da Expectativa 
	Michelle de Oliveira Paz Sousa
	Representante do Patrocinador
	Espera que a elaboração do Escopo e Termo de Abertura do Projeto atenda aos primeiros passos descritos nas etapas do ATPS de ESGP. 
	Michelle de Oliveira Paz Sousa
	Desenvolvimento
	Contribuir de tal maneira a suprir as necessidades esperadas nos processos de criação, fazendo uso das boas práticas de programação que as normas de desenvolvimento de softwares seguros pontuam.
	Michelle de Oliveira Paz Sousa
	Desenvolvimento
	Contribuir de tal maneira a suprir as necessidades esperadas nos processos de criação, fazendo uso das boas práticas de programação que as normas de desenvolvimento de softwares seguros pontuam.
	Michelle de Oliveira Paz Sousa
	Gerenciamento
	Assegurar que o projeto tenha êxito nos pontos determinados no plano de projeto à media que as fases forem executadas,desenvolvimento de requisitos de alta complexidade.
	Gerente de Projeto
	Coordenar pessoas e recursos de acordo com os planos estabelecidos, assegurando que os objetivos do projeto sejam atendidos, através do acompanhamento e aferição do progresso do projeto, e da tomada de ações corretivas quando necessárias.
	Supervisor
	Responsável por áreas específicas de desenvolvimento.
	Conselheiro
	Atuante na validação de premissas.
	 2.7 COMITÊ DE CONFIGURAÇÃO DE MUDANÇAS
Equipe responsável por realizar e validar mudanças recorrentes ao projeto.
	Membros
	Atribuições
	Michelle de Oliveira Paz de Sousa
	Validação de códigos
	Michelle de Oliveira Paz de Sousa
	Validação de lógica
	Michelle de Oliveira Paz de Sousa
	Validação de segmentação 
	Michelle de Oliveira Paz de Sousa
	Validação de regras de negócio
	Michelle de Oliveira Paz de Sousa
	Validação de normas
	2.8 PREVISÃO DE INÍCIO E TÉRMINO DO PROJETO
Seguindo as especificações do escopo estabelecidas no projeto e validando a premissa de que o projeto será concluído em 06 (seis) meses, estimam-se as seguintes datas:
	Estimativa
	Data de Início
	05/02/2017
	Data de Término
	18/08/2017
Com o prazo de execução do projeto estimado em 151 (cento e cinquenta e um) dias, tem-se a média de 5.3 meses para a total conclusão e entrega do projeto.
	2.9 PREVISÃO ORÇAMENTÁRIA
	Nome da Tarefa
	Acumulação de custo fixo
	Custo Total
	Variação
	Restante
	Desenvolvimento de Requisito 3
	Rateado
	R$ 25.600,00
	R$ 25.600,00
	R$ 25.600,00
	Levantamento de Requisito 3
	Rateado
	R$ 19.200,00
	R$ 19.200,00
	R$ 19.200,00
	Levantamento de Requisito 1
	Rateado
	R$ 12.800,00
	R$ 12.800,00
	R$ 12.800,00
	Levantamento de Requisito 2
	Rateado
	R$ 12.800,00
	R$ 12.800,00
	R$ 12.800,00
	Iterações de Lições Aprendidas
	Rateado
	R$ 9.840,00
	R$ 9.840,00
	R$ 9.840,00
	Desenvolvimento de Requisitos 4
	Rateado
	R$ 7.200,00
	R$ 7.200,00
	R$ 7.200,00
	Desenvolvimento de Requisito 5
	Rateado
	R$ 7.200,00
	R$ 7.200,00
	R$ 7.200,00
	Levantamento de Requisitos 4
	Rateado
	R$ 6.400,00
	R$ 6.400,00
	R$ 6.400,00
	Levantamento de Requisitos 5
	Rateado
	R$ 6.400,00
	R$ 6.400,00
	R$ 6.400,00
	Desenvolvimento de Requisito 1
	Rateado
	R$ 6.400,00
	R$ 6.400,00
	R$ 6.400,00
	Desenvolvimento de Requisito 2
	Rateado
	R$ 6.400,00
	R$ 6.400,00
	R$ 6.400,00
	Plano de Projeto
	Rateado
	R$ 6.000,00
	R$ 6.000,00
	R$ 6.000,00
	Declaração de Escopo
	Rateado
	R$ 6.000,00
	R$ 6.000,00
	R$ 6.000,00
	Termo de Abertura do Projeto
	Rateado
	R$ 4.800,00
	R$ 4.800,00
	R$ 4.800,00
	EAP
	Rateado
	R$ 3.600,00
	R$ 3.600,00
	R$ 3.600,00
	Dicionário de EAP
	Rateado
	R$ 1.200,00
	R$ 1.200,00
	R$ 1.200,00
	Formalização de Entrega
	Rateado
	R$ 1.200,00
	R$ 1.200,00
	R$ 1.200,00
	Formalização de Entrega do Projeto
	Rateado
	R$ 1.200,00
	R$ 1.200,00
	R$ 1.200,00
	Repasse de Conhecimento
	Rateado
	R$ 640,00
	R$ 640,00
	R$ 640,00
	Total
	R$ 44.880,00
	R$ 144.880,00
	R$ 144.880,00
A estimativa orçamentária do projeto foi estipulada em R$ 144.880,00, (cento e quarenta e quatro mil, oitocentos e oitenta reais), referentes às despesas compreendidas em todo o período e fases de desenvolvimento do projeto.
	2.10 DECLARAÇÃO DO ESCOPO
Áreas ou artefatos atendidos pelo escopo:
1) Implementação de uma aplicação web que pode ser acessada em diversos tipos de dispositivos, onde o acesso aos dados somente é permito por usuário logado ao sistema como administrador,
2) Criptografia de dados pessoais cedidos pelos usuários, como senha e números de documentos e, que não serão visíveis a outros usuários,
3) Inclusão dos dados na base de dados de outras aplicações do Governo Federal e,
4) Validação de dados mediante a lógica imposta nas regras de negócio, emissão de relatórios totais ou parciais e modelagem de banco de dados.
Áreas ou artefatos não atendidos pelo escopo:
1) Não gerenciamento de calendários e vagas. 
2) Manutenções futuras do sistema.
3) Disponibilização de qualquer tipo de hospedagem para o sistema.
	2.11 PREMISSAS
A equipe de desenvolvimento será composta por 03 (três) desenvolvedores, 01(um) analista e 01 (um) gerente de projeto.
O projeto seguirá rigorosamente os prazos estipulados, assegurando as margens para mais ou para menos das datas já definidas no planejamento.
A codificação e lógica aplicadas ao produto seguirão os padrões adotados pelas principais entidades de certificação de normas.
	2.12 RESTRIÇÕES
De prazo;
O projeto será conduzido de maneira a cumprir os prazos estipulados para execução de cada etapa.
De custo;
Consultorias e análises de viabilidade possibilitarão que as estimativas de orçamento atendam sem se distanciar dos valores já previstos.
De qualidade;
Atendendo a todos os requisitos levantados com o cliente e estudos de viabilidade, para que o produto atenda ao que se espera, cadastro e insumos para apoiar tomadas de decisão.
	2.13 PLANO DE COMUNICAÇÃO
A comunicação, como item principal para fluência de informações, necessita de mecanismos pré-definidos em métricas eficazes para que seja feita de maneira satisfatória.
Esta seção tem por objetivo fornecer insumos para melhor utilização do plano de comunicação que é destinado a todos os membros da equipe.
Entre os Stakeholders, objetivando facilitar a comunicação, serão utilizadas tecnologias que permitem acesso imediato a informações e conferências internas e externas, como E-mail, Skype, WhatsApp e Telefone.
Integrantes da equipe de desenvolvimento e os respectivos contatos:
	Nome
	E-mail
	Telefone
	Skype
	WhatsApp
	Cliente 
	e-mail.gov.fed@gov.br
	(99)
9999-9999
	gov.fed.skype@gov.br
	(99)
9999-9999
	Michelle de Oliveira Paz de Sousa
	michellypaz.fp@gmail.com
	(99)
9999-9999
	michellypaz.fp@gmail.com
	(99)
9999-9999
	Michelle de Oliveira Paz de Sousa
	michellypaz.fp@gmail.com
	(99)
9999-9999
	michellypaz.fp@gmail.com
	(99)
9999-9999
	Michelle de Oliveira Paz de Sousa
	michellypaz.fp@gmail.com
	(99)
9999-9999
	michellypaz.fp@gmail.com
	(99)
9999-9999
	Michelle de Oliveira Paz de Sousa
	michellypaz.fp@gmail.com
	(99)
9999-9999
	michellypaz.fp@gmail.com
	(99)
9999-9999
	Michelle de Oliveira Paz de Sousa
	michellypaz.fp@gmail.com
	(99)
9999-9999
	michellypaz.fp@gmail.com
	(99)
9999-9999
	2.14 ANEXOS
	Ao escopo do projeto é acrescentado o anexo Cronograma.
	Anexo 3 - Cronograma
17
EAP- (ANEXO 1)
EAP
Estrutura Analítica do Projeto
18
12
Dicionário da EAP - (ANEXO 2)
Dicionário da EAP
	ID
	PACOTES DE TRABALHO
	DESCRIÇÃO
	CRITÉRIOS DE ACEITAÇÃO
	1
	CNTB
	Projeto de implantação de um sistema de cadastro em projetos sociais.
	Sob a demanda do patrocinador.
	1.1
	Iniciação
	Define todos os macros processos para iniciar o projeto.
	Todos os passos descritos seguem mediante aprovação do patrocinador.
	1.1.1
	Planejamento do Projeto
	Todas as atividades de gestão e gerenciamento de tarefas referentes ao projeto.
	Determinar as condições específicas para que o projeto seja finalizado com êxito.
	1.1.1.1
	Termo de Abertura do Projeto
	Documento que possibilita ao gerente aplicar recursos organizacionais nas atividades prévias e posteriores ao projeto.
	Aprovação por parte do patrocinador atendendo às premissas.
	1.1.1.2
	Plano de Projeto
	Contem ações para definição e coordenação de modo a integrar todos os planos alheios ao projeto.
	Definição de como será executado o projeto.
	1.1.2
	Artefatos
	Definição dos subprodutos que detêm as modelagens específicas para cada fase do desenvolvimento.
	Os artefatos como, Casos de Uso, Diagramas e UML deverão ser revisados.
	1.1.2.1
	Declaração do Escopo
	Descrição das entregas do projeto e os trabalhos que serão necessários para a elaboração.
	Consolidação dos estudos de viabilidade.
	1.1.2.2
	EAP
	Indicação dos produtos e das principais entregas do projeto.
	Elaboração da EAP, Dicionário e detalhes aprovados pelo Gerente de projeto.
	1.1.2.3
	Dicionário da EAP
	Detalhamento necessário para todos os elementos da EAP, provendo a orientação da equipe do projeto.
	Contemplar cada etapa do projeto.
	1.2
	ElaboraçãoLevantamento e validação de todos os requisitos do sistema para o desenvolvimento do projeto.
	Aprovação mediante critérios do Patrocinador, como a validação dos requisitos funcionais e não funcionais. 
	1.2.1
	E1
	Etapa responsável pelo agrupamento de requisitos iniciais do projeto.
	Requisitos que atendam as premissas iniciais do projeto.
	1.2.1.1
	Levantamento de Requisito 1
	Contempla os requisitos iniciais.
	Definição de requisitos de acordo com o escopo.
	1.2.1.2
	Levantamento de Requisito 2
	Contempla os requisitos iniciais.
	Definição de requisitos de acordo com o escopo.
	1.2.2
	E2
	Bloco de tarefa destinado à elaboração de requisitos com maior grau de complexidade.
	Requisitos que necessitam de uma lógica específica para classificação.
	1.2.2.1
	Levantamento de Requisito 3
	Contempla o requisito com um maior grau de complexidade.
	Deverá ser analisado por especialista com experiência em programas que atendam ao governo.
	1.2.3
	E3
	Bloco de tarefa destinado à elaboração de requisitos de média complexidade.
	Atender as restrições do escopo.
	1.2.3.1
	Levantamento de Requisito 4
	Comtempla os requisitos de média complexidade.
	Estudos de viabilidade para uso e disponibilidade de uma plataforma web.
	1.2.3.2
	Levantamento de Requisito 5
	Comtempla os requisitos de média complexidade.
	Estudos de viabilidade para uso e disponibilidade de uma plataforma web.
	1.3
	Construção
	Bloco definido a partir do desenvolvimento dos requisitos levantados junto ao escopo.
	Deverá ser desenvolvido por profissionais com experiência.
	1.3.1
	C1
	Bloco que define a sequência de desenvolvimento dos requisitos.
	Início do desenvolvimento (codificação), mediante validação dos requisitos.
	1.3.1.1
	Desenvolvimento de Requisito 1
	Codificação dos requisitos sequencialmente de acordo com os requisitos iniciais.
	Início do desenvolvimento (codificação), mediante validação dos requisitos.
	1.3.1.2
	Desenvolvimento de Requisito 2
	Codificação dos requisitos sequencialmente de acordo com os requisitos iniciais.
	Início do desenvolvimento (codificação), mediante validação dos requisitos.
	1.3.1.3
	Desenvolvimento de Requisito 4
	Codificação dos requisitos sequencialmente de acordo com os requisitos de média complexidade.
	Início do desenvolvimento (codificação), mediante validação dos requisitos.
	1.3.1.4
	Desenvolvimento de Requisito 5
	Codificação dos requisitos sequencialmente de acordo com os requisitos de média complexidade.
	Início do desenvolvimento (codificação), mediante validação dos requisitos.
	1.3.2
	C2
	Codificação de requisitos complexos.
	Exigida a codificação por desenvolvedores, (Pleno ou Sênior).
	1.3.2.1
	Desenvolvimento de Requisito 3
	Codificação mais complexa devido ao grau de complexidade do requisito.
	Codificado por desenvolvedores, (Pleno ou Sênior).
	1.4
	Transição
	Bloco que define as fases de encerramento do projeto.
	Validação das iterações de requisitos e codificação.
	1.4.1
	T1
	Iterações entre Stakeholders.
	Reunião para validação de entregas.
	1.4.1.1
	Iterações de Lições Aprendidas
	Iterações entre Stakeholders.
	Reunião de todos os envolvidos no projeto avaliando os prós e contras, vantagens e desvantagens, dificuldades e aprendizado agregado.
	1.4.1.1
	Formalização de Entrega
	Iteração entre Patrocinador e Gerente de projeto para formalizar o encerramento do projeto.
	Emissão de relatórios que validarão o sucesso do projeto junto ao patrocinador.
	1.4.2
	T2
	Finalização do projeto.
	Termos e medidas para formalizar a entrega e o encerramento do projeto.
	1.4.2.1
	Repasse de Conhecimento
	Troca de informações adicionais entre analistas e patrocinadores.
	Analistas validam as restrições junto aos patrocinadores passando adiante informações adquiridas sobre o negócio.
	1.4.2.2
	Formalizar o encerramento do Projeto
	Formalização da entrega do produto ao cliente e finalização das atividades.
	Documentação dos resultados do projeto, para formalização e aceitação junto ao patrocinador, apuração da satisfação do cliente com relação ao produto e ao desenvolvimento completo do projeto em si, de uma forma imparcial. 
19
20
CronogramaCRONOGRAMA - (ANEXO 3)
21
22
37
3
O que é “Levantamento de Requisitos”?
	O Levantamento de Requisitos é uma das partes mais importantes do processo que resultará no desenvolvimento de um sistema.
	Entender aquilo que o cliente deseja ou o que o cliente acredita que precisa e as regras do negócio ou processo do negócio.
A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do software, e pode ser entendida como responsável por definir os serviços que um sistema deve realizar sua interface com os demais elementos e sob quais restrições o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o sistema deve fazer ao invés de como isto será feito. Especificação um documento de requisitos de software é montando. Esse documento une a definição e a especificação dos requisitos. No desenvolvimento do processo alguns papéis estão envolvidos: os requerentes, os facilitadores e os implementadores. Os requerentes são os clientes e usuários, e representam as pessoas que precisam do sistema. Os facilitadores são analistas, e seu papel é o de desenvolver, ao longo do processo, as técnicas de extração, especificação, verificação e validação, numa descrição precisa do sistema que o requerente quer. Já os implementadores são engenheiros, projetistas e gerentes de projeto, que elaboram o sistema base do processo que efetivamente constroem os sistemas com base no documento de requisitos e no processo do software. Algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento pode não garantir que o software contemple todas as reais necessidades dos usuários, mas tende a antecipar o surgimento dos erros de entendimento e não consistências, aprimorando o processo de desenvolvimento de produtos de software. Este artigo trata as metodologias fazer um bom levantamento e especificação de requisitos é existente para descoberta destes requisitos.
(MELLO; LEANDRO, 2010, p. 01).
	A análise de requisitos é vital para o desenvolvimento de um sistema. Ela vai determinar o sucesso ou o fracasso do projeto.
Os requisitos colhidos devem ser quantitativos, detalhados e relevantes para o projeto, pois, eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam em um retrabalho.
Um estudo baseado em 6.700 sistemas desenvolvidos em 1997 demonstrou que os custos resultantes da má realização da etapa de levantamento de requisitos, podem levar os sistemas a custar duzentas vezes mais que o necessário.
Baseado nestas informações, pode se verificar a existência de dificuldades para se realizar adequadamente o levantamento de requisitos.
Entre as dificuldades encontradas na fase de levantamento de requisitos estão:
· O usuário principal do sistema normalmente não sabe o que ele quer que o sistema faça e não consegue transmitir para o analista;
· Requisitos identificados, mas que não são realistas, não identificam os requisitos similares informados por pessoas diferentes; e,
· Um Stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.
Reconhecer os problemas e a especificação do sistema, o planejamento, o contato do analista com o cliente, facilita no entendimento sobre a visão do cliente com relação ao problema.
 A avaliação e síntese de uma solução viável refletem no entendimento do problema fazendo a identificação das informações que serão necessárias ao usuário, bem como necessárias ao sistema, como o que será funcional ou não e a seleção da melhor solução possível dentro das soluções propostas.
Tipos de Requisitos
Requisitos Funcionais
Os Requisitos Funcionais vão estabelecer como o sistema agiráe o que deverá fazer as funcionalidades e serviços do sistema, devendo ser descritos detalhadamente.
Nesta fase, pode-se usar o MER (Modelo Entidade Relacionamento), um dos modelos de casos de uso e fluxogramas para facilitar o entendimento das funções do sistema.
Requisitos Não Funcionais
Os Requisitos Não Funcionais definem as propriedades do sistema e suas restrições. Ex: a confiabilidade do sistema, o tempo de resposta do programa e o espaço em disco.
Técnicas de Levantamento de Requisitos
As técnicas de levantamento de requisitos empregadas têm por objetivo superar as dificuldades relativas a esta fase. Todas as técnicas empregadas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.
Apresentamos a seguir as principais técnicas utilizadas, com suas vantagens e desvantagens:
Entrevistas (Interviews)
	A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados.
Convém que o entrevistador dê espaço ao entrevistado para esclarecer as suas necessidades. É uma discussão do projeto desejado com diferentes grupos de pessoas.
Vantagens:
· Com um plano geral bem elaborado, o analista terá facilidade em descobrir qual informação o usuário está mais interessado e usar um estilo adequado ao entrevistador;
· Alterar o curso da entrevista de forma a obter informações sobre aspectos importantes que não tinham sido previstos no planejamento da entrevista;
· Alterar a ordem sequencial das perguntas;
· Incluir perguntas que não estavam na programação da entrevista; e,
· Motivar o entrevistado no decorrer do processo.
Desvantagens:
· Podem ocorrer desvios de curso no decorrer da entrevista;
· Consumir mais tempo e recursos com sua realização;
· Ter um tratamento diferenciado para os entrevistados;
· É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados;
· O usuário tem dificuldade de concentração em reuniões muito longas; e,
· O entrevistado pode não saber expressar corretamente suas necessidades ao analista.
WorkShop
	Trata-se de uma técnica de elicitação 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.
	Vantagens:
· Obtêm um conjunto de requisitos bem definido;
· Trabalho em equipe tornando o levantamento de requisitos mais eficaz;
· Baixo custo e resposta relativamente rápida; e,
· Tempo de obtenção de informações é reduzido.
Desvantagens:
· Por ser realizado por convocação por dia e horário, pode ocasionar problemas no presencial dos Stakeholders;
· Não abre caminho para ideias externas além da equipe de analistas; e,
· Dados excessivamente agregados.
BrainStorming
	É utilizado normalmente em workshops. Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido.
	Seu objetivo é uma apresentação do problema/necessidade a um grupo específico, requerendo assim soluções imediatas.
	Vantagens:
· Várias pessoas pensam melhor do que uma (grupo pensante);
· Rompe a inibição de ideias; e,
· Generaliza a participação dos membros do grupo.
Desvantagens:
· Disponibilidade de todos pode inviabilizar o levantamento de dados.
Questionário
	Diferente da entrevista, essa técnica é interessante quando temos uma quantidade grande de pessoas para extrair as mesmas informações.
As questões são dirigidas por escrito aos participantes com o objetivo de ter conhecimento sobre opiniões das mesmas questões. São autoaplicáveis, pois o próprio informante responde.
Vantagens:
· Atinge um grande número de pessoas;
· Menor custo;
· Permite que os participantes respondam no momento em que acharem convenientes; e,
· Questões padronizadas garantem uniformidade.
Desvantagens:
· Não há garantia de que a maioria dos participantes responda o questionário; e,
· Os resultados são demasiadamente críticos em relação ao objetivo, pois as perguntas podem ter significados diferentes a cada participante questionado.
Prototipação
	É utilizada no estágio inicial do projeto ajudando os Stakeholders a desenvolver uma forte noção sobre a aplicação a qual ainda não foi implementada.
Através da visualização dessa técnica é possível aos Stakeholders identificar os reais requisitos e fluxos de trabalho existentes no sistema. É muito utilizada quando os Stakeholders são incapazes de expressar os seus requisitos ou quando eles não têm nenhuma experiência com o sistema.
Vantagens:
· Permite alcançar um feedback antecipado dos Stakeholders;
· Redução de tempo e custo de desenvolvimento devido à detecção dos erros em uma fase inicial do projeto; e,
· Provê alto nível de satisfação dos usuários devido à sensação de segurança ao ver algo próximo do real.
Desvantagens:
· Para ser realizada, demanda um alto custo de investimento em relação a outros métodos; e,
· Demanda um tempo maior para sua realização devido à complexidade do sistema e a limitação de técnicas.
Questionário de Ambiente
	O Questionário de Ambiente permite aos analistas o real entendimento das necessidades dos Stakeholders com a coleta detalhada de informações através de observação e interação com as pessoas no ambiente de trabalho.
	Alguns profissionais são escolhidos e acompanhados a fundo para o completo entendimento de suas práticas de trabalho.
	Vantagens:
· Permite um levantamento profundo e detalhado das necessidades dos Stakeholders; e,
· Pode ser utilizado para resolver problemas extremamente complexos.
Desvantagens:
· Dependendo dos processos de trabalho, necessita de uma grande quantidade de tempo e pessoas para ser executado.
Técnicas Utilizadas no Projeto CNTB
	Para a perfeita realização deste projeto, obtendo resultados satisfatórios, foram utilizadas as técnicas de Entrevista e Prototipação, onde as discussões contribuíram para o levantamento de requisitos funcionais e não funcionais do patrocinador, conforme a seguir:
	Requisitos Funcionais:
· Manter cadastros de beneficiários; e,
· Emitir relatórios.
Requisitos Não Funcionais:
· Solução Web;
· Acessibilidade;
· Usabilidade; e,
· Viabilidade.
Pontos de Dúvida:
· Que plataformas serão utilizadas: Web, Desktop ou Mobile.
Telas de Prototipação do Sistema abordadas no Projeto CNTB
Figura 01 - Tela Inicial de Acesso ao Sistema
Figura 02 - Seleção do Tipo de Usuário para Acesso ao Sistema - (Administrador ou Beneficiário)
Figura 03 - Validação dos Dados de Acesso do Administrador ao Sistema
Figura 04 - Tela de Pesquisa - (Usuário: Administrador)
Figura 05 - Tela de Acesso a Lista de Beneficiários - (Usuário: Administrador)
Figura 06 - Exclusão de Beneficiários do Cadastro do Sistema - (Usuário: Administrador)
Figura 07 - Tela de Cadastro de Beneficiários
Figura 08 - Tela de Alteração de Dados do Beneficiário
Figura 09 - Tela de Exclusão de Beneficiário do Cadastro
Figura 10 - Institucional
Figura 11 - Informações para Contato
Conclusão
	Como já proposto, existem diversas maneiras de se fazer um bom levantamento de requisitos. Esses requisitos, por sua vez, apresentam vantagens e desvantagens, que devem ser analisadas de acordo com a necessidade do projeto.
	É de responsabilidade da equipe que irá executar o levantamento de requisitos, escolher a melhor técnica de trabalho a ser empregada, de acordo com o que o sistema propõe.
	É sabido que nenhuma técnica é completa, devido às inúmeras variáveis de complexidade dos sistemas a serem analisados.
Outrora, levando em consideração os perfis dos Stakeholders, a comunicação, o nível de conhecimento do negócio e o nível de qualificação dos profissionais e analistas, conclui-se que,fazer uma análise aplicando as vantagens que cada técnica possui, define um bom plano para gerenciar o levantamento dos requisitos, minimizando assim, possíveis falhas que podem fazer com que o projeto sofra readequações que onerem tempo e custo e, no pior caso, o encerramento do projeto por parte do patrocinador.
Referências
O que é Gerenciamento de Projetos. Disponível em . 
Gerenciamento de Projeto. Disponível em 
PMO - Escritório de Projetos. Disponível em .
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em .
O que é Gerenciamento de Projetos. Disponível em . 
Gerenciamento de Projeto. Disponível em . 
PMO - Escritório de Projetos. Disponível em . 
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em . 
O que é Gerenciamento de Projetos. Disponível em .
Gerenciamento de Projeto. Disponível em . 
PMO - Escritório de Projetos. Disponível em .
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em . Acesso em 15 mar. 2015, 11h20.
O que é Gerenciamento de Projetos. Disponível em . 
Gerenciamento de Projeto. Disponível em . 
PMO - Escritório de Projetos. Disponível em . 
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em .
Oeste	Iniciação	Elaboração	Construção	Transição	30.6	38.6	34.6	31.6	
image2.jpg
image3.png
image4.png
image5.png
image6.png
image7.png
image8.png
image9.png
image10.png
image11.png
image12.png
image13.png
image14.png
image15.png
image16.png
image17.png
image1.pngfazer uma análise aplicando as vantagens que cada técnica possui, define um bom plano para gerenciar o levantamento dos requisitos, minimizando assim, possíveis falhas que podem fazer com que o projeto sofra readequações que onerem tempo e custo e, no pior caso, o encerramento do projeto por parte do patrocinador.
Referências
O que é Gerenciamento de Projetos. Disponível em <http://brasil.pmi.org/brazil/AboutUS/WhatIsProjectManagement.aspx>. 
Gerenciamento de Projeto. Disponível em <http://www.ebah.com.br/content/ABAAAAC9kAJ/gerenciamento-projeto>
PMO - Escritório de Projetos. Disponível em <http://escritoriodeprojetos.com.br/definir-o-escopo.aspx>.
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em <http://www.ricardo-vargas.com/pt/podcasts/assumptions/>.
O que é Gerenciamento de Projetos. Disponível em <http://brasil.pmi.org/brazil/AboutUS/WhatIsProjectManagement.aspx>. 
Gerenciamento de Projeto. Disponível em <http://www.ebah.com.br/content/ABAAAAC9kAJ/gerenciamento-projeto>. 
PMO - Escritório de Projetos. Disponível em <http://escritoriodeprojetos.com.br/definir-o-escopo.aspx>. 
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em <http://www.ricardo-vargas.com/pt/podcasts/assumptions/>. 
O que é Gerenciamento de Projetos. Disponível em <http://brasil.pmi.org/brazil/AboutUS/WhatIsProjectManagement.aspx>.
Gerenciamento de Projeto. Disponível em <http://www.ebah.com.br/content/ABAAAAC9kAJ/gerenciamento-projeto>. 
PMO - Escritório de Projetos. Disponível em <http://escritoriodeprojetos.com.br/definir-o-escopo.aspx>.
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em <http://www.ricardo-vargas.com/pt/podcasts/assumptions/>. Acesso em 15 mar. 2015, 11h20.
O que é Gerenciamento de Projetos. Disponível em <http://brasil.pmi.org/brazil/AboutUS/WhatIsProjectManagement.aspx>. 
Gerenciamento de Projeto. Disponível em <http://www.ebah.com.br/content/ABAAAAC9kAJ/gerenciamento-projeto>. 
PMO - Escritório de Projetos. Disponível em <http://escritoriodeprojetos.com.br/definir-o-escopo.aspx>. 
Podcast de Ricardo Varga - O que são premissas e o que são restrições. Disponível em <http://www.ricardo-vargas.com/pt/podcasts/assumptions/>.
Oeste	Iniciação	Elaboração	Construção	Transição	30.6	38.6	34.6	31.6	
image2.jpg
image3.png
image4.png
image5.png
image6.png
image7.png
image8.png
image9.png
image10.png
image11.png
image12.png
image13.png
image14.png
image15.png
image16.png
image17.png
image1.png