Etapa 1

Introduo

Marcada uma reunio, comparecemos CLIVET, uma clinica veterinria com uma
grande quantidade de funcionrios. A CLIVET, alm de ser uma Clinica Veterinria,
possui laboratrio, hospedagem para ces, banho e tosa, transporte de entregas e muito
mais. Futuramente o proprietrio Bruno Pereira, planeja em ampliar sua clinica em um
Hospital veterinrio. Entendendo sua necessidade, nos comunicou para desenvolvermos
um software que se adapta a todas as funes que sua clinica oferece. Enfim,
resolvemos trabalhar com algum mtodo/metodologia que nos permita entregar: ou
prottipos ou fazer com que nosso software seja facilmente modificado.
Na entrevista com nosso cliente, perguntando sobre as caractersticas desejadas do
software, complexidade, integrao com qual tipo de banco de dados (se necessrio),
tamanho da base de dados do mesmo, necessidade (ou no) de ser acessado via web, ser
expansvel para possveis filiais, vontade do mesmo em ter um software que possa ser
atualizado facilmente, etc.
Com as necessidades de nosso cliente, escolhemos entre as trs metodologias
inicialmente propostas, a que julgamos ser melhor pelo comportamento de nosso
cliente, e pelo que julgamos que o cliente quer ou espera do software.

Clssico
(cascata)
P

Prototipao

Exige extensa
documentao:
Software facilmente modificado PP
/ expansvel:
Gerar um prottipo / beta:
NP

Metodologia
gil / Scrum
PP*

Exige
excelentes/experientes
programadores:
Clculo do fator risco:

NA**

NA**

NP

NP

Fcil clculo do tempo de entrega PP

do software

NA

Onde: P = possui; PP = possui parcialmente; NA = no se aplica; NP = no possui.

* = se o cliente desejar feito; porm no uma caracterstica da metodologia.
** = a menos que a empresa j conte com excelentes programadores; em teoria, no
necessrio.
Vamos, agora, apresentar uma tabela comparativa entre as trs metodologias:

,
Clssico
(cascata)

Prototipao

gil / Scrum

Vantagens
* antigo;
* muito utilizado;
*Minimiza o tempo de
planejamento;
*Funciona bem com equipes
tecnicamente mais fracas;
* linear.

Desvantagens
*Perde-se muito tempo com
documentaes, nem sempre
necessrio;
*Projetos chegam a levar muitos
meses para serem concludos;
*Cliente s v o programa em
funcionamento ao final de todo o
processo;
*No necessita de uma equipe
bem integrada, o que pode gerar
falhas ou incapacidade do
programa ser atualizado;
*No tem anlise de risco.
*Trabalha com um prottipo do
*Cliente pode se contentar com o
software;
prottipo, e esquecer a verso
*Cliente recebe uma verso
final;
prottipo do mesmo, para
*Impossvel determinar com
utilizao e testes;
exatido o tempo que o processo
*Pode ser utilizado quando a
vai durar;
comunicao com o cliente no *No h formas de saber o
completa;
nmero de iteraes necessrias;
*Facilmente atualizvel;
*Muitas vezes, o prottipo acaba
*Bom para softwares com
atrapalhando o desenvolvimento
mudanas de requisitos constantes. da verso final;
*No h anlise de risco.
* gil;
*Necessita de um time bem
*Utiliza anlise de risco;
entrosado;
*Focado na negociao interna e
*Necessita de bons
com clientes;
programadores;
*Agrega muito valor ao produto e *Ambiente que facilite a fcil
ao cliente;
comunicao entre os membros;
*Geralmente, traz alto grau de
*Quebra de paradigmas
satisfao do cliente com o
complicado;
produto;
*Difcil de gerenciar projetos que
*Time pequeno.
precisam de muitas pessoas.

Diante das necessidades requeridas o proprietrio da clinica CLIVET, optou pelo

mtodo scrum. Por ser um software barato, rpido e que facilmente atualizvel, e, sem
uma extensa documentao.

Etapa 2
Requisitos Funcionais

Ser apresentada uma pgina inicial, com o logotipo da empresa, e campos de nome e
senha; nesta pgina, pode-se entrar como usurio com privilgios de consulta (apenas),
cadastro de clientes e animais, e diagnsticos/vacinas/compras de produtos, etc.
RF.01 <Controle de Funcionrios>
O sistema ter a funcionalidade de fazer os cadastros dos funcionrios de acordos com
os dados informados ou coletado (nome, cargo, e-mail, telefone, sexo, data de
nascimento, cidade, bairro, endereo, nmero, CEP, RG, CPF, salrio, perodo de
trabalho, foto). O sistema gera um cdigo para o cadastro do funcionrio, onde este
jamais possa ser alterado.

RF.02 <Controle de Cargo>

Ser responsvel pela seleo do Cargo quando o cadastro do funcionrio for feito,
podendo escolher dentre as opes criadas neste Controle. Dever permitir tambm que
seja possvel incluir, alterar e excluir os dados: cdigo do Cargo, tipo do cargo (comum,
estagirio, veterinrio, entre outros),horrio de expediente.

RF.03 <Controle de Cadastro >

A tela de cadastramento vai ser aberta por abas (Cliente, Animal, Informaes)

RF.03.1 <<Cliente>>

Permite ao usurio o cadastramento de clientes, juntamente com seus animais, atravs

dos dados coletados: nome, sexo , data de nascimento, CPF/CNPJ, RG, telefone , email, endereo, numero, cidade, bairro, CEP, grupo, codigo. Ex: figura 1

Figura 1: exemplificando uma tela de cadastro: sistema Autopet.

RF.03.2 <<Animais>>
Este requisito est relacionado est relacionado com o cadastro do cliente. Onde permite
ao usurio, assim que terminar o cadastro do cliente, cadastrar o animal e servios
prestados na aba seguinte. O sistema dever permitir tambm que seja possvel incluir,
alterar e excluir os dados: nome, caractersticas, idade, raa, espcie, sexo, proprietrio
(abrir nova tela para associar / registrar), veterinrio responsvel (abrir nova tela para
associar), porte, foto. No campo informaes do animal constar todo procedimento
feito na clinica no caso de consulta. No caso de vacina. O sistema vai requerer a data da
vacina aplicada, pra assim que houver um vencimento, possa avisar o usurio e o
veterinrio responsvel do mesmo vencimento.
RF.04 <Agendamento>
RF04.1 <<Consulta>>

Esse requisito ser referente as consultas agendadas na clinica. O usurio ter que
obedecer alguns requisitos do sistema para no haver casos de dois agendamento ao
mesmo tempo. Ao agendar uma consulta, esta ser automaticamente agendada na
agendado veterinrio responsvel. O sistema dever permitir tambm que seja possvel
incluir, alterar e excluir os dados:cdigo Consulta, data, hora, tipo. Consultas
Emergenciais devero ser includas.
Este Requisito ser responsvel pelo cadastro dos clientes da clnica atravs de suas
informaes pessoais. E est relacionado aos animais o qual o cliente proprietrio.

RF04.2 <<Banho e tosa>>

Este requisito apenas os funcionrios de frente de recepo e banho e tosa poder ter
acesso s informaes. Neste requisito o usurio poder agendar animais para banho

com os servios e as informaes necessrias que o tosador poder usar. Cada tosador
ter seu campo com seu nome, agenda dos horrios e servios. O usurio poder alterar,
excluir, acessar informaes de cadastro (endereo e telefone). Este Requisito ser
responsvel pelo cadastro dos clientes da clnica atravs de suas informaes pessoais.
E est relacionado aos animais o qual o cliente proprietrio.
RF04.3<<Hospedagem>>

Este requisito fornece quase as mesmas informaes que os anteriores. Ser responsvel
pelo cadastro dos clientes da clnica atravs de suas informaes pessoais. E est
relacionado aos animais o qual o cliente proprietrio. O sistema abrir uma agenda do
ms e dia, ao qual o funcionrio ter acesso data e horrio que o animal hospedado
entra e sai da hospedagem. O prprio sistema gera uma pendncia, onde o proprietrio
pode opinar por pagar na entrada e na sada. O sistema s no poder gerar uma
pendncia no caso de o proprietrio passar do horrio que j foi pago. Nesse caso o
prprio usurio tem que gerar o pagamento de acordo com o atraso. Nas informaes do
animal, haver os pertences obrigatrio, registrados detalhadamente feitos pelo prprio
usurio.
RF05 <<>>

Figura 2: Tela de lanamento, consultas, agenda, fechamento e etc.

No fechamento de vendas, o sistema solicita o CPF do cliente caso este no tenha

cadastro. Se o cliente for cadastrado o sistema fecha a venda com CPF na nota. O
operador ter opes de formas de pagamentos. Crdito, Dbito, Cheque, Dinheiro. No
fechamento, o sistema pode lanar vales para o cliente, resgatar e gerar pendncias.

Veterinrio: permite ao usurio o cadastramento de animais, agendamento e pesquisa

de retornos, impresso de receitas, relatrio de consulta e procedimentos. O modulo
possui histrico de receitas, de consultas/vacinas, lembrete de retornos e vacinas entre
outros.
Administrativo: permite ao usurio o cadastramento de produtos, controle de estoque,
controle de funcionrio, controle de vendas de funcionrios, estornos de vendas,
controle de senhas e login. Este mdulo possui o controle de permisso dos outros
mdulos. Por exemplo: O usurio (chefe) poder determinar qual login tem acesso ao
veterinrio; qual ter acesso ao administrativo.
O sistema permite a alterao dos dados do cliente com exceo do cdigo do cliente
que gerado automaticamente pelo sistema.
Produtos/ Estoque: Permite ao funcionrio do estoque ter apenas acesso quantidade
de produtos que entra e sai do estoque. Automaticamente, esse mdulo, anda junto com
o Caixa e Administrativo, para que assim tenham certo controle da preciso da clinica.
O sistema ter um cabeamento de rede, onde liga um computador servidor.

Requisitos no funcionais

Nas questes dos itens no funcionais temos:

Manutenibilidade: para preservar o banco de dados sempre atualizado e ativo, haver
uma opo de backup na tecla Sair, onde permite enviar tudo ao banco de dados do
servidor. Evitando futuros erros ao sistema. Lembrando que o funcionrio noturno
dever fazer isso toda vez depois da meia-noite. Caso no for resolvido por backup e o
erro for fatal, haver sempre um suporte on-line que poder ser auxiliado.
Eficincia: O sistema ter um controle do fluxo de informaes financeiras. Ser capaz
de corrigir e melhorar processos e carregar as informaes dos clientes dentro de no
mximo 15 segundos aps sua requisio.
Segurana: O sistema vai conter uma hierarquia de permisses administrada por um
usurio qualificado e autorizado pelo responsvel da empresa. Onde cada login vai
determinar o acesso permitido, conforme j explicado.
Confiabilidade: Os backups dirios proporcionaro menos erros ao sistema. Mas em
casos de erros fatais o servidor ser o nico a no ser derrubado, sendo este o nico

usado pra o suporte on-line possibilitando assim a permanncia eficiente do banco de

dados.
Portabilidade: Poder ser executado apenas em Windows a partir de sua verso XP,
nas plataformas 32bits. Exigindo no mnimo 512mb RAM , 50gb HD, Pentium4
(mnimo).

Definio das prioridades dos requisitos

Prioridade
Manutenibilidade
Eficincia
Segurana
Confiabilidade
Portabilidade

Grau
1
2
2
1
3