Grupo4_DocumentoVisao_2013_1

Prévia do material em texto

UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 1 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
Documento de Visão 
Projeto: WAGER 
 
Controle de Versão 
Versão Data Descrição da Alteração Autor 
1.0 20/03/2013 Primeira versão do documento Aluno 1 
1.1 21/03/2013 Objetivos do Projeto Aluno 2 
1.2 21/03/2013 Complementação da Situação Atual e Objetivos, e 
início dos requisitos funcionais 
Aluno 3 
1.3 22/03/2013 Revisão de Situação Atual Aluno 1 
1.4 23/03/2013 Restrições Aluno 4 
1.5 23/03/2013 Escrita do escopo, dos requisitos funcionais, das 
interdependências do produto, e das premissas e 
revisão das restrições 
Aluno 3 
1.6 24/03/2013 Complementação dos Requisitos Funcionais, 
revisão do Escopo do projeto 
Aluno 1 
1.7 24/03/2013 Revisão em restrições, Objetivos do projeto e 
Requisitos funcionais 
Aluno 4 
1.8 24/03/2013 Revisão em Objetivos, Situação atual, Escopo do 
projeto 
Aluno 5 
1.9 29/03/2013 Requisitos Não-funcionais Aluno 1 
1.10 31/03/2013 Finalização das premissas e restrições, atualização 
das Interdependências do produto 
Aluno 5 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 2 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
1.11 31/03/2013 Arquitetura do Produto, Requisitos Não 
Funcionais, Revisão Requisitos Funcionais 
Aluno 2 
1.12 01/02/2013 Revisão em Requisitos Funcionais e Não 
Funcionais 
Aluno 1 
1.13 02/04/2013 Não Funcionais, Arquitetura do Produto Aluno 2 
1.14 02/04/2013 Revisão em Requisitos Não Funcionais Aluno 4 
1.15 02/04/2013 Revisão em Requisitos Funcionais Aluno 1 
1.16 04/04/2013 Revisão geral de todos os itens do documento, no 
que se refere à linguagem, ao conteúdo, à 
homogeneidade da apresentação, a coerência das 
informações e à formatação 
Aluno 3 
1.17 04/04/2013 Revisão Final dos Recursos Funcionais, 
Requisitos Não Funcionais, Visão Geral do 
Produto e Arquitetura do Produto 
Aluno 2, Aluno 1 
1.18 04/04/2013 Revisão Final dos Requisitos Funcionais e Não-
Funcionais, à Arquitetura do Produto 
Aluno 5 
1.19 04/04/2013 Revisão Geral do Projeto Aluno 4,Aluno 5, 
Aluno 2, Aluno 
1, 
Aluno 3 
 
Sumário 
1. Objetivo do documento 
2. Situação Atual 
3. Objetivos do projeto 
4. Escopo do Projeto 
5. Premissas 
6. Restrições 
7. Visão geral do produto 
7.1 Interdependências do Produto 
7.2 Requisitos Funcionais 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 3 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
7.3 Requisitos Não Funcionais 
7.4 Arquitetura do Produto 
 
1. Objetivo do documento 
O presente documento tem como objetivo apresentar uma visão geral sobre o 
WAGER. Portanto, é apresentada a documentação das funcionalidades, as regras de negócio, 
os recursos necessários aos envolvidos e usuários-chave. Os detalhes de como o WAGER 
satisfaz essas necessidades serão descritos nos documentos de requisitos funcionais e não 
funcionais. 
 
2. Situação Atual 
A Calçados PQT é uma empresa de grande porte do ramo calçadista, com mais de 65 
anos no mercado e sede localizada no Brasil. Atua em diversas áreas de negócio ligadas à 
indústria, varejo multimarca, varejo monomarca, franquias monomarca, empreendimentos 
imobiliários e administração de cartões de crédito. Os principais processos da empresa são o 
desenvolvimento de produtos, a venda através de representantes, a industrialização dos 
produtos e a logística. A Calçados PQT está presente tanto no mercado interno quanto no 
externo, possuindo também unidades produtivas na Argentina e na República Dominicana. 
A organização possui várias marcas, e cada uma apresenta características diferentes, 
ao menos no que se refere à sua estruturação, público alvo, modelação dos produtos e alcance 
de mercado. Além disso, a organização produz duas coleções por ano, com três lançamentos 
para cada marca, cada um contando com uma nova apresentação no sistema. Cada 
representante trabalha com apenas uma marca. 
A empresa atualmente trabalha com um software de “Força de Vendas”, utilizado 
pelos seus representantes para sistematizar e padronizar os processos referentes à venda de 
produtos. Estes processos devem obedecer a uma série de regras constantemente variáveis 
determinadas pela empresa. O representante utiliza o sistema como um catálogo digital, a 
partir do qual apresenta os produtos aos clientes, realiza o cadastro de novos clientes e realiza 
pedidos, além de o utilizar na apresentação de informações relevantes na hora da negociação, 
como, por exemplo, a disponibilidade dos produtos para a pronta entrega. 
No sistema atualmente utilizado, as regras de vendas, layout do catálogo virtual e lista 
de valores variam conforme a marca e o mercado: interno ou externo. Por ser utilizado em 
diversas localidades e por mais de uma nacionalidade, possuindo suporte a três idiomas 
(inglês, espanhol e português) e disponibilização de informações conforme a cultura do 
cliente. 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 4 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
O sistema atualmente utilizado possui dois módulos: online e offline. Os dois módulos 
possuem funcionalidades equivalentes, porém o modo offline necessita de atualizações 
periódicas para que possa acompanhar as constantes mudanças nas regras de negócio e 
atualizar outras informações importantes para a realização dos pedidos. A opção pelo modo 
offline se faz necessária devido ao fato de que existem regiões onde os representantes atuam 
que não possuem conexão com a internet disponível. Essa falta de sincronização de dados em 
tempo real gera problemas para a empresa, criando situações em que, por exemplo, um 
representante, utilizando o sistema desatualizado, acaba realizando o pedido de um produto 
que não se encontra mais disponível dentro das condições negociadas. Por isso existe uma 
regra em que o sistema deve ter seu banco de dados atualizado a cada cinco dias no máximo; 
se isto não ocorrer, a sincronização e outras funcionalidades são bloqueadas automaticamente. 
 
3. Objetivos do projeto 
Este projeto tem por objetivo criar um novo software de “Força de Vendas” que 
auxilie os representantes da Calçados PQT a visualizar os produtos da nova coleção, os 
produtos disponíveis em estoque de coleções anteriores, cadastrar novos representantes e 
cadastrar novos pedidos. O projeto contribui para o negócio na medida em que oferece 
interfaces independentes de acordo com as marcas da organização, com layout intuitivo e 
suporte multi-idioma. Além disso será desenvolvido numa arquitetura flexível que facilite a 
migração para outras tecnologias, as mudanças nas regras de negócio e que solucione outros 
problemas existentes no sistema atual. 
 
4. Escopo do Projeto 
O escopo do projeto se refere ao que será entregue e o que será realizado durante o 
período. Faz parte do escopo do projeto: 
● Elicitação da necessidade do negócio junto ao cliente; 
● Análise dos requisitos e escrita da documentação referente; 
● Planejamento da estrutura/ arquitetura a ser adotada; 
● Desenvolvimento dos requisitos elicitados e analisados conforme item 7.2; 
● Verificação dos requisitos não-funcionais do projeto (documentos, código escrito) e 
validação do sistema (testes de software); 
● Reuniões quinzenais de status report das atividades com o cliente; 
● Testes de aceitação com o cliente; 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 5 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
● Acompanhamento da homologação; 
● Prestação da garantia do projeto durante três meses. 
Não faz parte do escopo do projeto o treinamento dos usuários finais, a preparação do 
ambiente dos servidores do banco de dados e da aplicação, tão bem quanto a responsabilidade 
pela disponibilidade de recursos de rede. 
 
5. Premissas 
Como premissas do projeto apresentam-se as características que devem se constituir 
enquanto foco principal no planejamento e na estruturação do novo sistema. São as premissas: 
● Performance e usabilidade: 
Será desenvolvido um sistema que possua bom desempenho em conexões de rede 
mais lentas, que não apresente muito tempo de carregamento e que seja de fácil 
utilização para o usuário final. As informações e imagens devem ser carregadas em até 
cinco segundos. O layout do sistema será configurável pelo cliente e também será 
carregado de forma eficiente ao ser trocada a marca. A apresentação de relatórios, 
cadastros e catálogos eletrônicos serão eficazes, dinâmicas e amigáveis ao usuário; 
● Portabilidade: 
Será desenvolvido um sistema com portabilidade, isto é, independente da 
configuração, arquitetura e estrutura do computador, navegador ou eletrônico, as 
funcionalidades principais do sistema poderão ser utilizadas de maneira eficiente e 
satisfatória. São funcionalidade principais: cadastro, edição ou inativação de cliente e 
de pedido, visualização dos dados de cadastro, visualização do catálogo eletrônico da 
marca. Estas funcionalidade foram priorizadas na portabilidade por serem 
consideradas essenciais no projeto; 
● Configurabilidade: 
Será desenvolvido um sistema que seja altamente configurável, isto é, que não seja 
dependente de uma equipe de desenvolvimento para informar novas regras de vendas, 
valores, descontos, para cadastrar novos layouts, ou para cadastrar novos relatórios. O 
foco do projeto é desenvolver um produto que atenda as necessidades de todos os 
clientes a todo momento. 
 
6. Restrições 
[B1] Comentário: Os itens estão mais 
próximos de requisitos não funcionais. 
Premissas são eventos, fatores, hipóteses, 
pressupostos que devem ser considerados 
verdadeiros para fins de planejamento. 
Declaração que acreditamos ser verdadeira. 
Ou seja, não temos 100% de certeza se é 
um fato, mas para a finalidade de 
planejamento do projeto, acreditamos ser 
verdadeiro (TenStep, 2011). 
Em geral oferecem um grau de risco, caso 
não sejam atendidas e influenciam todos os 
aspectos do planejamento de um projeto. 
Portanto, devem ser constantemente 
revisadas e atualizadas. 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 6 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
Como restrições do projeto apresentam-se as características do ambiente, da equipe e 
da disponibilização de informações por parte do cliente, as aprovações dos documentos e 
fluxos propostos para início das novas fases do projeto, o cumprimento do cronograma de 
datas e de orçamento. São as restrições: 
● Ambiente de desenvolvimento e testes: 
Devem estar disponíveis e configurados os ambientes de desenvolvimento com as 
configurações reais do novo ambiente de produção. Os ambientes devem possuir: 
banco de dados, webservice, dados para testes, sistema. O ambiente de 
desenvolvimento será utilizado pela equipe de desenvolvimento do projeto para as 
novas publicações e para a realização de testes internos. O ambiente de testes será 
utilizado para os testes de aceitação sobre o produto pelo cliente; 
● Equipe de desenvolvimento do projeto: 
A equipe de desenvolvimento do projetos deverá ser formada por: um gerente de 
projeto, dois analistas de sistemas, um arquiteto de software, um líder de qualidade, 
dois analistas de testes, três desenvolvedores, um testador; 
● Documentos e software do cliente: 
Devem ser criados dois usuários no ambiente de desenvolvimento do software atual 
com os perfis de representante e administrador para fins de consulta ao funcionamento 
do sistema atual, às regras de negócio e fluxo de utilização do software; 
● Aprovação dos documentos: 
Devem ser aprovados pelo cliente todos os documentos escritos pela equipe de 
desenvolvimento do projeto, como documento de visão, de requisitos funcionais e 
não-funcionais, de casos de testes, entre outros. Os documentos devem ser enviados ao 
cliente para aprovação conforme data estipulada no cronograma do projeto e ter prazo 
de rejeição de até uma semana; se ao final desta semana nenhuma alteração for 
solicitada, serão iniciadas as atividades seguintes do projeto; 
● Cronograma de entregas e orçamento: 
Deve ser consultado e seguido, em todas as atividades do projeto, o cronograma de 
datas de início e fim das atividades do projeto, bem como o orçamento de custos 
alinhado com o cliente. A cada alteração das datas, ou a cada problema no seu 
cumprimento, o cliente deve ser notificado. 
 
 
7. Visão geral do produto 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 7 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
Como itens gerais do produto a ser desenvolvido constam: características técnicas, 
funcionalidades a serem planejadas, desenvolvidas e testadas, ferramentas e dependências do 
sistema, e a estrutura do novo sistema. Estes itens estão detalhados abaixo: 
 
 
7.1 Interdependências do Produto 
A seguir são listadas as dependências do sistema. Estas dependências podem se referir 
ao ambiente, à fonte de dados, a outros sistemas, entre outros. O software de Força de Vendas 
é dependente dos itens abaixo: 
● Rotina de atualização de dados do ERP: 
Diariamente é executada uma rotina de atualização de dados do ERP para os demais 
softwares da empresa, como o software de Força de Vendas. São atualizados dados 
como: novos produtos, novas marcas, novo layout, nova campanha, novas listas de 
preços, e novas regras comerciais; 
● Base de Dados: 
A fonte de dados (base de dados) da empresa é compartilhada entre os sistemas 
utilizados. O compartilhamento de dados garante que não exista duplicidade de dados, 
permite a atualização imediata de informações entre os sistemas utilizadores da base 
de dados e conectados à rede, e a padronização das estruturas de controle e rotina e 
dos formatos de dados; 
● Servidor: 
A disponibilidade do sistema dependerá do funcionamento dos servidores. Existem, 
atualmente, dois servidores com configurações idênticas e com espelhamento de disco 
que fornece maior segurança, distribuição de processamento e maior disponibilidade 
em casos de falha; 
● Java Virtual Machine: 
As máquinas que utilizarem o sistema devem possuir a JVM (Java Virtual Machine) 7 
ou superior para executar a aplicação. 
 
A máquina servidora web deverá suportar o servidor de aplicaçõesOracle. 
As máquinas clientes deverão possuir disponíveis browsers compatíveis e acesso à internet 
para a atualização dos catálogos e regras de negócio. 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 8 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
7.2 Requisitos Funcionais 
● RF001 - Gerenciar pedido 
● RF002 - Gerenciar cliente 
● RF003 - Autenticar usuário 
● RF004 - Visualizar catálogo eletrônico 
● RF005 - Visualizar produto 
● RF006 - Gerenciar carrinho de compras 
● RF007 - Visualizar material de marketing 
● RF008 - Gerenciar relatórios 
● RF009 - Suportar multi-idioma 
● RF010 - Gerenciar interface 
● RF011 - Sincronizar dados 
● RF012 - Gerenciar tabela de valores 
● RF013 - Gerenciar configurações de negócio 
● RF014 - Gerenciar configurações técnicas 
● RF015 - Notificar representante 
● RF016 - Selecionar marca 
 
7.3 Requisitos Não Funcionais 
● RNF001 - Suporte aos navegadores Internet Explorer 7 ou superior, Mozilla Firefox 
19, Google Chrome 19 ou superior, Safari 3.0 ou superior 
● RNF002 - Suporte às plataformas móveis Windows RT, iOS v.:6.0 e Android v.:2.2 
ou superior 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 9 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
● RNF003 - Suporte aos sistemas operacionais Windows XP ou superior, Linux Ubuntu 
8.04, MacOS X 10 ou superior 
● RNF004 - Suporte à arquivos de vídeo: pacote de codecs com Dvix 
● RNF005 - Suporte à arquivos de imagens: GIF, JPEG ou PNG 
● RNF006 - Suporte à arquivos PDF: Adobe Reader 10 ou superior 
● RNF007 - Integrações às plataformas: webservice, banco de dados Oracle, módulo BI 
SAP 
● RNF008 - Padrões de usabilidade 
● RNF009 - Padrões de performance 
● RNF010 - Padrões de interoperabilidade 
● RNF011 - Padrões de segurança e criptografia 
● RNF012 - Padrões de sincronização 
● RNF013 - Módulos On-Line e Off-Line 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDADE DO VALE DO RIO DOS SINOS 
 
Ciências Exatas e Tecnologicas 
 
Documento de Visão 10 
Engenharia de Requisitos - Prof. Me Josiane Brietzke Porto 
 
7.4 Arquitetura do Produto 
 
● Servidor BD: Base de dados de todas as ferramentas utilizadas pelo projeto, direta ou 
indiretamente, utilizando banco de dados Oracle. 
● Servidor de Integração Rest: Serviço responsável pela conversão de dados para 
integração com diferentes aplicações, neste caso, banco de dados Oracle com o 
software “Força de Vendas” independentemente do tipo de acesso. 
● Funcionamento Off-Line: Permite acesso a todos os recursos previstos no software de 
“Força de Vendas”, implementando assim apenas regras de negócio simples e regras 
de interface, esta baseada na marca comercializada, agilizando assim o fechamento 
dos pedidos e preservando a qualidade na apresentação do catálogo, e tendo um prazo 
de até cinco dias para atualizar sua base de dados com o servidor. 
● Funcionamento On-Line: Mantém todos os recursos da aplicação off-line com ênfase 
na centralização de relatórios comerciais, financeiros e integração com BI para 
representantes com maior exigência.