ATPS parte 4

segue o link do ATPS

http://www.4shared.com/document/_NrfNwlH/Projeto_de_Engenharia_de_Softw.html

Etapa 4

Tiago Ap. Pessoa RA: 0911345828
Wesley S.Dia RA: 0959532446
Evandro D. Oliveira RA: 0919435 437
Marcio S. Oliveira RA: 0920349523
































Referencias de Requisitos Funcionais


RF1 – Cadastro de clientes
RF2 – Cadastro de animal
RF3 – Remoção do animal
RF4 – Remoção do Cliente
RF5 – Alteração de médico
RF6 – Remoção de médico
RF7 – Cadastro de usuário do sistema
RF8 – Alteração de usuário do sistema
RF9 – Inativação de usuário do sistema
RF10 – Geração de agenda médica
RF11 – Consulta de agenda médica
RF12 – Agendamento de consultas
RF13 – Cancelamento de consultas agendas
RF14 – Cadastro de medicamentos
RF15 – Alteração de medicamentos
RF16 – Exclusão de medicamentos
RF17 – Cadastro de Exames
RF18 – Alteração de Exames
RF19 – Id do usuario
RF20 – Alteração id do usuario
RF21 – Preenchimento de prontuário
RF22 – Consulta de prontuário
RF23 – Relatório de pacientes
RF24 – Relatório de consultas agendadas
RF25 – Relatório de estatística de medicamentos por prontuário médico








REQUISITOS NÃO FUNCIONAIS


Requisitos de Hardware/Software
RNF01: Rede de computadores.
RNF02: Hardware.
RNF03: Compatibilidade



REQUISITOS DE PERFORMANCE


RNF04: Agendamento de Consultas.
RNF05: Consulta ao prontuário.

ATPS ENGENHARIA DE SOFTWARE - ETAPA 04

ATIVIDADES PRÁTICAS SUPERVISIONADAS
ETAPA IV




Donizeti de Assis Dantas RA: 0995534163
Cinara Saraiva Cardoso RA: 0901345894
Kivia F. Azevedo Ramos RA: 2507415553
Ronaldo Cezar Cavalcanti RA: 0901395323
Bruno Luiz M. de Oliveira RA: 0919440340











Introdução:













Neste documento apresentamos uma previa de um projeto de software que pode ser implantado na empresa para auxiliar no controle de clientes , no fluxo de caixa, estabilidade na qualidade de atendimento e projeções para futuros investimentos no campo de atuação na rede de pet shop.










ETAPA 04



Prezado cliente apresentamos abaixo o desenvolvimento do projeto.


Clicara em cima da tecla de atalho Clivet, logo abrira a tela para logar tem dois tipos de login Administrador e Usuario.
Seleciona o tipo de login em seguida insere a senha, para o sistema fazer o reconhecimento do mesmo.
Possui tres abas com os seguintes informações: Cadastrar , Imprimir e Pesquisar.
No momento que clicar em cadastrar aparece as opções: Clientes, produtos, fornecedores, usuarios e notas fiscais.
Selecionada a opção clientes, abrira a tela para inserir os dados do cliente e do animal, após preenchido clicar em salvar e os dados ficam gravados em um banco de dados.
Selecionado a opção produtos, abrira a tela para inserir os dados do produto, codigo, nome do fornecedor, nome do produto, valor , nota fiscal de entrada , tipos de impostos destacados no produto, após inserido as informações clicamos em salvar.
Selecionando a opção fornecedor , abrira a tela para inserir os dados do fornecedor: razao social, CNPJ , endereço Completo.telefone de contato, pessoa de contato, email, logo clicamos em salvar.
Somente é permitido ao Administrador da rede utilizar a opção usuario, é o mesmo que possui pleno poderes para cadastrar os usuarios e definir o grau de acesso de cada usuario.
No campo pesquisar digitamos o que desejamos pesquisar e aparece uma tela Resultados da Pesquisa, com os resultados encontrados com a palavra inserida logo tem aopção visualizar ou cancelar.
Opção visualizar aparece a tela com os dados existentes no cadastro com opções de editar , salvar e cancelar.
Na opção Editar conseguimos alterar os dados ja existentes e possui a opção agenda, no qual consegue visualizar os dias disponiveis para atendimentoe possui o campo de observações para colocar informações pertinentes sobre o animal.
Na aba imprimir disponibilizamos das seguintes sub-opções: Clientes:Dados do cliente, imprimi a ficha cadastral do mesmo, Dados do Animal, imprimi a ficha do mesmo, valor a pagar , historico de atendimento do cadastro.
Sub-opção Produtos: imprimi a relação de produtos em estoque.
Sub-opção Fornecedor: possui a possibilidade de imprimir a ficha cadastral da empresa e imprimi a relação de fornecedores da empresa.
Sub-opção notas Ficais: possui a opção de imprimi a relação da notas fiscais emitidas, das notas de entradas , bem como a relação dos valores a receber e dos valores a pagar.

omputação – 5ª Série – Engenharia de Software e Análise de Projeto de Sistemas

Especificação dos Requisitos do Software
Sistema de Gerenciamento da Clínica Veterinária Clivet
ATPS Etapa 04 Passos 1,2,3

Nome: Estevan Caetano da Silva RA:0991003743
Nome:Carlos Ap. Galvão RA:0943475647
Nome: Luiz Gustavo capareli RA:1099477617
Aprovação
Aprovo a Especificação dos Requisitos do projeto de Sistema de Gerenciamento da Clínica Veterinária Clivet.


Tânia Ramires
09/05/2011






















Especificação dos Requisitos do Software
Sumário


Especificação dos Requisitos do Software....................................................................... 4
1 Introdução................................................................................................................ 5
1.1 Objetivos deste documento................................................................................ 5
1.2 Escopo do produto............................................................................................. 5
1.2.1 Nome do produto e de seus componentes principais.................................. 5
1.2.2 Missão do produto....................................................................................... 5
1.2.3 Benefícios do produto.................................................................................. 5
1.3 Materiais de referência....................................................................................... 6
1.4 Definições e siglas............................................................................................. 6
1.5 Visão geral deste documento............................................................................. 6
2 Descrição geral do produto....................................................................................... 7
2.1 Perspectiva do produto....................................................................................... 7
2.1.6 Restrições de memória................................................................................. 8
2.1.7 Modos de operação...................................................................................... 8
2.1.8 Requisitos de adaptação ao ambiente.......................................................... 8
2.2 Funções do produto........................................................................................... 9
2.3 Usuários e sistemas externos............................................................................. 9
2.3.1 Descrição..................................................................................................... 9
2.3.2 Características dos usuários........................................................................ 9
2.4 Restrições......................................................................................................... 10
2.6 Requisitos adiados........................................................................................... 10
3 Requisitos específicos............................................................................................ 11
3.1 Requisitos funcionais....................................................................................... 11
3.1.1 Diagramas de casos de uso........................................................................ 11
3.1.1.1 Diagrama de casos de uso << nome do diagrama de casos de uso >> 11
3.1.2 Casos de uso.............................................................................................. 11
3.1.2.1 Caso de uso << nome do caso de uso >>........................................... 11
3.2 Requisitos não funcionais................................................................................ 13
3.2.1 Tempo de Resposta.................................................................................... 13
3.2.2 Interface Amigável..................................................................................... 13
3.2.3 Outros Requisitos...................................................................................... 13
4 Informação de suporte............................................................................................ 14

1 Introdução
1.1 Objetivos deste documento
O documento de requisitos objetiva por meio das necessidades e problemas passados pelo cliente descrever os requisitos funcionais (funcionalidades) do projeto, assim como os não-funcionais (requisitos implícitos de engenharia de software) e as telas para implementação dos dados.

1.2 Escopo do produto
1.2.1 Nome do produto e de seus componentes principais
O projeto Pet Shop Clivet será um sistema de gerenciamento personalizado para a clínica e loja de animais de estimação. Terá como principais características o gerenciamento de seus clientes e animais, de venda de produtos e de assistência veterinária.

1.2.2 Missão do produto
Sistematizar o gerenciamento do estabelecimento, informatizando os processos de atendimento e manutenção; isso de forma que o usuário interaja facilmente com um sistema confiável adaptado ao ambiente em questão.

1.2.3 Benefícios do produto
Número de ordem
Benefício
Valor para o cliente
1
Facilitar o gerenciamento de clientes
Essencial
2
Facilitar o gerenciamento dos animais
Essencial
3
Agendar e controlar atividades
Essencial
4
Facilitar o controle de vendas
Essencial
5
Facilitar o controle de amostras de animais
Essencial
6
Gerar documentos dos os animais
Essencial

1.3 Materiais de referência
Número de ordem
Tipo do material
Referência bibliográfica
1
Site
www.cin.ufse.br/~if682 (Templates)
2
Livro
Ian Sommerville, Engenharia de Software
3
Site
www.cin.ufse.br/~bgf/ess

1.4 Definições e siglas
Número de ordem
Sigla
Definição
1
ESS
Engenharia de Software e Sistemas
2
HD
Hard Disk
3
RAM
Random Memory Access
4
BD
Banco de Dados

1.5 Visão geral deste documento
Este documento trata de especificar com bom grau de detalhamento os requisitos a serem implementados pela equipe de desenvolvimento.
Para ter uma visão geral do funcionamento do sistema foi produzido um diagrama de casos de uso que mostra de forma ampla a interação entre os atores e as funcionalidades do sistema. Este diagrama é de fácil compreensão e ajuda o cliente a perceber se o projeto está de acordo com seus interesses.
Para ajudar os desenvolvedores na implementação do sistema, é definida uma seção que detalha todos os casos de uso funcionais e não-funcionais. Através delas se têm, com alto grau de precisão, o modo de funcionamento de todos os casos de uso.
Neste documento é descrito ainda o perfil dos usuários, as interfaces com que o sistema terá de lidar e as restrições com as quais terá de se adequar.


2 Descrição geral do produto
2.1 Perspectiva do produto
2.1.1 Restrições de memória
Número de ordem
Tipo de memória
Limites aplicáveis
1
Memória secundária
Limite de um HD de 40GB para o banco de dados e não é interessante implementar um programa maior que a capacidade de um CD.
2
Memória Primária
O programa não deve consumir mais do que 40MB da Memória RAM da máquina, acima disso, pode haver uma queda de desempenho uma vez que a memória é limitada e o sistema operacional é Windows Vista (relativamente pesado em termos de memória primária).

2.2 Funções do produto
Número de ordem
Caso de uso
Descrição
1
Controlar cadastramento de animais
Poder ter acesso às informações sobre todos o animais que são tratados na clínica.
2
Controlar cadastramento de proprietários
Poder ter acesso às informações sobre todos o proprietários que visitam a clínica
3
Controlar Internações
Saber quais animais estão internados e quais são as medicações que cada internado recebe.
4
Controlar vacinações
Controlar se os animais estão corretamente vacinados e controlar a data de segunda dose.
5
Controlar tosa/banho
Controlar os banhos e tosas que cada animal teve e se há algum banho/tosa marcado.
6
Controlar consultas
Poder guardar um histórico de todas as consultas de cada cão. Também deve ser possível gerar receitas a partir da consulta.
7
Controlar estoque
Controlar tudo o que entra e sai do estoque.
8
Controlar caixa
Controlar o dinheiro que entra e sai da clínica.
9
Controlar amostra a serem analisadas
Controlar a entrada e saída das amostras de sangue, feses e urina dos animais.
10
Controlar funcionários
Controlar o pagamento e as horas extras dos funcionários.

2.3 Usuários e sistemas externos
2.3.1 Descrição
Número de ordem
Ator
Definição
1
Veterinário
Responsável por administrar os animais e proprietários
2
Secretária
Trata das questões financeiras e também usa os cadastros dos animais e proprietários
3
Vendedora
Controla o estoque

2.3.2 Características dos usuários
Número de ordem
Ator
Freqüência de uso
Nível de instrução
Proficiência na aplicação
Proficiência em informática
·
Veterinário
Diário
Alto
Alto
Médio
·
Secretaria
Diário
Médio
Médio
Baixo
·
Vendedora
Diário
Médio
Médio
Médio








3 Requisitos específicos
3.1 Requisitos funcionais
Código
Nome
Prioridade
Área
RF-001-A
Cadastrar Animal
Essencial
Animal
RF-002-A
Cadastrar Proprietário
Essencial
Animal
RF-003-A
Buscar Animal
Essencial
Animal
RF-004-A
Busca Proprietário
Essencial
Animal
RF-005-A
Alterar Animal
Essencial
Animal
RF-006-A
Alterar Proprietário
Essencial
Animal
RF-007-A
Remover Animal
Essencial
Animal
RF-008-A
Remover Proprietário
Essencial
Animal
RF-009-A
Cadastrar Consulta
Essencial
Animal
RF-010-A
Cadastrar Cirurgia
Essencial
Animal
RF-011-A
Cadastrar Vacinação
Essencial
Animal
RF-012-A
Cadastrar Internação
Essencial
Animal
RF-013-A
Gerar Receita (da consulta)
Desejável
Animal
RF-014-A
Cadastrar tosa/banho
Essencial
Animal
RF-015-A
Registrar que vacinação já foi administrada
Essencial
Animal
RF-016-A
Gerar relatório (animais a serem vacinados)
Desejável
Animal
RF-017-A
Gerar relatório (internamento)
Desejável
Animal
RF-018-A
Gerar fatura Cirurgia
Essencial
Animal
RF-019-A
Gerar fatura Consulta
Essencial
Animal
RF-020-A
Gerar fatura Internamento
Essencial
Animal
RF-021-A
Gerar fatura tosa/Banho
Essencial
Animal
RF-022-E
Cadastrar Produto
Essencial
Estoque
RF-023-E
Buscar Produto (por nome)
Essencial
Estoque
RF-024-E
Buscar Produto (por fornecerdor)
Essencial
Estoque
RF-025-E
Registrar compra de Produto
Essencial
Estoque
RF-026-E
Registrar venda de Produto
Essencial
Estoque
RF-027-E
Aviso: Produto acabando
Desejável
Estoque
RF-028-E
Gerar fatura Venda
Essencial
Estoque
RF-029-L
Cadastrar Amostra
Essencial
Laboratório
RF-030-L
Buscar Amostra por nome do Animal
Essencial
Laboratório
RF-031-L
Despachar Amostra
Essencial
Laboratório
RF-032-C
Cadastrar Funcionário
Essencial
Controle de caixa
RF-033-C
Registrar compra de utilidades da veterinária
Essencial
Controle de caixa
RF-034-C
Gerar Receita
Essencial
Controle de caixa
RF-035-C
Pagar Cirurgia
Essencial
Controle de caixa
RF-036-C
Pagar Consulta
Essencial
Controle de caixa
RF-037-C
Pagar Funcionário
Essencial
Controle de caixa
RF-038-C
Pagar Internamento
Essencial
Controle de caixa
RF-039-C
Pagar Tosa/Banho
Essencial
Controle de caixa
RF-040-C
Pagar Venda
Essencial
Controle de caixa
RF-041-C
Registrar hora-extra
Essencial
Controle de caixa



3.2 Descrição dos Requisitos funcionais


RF-001-A
Nome:
Cadastrar Animal
Descrição:
O programa deve inserir um novo animal no seu sistema de banco de dados.
Plataformas:
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome do Animal
· Proprietário já cadastrado
· Peso
· Idade (calculada na hora de acordo com a data de nascimento)
· Sexo
· Espécie
· Raça
· Porte
· Pelagem
Saídas e pós-condições:
Animal cadastrado no sistema com um Id definido
Fluxos de eventos
Fluxo principal:
O usuário deve informar todas as entradas.
Após essa etapa o usuário terá cadastrado um novo animal no banco de dados.
Fluxo secundário 1:
Caso alguma informação seja inválida (não preenchida), uma janela será apresentada informando que os dados solicitados para cadastro estão incompletos.






RF-002-A
Nome:
Cadastrar Proprietário
Descrição:
O programa deve inserir um novo proprietário de animais no sistema de banco de dados.
Plataformas:
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome do Proprietário
· Animais do proprietário (pode ser nenhum, um ou mais de um)
· CPF
· Endereço do Proprietário (CEP, cidade, bairro, rua, número, complemento)
· Telefone e celular do Cliente
Saídas e pós-condições:
Proprietário cadastrado no sistema com um Id definido
Fluxos de eventos
Fluxo principal:
O funcionário deve informar o nome, CPF, endereço, telefone do cliente.
Após essa etapa o funcionário terá cadastrado um novo cliente no banco de dados do sistema.
Fluxo secundário 1:
Caso alguma informação seja inválida (não preenchida), uma janela será apresentada informando que os dados solicitados para cadastro estão incompletos.





RF-003-A
Nome:
Buscar Animal
Descrição:
O programa deve buscar um animal no seu sistema de banco de dados.
Plataformas:
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome animal ou parte dele
Saídas e pós-condições:
O objeto animal que contém os seguintes atributos:
· Nome do Animal
· Peso
· Idade (calculada na hora de acordo com a data de nascimento)
· Sexo
· Espécie
· Raça
· Porte
· Pelagem
· Óbito (sim/não)
· Id do Animal
Fluxos de eventos
Fluxo principal:
O usuário deve digitar o nome do animal que deseja.
Caso haja dois animais com o mesmo nome, o usuário deverá diferenciar a partir de outros atributos e em última instância pelo Id do animal que é único.
Ao achar o animal desejado, ele deverá selecioná-lo a fim de acompanhar todo seu perfil.









RF-004-A
Nome:
Buscar Proprietário
Descrição:
O programa deve buscar um proprietário no seu sistema de banco de dados.
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome do proprietário ou parte dele
Saídas e pós-condições:
O objeto proprietário que contém os seguintes atributos:
· Nome do Proprietário
· Animais do proprietário (pode ser nenhum, um ou mais de um)
· CPF
· Endereço do Proprietário (CEP, cidade, bairro, rua, número, complemento)
· Telefone e celular do Cliente
· Id do proprietário
Fluxos de eventos
Fluxo principal:
O usuário deve digitar o nome do proprietário que deseja.
Caso haja dois proprietários com o mesmo nome, o usuário deverá diferenciar a partir de outros atributos e em última instância pelo Id do proprietário que é único.
Ao achar o proprietário desejado, ele deverá selecioná-lo a fim de acompanhar todo seu perfil.














RF-005-A
Nome:
Alterar animal
Descrição:
O sistema deve permitir que o usuário altere informações do cadastro de um animal.
Ator:
Veterinário e Secretária
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Todos os atributos do animal poderão ser alterados a fim de deixar o sistema mais dinâmico e seguro, protegido de erros futuros gerados por cadastros mal gerados.
Saídas e pós-condições:
O animal terá seu cadastro atualizado.
Fluxos de eventos
Fluxo principal:
O sistema altera os dados do animal selecionado;
É exibida uma mensagem de êxito na tela.
Fluxo secundário 1:
Caso o usuário entre com algum dado inconsistente, durante o cadastro, deverá ser exibida uma mensagem de erro.


































RF-006-A
Nome:
Alterar Proprietário
Descrição:
O sistema deve permitir que o usuário altere informações do cadastro de um proprietário.
Ator:
Veterinário e Secretária
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Todos os atributos do proprietário poderão ser alterados a fim de deixar o sistema mais dinâmico e seguro, protegido de erros futuros gerados por cadastros mal gerados.
Saídas e pós-condições:
O proprietário terá seu cadastro atualizado.
Fluxos de eventos
Fluxo principal:
O sistema altera os dados do proprietário selecionado;
É exibida uma mensagem de êxito na tela.
Fluxo secundário 1:
Caso o usuário entre com algum dado inconsistente, durante o cadastro, deverá ser exibida uma mensagem de erro.
































RF-007-A
Nome:
Remover animal
Descrição:
O sistema deverá permitir que o usuário exclua um animal de seu banco de dados.
Ator:
Veterinário e Secretária

Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nome do animal, ou parte dele
Saídas e pós-condições:
O animal removido do sistema.
Fluxos de eventos
Fluxo principal:
Com o perfil do animal carregado, o usuário solicitará exclusão apartir de um botão;
O sistema solicita confirmação de exclusão;
O usuário confirma a exclusão;
O sistema remove o animal da base de dados.
Fluxo secundário 1:
Caso a exclusão não seja confirmada, volta-se a tela de dados do animal solicitado.































RF-008-A
Nome:
Remover proprietário
Descrição:
O sistema deverá permitir que o usuário exclua um proprietário de seu banco de dados.
Ator:
Veterinário e Secretária

Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nome do proprietário, ou parte dele
Saídas e pós-condições:
O proprietário removido do sistema.
Fluxos de eventos
Fluxo principal:
Com o perfil do proprietário carregado, o usuário solicitará exclusão apartir de um botão;
O sistema solicita confirmação de exclusão;
O usuário confirma a exclusão;
O sistema remove o proprietário da base de dados.
Fluxo secundário 1:
Caso a exclusão não seja confirmada, volta-se a tela de dados do proprietário solicitado.































RF-009-A
Nome:
Cadastrar consulta
Descrição:
O sistema deverá permitir ao veterinário adicionar uma nova entrada no histórico de consultas do animal
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Data/Hora
Sintomas;
Diagnóstico;
Exame Complementar;
Tratamento Realizado;
Saídas e pós-condições:
A consulta adicionada no histórico do animal.
Fluxos de eventos
Fluxo principal:
Com o perfil do animal aberto, o veterinário solicitará cadastro de consulta.
O sistema preenche automaticamente o campo da data e hora da entrada
O veterinário digita os outros dados
O usuário solicita a inclusão da nova entrada no histórico do animal.
O sistema grava a nova entrada no histórico do animal.
Fluxo secundário 1:
Caso alguma entrada não seja informada, o programa avisará ao veterinário o campo em branco, e perguntará se o usuário deseja proceder mesmo assim.



















RF-010-A
Nome:
Cadastrar cirurgia
Descrição:
O sistema deverá permitir ao veterinário adicionar uma nova entrada no histórico de cirurgias do animal.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Data/Hora;
Histórico;
Operação;
Saídas e pós-condições:
A cirurgia adicionada no histórico do animal.
Fluxos de eventos
Fluxo principal:
Com o perfil do animal aberto, o veterinário solicitará cadastro de cirurgia.
O sistema preenche automaticamente o campo da data e hora da entrada
O veterinário digita os outros dados
O usuário solicita a inclusão da nova entrada no histórico do animal.
O sistema grava a nova entrada no histórico do animal.
Fluxo secundário 1:
Caso a data e horário não sejam correspondentes aos valores atuais, o veterinário poderá modificá-las manualmente
Fluxo secundário 2:
Caso alguma entrada não seja informada, o programa avisará ao veterinário o campo em branco, e perguntará se o usuário deseja proceder mesmo assim.



















RF-011-A
Nome:
Cadastrar vacinação
Descrição:
O sistema deverá permitir ao veterinário adicionar uma nova entrada no histórico de vacinas do animal.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Data/Hora;
Vacina;
Observação;
Retorno (Sim/Não);
Data de retorno;
Saídas e pós-condições:
A vacina adicionada no histórico do animal.
Fluxos de eventos
Fluxo principal:
Com o perfil do animal aberto, o veterinário solicitará cadastro de vacina.
O sistema preenche automaticamente o campo da data e hora da entrada
O veterinário digita os outros dados
O usuário solicita a inclusão da nova entrada no histórico do animal.
O sistema grava a nova entrada no histórico do animal.
Fluxo secundário 1:
Caso a data e horário não sejam correspondentes aos valores atuais, o veterinário poderá modificá-las manualmente
Fluxo secundário 2:
Caso alguma entrada não seja informada, o programa avisará ao veterinário o campo em branco, e perguntará se o usuário deseja proceder mesmo assim.
















RF-012-A
Nome:
Cadastrar internação
Descrição:
O sistema deverá permitir ao veterinário adicionar uma nova entrada no histórico de internações do animal.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Data/Hora;
Medicações em seus devidos horários;
Saídas e pós-condições:
A internação adicionada no histórico do animal.
Fluxos de eventos
Fluxo principal:
Com o perfil do animal aberto, o veterinário solicitará cadastro de internações.
O sistema preenche automaticamente o campo da data e hora da entrada
O veterinário preencherá a tabela de medicações e cuidados e seus horários
O usuário solicita a inclusão da nova entrada no histórico do animal.
O sistema grava a nova entrada no histórico do animal.
Fluxo secundário 1:
Caso a data e horário não sejam correspondentes aos valores atuais, o veterinário poderá modificá-las manualmente
Fluxo secundário 2:
Caso alguma entrada não seja informada, o programa avisará ao veterinário o campo em branco, e perguntará se o usuário deseja proceder mesmo assim.




















RF-013-A
Nome:
Gerar receita (da consulta)
Descrição:
O veterinário deve poder gerar uma receita de uma consulta.
Plataformas
Animal
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
1 Consulta cadastrada
Saídas e pós-condições:
Receita impressa com sucesso.
Fluxos de eventos
Fluxo principal:
No momento que o usuário solicitar impressão de receita, o programa irá gerar um documento de uma receita e irá imprimir de acordo com os dados na consulta.
Fluxo secundário 1:
Fluxos secundários podem ocorrer decorrente da rotina de impressão padrão do Windows. Ele mesmo se encarregará de tratar os possíveis fluxos do programa na impressão.








RF-014-A
Nome:
Cadastrar Tosa/Banho
Descrição:
O programa deve poder cadastrar uma tosa/banho de um animal. Também será possível agendar futuras Tosas/Banhos.
Plataformas:
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Data/Hora
· Tipo do serviço
· Valor
· Desconto
Saídas e pós-condições:
Banho/tosa cadastrado no sistema com sucesso.
Fluxos de eventos
Fluxo principal:
O usuário deve informar todas as entradas.
Após essa etapa o usuário terá cadastrado uma tosa/banho referente ao Animal no banco de dados.
Fluxo secundário 1:
Caso alguma informação seja inválida (não preenchida), uma janela será apresentada informando que os dados solicitados para cadastro estão incompletos.






RF-015-A
Nome:
Registrar que Vacinação já foi administrada
Descrição:
O programa deve poder gravar no banco de dados que certa vacina já foi aplicada.
Plataformas:
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· O cadastro de vacinas de um Animal
Saídas e pós-condições:
Registrado o animal já vacinado.
Fluxos de eventos
Fluxo principal:
No cadastro do animal o usuário deve acessar o histórico de vacinas do mesmo.
Ele então seleciona a vacina que já foi aplicada e clica no botão correspondente que grava no sistema que o animal já foi vacinado.
Após essa etapa o sistema já terá gravado no BD que o animal já foi vacinado, e não mais participará do relatório dos animais a serem vacinados.



















RF-016-A
Nome:
Gerar relatório (animais a serem vacinados)
Descrição:
O veterinário deve poder gerar um relatório de cães a serem vacinados, contendo data de vacinação programada, nome do proprietário, nome do animal, tipo da vacina e telefone de contato.
Plataformas
Animal
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
O programa irá procurar no banco de dados as entradas.
Saídas e pós-condições:
Relatório impresso com sucesso.
Fluxos de eventos
Fluxo principal:
O usuário deve requerer um relatório dos cães ainda a serrem vacinados.
Após essa etapa o usuário receberá um relatório com todos cães a serem vacinados e as datas de suas vacinações.

























RF-017-A
Nome:
Gerar relatório (internamento)
Descrição:
O veterinário deve poder gerar um relatório de um internamento de um animal.
Plataformas
Animal
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Cadastro de internamento do animal
Saídas e pós-condições:
Relatório de internamento
Fluxos de eventos
Fluxo principal:
O usuário deve requerer um relatório de um internamento conhecido.
Após essa etapa o usuário receberá um relatório com os dados do internamento.






















RF-018-A
Nome:
Gerar fatura cirurgia
Descrição:
O veterinário pode emitir uma fatura da cirurgia para a secretária.
Plataformas
Desktop
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Informações de cadastro do animal, da atividade e preço do procedimento.
Saídas e pós-condições:
Fatura da cirurgia
Fluxos de eventos
Fluxo principal:
O usuário deve requerer a fatura de um de cirurgia
relativa a um animal.
A fatura será encaminhada para a secretária, de modo que
através desta o cliente tenha acesso àquela.





RF-019-A
Nome:
Gerar fatura consulta
Descrição:
O veterinário pode emitir uma fatura da consulta para a secretária.
Plataformas
Desktop
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Informações de cadastro do animal, da atividade e preço do procedimento.
Saídas e pós-condições:
Fatura da consulta
Fluxos de eventos
Fluxo principal:
O usuário deve requerer a fatura de um da consulta
relativa a um animal.
A fatura será encaminhada para a secretária, de modo que
através desta o cliente tenha acesso àquela.




RF-020-A
Nome:
Gerar fatura internamento
Descrição:
O veterinário pode emitir uma fatura do internamento para a secretária.
Plataformas
Desktop
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Informações de cadastro do animal, da atividade e preço do procedimento.
Saídas e pós-condições:
Fatura do internamento
Fluxos de eventos
Fluxo principal:
O usuário deve requerer a fatura de um internamento
relativo a um animal
A fatura será encaminhada para a secretária, de modo que
através desta o cliente tenha acesso àquela.














RF-021-A
Nome:
Gerar fatura tosa/banho
Descrição:
O veterinário pode emitir uma fatura da tosa/banho para a secretária.
Plataformas
Desktop
Atores:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Informações de cadastro do animal, da atividade e preço do procedimento.
Saídas e pós-condições:
Fatura da tosa/banho
Fluxos de eventos
Fluxo principal:
O usuário deve requerer a fatura de uma tosa/banho
relativa a um animal.
A fatura será encaminhada para a secretária, de modo que através desta o cliente tenha acesso àquela.













































RF-022-E
Nome:
Cadastrar produto
Descrição:
O veterinário deve poder cadastrar um produto.
Plataformas
Estoque
Atores:
Vendedora
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Informações do produto:
1 Fornecedor
2 Nome do produto
3 Valor de compra
4 Quantidade
5 Vendidos
Saídas e pós-condições:
Confirmação de cadastro bem sucedido.
Fluxos de eventos
Fluxo principal:
O vendedor deve poder cadastrar um produto informando suas características.
Após essa etapa o usuário receberá uma confirmação de cadastro bem sucedido.




















RF-023-E
Nome:
Buscar produto (por fornecedor)
Descrição:
O veterinário deve poder buscar todos produtos cadastrados com determinado nome de fornecedor.
Plataformas
Estoque
Atores:
Vendedora
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
1 Nome do fornecedor
Saídas e pós-condições:
Lista dos produtos cadastrados encontrados
Fluxos de eventos
Fluxo principal:
O usuário deve requerer uma lista dos produtos de determinado fornecedor.
Após essa etapa o usuário receberá uma lista com os produtos encontrados.




RF-024-E
Nome:
Buscar Produto (por nome)
Descrição:
O veterinário deve poder buscar informações sobre um produto.
Plataformas
Estoque
Atores:
Vendedora
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
1 Nome do produto
Saídas e pós-condições:
Produto
Fluxos de eventos
Fluxo principal:
O vendedor deve poder buscar um produto informando o seu nome.
Após essa etapa o usuário receberá um produto com suas informações.


RF-025-E
Nome:
Registrar compra de Produto
Descrição:
No momento que a clínica veterinária compra produtos de um fornecedor, o usuário do sistema deve informar ao S.G.C.V as informações da compra a fim de atualizar dados no BD.
Plataformas
Desktop
Atores:
Vendedora
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome do produto
· Fornecedor
· Data de compra
· Preço de compra
· Preço de venda
Saídas e pós-condições:
Novos produtos cadastrados com sucesso.
Fluxos de eventos
Fluxo principal:
O usuário deve informar todas as entradas.
Após essa etapa o usuário terá cadastrado um novo produto no estoque.
Fluxo secundário 1:
O fornecedor deve está previamente cadastrado no sistema, caso o fornecedor seja inválido, uma janela de erro aparecerá informando que o fornecedor não existe.




RF-026-E
Nome:
Registrar venda de Produto
Descrição:
A vendedora ao vender um produto deve registrar o mesmo no estoque do sistema. Ao fazer isso, o sistema gera uma janela na recepção que indica uma conta a ser paga pelo cliente. Para o cliente sair a conta deve ser paga. Caso ele seja cadastrado no sistema, ele pode pagar depois e a conta dele ficará armazenada.
Plataformas
Desktop
Atores:
Vendedora
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· A lista de produtos vendidos
· O seus respectivos preços
Saídas e pós-condições:
Venda cadastrada e conta para pagamento disponível na recepção.
Fluxos de eventos
Fluxo principal:
O usuário deve informar todas as entradas.
Após essa etapa o usuário terá cadastrado uma nova venda no banco de dados.


RF-027-E
Nome:
Registrar: Produto acabando
Descrição:
Quando o tamanho do estoque for menor que um valor determinado. O sistema deve avisar aos usuários que o produto está acabando.
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nenhuma entrada é dada. O método é disparado a cada venda feita.
Saídas e pós-condições:
Caso haja deficiência no estoque uma janela será aberta.
Fluxos de eventos
Fluxo principal:
O sistema checa o estoque dos produtos que foram comprados. Caso esteja deficiente, um alerta é disparado.
Fluxo secundário 1:
O sistema checa o estoque dos produtos que foram comprados. Caso não esteja deficiente, nada acontece.



RF-028-E
Nome:
Gerar fatura de venda
Descrição:
Nesta área o usuário poderá gerar uma diversidade de relatórios. Relativo a data, cliente, fornecedor, entre outras opções de gerar relatório.
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· O tipo de pesquisa que deseja e suas entradas
Saídas e pós-condições:
Um relatório é impresso com os dados requeridos
Fluxos de eventos
Fluxo principal:
O usuário deve informar todas as entradas.
Após essa etapa o usuário terá impresso a fatura desejada.



RF-029-L
Nome:
Cadastrar Amostra
Descrição:
O veterinário deve poder cadastrar uma amostra laboratorial no sistema.
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
1 Data do recebimento
2 Nome do animal
3 Nome do proprietário
4 Raça
5 Espécie
6 Tipo de amostra
7 Procedimento
8 Clínica proveniente
Saídas e pós-condições:
Amostra cadastrada no sistema com uma Id definido
Fluxos de eventos
Fluxo principal:
O usuário deve informar todas as entradas.
Após essa etapa o usuário terá cadastrado uma nova amostra no banco de dados.
Fluxo secundário 1:
Caso alguma informação seja inválida (não preenchida), uma janela será apresentada informando que os dados solicitados para cadastro estão incompletos.














RF-030-L
Nome:
Buscar amostra por nome do animal
Descrição:
O veterinário deve poder buscar uma amostra através do nome do animal que realizou o exame, o qual resultou na amostra.
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
9 Nome do animal ou parte dele
Saídas e pós-condições:
Amostra do animal
Fluxos de eventos
Fluxo principal:
O usuário deve informar o nome do animal ou parte dele.
Assim que for encontrada a amostra requerida na tabela dinâmica o usuário poderá acessar as informações da amostra.



RF-031-L
Nome:
Despachar amostra
Descrição:
O usuário, no momento que teve uma amostra já analisada pelo laboratório, ele poderá cadastrar como amostra já despachada.
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
10 Amostra
Saídas e pós-condições:
Amostra despachada com sucesso.
Fluxos de eventos
Fluxo principal:
O usuário deve informar a amostra a ser despachada.
Após essa etapa o usuário receberá a confirmação de que a amostra foi despachada com sucesso.






RF-032-C
Nome:
Cadastrar Funcionário
Descrição:
O programa deve poder cadastrar um funcionário do Banco de dados.
Plataformas:
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome
· CPF
· Endereço
· Salário
· Telefone de Contato
Saídas e pós-condições:
Funcionário cadastrado com sucesso.
Fluxos de eventos
Fluxo principal:
O usuário deve informar os dados do funcionário.
Caso todas as informações tenham sido dadas corretamente o programa irá dá a operação como bem sucedida.
Fluxo secundário 1:
Caso alguma informação tenha sido dada de forma incorreta o programa irá avisar que existe algum problema no cadastro.


RF-033-C
Nome:
Registrar compra de utilidades da clínica
Descrição:
Será possível registrar as pequenas compras da clínica que serão embutidas posteriormente na receita da clínica
Plataformas
Desktop
Atores:
Secretária e Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
· Nome do produto
· Valor do produto
Saídas e pós-condições:
Produto registrado com sucesso.
Fluxos de eventos
Fluxo principal:
O usuário deve preencher o cadastro com o nome do produto e o valor.
Após isso o sistema terá guardado na receita da clínica o gasto feito.

RF-034-C
Nome:
Gerar Receita
Descrição:
Nesta funcionalidade o usuário poderá gerar o tipo de receita que lhe convier. Podendo tirar extrato de todos os gastos em um período desejado, assim como os gastos de determinado animal ou proprietário, ou gastos só de utilidades da clínica.
Ator:
Veterinário e Secretária
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
O tipo de receita que deseja gerar
O período desejado
Saídas e pós-condições:
Será gerada uma receita que pode ser impressa.
Fluxos de eventos
Fluxo principal:
O usuário deve preencher o tipo de receita e o período desejado.
Após informar os dados ele deverá obter a receita de todos os gastos que podem inclusive ser impressos.




RF-035-C
Nome:
Pagar Cirurgia
Descrição:
O sistema realizará o cadastramento do pagamento referente ao
procedimento cirúrgico realizado em determinado animal.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nome do animal, valor da cirurgia.
Saídas e pós-condições:
O pagamento é adicionado à receita do dia referente.
Fluxos de eventos
Fluxo principal:
O usuário procura o animal. Com a ficha do mesmo aberta, solicitará a ficha de cirurgias. Informará ao sistema o pagamento da cirurgia, atualizando assim o sistema de caixa.
Fluxo secundário 1:
Caso a cirurgia não tenha sido paga, o sistema informará na ficha do animal débito pendente.




RF-036-C
Nome:
Pagar Consulta
Descrição:
O sistema realizará o cadastramento do pagament
o referente ao procedimento clínico realizado em
determinado animal.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nome do animal, valor da consulta;
Saídas e pós-condições:
O pagamento é adicionado à receita do dia referente.
Fluxos de eventos
Fluxo principal:
O usuário procura o animal. Com a ficha do mesmo aberta, solicitará a ficha de consultas. Informará ao sistema o pagamento da consulta, atualizando assim o sistema de caixa.
Fluxo secundário 1:
Caso a consulta não tenha sido paga, o sistema informará na ficha do animal débito pendente.







RF-037-C
Nome:
Pagar Funcionário
Descrição:
O sistema realizará o cadastramento do
pagamentoreferente ao funcionário referente ao
período do tempo combinado para pagamento.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nome do funcionário, custo/hora e
horas trabalhadas.
Saídas e pós-condições:
O pagamento é adicionado à receita do dia.
Fluxos de eventos
Fluxo principal:
O usuário procura o funcionário. Com a ficha do mesmo aberta, solicitará a ficha de pagamentos. Informará ao sistema o pagamento do procedimento, atualizando assim o sistema de caixa.
Fluxo secundário 1:
Caso o pagamento esteja atrasado, um aviso de pagamento pendentes será disparado.
















RF-038-C
Nome:
Pagar Internamento
Descrição:
O sistema realizará o cadastramento do pagamento referente ao procedimento de internamento realizado sobre determinado animal.
Ator:
Veterinário
Prioridade:
Essencial
Requisitos Não Funcionais Associados:

Entradas e pré-condições:
Nome do animal, valor do internamento;
Saídas e pós-condições:
O pagamento é adicionado à receita do dia referente.
Fluxos de eventos
Fluxo principal:
O usuário procura o animal. Com a ficha do mesmo aberta, solicitará a ficha de internamentos. Informará ao sistema o pagamento do internamento, atualizando assim o sistema de caixa.
Fluxo secundário 1:
Caso o internamento não tenha sido pago, o sistema informará na ficha do animal débito pendente.







RF-039-C
Nome:
Pagar Tosa/Banho
Descrição:
O sistema realizará o cadastramento do pagamento referente ao procedimento de limpeza realizado em determinado animal, seja ele tosa ou banho.
Ator:
Secretária
Prioridade:
Essencial
Requisitos Não Funcionais Associados:
RNF/USA-11
RNF/USA-10
Entradas e pré-condições:
Nome do animal, valor do procedimento
e tipo(tosa ou banho).
Saídas e pós-condições:
O pagamento é adicionado à receita do dia referente.
Fluxos de eventos
Fluxo principal:
O usuário procura o animal. Com a ficha do mesmo aberta, solicitará a ficha de banhos. Informará ao sistema o pagamento do procedimento, atualizando assim o sistema de caixa.
Fluxo secundário 1:
Caso o procedimento não tenha sido pago, o sistema informará na ficha do animal débito pendente.




RF-040-C
Nome:
Pagar Venda
Descrição:
O sistema realizará o cadastramento do
Pagamento referente ao produto vendido na
loja.
Ator:
Secretária
Prioridade:
Essencial
Requisitos Não Funcionais Associados:
RNF/USA-11
RNF/USA-10
Entradas e pré-condições:
Nome do produto, tipo, preço.
Saídas e pós-condições:
O pagamento é adicionado à receita do dia referente.
Fluxos de eventos
Fluxo principal:
O usuário procura o produto da venda de acordo com o nome ou o fabricante. Seleciona a quantidade e aciona a venda. O produto é retirado do estoque e a receita é adicionada ao sistema de pagamentos do dia.
Fluxo secundário 1:
Caso o produto não conste no sistema, será emitido um aviso.


RF-041-C
Nome:
Registrar hora-extra
Descrição:
Poderá ser registrado as horas extras de cada funcionário a fim de adicionar o pagamento no fim do mês.
Ator:
Veterinário e Secretária
Prioridade:
Essencial
Requisitos Não Funcionais Associados:
RNF/USA-11
RNF/USA-10
Entradas e pré-condições:
Quantidade de horas extras do dia.
Saídas e pós-condições:
Será adicionado no sistema a quantidade de horas extras do funcionário.
Fluxos de eventos
Fluxo principal:
O usuário só precisa informar a quantidade de horas extras do dia do funcionário.
O sistema se encarregará de adicionar no total das horas extras do mês do funcionário.

3.2.1 Diagramas de casos de uso
3.2.1.1 Diagrama de casos de uso do Sistema de Gerenciamento de Clínica Veterinária Clivet .
3.2.2 Casos de uso

3.3 Requisitos não funcionais

Foram identificado alguns requisitos não-funcionais. Eles estão agrupados em requisitos de processo, produto.
3.3.1 Requisitos de Processo

Ident.
Descrição
RNF/PROC-01
O sistema será implementado na Linguagem de Programação C#, sendo assim portável nas plataformas mais utilizadas (Windons, Linux).
RNF/PROC-02
Será feita uma documentação contendo o diagrama de classes, visto que a linguagem utilizada segue o paradigma da orientação a objetos. E também informações sobre o código-fonte do projeto.
RNF/PROC-03
Serão utilizadas ferramentas CASE, e também será criada uma modelagem usando a linguagem UML.


3.3.2 Requisitos do Produto.
Segurança
Ident.
Descrição
RNF/SEG-04
A secretária terá acesso as funções de cadastro de animais e controle de caixa.
RNF/SEG-05
O veterinário terá acesso as funções de cadastramento de animais.
RNF/SEG-06
A vendedora terá acesso as funções de controle de estoque.
RNF/SEG-07
O dono terá acesso à todas funcionalidades.















Performance

Identificador
Descrição
RNF/PER-08
O tempo de retorno das consultas (isto é, o intervalo de tempo entre qualquer consulta e seu resultado) não pode ser maior do que 4 segundos.

Usabilidade
Identificador
Descrição
RNF/USA-10
O tratamento de exceções deverá facilitar eventuais manutenções no sistema.

RNF/USA-11
O sistema usará uma interface intuitiva que permitirá a utilização do sistema com toda sua potencialidade em um curto espaço de tempo e beneficiará o trabalho dos usuários.

Manutenabilidade
Identificador
Descrição
RNF/MAN-12
O sistema será dividido em módulos, de modo que as atualizações serão feitas mais rapidamente e sem a necessidade de longos períodos de atualização onde o sistema ficaria impossibilitado de operar.

Documentação
Identificador
Descrição
RNF/DOC-13
O sistema possuirá um manual de uso a fim de auxiliar os diferentes tipos de usuário. O mesmo explicará detalhadamente como proceder na realização das funções requisitadas para a aplicação.
















Casos de teste

Caso de teste
CT-01 Buscar pelo “Cadastro”, escolher a aba tipo de cadastro: Animal/Proprietário
Pré Condição
Ao ticar na aba escolhida
Procedimentos
1. Ator1 clicar na aba desejada.
2.O sistema apresentara ao ator todos os campos necessários para a inserção dos dados do animal e o proprietário do animal
Resultados Esperados
Carregar a tela de cadastro
Dados de Entrada

Critérios Especiais
Não se aplica
Ambiente
Desktop
Implementação
RF-001/RF002
Interação
Manual

Caso de teste
CT-02 Buscar por “Alterar” escolher a aba tipo de alteração Animal/Proprietário
Pré Condição
Ao ticar na aba escolhida
Procedimentos
1.Ator1 Clica na aba desejada
2. O sistema apresentara ao ator todos os campos necessários para a alteração dos dados do animal e do proprietário do animal
Resultados Esperados
Carregar a tela de Alteração
Dados de Entrada

Critérios Especiais
Não se aplica
Ambiente
Desktop
Implementação
RF-005/RF006
Interação
Manual


Caso de teste
CT-03 Buscar por “Pesquisar” escolher pela aba pesquisar
Pré Condição
Ao ticar na aba escolhida
Procedimentos
1-ator1 clica na aba desejada
2- O sistema apresentara ao ator todos os campos necessários para a pesquisa de dados
Resultados Esperados
Carregar a tela com os dados solicitados
Dados de Entrada

Critérios Especiais
Não se aplica
Ambiente
Desktop
Implementação
RF-003/RF-004
Interação

АТПС по программной инженерии (Шаг 4)

Etapa IV

Prototipação e Teste de Software

Introdução

Apresentaremos nesta etapa os diagramas das interfaces gráficas (não todas elas, por economia de toner colorido; porém, explicaremos todas elas) do nosso projeto, referentes a cada requisito funcional.

Para cada interface, apresentaremos também um plano de testes funcionais, em formulários.

Desenvolvimento

Temos os seguintes requisitos funcionais em nosso software (ver Tabela 1 abaixo):

Nome	Tipo	Código
Efetuar login no sistema	Funcionais	P00
Cadastro de dados no sistema	Funcionais	C00
Gerência de usuários	Funcionais	P01
Tela para inserção/remoção/co nsulta de dados	Funcionais	P02
Apresentação da aplicação	Funcionais	P03
Menu Ajuda	Funcionais	H01
Cadastro (Inserção/Remoção) de Animais	Funcionais	C01
Cadastro (Inserção/Remoção) de Clientes/Donos	Funcionais	C02
Cadastro (Inserção/Remoção) de Produtos	Funciona is	C04
Cadastro (Inserção/Remoção) de Horários na Agenda	Funcionais	C03
Busca/Consulta de Animais, Clientes, Produtos e Agenda	Funcionais	B00

Tabela 1: requisitos funcionais e código dos mesmos.

O formulário do caso de teste segue o seguinte padrão:

Informação	Descrição
Caso de teste
Pré-condições
Procedimentos
Resultado esperado
Dados de entrada
Critérios especiais
Ambiente
Implementação
Iteração

Formulário 1: guia

Tela de Login

Informação	Descrição
Caso de teste	P00 e P01 – Login no sistema
Pré-condições
Procedimentos	Inserir nome de usuário e senha
Resultado esperado	Logar no sistema; ir para a próxima tela
Dados de entrada	Login e senha (chars / strings)
Critérios especiais	Contagem interna do número de tentativas de login, sem sucesso; apresentação da tela de login/senha inválido(s) caso necessário
Ambiente	Tela do cliente, acessa o servidor
Implementação	Manual
Iteração	Primeira

Formulário 2: P00 e P01

Fig. 1: interface de login

Podemos verificar a interface de login aqui. Temos 2 campos, um para nome de usuário, e o outro para a senha (mascarada com **********). Além disso, temos um aviso de conexão do servidor (verde = ok, vermelho = sem conexão) e um e-mail para contato com o nosso suporte.

Fig. 2: tela de Login / senha inválido(s)

Conforme vemos na página anterior, caso o login e/ou senha sejam inválidos, aparece a tela anterior. O usuário, então, clica em Ok e retorna à tela da Fig. 1.

Caso seja de interesse do usuário, podemos fazer (por segurança) um módulo que conta o número de logins incorretos sequenciais, bloqueando o acesso por “n”minutos, após “m”tentativas incorretas de acesso.

Para cada usuário, a tela seguinte pode variar (por exemplo, um usuário com maiores privilégios veria a tela a seguir (Fig. 3)).

Tela para inserção/remoção/consulta de dados

Informação	Descrição
Caso de teste	P02 e P03 – Tela para inserção/remoção/consulta de dados
Pré-condições	Ter fornecido login/senha corretos
Procedimentos	Consultar/Inserir/Alterar/Excluir registros (caso tenha permissão)
Resultado esperado	Ir para a próxima tela (de acordo com a escolha)
Dados de entrada	Clicar no botão da operação desejada
Critérios especiais	Caso o usuário não possa acessar um ou outro item, o mesmo aparecerá em baixo relevo; botões que possam ser acessados, sempre em alto relevo.
Ambiente	Tela do cliente
Implementação	Manual
Iteração	Segunda

Formulário 3: P02 e P03

Fig. 3: interface pós login

Temos aqui a interface do usuário; os botões podem ser acessados pelo clique do mouse ou por teclas de atalho. Por se tratar de um protótipo, campos de inserção de cadastro dos donos dos animais, botões de logout/logoff não forem criados e nem o menu de ajuda para esta tela.

Podemos verificar a existência de 2 botões, escritos em vermelho. Estes são para pesquisas gerais (em toda a base de dados) e para recuperar um registro apagado anteriormente.

Caso cliquem em Pesquisar, a seguinte tela aparecerá:

Fig. 4: atalho para tela de pesquisa

Esta tela nada mais é do que um atalho para a pesquisa de animais (o mesmo que clicar em Consultar Animais), Consultar Dono (função ainda não disponível no menu inicial) e Estoque de Produtos (PS: produtos aparecem no estoque mesmo se a quantia for 0). Caso não queira consultar nada, clicar em “Cancelar” para voltar à tela anterior.

Busca/Consulta de Animais, Clientes, Produtos e Agenda

Informação	Descrição
Caso de teste	B00 - Busca/Consulta de Animais, Clientes, Produtos e Agenda
Pré-condições	Ter elementos inseridos na base de dados (base não nula)
Procedimentos	Preencher de 1 a “n” campos da tela de busca
Resultado esperado	Obter (ou não) o valor buscado
Dados de entrada	Strings (chars), inteiros e números com casas decimais
Critérios especiais	Trata-se de um “select” na tabela X, tendo como valor(es) os dados inseridos pelo usuário.
Ambiente	Tela do cliente, acessa o servidor para fazer a busca na base
Implementação	Manual
Iteração	Quarta

Formulário 4: B00 - Busca/Consulta de Animais, Clientes, Produtos e Agenda

Fig 5: Pesquisar animais

Conforme vemos, temos vários campos; pode-se preencher apenas um ou vários deles; caso mais de um animal com a mesma informação buscada aparecer, eles serão listados (com poucos campos numa tela de refinamento de busca; tela ainda não criada).

Caso apenas um animal seja encontrado, ele aparecerá no campo “Resultados da busca”, com todas as suas informações. Tais dados (dos animais, nos resultados) podem ser alterados ou impressos.

Fig. 6: Busca sem sucesso Fig. 7: Alterar dados?

Conforme vemos, a Fig. 6 mostra a tela que trata de erros na busca; já a Fig. 7 é um menu pop-up de confirmação caso cliquem em “Alterar”.

Por se tratar de um protótipo, esta tela está pronta, mas, não temos ainda a tela de pesquisar Produtos.

Vale ressaltar que esta tela busca Animais e Donos de animais.

Fig. 8: Verificar Agenda

Mais um elemento de pesquisa (pronto) em nosso protótipo; nele, seleciona-se o dia/mês/ano que queira consultar e, automaticamente, a agenda aparece no campo: “Resultado da busca”, podendo ser alterada ou impressa. Os pop-ups (Fig. 6 e Fig. 7) podem aparecer de novo, caso necessário (dependendo da escolha da operação e/ou de seu resultado)

Menu Ajuda (?)

Informação	Descrição
Caso de teste	H01 – Ajuda
Pré-condições
Procedimentos	Clicar no link Ajuda(?)
Resultado esperado	Obter um janela de pop-up com informações detalhadas de todos os botões e campos da tela referente ao link de ajuda.
Dados de entrada
Critérios especiais
Ambiente	Tela do cliente, local.
Implementação	Manual
Iteração	Última

Formulário 5: H01 – Menu Ajuda

Por se tratar de um protótipo, tais menus de ajuda não encontram-se prontos, pois, estes serão a última coisa a ser feita em nosso projeto.

Cadastro de dados no sistema

Informação	Descrição
Caso de teste	Engloba C00, C01, C02, C03 e C04 – Cadastra (Insere/Remove) Animais, Clientes, Produtos e dados na Agenda.
Pré-condições	Ter permissão para inserir dados na base de dados
Procedimentos	Preencher, ao menos, os campos em negrito para cada tabela.
Resultado esperado	Obter (ou não) sucesso na operação de cadasto( inserção ou remoção)
Dados de entrada	Strings (chars), inteiros e números com casas decimais
Critérios especiais	Trata-se de inserir ou remover valores na tabela. PS: Inserir / Remover não é o mesmo que Alterar!
Ambiente	Tela do cliente, acessa o servidor para fazer inserção/remoção de dados na base
Implementação	Manual
Iteração	Terceira

Formulário 6: Cadastrar / Excluir

A interface será muito semelhante ã interface apresentada nas Figs. 5 e 8; porém, os dados serão diferentes para:

• Animais;

• Donos;

• Produtos;

• Agenda.

Além disso, será apresentada uma tela pop-up sempre perguntando se “Realmente deseja inserir este cadastro?” ou “Realmente deseja excluir este cadastro?“, com opções de “Sim”, “Não” e “Ajuda”.

Conclusão

Este documento será entregue ao cliente, junto ao protótipo da aplicação, buscando mostrar ao mesmo os rumos do projeto, e, se este precisa de muito mais funções do que as atualmente disponíveis.

Além disso, tal protótipo ajudar-nos-á a validar as soluções propostas e a performance da aplicação.

Alunos:

Samir Piccolotto RA: 0943486061

Nathalia Elias RA: 0832494

Jean Pavanelli RA: 0945489169

Gustavo Chinaglia RA: 0901348552

Cesar Cardoso RA: 0901412846