HeadShot Documento de Requisitos Completo

Prévia do material em texto

UNIVERSIDADE DO OESTE DE SANTA CATARINA 
ÁREA DE CIÊNCIAS EXATAS E DA TERRA 
CURSO: ENGENHARIA DA COMPUTAÇÃO 
DISCIPLINA: ENGENHARIA DE SOFTWARE I CRÉDITOS: 4 HORAS/AULA: 60 
PROFESSORA: ROGERIA MONTEIRO <rogeria.monteiro@unoesc.edu.br> 
PERÍODO LETIVO: 1º SEM DE 2012 FASE: 3ª 
DATA DA SOLICITAÇÃO: 11/ABRIL/2012 
DATA DA ENTREGA: 18/ABRIL/2012 
NOME DOS INTEGRANTES DA EQUIPE: Carolina Franco, Carlos Stöckl, Elder Debertolis. 
NOTA:_________ 
 
Avaliação A1p1 Parte 1 
Documento de Requisitos do Projeto de Sistema Gerenciador da Loja Clecy Modas. 
 
1. TAREFA DE ESPECIFICAÇÃO DE REQUISITOS 
 
1.1 Fundamentação teórica 
A especificação dos requisitos de software é o documento oficial de descrição dos 
requisitos de um software. Ela pode se referir a um produto indivisível de software, ou a um 
conjunto de componentes de software, que formam um produto indivisível de software, que 
formam um produto quando usados em conjunto. 
A especificação dos requisitos de software deve ser escrita por membros de equipe de 
desenvolvimento de um projeto, com a participação obrigatória de um ou mais usuários chave 
do produto em pauta. 
Um software pode conter toda a funcionalidade necessária ao cliente, ou ser parte de 
um sistema maior. 
Os requisitos de software podem ser classificados em dois grupos principais. Os 
requisitos funcionais de clientes em um software de uma loja podem ser considerados um 
requisito funcional. Os requisitos não funcionais, ou suplementares, são requisitos que 
expressam condições que o software deve atender ou qualidades específicas que o software 
deve ter. 
 
A Especificação de Requisito de Software é desenvolvida como uma 
consequência da analise. A revisão é fundamental para garantir que o 
desenvolvedor e o cliente tenham a mesma percepção do sistema: 
Infelizmente, mesmo com o melhor dos métodos, “o problema” é que o 
“problema” continua mudando. (PRESSMAN S. ROGER. Engenharia de 
Software. São Paulo; Mac Graw Hill, 2006, p.271) 
 
 
Após a entrevista é necessário validar se o que foi documentado pelo analista está de 
acordo com a necessidade do usuário, que o usuário não mudou de opinião e que o usuário 
entende a notação ou representação gráfica de suas informações. 
 
 
 
1.2 Visão geral 
 
O Sistema tem como objetivo auxiliar o controle das atividades cotidianas da loja de 
vestuário Clecy Modas. O sistema deve ser capaz de armazenar um cadastro com os dados de 
clientes. Deve armazenar um cadastro de funcionários com os mesmos dados cadastrais do 
cliente, mas que seja capaz de diferenciar o gerente da loja, também é importante o controle 
do pagamento dos colaboradores. Deve existir um registro de estoque com as peças 
cadastradas por tipo, marca e valor. Cada venda realizada deve estar vinculada a um vendedor 
que receberá comissão de 5% no valor do produto e também ao cliente contendo referencia 
da peça, após a venda deverá ser gerado um cupom fiscal. Nas vendas em crediário, se após 10 
dias a partir do vencimento o cliente não efetuar pagamento ele deve receber um e-mail 
sendo informando. Apenas o usuário do gerente pode cadastrar uma venda. Quando um 
produto for vendido ele deve ser retirado do estoque no sistema, e quando mais peças forem 
compradas elas devem ser cadastradas no sistema. Os fornecedores também devem ser 
cadastrados. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1.3 Índice de Requisitos Funcionais 
 
 
F01. Armazenar informações de funcionários. 
F02. Guardar informações de clientes. 
F03. Acumular informações de venda. 
F04. Armazenar informações sobre produtos - estoque. 
F05. Notificar saída de produto (reduzir estoque). 
F06. Cadastrar fornecedores 
F07. Cadastrar pagamentos de funcionários 
F08. Registrar compra de produtos. 
 
 
1.4 Índice de Requisitos Não-Funcionais 
 
 
NF 01. O computador em que será instalado o sistema deverá atender as configurações 
mínimas quanto à capacidade de processamento e memória que são Processador 1 GHz (32- 
ou 64-bit), 1 GB de RAM (32-bit); 2 GB de RAM (64-bit), 16 GB de espaço livre no HD (32-bit); 
20 GB de espaço livre no HD (64-bit). 
NF 02. Usar No-Break para evitar o desligamento repentino do computador por falta de 
energia, o que pode ocasionar danos ao sistema e até, perda de dados. 
 
NF 03. Usar um sistema de gerenciamento de banco de dados (SGBD) pera garantir a 
integridade dos dados. 
 
NF 04. Interface gráfica amigável para que o sistema seja de fácil entendimento, fazendo com 
que o tempo de aprendizagem seja menor e o sistema ofereça maior produtividade ao usuário. 
A Interface não deve ter muitas animações que poluem o sistema, deve ser usado as cores 
padrões do Sistema Operacional Windows 7 que é o padrão utilizado na loja com o qual os 
funcionários já estão adaptados, a estrutura do menu principal também deve ser o mais 
parecido possível com a do Windows. 
 
NF 05. É necessária uma ferramenta que efetue o backup do sistema diariamente ou 
semanalmente, para evitar a perda dos dados. 
 
NF 06. Deve ter uma opção para limitar os acessos dos usuários. Os níveis de acesso devem 
ser: 
• User, utilizado pelo funcionário com restrições de acesso em cadastro de funcionários, 
registros de venda e compra. 
• AdminUser, utilizado pelo gerente da loja sem restrições de acesso. 
 
 
 
 
 
 
 
 
 
1.5 Detalhamentos dos Requisitos Funcionais 
 
 
F01. Armazenar informações de funcionários. 
 
Descrição: Quando um funcionário for contratado deverá fornecer informações para cadastro 
que devem ficar armazenadas no sistema. Todas as operações de CRUD poderão ser realizadas. 
 
Fontes: O Funcionário. 
 
Usuário: AdminUser. 
 
Informações de entrada: Nome completo, CPF, RG, data de nascimento, endereço, telefone, e-
mail, Data de admissão, Salário, nome do banco que o funcionário utiliza, número da conta 
corrente, e agência. 
 
Informações de saída: Relatório de informações dos colaboradores cadastrados. 
 
Restrições Lógicas: Todos os campos são obrigatórios. 
 
Restrições Tecnológicas: CPF, RG e datas devem ser digitados apenas em números e então o 
sistema é responsável pela formatação correta. As operações de CRUD só podem ser realizadas 
pelo AdminUser. 
 
F02. Guardar informações de clientes. 
 
Descrição: Quando um cliente realizar uma compra no crediário deverá primeiramente 
fornecer informações para cadastro no sistema. Todas as operações de CRUD poderão ser 
realizadas, exceto deletar um cliente. 
 
Fontes: O cliente. 
 
Usuários: User e AdminUser. 
 
Informações de entrada: nome completo, CPF, RG, data de nascimento, endereço, telefone, e-
mail. 
 
Informações de saída: 
• Relatório de informações do cliente, contendo: nome completo, CPF, RG, data de 
nascimento, endereço, telefone e e-mail. 
• Relatório de compras efetuadas pelo cliente, contendo: nome completo do cliente, 
CPF, endereço, telefone, email, nome do vendedor, valor da compra, referencia de 
produto comprado, data da compra, forma de pagamento. 
• Relatório de situação quanto aos prazos das contas do cliente: nome completo, CPF, 
telefone, email, data de compras efetuadas, forma de pagamento e data de 
pagamentos registrados. 
 
Restrições Lógicas: Todos os campos são obrigatórios. 
 
Restrições Tecnológicas: CPF, RG e datas devem ser digitados apenas em números. 
F03. Acumular informações de venda. 
 
Descrição: Quando um cliente realizar uma compra está deverá ser armazenada no sistema. 
 
Fontes: O Gerente. 
 
Usuários: AdminUser. 
 
Informações de entrada: Cliente. Referencia do produto vendido, valor total, condições de 
pagamento. Data de Venda. Vendedor responsável. Data de Pagamento. 
 
Informações de saída: 
• Relatório de vendas pelo período que o administrador delimitar,contendo: Data da 
Venda, Vendedor Responsável, Cliente, Referencia do produto, Valor total da Venda e 
forma de pagamento. 
• Relatório de venda por cliente, contendo: cliente, referência dos produtos comprados, 
data das compras e valor das compras. 
• Relatório de venda por vendedor, contendo: vendedor, referência dos produtos 
vendidos, data das vendas e valor das vendas. 
 
Restrições Lógicas: A venda tem que ser finalizada. 
 
Restrições Tecnológicas: Datas devem ser digitadas apenas em números e então o sistema é 
responsável pela formatação correta DD/MM/AAAA. É necessária uma impressora fiscal 
conectada ao computador. 
 
F04. Armazenar informações sobre produtos - estoque. 
 
Descrição: Deve existir um registro – estoque de todos os produtos disponíveis na loja. Todas 
as operações de CRUD são permitidas 
 
Fontes: Gerente e Funcionário. 
 
Usuários: User e AdminUser. 
 
Informações de entrada: Referencia do produto, categoria do produto, marca do produto, 
valor de compra, valor para venda, fornecedor, data de entrada. 
 
Informações de saída: 
• Relatório de estoque, contendo: Referencia do produto, categoria do produto, marca, 
valor de compra, valor para venda, fornecedor, data de entrada. 
• Relatório de Estoque por fornecedor, contendo: nome do fornecedor, referencia do 
produto comprado, valor do produto comprado, data de entrada do produto. 
 
• Relatório de Estoque por Marca, contendo: marca do produto, referencia do produto, 
valor de compra do produto, valor de venda do produto, fornecedor e data de entrada. 
 
Restrições Lógicas: Todos os campos são obrigatórios. 
 
Restrições Tecnológicas: Datas devem ser digitadas datas no formato DD/MM/AAAA. 
 
F05. Notificar saída de produto (reduzir estoque). 
 
Descrição: Quando uma venda for efetuada o produto vendido deve ser reduzido do estoque. 
 
Fontes: O Gerente e Funcionário. 
 
Usuários: User e AdminUser. 
 
Informações de entrada: Referencia do produto. Venda. 
 
Informações de saída: 
• Relatório de controle de estoque, contendo: Referencia do produto, valor de venda, 
data de entrada e data de saída. 
• Relatório de saída de produtos em data delimitada pelo administrador: Referencia do 
produto, valor de venda e data de saída. 
 
Restrições Lógicas: Todos os campos são obrigatórios. 
 
Restrições Tecnológicas: A Data deve ser digitada apenas em números, o sistema a formatará 
no formato correto. 
 
F06. Cadastrar fornecedores 
 
Descrição: Para uma compra ser realizada é necessário o cadastro do fornecedor. Todas as 
operações de CRUD serão resolvidas. 
 
Fontes: O Gerente e Funcionário. 
 
Usuários: User e AdminUser. 
 
Informações de entrada: Nome da empresa, nome do vendedor (fornecedor), CNPJ, telefone, 
email. 
 
Informações de saída: 
• Relatório de fornecedores: listagem de todos os fornecedores. 
• Compras realizadas por fornecedor contendo: Compra, Nome do fornecedor. 
 
 
Restrições Lógicas: Todos os campos são obrigatórios. 
 
Restrições Tecnológicas: Não existem. 
 
 
 
 
 
F07. Cadastrar pagamentos de funcionários 
 
Descrição: Lançar o custo com o pagamento dos funcionários. 
 
Fontes: O Gerente. 
 
Usuários: AdminUser. 
 
Informações de entrada: Funcionário, data de pagamento, salário, nome do banco, número da 
conta, agencia. 
 
Informações de saída: Folha de pagamento, contendo: Empresa, Funcionário, proventos, 
descontos, valor liquido. 
 
Restrições Lógicas: O funcionário tem que estar cadastrado. Ao valor do salário deve ser 
adicionada a comissão de 5% sobre o valor dos produtos vendidos. 
 
Restrições Tecnológicas: Não Existe. 
 
F08. Registrar compra de produtos. 
 
Descrição: Quando uma compra for realizada deve ser cadastrada no sistema. 
 
Fontes: O Gerente. 
 
Usuários: AdminUser. 
 
Informações de entrada: Referencia do Produto, Fornecedor, valor de compra, data de compra. 
 
Informações de saída: 
• Relatório de compras por fornecedor, contendo: Referencia do produto, Fornecedor, 
Marca, Valor de compra. 
 
Restrições Lógicas: A compra tem que ser finalizada. 
 
Restrições Tecnológicas: Não Existe 
 
 
 
 
 
 
 
 
2 TAREFA DE ANÁLISE DE REQUISITOS 
2.1 Aplicação das propriedades de requisitos 
 
REQUISITOS PROPRIEDADES 
F01. Armazenar informações de funcionários. 
Permanente; 
Obrigatório; 
Evidente. 
F02. Guardar informações de clientes. 
Permanente; 
Obrigatório; 
Evidente. 
F03. Acumular informações de venda. 
Permanente; 
Obrigatório; 
Evidente. 
F04. Armazenar informações sobre produtos - 
estoque. 
Permanente; 
Obrigatório; 
Evidente. 
F05. Notificar saída de produto (reduzir 
estoque). 
Permanente; 
Obrigatório; 
Oculto. 
F06. Cadastrar fornecedores 
Permanente; 
Obrigatório; 
Evidente. 
F07. Cadastrar pagamentos de funcionários 
Permanente; 
Obrigatório; 
Evidente. 
F08. Registrar compra de produtos 
Permanente; 
Obrigatório; 
Evidente. 
NF 01. 
Transitório; 
Obrigatório; 
Evidente. 
NF 02. 
Transitório; 
Desejável; 
Evidente. 
NF 03. 
Permanente; 
Obrigatório; 
Oculto. 
NF 04. 
Transitório; 
Obrigatório; 
Evidente. 
NF 05. 
Permanente; 
Desejável; 
Oculto. 
NF 06. 
Transitório; 
Obrigatório; 
Oculto. 
 
 
 
2.2 Casos de Uso – UCs 
 
 
 
 
 
2.2.1 Identificação de Casos de Uso e Classificação de acordo com sua complexidade 
 
UC01 – Registrar compra de peças; 
UC02 – Registrar venda de peças; 
UC03 – Atualizar estoque; 
UC04 – Registrar pagamentos; 
CRUD01 – Manter informações de funcionário; 
CRUD02 – Manter informações de fornecedor; 
CRUD03 – Manter informações de cliente; 
REL01 – Gerar relatórios de estoque; 
REL02 – Gerar relatórios de cliente; 
REL03 – Gerar relatórios de venda. 
 
 
 
2.2.2 Priorização de Casos de Uso 
 
Ciclo Referência de Caso de Uso Referência de Requisitos Vinculados 
1 UC01 F04, F06, F08. 
2 UC02 F01, F02, F03, F04, F05. 
3 UC03 F04, F05, F08. 
4 UC04 F01, F02, F03, F07, F08. 
5 CRUD01 F01. 
6 CRUD02 F06 
7 CRUD03 F02. 
8 REL01 F04. 
9 REL02 F02, F03. 
10 REL03 F01, F02, F03, F04. 
 
 
3 MODELAGEM CONCEITUAL PRELIMINAR 
 
Modelo é a representação abstrata e simplificada de um sistema real, com a qual se 
pode explicar ou testar o seu comportamento, em seu todo ou em partes. 
O modelo não é objeto real mas algo que o representa, com maior ou menor 
fidelidade. Faz com que pela sua observação e manipulação tenhamos nossas necessidades de 
conhecimento e conceituação sobre um objeto satisfeito. 
A definição das classes e dos relacionamentos irá compor os diagramas de classes do 
sistema. Este é um dos principais diagramas da UML e dos projetos de software, pois eles 
descrevem o esqueleto do sistema sendo projetado. 
Os principais tipos de relacionamento entre classes são: associação, dependência, 
composição, agregação e generalização. 
 
Associação: 
A associação é o tipo mais comum de relacionamento entre classes em sistemas 
orientados a objetos. Sua principal função é permitir a comunicação entre objetos de classes 
diferentes. 
Esse tipo de relacionamento aplica-se a classes independentes que necessitam 
comunicar-se de forma unidirecional ou bidirecional a fim de colaborar para a execução de 
algum caso de uso. É permitido o relacionamento entre tantas classes quanto for necessário, 
não há um limite máximo de associações de uma classe para com outras. 
Em UML, a notação utilizada para representar uma associação é um segmento de reta 
entre duas classes, onde, se o relacionamento for unidirecional inclui-se uma seta na 
extremidade de destino da associação. 
 
Dependência: 
Sua principal característica é ser uma relação leve entre dois objetos, uma relação não 
estrutural. Neste tipode relacionamento sempre existirá a figura do objeto fornecedor e do 
objeto cliente, ou seja, um objeto irá fornecer um determinado serviço que será consumido 
pelo cliente. Um relacionamento de dependência pode ser implementado como: 
- Uma variável local a uma operação. 
- Um parâmetro por referência. 
- Uma classe utilitária. 
Uma classe utilitária é uma classe de auxílio e normalmente não é modelada, ou seja, 
não aparece no modelo. Este relacionamento poderá aparecer em várias classes, o que irá 
poluir o diagrama. As classes utilitárias são representadas na UML com o lado direito e inferior 
com uma faixa cinza. 
 
Composição: 
Composição é uma associação muito forte e representa que o tempo de vida entre os 
objetos coincide. A representação da UML é um losango preto no lado da classe que possui a 
parte (o todo). A seta representa a navegabilidade, ou seja, quem utiliza os serviços de quem. 
 
Agregação: 
Uma agregação é uma associação de força média em que o tempo de vida não 
coincide e os objetos podem existir independentes um do outro. 
A agregação é representada na UML usando um losango branco. 
 
Generalização: 
O compartilhamento da estrutura ou comportamento entre classes chama-se 
generalização, também é conhecido como “é um tipo de” ou “é um”. 
MODELO CONCEITUAL. 
 
 
REFERÊNCIAS 
 
SCHACH R. STEPHEN. Engenharia de Software: Os Paradigmas Clássico Orientado a Objetos. 
São Paulo: Mc Graw Hill, 2009. 
 
SOMMERVILLE. Engenharia de Software. São Paulo: Editora Afiliada, 2007. 
 
PRESSMAN S. ROGER. Engenharia de Software. São Paulo; Mac Graw Hill, 2006. 
 
WAZLAWICK SIDNEI RAUL. Análise e Projeto de Sistemas de Informação Orientadas a Objetos. 
Rio de Janeiro: Elsevier, 2011. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ANEXO I - Entrevista. 
 
Headshot: Olá, temos um enorme prazer em atendê-lo, quais são suas principais dificuldades 
ao realizar uma venda ao cliente? 
 
Clecy Modas: Na hora da venda abrimos uma ficha em papel e guardamos, mas como nossa 
loja está crescendo precisamos de uma maneira mais ágil para fazer isso. 
 
Headshot: Quais as informações de clientes que você precisa guardar? 
 
Clecy Modas: As principais informações que precisamos é do Nome, CPF, Telefone, email e 
endereço. 
 
Headshot: E para os seus funcionários que tipo de informações? 
 
Clecy Modas: As mesmas que dos clientes. 
 
Headshot: E os produtos? 
 
Clecy Modas: Nesse caso preciso saber o tipo, a marca e o valor de cada peça. 
 
Headshot: Agora que já temos um cliente, um vendedor e os produtos como acontecerá à 
venda? 
 
Clecy Modas: Cada venda realizada deve aparecer quem foi o vendedor, para poder receber 
uma comissão igual a 5% no valor da venda. E deve estar registrado também ao cliente 
contendo referencia de produtos comprados. Preciso que o sistema gere um cupom fiscal. 
Para vendas em crediário, o sistema terá que avisar os clientes desatentos, quando o prazo do 
pagamento vencer ultrapassar 10 dias, com um e-mail formal. 
 
Headshot: Todos os seus funcionários podem ter acesso total ao sistema? 
 
Clecy Modas: Não, somente e somente o gerente pode cadastrar uma venda, pois a comissão 
dos funcionários terá que ser gerada a cada venda realizada. 
 
Headshot: Com relação aos produtos damos a sugestão de cadastro de fornecedores para 
maior controle. 
 
Clecy Modas: Ótimo, preciso também que a cada produto vendido ele seja retirado do estoque 
no sistema, e reposto na compra. 
 
 
 
 
 
 
 
 
 
 
 
 
ANEXO II - CRITÉRIOS DE AVALIAÇÃO e DISTRIBUIÇÃO DA PONTUAÇÃO 
1. Os itens estruturais do trabalho serão avaliados de acordo com os critérios descritos abaixo, 
cada qual com sua respectiva pontuação: 
 
TAREFA DE ESPECIFICAÇÃO DE REQUISITOS (1 ponto no total deste item) 
• o Atende às considerações realizadas sobre a avaliação A1p1 Parte 1 (1) 
• Atende parcialmente às considerações realizadas sobre a avaliação A1p1 Parte 1 (0,5) 
• Não atende às considerações realizadas sobre a avaliação A1p1 Parte 1 (0) 
 
TAREFA DE ANÁLISE DE REQUISITOS (1 ponto no total deste item) 
• Atende às considerações realizadas sobre a avaliação A1p1 Parte 2 (1) 
• Atende parcialmente às considerações realizadas sobre a avaliação A1p1 Parte 2 (0,5) 
• Não atende às considerações realizadas sobre a avaliação A1p1 Parte 2 (0) 
 
MODELAGEM CONCEITUAL PRELIMINAR (2 pontos no total deste item) 
• Fundamentação teórica (0,4): este item será avaliado de acordo com a veracidade das 
informações, corretamente fundamentadas em fontes de consulta científicas, assim 
como, a completude dos itens solicitados (objetivo do artefato modelo conceitual, 
principais tipos de relacionamentos entre conceitos do modelo conceitual). 
• Modelo Conceitual (1,6): este item será avaliado de acordo com a coerência e 
consistência das informações indicadas, tendo como suporte as atividades de 
especificação e de análise de requisitos. Também serão observadas as quantidades 
corretas de cada elemento, assim como a nomenclatura adequada em relação ao 
contexto abordado por cada grupo. Os elementos que fazem parte do Modelo 
Conceitual Preliminar são: 
� Conceitos 
� Atributos 
� Associações 
� Multiplicidade das associações 
 
1. A nota máxima desta avaliação parcial é de 04 pontos, para os trabalhos entregues até o 
dia 16/05/2012. Porém, a cada dia de atraso na entrega deste documento, haverá a 
redução de 0,2 pontos na nota obtida. 
 
2. O relatório deve estar no formato pdf e deve ser postado no Portal de Ensino da 
Unoesc/Área de Colaboração. Caso houver algum problema com este procedimento, 
também será aceito o relatório enviado ao email da professora 
(rogeria.monteiro@unoesc.edu.br) com o assunto “EngSw1 A1p1 Parte 3 <nome da 
equipe>”. 
 
3. O DOCUMENTO DE REQUISITOS COMPLETO DEVE SER IMPRESSO E ENTREGUE NA DATA 
INDICADA NO ITEM 2. 
 
4. ESTE DOCUMENTO DEVE SER INCLUÍDO COMO ANEXO ao relatório relativo a esta 
avaliação parcial. 
 
5. Esta avaliação pode ser realizada em equipes de até 03 integrantes, mantendo a formação 
adotada para realizar a avaliação A1p1 Parte 1 e Parte 2.