ATPS Engenharia de Software

Prévia do material em texto

Anhanguera Educacional 
Faculdade Anhanguera de Valinhos 
Ciência da Computação 
 
 
 
 
Engenharia de Software e Análise de Sistemas Atividades Práticas 
Supervisionadas 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Valinhos 
2014
 
 
 
 
 
 
 
 
Engenharia de Software e Análise de Sistemas Atividades Práticas 
Supervisionadas 
 
 
 
 
Monografia apresentada como exigência 
para obtenção do grau de Bacharelado 
em Ciência da Computação da Matéria de 
Engenharia de Software e Análise de 
Sistemas da Anhanguera Educacional. 
Orientador: 
 
 
 
 
 
 
 
 
 
 
Valinhos 
2014 
RESUMO 
 
 
 
Esta monografia irá demonstrar o processo de um desenvolvimento de um software 
cujo temos que seguir as características do clientes que serão impostas em nosso 
projeto, sendo que o cliente é uma clínica veterinária cujo quer obter um software 
comercia para cadastro, será colocada também os diagramas do software 
desenvolvido e sua interface gráfica que é de suma importância. 
 
Palavras-chave: Escalonamento, Requisitos, Sistemas, Gerenciamento, Diagrama 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURAS 
 
 
Figura 1 - Diagrama de classe funcionalidades do sistema. ..................................... 10 
Figura 2 - Diagrama de classe cadastro e serviços ................................................... 11 
Figura 3 - Diagrama de classe agenda ..................................................................... 14 
Figura 4 - Diagrama de classe consultas .................................................................. 15 
Figura 5 - Diagrama de classe funcionamento do caixa ............................................ 16 
Figura 6 - Diagrama de classe finanças .................................................................... 17 
Figura 7 - Diagrama de classe estoque ..................................................................... 17 
Figura 8 - Diagrama de classe cadastro parte 1 ........................................................ 17 
Figura 9 - Diagrama de classe cadastro parte 2 ........................................................ 17 
Figura 10 - Diagrama de classe cadastro parte 3 ...................................................... 17 
Figura 11 - Diagrama de classe cadastro parte 4 ...................................................... 17 
Figura 12 - Diagrama de classe ferramentas ............................................................ 17 
Figura 13 - Diagrama de casos de uso usuário ......................................................... 17 
Figura 14 - Diagrama de casos de uso agenda......................................................... 17 
Figura 15 - Diagrama de casos de uso consultas ..................................................... 17 
Figura 16 - Diagrama de casos de uso pré-venda .................................................... 17 
Figura 17 - Diagrama de casos de uso caixa ............................................................ 17 
Figura 18 - Diagrama de casos de uso finanças ....................................................... 17 
Figura 19 - Diagrama de casos de uso estoque ........................................................ 17 
Figura 20 - Diagrama de casos de uso gerencial ...................................................... 17 
Figura 21 - Diagrama de casos de uso cadastro ....................................................... 17 
Figura 22 - Diagrama de casos de uso ferramentas ................................................. 17 
Figura 23 - Diagrama de sequência módulo do cliente ............................................. 17 
Figura 24 - Diagrama de sequência agenda ............................................................. 17 
Figura 25 - Diagrama de sequência consultas .......................................................... 17 
Figura 26 - Diagrama de sequência pré-venda ........................................................ 17 
Figura 27 - Diagrama de sequência finanças ............................................................ 17 
Figura 28 - Diagrama de sequência estoque ............................................................ 17 
Figura 29 - Diagrama de sequência finanças gerência (cadastro) 1 ......................... 17 
Figura 30 - Diagrama de sequência finanças gerência (cadastro) 2 ......................... 17 
Figura 31 - Diagrama de sequência finanças gerência (cadastro) 3 ......................... 17 
Figura 32 - Diagrama de sequência ferramentas ...................................................... 17 
Figura 33 - Diagrama de atividade cadastro ............................................................. 17 
Figura 34 - Diagrama de atividade agenda ............................................................... 17 
Figura 35 - Diagrama de atividade consulta .............................................................. 17 
Figura 36 - Diagrama de atividade pré-venda e venda (caixa) .................................. 17 
Figura 37 - Diagrama de atividade finanças .............................................................. 17 
Figura 38 - Diagrama de atividade estoque .............................................................. 17 
Figura 39 - Diagrama de atividade gerencia (cadastro) ............................................ 17 
Figura 40 - Diagrama de atividade ferramentas ........................................................ 17 
Figura 41 - Software Clivet interface “Acesso ao sistema”. ....................................... 17 
Figura 42 - Software Clivet interface “Agendamentos”. ............................................. 17 
Figura 43 - Software Clivet interface “Agendamento completo”. ............................... 17 
Figura 44 - Software Clivet interface “Agendamento simplificado”. ........................... 17 
Figura 45 - Software Clivet interface “Consultas”. ..................................................... 17 
Figura 46 - Software Clivet interface “Ficha clínica”. ................................................. 17 
Figura 47 - Software Clivet interface “Consultas” (Documentos) ............................... 17 
Figura 48 - Software Clivet interface “Atestado de Saúde Animal” ............................ 17 
Figura 49 - Software Clivet interface “Controle de vacinações”................................. 17 
Figura 50 - Software Clivet interface “Pré-Vendas” ................................................... 17 
Figura 51 - Software Clivet interface “Caixa” ............................................................. 17 
Figura 52 - Software Clivet interface “Finanças” ....................................................... 17 
Figura 53 - Software Clivet interface “Finanças” (Contas a receber) ......................... 17 
Figura 54 - Software Clivet interface “Relatórios financeiros”.................................... 17 
Figura 55 - Software Clivet interface “Estoque”. ........................................................ 17 
Figura 56 - Software Clivet interface “Estoque” (Saídas) .......................................... 17 
Figura 57 - Software Clivet interface “Estoque” (Ajustes) .......................................... 17 
Figura 58 - Software Clivet interface “Relatórios estoque” ........................................ 17 
Figura 59 - Software Clivet interface “Gerencial”. ...................................................... 17 
Figura 60 - Software Clivet interface “Imprimir” ......................................................... 17 
Figura 61 - Software Clivet interface “Cadastros”. ..................................................... 17 
Figura 62 - Software Clivet interface “Ferramentas”. .................................................17 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
 
1 CONCEITOS DA ENGENHARIA DE SOFTWARE. PROCESSOS DE 
DESENVOLVIMENTO DE SOFTWARES CLÁSSICOS E ÁGEIS .............................. 6 
1.1 Modelo de prototipagem .................................................................................... 6 
1.1.1 Protipação evolucionária ......................................................................... ....7 
1.1.2 Protipação descartável ............................................................................ ....8 
1.2 Modelo espiral .................................................................................................... 9 
1.3 Cascata ............................................................................................................ 11 
1.3.1 Tabela de caractéristicas ................................... .......................................12 
1.3.2 Tabela de vantagens ............................................................................. ....13 
1.4 Scrum ............................................................................................................... 14 
2 REQUISITOS DE SOFTWARE. PROCESSOS DE ENGENHARIA DE 
REQUISITOS. ........................................................................................................... 16 
2.1 Objetivo ............................................................................................................ 16 
2.2 Âmbito .............................................................................................................. 16 
2.3 Referências ...................................................................................................... 16 
2.4Visão geral ........................................................................................................ 16 
3 ENTREVISTA ......................................................................................................... 17 
4 DOCUMENTO DE REQUISITOS ........................................................................... 19 
4.1 Passo 1 ............................................................................................................ 19 
4.2 Passo 2 ............................................................................................................ 22 
4.3 Passo 3 ............................................................................................................ 23 
4.4 Passo 4 ............................................................................................................ 24 
4.5 Passo 5 Glossário ............................................................................................ 25 
5 MODELAGEM DE OBJETOS. DIAGRAMAS DE CASOS DE USO. MODELAGEM 
DE OBJETOS E CLASSES.DIAGRAMAS DE CLASSES. MODELAGEM DE 
OPERAÇÕES. DIAGRAMA DE SEQUÊNCIA E DIAGRAMA DE ATIVIDADES. ...... 26 
5.1 Diagrama de classe ......................................................................................... 26 
5.1.1 Diagrama de classe no software Clivet ................................................. ....27 
5.2 Diagrama de casos de uso .............................................................................. 35 
5.2.1 Diagrama de casos de uso no software Clivet ...................................... ....36 
5.3 Diagrama de sequência ................................................................................... 41 
5.3.1 Diagrama de sequência no software Clivet ........................................... ....42 
5.4 Diagrama de atividade ..................................................................................... 47 
5.4.1 Diagrama de atividade no software Clivet ............................................. ....48 
5.5 Software Clivet descrição ................................................................................. 52 
5.6 Software Clivet interface gráfica....................................................................... 53 
REFERÊNCIAS ......................................................................................................... 64 
6 
 
 
1 CONCEITOS DA ENGENHARIA DE SOFTWARE. PROCESSOS DE 
DESENVOLVIMENTO DE SOFTWARES CLÁSSICOS E ÁGEIS 
 Primeiramente marcamos uma reunião com o nosso cujo é a clínica veterinária 
CLIVET, onde nelas discutimos a necessidade de toda a equipe da CLIVET que é 
composta por uma secretaria, uma assistente, um estagiário e um veterinário. 
 
 Assim sendo ficou definido que o método de nosso projeto será feito através do 
processo de desenvolvimento iterativo e incremental Scrum cujo o cliente pode 
acompanhar a evolução do projeto assim fortalecendo uma opinião sobre as 
funcionalidades imposta no produto. 
 
 Com isso nossa equipe desenvolve-se uma relação muito amigável e 
compreensível com o cliente, consequentemente constrói-se a confiança e o 
conhecimento cresce. 
 
 Mas antes será mostrado outros modelos de desenvolvimento de software para que 
fique claro os demais métodos. 
 
1.1 Modelo de Prototipagem 
 
Vantagem: 
1 - A característica principal desse modelo é gerar protótipos do sistema com 
definições de requisitos dadas pelo cliente. Essas definições geram documentos 
que, por sua vez resultam no protótipo. Esse protótipo é então testado pelo cliente 
para validar suas funcionalidades. 
 
2 - O modelo de prototipagem tem a grande vantagem de gerar resultados visíveis 
para o cliente de uma maneira veloz, e ao final de cada ciclo, onde novas 
funcionalidades são adicionadas, pode mostrar a evolução do sistema. 
 
3 - Melhorias na facilidade de uso dos sistemas (usabilidade) 
 
4 - Maior aproximação do sistema com as necessidades dos usuários (menor 
7 
 
 
resistência à implantação) 
 
5 - Melhorias da qualidade do projeto (menor custo de manutenção corretiva) 
 
6 - Melhorias na facilidade de manutenção (manutenibilidade) 
 
7 - Esforços de desenvolvimento reduzido (melhor definição dos requisitos) 
 
 1.1.1 - Prototipação evolucionária: 
 
Vantagens: 
 
 Rápido fornecimento do sistema: Em função do ritmo das mudanças nos negócios, 
em alguns casos é essencial que o sistema seja entregue rapidamente; em 
detrimento de detalhes de funcionalidade ou facilidade de manutenção em longo 
prazo. 
 
 Compromisso do usuário com o sistema: A participação dos usuários no processo 
de software não só garante uma maior aderência aos requisitos, mas também gera 
um compromisso tácito que facilita o processo de implantação. 
 
Problemas: 
 
 Gerenciamento: Necessidade de ferramentas de gerenciamento de versão. Abaixa 
documentação torna difícil a alocação de novos desenvolvedores 
 
 Manutenção: O alto grau de alterações pode corromper a estrutura do software. 
Contratuais: Difícil de fechar um contrato quando o cliente busca um preço fixo e os 
desenvolvedores não podem fornecê-lo em virtude da dinâmica do processo. 
 
 
 
 
8 
 
 
1.1.2 - Prototipação descartável: 
Vantagens: 
Melhor definição de requisitos: Na utilização de uma modelo cascata, por 
exemplo, existe a necessidade de se conhecer os requisitos já na fase de análise. 
Protótipos podem ser utilizados como ferramenta de apoio. 
Melhor definição de riscos no projeto: Protótipos podem ser utilizados como 
testes de conceito para validação do uso de determinadas tecnologias e, desse 
modo, prever risco sem sua utilização. 
Desvantagens: 
1 - Por se tratar de protótipos, nem sempre a solução escolhida para resolver 
tal problema é a ideal, pois não leva em consideração as variáveis de ambiente, 
como o sistema operacional onde o software funcionará ou se a linguagem de 
programação é adequada. 
2 - O desenvolvedor pode acabar se acostumando com a ideia de utilizar o 
protótipo que foigerado como parte integral do sistema, deixando “brechas” e 
possíveis erros. 
3 - Desempenho geral do sistema ruim quando códigos ineficientes passam 
do protótipo à versão final 
4 - Conscientização dos usuários em relação à finalidade do protótipo 
Problemas: 
Uso de protótipos como especificação de sistema: Embora possam ser 
utilizados com essa finalidade, geralmente trazem problemas como: exclusão de 
características importantes e má avaliação de requisitos não funcionais. Além de não 
ter apoio legal como um contrato. 
Pressão para entrega de protótipos descartáveis para uso: Fato que 
normalmente acontece, pode trazer diversos problemas como: não conformidade 
com requisitos não funcionais, falta de documentação adequada, estrutura 
danificada de software degradada e falta de padrões de qualidade. 
 
 
9 
 
 
1.2 - Modelo espiral 
Características 
Determinação dos objetivos, alternativas e restrições; 
Análise de risco e prototipação; 
Validação e verificação; 
Planejamento da fase seguinte. 
 Esta concepção tende a criar um roteiro de atividades e etapas para que se 
alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas 
complexos e obter, ao final, um produto em sua forma mais completa possível. 
 
 O modelo original em espiral organiza o desenvolvimento como um processo 
iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema 
final. Um ciclo se inicia com a determinação de objetivo, alternativas e restrições 
(primeira tarefa) onde ocorre o comprometimento dos envolvidos e o 
estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa, 
avaliação de alternativas, identificação e solução de riscos, executa-se uma análise 
de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for 
considerado inaceitável, pode parar o projeto. 
 
 Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se 
considerar o modelo cascata. Na quarta tarefa o produto é avaliado e se prepara 
para iniciar um novo ciclo. 
 
Vantagens 
1. Código modular e reutilizável 
2. Capacidade de adaptação à mudança 
3. Desenvolvimento mais rápido 
4. Custo de manutenção reduzido; 
10 
 
 
5. Modelo evolutivo possibilita uma maior integração entre as fases 
e facilita a depuração e a manutenção do sistema. 
6. Permite que o projetista e cliente possam entender e reagir aos 
riscos em cada etapa evolutiva.
7. Estimativas (por exemplo: cronogramas) tornam-se mais 
realísticas com o progresso do trabalho, porque problemas importantes 
são descobertos mais cedo. 
8. É mais versátil para lidar com mudanças (sempre inevitáveis) 
que desenvolvimento de software geralmente exige.
9. Permite que ao longo de cada iteração se obtenham versões do 
sistema cada vez mais completas, recorrendo à prototipagem para reduzir 
os riscos. 
 
Desvantagens 
 
1. Pode ser difícil convencer grandes clientes (particularmente em 
situações de contrato) de que a abordagem evolutiva é controlável. 
 
2. A abordagem deste tipo de modelo exige considerável 
experiência na avaliação dos riscos e fia-se nessa experiência para o 
sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas. 
3. Este tipo de modelo é relativamente novo e não tem sido 
amplamente usado. 
4. É importante ter em conta que podem existir diferenças entre o 
protótipo e o sistema final. O protótipo pode não cumprir os requisitos de 
desempenho, pode ser incompleto, e pode refletir somente algumas facetas 
do sistema a desenvolver. 
5. O modelo em espiral, por suas características de avaliação e 
planejamento baseadas em risco, exige que se tenham gerentes e técnicos 
experientes. 
11 
 
 
6. As tarefas gerenciais para acompanhamento e controle do 
projeto tornam-se mais difíceis, uma vez que o modelo em espiral pode levar 
ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma 
sendo abordada de modo diferenciado. É necessário o uso de técnicas 
específicas para estimar e sincronizar cronogramas, bem como para 
determinar os indicadores de custo e progresso mais adequados. 
 
1.3 – Cascata 
 Entre os modelos de engenharia de software o modelo de cascata – 
também chamado de modelo sequencial linear e ciclo de vida clássico – 
continua sendo um modelo bastante utilizado para a engenharia de software, 
apesar de ser relativamente antigo. Basicamente um modelo de 
desenvolvimento em cascata resume-se em um modelo sequencial de 
desenvolvimento, com fases bem definidas, sendo comum as fases de: 
análise, projeto, codificação, teste e manutenção. 
Modelo Cascata - Vantagens 
 
1. Fases bem definidas. 
2. Maior foco no planejamento. 
3. A fase seguinte só se inicia – geralmente - caso o cliente aceite os artefatos 
produzidos na fase anterior. 
Modelo cascata -Desvantagens 
 
1. O modelo cascata exige que o cliente estabeleça todos os requisitos no 
início do projeto. 
2. O cliente irá visualizar alguma coisa apenas perto do fim do projeto. 
3. Um esforço considerável na fase de teste do projeto e ocorrências de 
alguns “estados de bloqueio”, nos quais alguns membros de equipe do projeto 
precisam esperar que outros membros terminem as tarefas dependentes para 
que o projeto prossiga. 
12 
 
 
 
1.3.1 – Tabela de características 
Características Cascata Espiral Prototição Scrum 
 - Facilidade em entender planejamento P NP P P 
 - Facilidade de alterações durante o processo NP P PP P 
 - Fácil Planejamento P PP P P 
 - Boa Intimidade do Cliente com o processo PP P P P 
 - Facilidade de Manutenção NP NP P P 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
13 
 
 
1.3.2 – Tabela de vantagens 
Metodologias Vantagens Desvantagens 
Cascata 
Simplicidade; 
Mínimo tempo de planejamento; 
Funciona bem para pequenas 
aplicações; 
Inflexível; 
Apenas no fim da Integração se entrega 
algo. (Longo tempo até entregar); 
Difícil de dar manutenção em erros de 
etapas passadas; 
Espiral 
Código modular e reutilizável; 
Capacidade de adaptação à 
mudança; 
Modelo evolutivo possibilita uma 
maior integração entre as fases e 
facilita a depuração e a 
manutenção do sistema; 
Permite que o projetista e cliente 
possam entender e reagir aos 
riscos em cada etapa evolutiva; 
Estimativas (por exemplo: 
cronogramas) tornam-se mais 
realísticas com o progresso do 
trabalho, porque problemas 
importantes são descobertos 
mais cedo; 
A abordagem deste tipo de modelo exige 
considerável experiência na avaliação 
dos riscos e fia-se nessa experiência para 
o sucesso. Se um grande risco não for 
descoberto, poderão ocorrer problemas; 
Este tipo de modelo é relativamente novo 
e não tem sido amplamente usado; 
O modelo em espiral, por suas 
características de avaliação e 
planejamento baseadas em risco, exige 
que se tenham gerentes e técnicos 
experientes; 
Prototipação 
Cliente ciente dos processos do 
software; 
Fácil de levantar custos; 
Fácil de dar feedback de 
estimativa de tempo; 
A diferença pode confundir o cliente que 
espera já ter o Produto pronto ao final da 
fase de prototipação; 
A utilização de técnicas ineficientes ou 
impróprias num Protótipo rápido podem 
permanecer ocultas numa versão final; 
 
Scrum 
Motivação - Os programadores se 
sentem muito mais motivados 
devido ao seu interesse de 
entregar o Sprint no prazo; O 
projeto pode ser visualizado - 
Dentro da organização o projeto 
pode ser observado por todos. 
Em outrasmetodologias esta 
possibilidade não existia; 
Ausência significante de - Como 
a qualidade é mais importante do 
que o prazo de entrega, o produto 
apresenta uma diminuição 
significativa de erros (bug) 
 
Prazo - Como a qualidade é mais 
importante do que o resultado, pode ser 
que os prazos não sejam estipulados de 
forma coerente, levando a um atraso do 
resultado final, o que pode deixar os 
clientes com uma certa raiva, mas isso 
pode ser ajustado em equipe; Desordem 
nas funções - a presença de papéis 
indefinidos nas funções presentes no 
projeto podem dar alguns problemas 
relacionados a comunicação interna e 
deixar os programadores confusos 
quanto as suas tarefas. 
 
 
 
 
14 
 
 
1.4 – Scrum 
 No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de 
Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades 
deve ser executado. Metodologias ágeis de desenvolvimento de software são 
iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints 
no caso do Scrum. 
 As funcionalidades a serem implementadas em um projeto são mantidas em uma 
lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um 
Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product 
Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que 
ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em 
um Sprint são transferidas do Product Backlog para o Sprint Backlog. 
 A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de 
manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que 
foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se 
inicia. 
 Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em 
uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe 
parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a 
ilustração abaixo: 
 
 
15 
 
 
 
 
 
 Para o desenvolvimento do sistema requerido pelo cliente que neste caso é a 
Clínica veterinária CLIVET será utilizado a metodologia de desenvolvimento ágil 
Scrum que melhor se encaixa no aspecto de iteração com o nosso cliente e que foi 
descrita anteriormente. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 
 
 
 
 
2 REQUISITOS DE SOFTWARE. PROCESSOS DE ENGENHARIA DE 
REQUISITOS. 
2.1 Objetivo 
Esse documento tem por objetivo a documentação dos requisitos funcionais, 
as ações que o sistema proporciona, e não-funcionais, ou seja as propriedades 
emergentes do sistema, do sistema proposto, para que possa ter clareza, definição e 
aprovação do cliente em relação ao produto a ser implementado. 
2.2 Âmbito 
O projeto Clivet System é um sistema para o controle de cadastro dos animais 
tratados na clínica CLIVET, o software tem o controle de estoque de medicamentos, 
agendamento de consultas personalizado, ficha clínica do animal, controle de 
vacinações, simulação de venda ou seja pré-venda, possibilita a venda de produtos 
através da opção caixa que faz a nota fiscal do respectivo produto ao cliente e gera 
um relatório financeiro diário e mensal cujo mostra o lucro da clínica veterinária. 
 A implementação será em 2 máquinas, uma vai ter localizado o banco de 
dados da aplicação e também suportará a interface do sistema, a da sala de 
consultas e a máquina da recepção que terá mais uso do sistema só terá instalado a 
interface e fará ligação com a outra máquina por rede para acessar a base de dados 
e para maior segurança o Banco de dados terá uma cópia de segurança e com a 
possibilidade usar o banco de dados na “nuvem” ou seja na rede. 
2.3 Referências 
Modelo de Documentação 
http://paginas.fe.up.pt/~jpf/teach/ERS0708/TemplateRequisitos.doc 
Definição de conceitos e geral 
SOMMERVILLE, Engenharia de Software, 6ª Edição 
2.4 Visão geral 
A documentação dos requisitos trata o detalhamento dos requisitos do 
sistema, para isso utilizamos o modelo de diagramação de casos de uso, 
17 
 
 
diagramação de atividades, diagramação de classes e diagramação de sequência 
que identifica as ações e usuários que o sistema abrange, esse modo simplificado 
ajuda, pelo lado da CLIVET a entender se o sistema oferece a solução desejada, 
pelo lado dos desenvolvedores a terem uma base de sólida de onde começar. 
Para suprir melhor os desenvolvedores tanto na execução inicial, mas 
também para posteriores manutenções, o documento possui uma seção de 
requisitos, separados por funcionais e não-funcionais, em cada uma delas também 
se usa modelos de caso de uso, porém de maior nível de detalhamento. 
No momento de implementação essa documentação também será útil no 
processo de treino de usuários, pois possui seção de perfil de usuário, onde define 
as interfaces, permissões e restrições do acesso e sistema. 
 
3. Entrevista 
O que você pretende controlar com o Sistema? 
Como hoje controlo meus clientes através de uma pasta tenho tudo 
documentado e guardo em fichários e arquivos, com a implementação do sistema 
pretendo ter controle de todos os clientes e de seus animais, assim como tenho hoje, 
os históricos das vacinas tomadas , das consultas realizadas, exames enfim todos 
os históricos do animal, além deste controle gostaria de controlar os estoques dos 
medicamentos e vacinas nós temos que no geral controlar a clínica, se eu pudesse 
iria até mais longe porque, como eu trabalho em uma cidade pequena, então os 
pagamentos são feitos aqui no escritório o cliente vem aqui eu atendo as vezes tem 
que marcar a consulta ou o retorno então eu deixo ele pagar tudo junto no final , 
então tenho que esperar ele me ligar de novo para eu poder cobrar ele então queria 
ter uma maneira de estar controlando isto também. 
Gostaria de saber qual de que forma você deseja marcar as consultas? 
Então hoje em dia o procedimento é assim, o cliente me liga mais se for só 
para marcar consulta ele nem fala comigo as vezes, fala direto com a secretária e aí 
ela olha na agenda, olha a data que tem livre e marca o horário, então ela pega as 
fichas de todos os horários marcados naquele dia e leva pra mim, então gostaria 
que no sistema fosse de uma forma parecida, ela poderia marcar no sistema os 
horários das consultas agendando conforme os clientes vão ligando ou marcam o 
18 
 
 
retorno, com o nome do cliente e do animal e no dia eu tenha todo o histórico do 
animal, ordenados pelo horários das consultas. 
Como seria a melhor forma de estar controlando o seu estoque de 
medicamentos? 
Eu sou muito rigoroso com isso, não posso deixar de falta nenhum 
medicamento ou vacina, normalmente quando tenho cinco produtos do 
medicamento, sempre peço para meu fornecedor que demora por volta de uns dez 
dias para estar me entregando, então gostaria de que no meu sistema ele avise 
quando os medicamentos estão acabando e também tivesse as datas de cada 
medicamento vai vencer para mim estar aproveitando todas os medicamentos e 
vacinas. 
Como que você quer o funcionamento das vendas? 
Neste aspecto, como eu quero que seja implementado um campo 
especialmente para que eu possa realizar a venda de meus produtos e inserir o 
atendimento feito para o meu cliente, a melhor opção seria gerar uma nota fiscal de 
tudo que ele adquiriu da minha clínica. 
Como serão realizados os cadastros dos seus clientes? 
Bom, como normalmente cada cliente tem um ou mais animais eu gostaria de 
relacionar cada animal ao seu dono no cadastro, terei, os dadosdo cliente como, 
Nome, telefones para contato, endereço para caso tenha que atender em domicilio 
em caso de urgência , e com os seus respectivos animais relacionados em seu 
cadastro , onde eu possa puxar todas as informações do cliente e dos animais dele, 
então teria os dois cadastros, o do cliente com seus dados pessoais e o cadastro 
dos animais com nome dele, o nome do proprietário, peso, data de nascimento, 
sexo, espécie, raça, porte e pelagem. 
Como funciona a forma de pagamento do serviço? 
No momento eu trabalho apenas com recebimento de dinheiro e cheque, 
como tenho que cobrar os medicamentos e vacinas eu marco nas fichas e deixo 
para o cliente pagar tudo no final, com isso tenho alguns problemas para estar 
cobrando o meu cliente, seria uma boa maneira do sistema estar me indicando caso 
o meu cliente esteja devendo o sistema me informa o valor e assim eu poderei estar 
cobrando dele quando ele for marcar consulta ou retorno, em caso de clientes que 
19 
 
 
tem vários animais eu lanço no sistema as informações dos medicamento ou 
vacinas que utilizei nos animais , e faço uma soma de tudo para estar passando para 
o cliente. 
 
4. DOCUMENTO DE REQUISITOS 
4.1 – Passo 1 
Descrição dos Requisitos Funcionais 
Área do Animal (Cadastro, Consulta, Internação/Hospedagem, Ficha médica) 
 Cadastro do Animal 
O sistema deve fornecer uma interface gráfica que permite incluir, alterar, excluir, 
procurar por índices, os dados de cadastrais citados abaixo. 
1. Dados Cadastrais do Animal de Estimação 
a. Nome 
b. Proprietário (já previamente cadastrado). 
c. Raça 
d. Peso 
e. Data de Nascimento 
f. Sexo 
g. Porte 
h. Pelagem 
 
 Cadastro do Proprietário 
O sistema deve permitir incluir, alterar, excluir, procurar por índices, os dados de 
cadastrais citados abaixo. 
a. CPF 
b. Nome 
c. Endereço 
d. Cidade 
e. Estado 
f. CEP 
g. Telefone Residencial 
h. Celular 
20 
 
 
i. Telefone Comercial 
 Agendamento da Consulta 
O sistema deve fornecer interface gráfica que permite o usuário A, a 
secretária, controlar horários de consultas e visitas. Nessa tela deve se definir: 
Para Consultas 
a. Data e hora da consulta 
b. Animal (já cadastrado, se não houver cadastro, realizar cadastro do 
proprietário, depois do animal) 
c. Especial ou não (visitas). 
Para Visitas 
a. Data da Consulta 
b. Proprietário (já cadastrado, se não houver cadastro, realizar) 
 
 
 Tratamento 
 O sistema deve reter histórico de consultas como fichas médicas, então no 
momento da consulta, o usuário B, o veterinário, utilizará o sistema para cadastrar 
as informações citadas abaixo, ou anotará e após término da consulta se realiza o 
cadastro. 
a. Animal; 
b. Tipo de Entrada (consulta, exame, aplicação de vacina, Hospedagem, 
outros procedimentos); 
c. Data de entrada; 
d. Observação; 
 
 
 Internação e Hospedagem 
 O sistema deve possibilitar o usuário A ou B, controlar uso e liberação de 
vagas para internação e hospedagem, fornecendo seguintes dados. 
21 
 
 
a. Local de Ocupação 
b. Animal 
c. Data de entrada 
d. Data de saída 
e. Observações/Tratamentos 
 
 Medicamentos 
O sistema deve permitir incluir, alterar, excluir, procurar por índices, os dados de 
cadastrais citados abaixo. 
a. Nome do medicamento 
b. Laboratório 
c. Data de validade 
d. Quantidade 
e. Valor 
 
 Fornecedores 
O sistema deve permitir incluir, alterar, excluir, procurar por índices, os dados de 
cadastrais citados abaixo. 
a. CNPJ; 
b. Nome Fantasia; 
c. Endereço; 
d. Cidade; 
e. Estado; 
f. CEP; 
g. Telefone; 
 
 Pedido de compra de medicamento 
O sistema deve permitir adicionar pedidos pendentes de medicamentos, 
utilizando os dados citados abaixo. 
22 
 
 
Pedido 
a. Fornecedor 
b. Data do Pedido 
c. Estimada de Entrega 
d. Data de Entrega 
Itens do pedido 
a. Pedido (número) 
b. Nome do medicamento 
c. Valor do produto unitário 
d. Quantidade 
 
4.2 - Passo 2 
Requisitos Não-funcionais 
1. Manutenibilidade – O código é aberto e plataformas que rodam eles são de 
fáceis acesso, a maneira que vai ser programado também é do padrão da empresa 
onde visa a manutenibilidade do código tão importante quanto sua funcionalidade. 
2. Eficiência – Após entregas parciais do protótipo do sistema, ele vai se 
adequando à necessidade de alterações nos requisitos do cliente. 
3. Segurança – O acesso ao banco de dados é restrito somente às máquinas 
de dentro da clínica. 
4. Confiabilidade – O servidor de banco de dados que estamos usando é um 
dos mais confiáveis, a plataforma que o sistema roda também é confiável devido sua 
presença marcante no mercado. Será programado um backup de dados para ser 
feito todos os dias, assim será garantido que os dados da empresa não serão 
perdidos. 
5. Portabilidade – Tanto o sistema de gerenciamento de banco de dados 
quanto a plataforma de execução do sistema são multi-plataformas, ou seja, eles 
rodam em vários sistemas operacionais, se o cliente quiser mudar para um ambiente 
Unix / Linux ou Mac, ele não terá dificuldades. 
23 
 
 
 
4.3 - Passo 3 
Prioridades Requisitos Funcionais 
Cód Nome Prioridade Área Prioridade 
1 Cadastrar Animal Essencial Animal Alta 
2 Cadastrar Proprietário Essencial Animal Alta 
3 Agendar Consulta Essencial Animal Alta 
4 
Agendar Visita (Consulta Especial, Pacote de 
Consultas) 
Essencial Animal Alta 
5 Buscar Histórico de Consultas Essencial Animal Alta 
6 Cadastrar Internação / Hospedagem Essencial Animal Média 
7 Liberar Espaço de Internação / Hospedagem Essencial Animal Média 
8 Cadastro de Medicamentos Essencial Estoque Alta 
9 Cadastro de Fornecedores Essencial Estoque Alta 
10 Registrar compra de medicamento Essencial Estoque Média 
11 Registrar utilização de medicamento Essencial Estoque Média 
12 
Aviso: medicamento acabando ou fora da data de 
validade. 
Essencial Estoque Média 
13 ‘Caixa’ onde será inserida as vendas Essencial Venda Alta 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
24 
 
 
Descrição geral do produto 
Funções do produto 
 
 
 Caso de uso Descrição 
1 Controlar cadastramento de 
animais 
Inserção e Alteração às informações sobre todos os 
animais que são tratados na clínica. 
2 Controlar cadastramento de 
proprietários 
Inserção e Alteração às informações sobre todos o 
proprietários que visitam a clínica 
3 Controlar tratamentos Cadastro de Tratamento, histórico de tratamentos que o 
animal já recebeu, interligada ao cadastro de animais. 
4 Controle de agendamento Cadastro de consultas e visitas, nas quais cada consulta 
está relacionada à um animal e visitas são um pacote de 
consultas 
5 Controlar Internações Entrada e saída de animais internados, interligado com 
os tratamentos de cada animal. 
6 Controlar estoque Controlar tudo o que entra e sai do estoque. 
7 Controlar caixa Controlar o pagamento de consultas, ligadas aos 
proprietários dos animais, quando um animal do 
proprietário tiver consulta, verificar pagamentos em 
aberto. 
 
 
4.4 - PASSO 4 
Descrições 
Usuário Ações 
Veterinário Responsável por administrar os animais e proprietários, 
medicamentos. 
Secretária Trata dos cadastros dos animais e proprietários. Controla os 
pedidos de compras, vencimento e armazenamento de 
medicamentos. 
 
 
 
 
 
 
 
 
 
 
25 
 
 
4.5 – Passo 5 Glossário 
 
Termo Descrição 
Interface gráfica A interface do gráfica ou interface de usuário é o 
conjunto de características com o qual os usuáriosinteragem com os aplicativos e a máquina 
dispositivos, programas ou alguma outra ferramenta , 
a grosso modo ela é a visão que o usuário tem do 
que está sendo mostrado na tela do computador. 
Base de dados Conjunto de vários banco de dados, que fornecem 
dados para um conjunto de aplicações. 
Multi-plataformas Diz-se multiplataforma um programa ou sistema que 
roda em mais de uma plataforma, por exemplo: O 
programa roda nos sistemas operacionais do Linux e 
da Microsoft. 
Protótipo Parte funcional da aplicação para entrega, demonstra 
idéia de como o sistema ficará após entrega mas não 
é o sistema completo. 
Backup É uma cópia de segurança, é a cópia de dados de 
um dispositivo de armazenamento ou de um sistema 
para que possam ser restaurados em caso da perda 
dos dados originais. 
Sistema Conjunto de aplicações que unidas, suprem os 
requisitos que estão descritas nesse documento. 
Requisito O conceito de requisito na informática referr-se à 
definição de uma característica, atributo, habilidade 
ou qualidade que um sistema (ou qualquer um de 
seus módulos e subrotinas) deve necessariamente 
prover para ser útil a seus usuários. 
Implementação Processo de treinamento e instalação do sistema no 
cliente. 
Banco de dados Banco de dados, é um conjunto de registros 
dispostos em estrutura regular que possibilita a 
reorganização dos mesmos e produção de 
informação. Um banco de dados normalmente 
agrupa registros utilizáveis para um mesmo fim. 
Máquina Computador onde o usuário do sistema trabalhará. 
Diagrama de casos de uso descreve a funcionalidade proposta para um novo 
sistema, que será projetado. 
Execução Inicial Parte da Implementação, introdução do sistema para 
o usuário. 
Restrições de acesso No caso do sistema a restrições de acesso, restringe 
o acesso de cada usuário personalizando os níveis 
de usuário para poder alterar, editar ou excluir 
alguma informação armazenada no sistema 
Índice de dados Ordem em que os dados estão dispostos, crescente, 
decrescente. 
Manutenibilidade É um aspecto da qualidade de software que se refere 
à facilidade de um software de ser modificado a fim 
de corrigir defeitos, adequar-se a novos requisitos, 
26 
 
 
aumentar a suportabilidade ou se adequar a um 
ambiente novo. 
 
 
5. MODELAGEM DE OBJETOS. DIAGRAMAS DE CASOS DE USO. 
MODELAGEM DE OBJETOS E CLASSES.DIAGRAMAS DE CLASSES. 
MODELAGEM DE OPERAÇÕES. DIAGRAMA DE SEQUÊNCIA E DIAGRAMA DE 
ATIVIDADES 
 
 Nesta etapa iremos descrever o funcionamento do software utilizando os 
diagramas para facilitar a visualização de interação do software com o seu usuário e 
a sua descrição em si com todos os aspectos relacionais concebidos no software. 
 
 Também será mostrada a interface gráfica do software da Clivet com todos os 
seus aspectos devidamente incrementados. 
 
5.1 – Diagrama de classe 
 
 Em programação, um diagrama de classes é uma representação da estrutura e 
relações das classes que servem de modelo para objetos. 
 
 É uma modelagem muito útil para o desenvolvimento de sistemas, pois define 
todas as classes que o sistema necessita possuir e é a base para a construção dos 
diagramas de comunicação, sequência e estados. 
 
 
 
 
 
 
 
 
 
 
 
 
27 
 
 
5.1.1 – Diagrama de classe no software Clivet 
 
Figura 1 – Diagrama de classe funcionalidades do sistema. 
Fonte: Autoria Própria 
 
Figura 2 – Diagrama de classe cadastro e serviços. 
28 
 
 
Fonte: Autoria Própria 
 
Figura 3 – Diagrama de classe agenda. 
Fonte: Autoria Própria 
 
 
Figura 4 – Diagrama de classe consultas. 
29 
 
 
Fonte: Autoria Própria 
 
Figura 5 – Diagrama de classe funcionamento do caixa. 
Fonte: Autoria Própria 
 
 
Figura 6 – Diagrama de classe finanças. 
Fonte: Autoria Própria 
30 
 
 
 
Figura 7 – Diagrama de classe estoque. 
Fonte: Autoria Própria 
 
 
 
 
31 
 
 
 
Figura 8 – Diagrama de classe cadastro parte 1. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
32 
 
 
 
Figura 9 – Diagrama de classe cadastro parte 2. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
 
 
33 
 
 
 
Figura 10 – Diagrama de classe cadastro parte 3. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
 
 
 
 
 
34 
 
 
 
Figura 11 – Diagrama de classe cadastro parte 4. 
Fonte: Autoria Própria 
 
 
35 
 
 
 
Figura 12 – Diagrama de classe ferramentas. 
Fonte: Autoria Própria 
 
 
5.2 – Diagrama de casos de uso 
 
 O diagrama de caso de uso descreve a funcionalidade proposta para um novo 
sistema que será projetado e uma excelente ferramenta para o levantamento dos 
requisitos funcionais do sistema. Segundo Ivar Jacobson, podemos dizer que um 
caso de uso é um "documento narrativo que descreve a sequência de eventos de 
um ator que usa um sistema para completar um processo". Um caso de uso 
representa uma unidade discreta da interação entre um usuário (humano ou 
máquina) e o sistema. Um caso de uso é uma unidade de um trabalho significante. 
Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são 
todos casos de uso. Cada caso de uso tem uma descrição da funcionalidade que 
será construída no sistema proposto. Um caso de uso pode "usar" outra 
funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio 
comportamento. 
 
 Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou 
entidade máquina que interage com o sistema para executar um significante 
trabalho. 
36 
 
 
5.2.1 – Diagrama de casos de uso no software Clivet 
 
Figura 13 – Diagrama de casos de uso usuário. 
Fonte: Autoria Própria 
 
Figura 14 – Diagrama de casos de uso agenda. 
Fonte: Autoria Própria 
 
37 
 
 
 
Figura 15 – Diagrama de casos de uso consultas. 
Fonte: Autoria Própria 
 
 
Figura 16 – Diagrama de classes pré-venda. 
Fonte: Autoria Própria 
 
 
38 
 
 
 
Figura 17 – Diagrama de casos de uso caixa. 
Fonte: Autoria Própria 
 
 
Figura 18 – Diagrama de casos de uso finanças. 
Fonte: Autoria Própria 
39 
 
 
 
Figura 19 – Diagrama de casos de uso estoque. 
Fonte: Autoria Própria 
 
 
 
Figura 20 – Diagrama de casos de uso gerencial. 
Fonte: Autoria Própria 
40 
 
 
 
Figura 21 – Diagrama de casos de uso cadastro. 
Fonte: Autoria Própria 
 
 
 
Figura 22 – Diagrama de casos de uso ferramentas. 
Fonte: Autoria Própria 
41 
 
 
5.3 – Diagrama de sequência 
 
 Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um 
diagrama usado em UML (Unified Modeling Language), representando a sequência 
de processos (mais especificamente, de mensagens passadas entre objetos) num 
programa de computador. Como um projeto pode ter uma grande quantidade de 
métodos em classes diferentes, pode ser difícil determinar a sequência global do 
comportamento. O diagrama de sequência representa essa informação de uma 
forma simples e lógica. 
 
 Um diagrama de sequência descreve a maneira como os grupos de objectos 
colaboram em algum comportamento ao longo do tempo. Ele registra o 
comportamento de um único caso de uso e exibe os objectos e as mensagens 
passadas entre esses objectos no caso de uso. 
 
 Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para 
representar interações entre objetos de um cenário, realizadas através de operações 
ou métodos (procedimentos ou funções). Este diagrama é construído a partir do 
Diagrama de Casos de Usos. Primeiro, define-se qual o papel do sistema (Use 
Cases), depois, é definido como o software realizará seu papel(Sequência de 
operações). 
 
 O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens 
são trocadas entre os objetos de um sistema. Entende-se por mensagens os 
serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as 
solicitações. 
 
 
 
 
 
 
 
 
 
 
 
 
 
42 
 
 
5.3.1 – Diagrama de sequência no software Clivet 
 
Figura 23 – Diagrama de sequência módulo do cliente. 
Fonte: Autoria Própria 
 
 
 
 
Figura 24 – Diagrama de sequência agenda. 
Fonte: Autoria Própria 
 
 
 
43 
 
 
 
Figura 25 – Diagrama de sequência consultas. 
Fonte: Autoria Própria 
 
 
Figura 26 – Diagrama de sequência pré-venda. 
Fonte: Autoria Própria 
 
 
 
 
44 
 
 
 
Figura 27 – Diagrama de sequência finanças. 
Fonte: Autoria Própria 
 
 
 
Figura 28 – Diagrama de sequência estoque. 
Fonte: Autoria Própria 
 
 
 
 
 
45 
 
 
 
Figura 29 – Diagrama de sequência gerência (cadastro) 1. 
Fonte: Autoria Própria 
 
 
 
 
Figura 30 – Diagrama de sequência gerência (cadastro) 2. 
Fonte: Autoria Própria 
 
 
 
 
 
 
46 
 
 
 
 
Figura 31 – Diagrama de sequência gerência (cadastro) 3. 
Fonte: Autoria Própria 
 
 
 
Figura 32 – Diagrama de sequência ferramentas. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
 
 
 
47 
 
 
5.4 – Diagrama de atividade 
 
 
 Um diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o fluxo 
de controle de uma atividade para outra e serão empregados para fazer a 
modelagem de aspectos dinâmicos do sistema. Na maior parte, isso envolve a 
modelagem das etapas sequenciais em um processo computacional; Enquanto os 
diagramas de interação dão ênfase ao fluxo de controle de um objeto para outro, os 
diagramas de atividades dão ênfase ao fluxo de controle de uma atividade para 
outra; Uma atividade é uma execução não atômica em andamento em uma máquina 
de estados e acabam resultando em alguma ação, formada pelas computações 
atômicas executáveis que resultam em uma mudança de estado do sistema ou o 
retorno de um valor. 
 
 O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem 
Unificada (UML), e representa os fluxos conduzidos por processamentos. É 
essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade 
para outra. Comumente isso envolve a modelagem das etapas sequenciais em um 
processo computacional. 
 
 Os diagramas de atividade não são importantes somente para a modelagem de 
aspectos dinâmicos de um sistema ou um fluxograma, mas também para a 
construção de sistemas executáveis por meio de engenharia de produção reversa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
48 
 
 
5.4.1 – Diagrama de atividade no software Clivet 
 
 
 
Figura 33 – Diagrama de atividade cadastro. 
Fonte: Autoria Própria 
 
 
 
Figura 34 – Diagrama de atividade agenda. 
Fonte: Autoria Própria 
 
49 
 
 
 
Figura 35 – Diagrama de atividade consulta. 
Fonte: Autoria Própria 
 
 
 
Figura 36 – Diagrama de atividade pré-venda e venda (caixa). 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
50 
 
 
 
Figura 37 – Diagrama de atividade finanças. 
Fonte: Autoria Própria 
 
 
 
Figura 38 – Diagrama de atividade estoque. 
Fonte: Autoria Própria 
 
 
 
 
51 
 
 
 
Figura 39 – Diagrama de atividade gerencial (cadastro). 
Fonte: Autoria Própria 
 
 
 
Figura 40 – Diagrama de atividade ferramentas. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
 
 
 
52 
 
 
5.5 – Software Clivet descrição 
 
 Depois de todos os passos feitos até aqui é chegada a hora de mostrar a interface 
gráfica do software produzido com todos os respectivos requisitos do nosso cliente 
que é a clínica veterinária Clivet. 
 
 No software primeiramente é inserida por cada usuário que irá usar o sistema o 
nome de usuário e sua senha sendo que cada um dos usuários tem permissões 
distintas os usuários que irão utilizar o sistema são os seguintes o veterinário, a 
secretaria, assistente e o estagiário. 
 
 Depois disso o software é aberto para cada usuário sendo que alguns tem funções 
limitadas no software devido aos requisitos descritos anteriormente, mas o software 
em si é composto primeiramente pela a opção “Agendamentos” que é o campo onde 
será agendado a consulta para o animal; depois terá a opção “Consultas” que é 
onde terá as opções de colocar as fichas clinicas dos animais atendidos, os 
documentos e o controle de vacinação; após isso tem a opção “Pré-venda” que faz a 
simulação da venda para o cliente e se ele concluir essa conclusão será feita na 
opção “Caixa” onde será feita a venda sendo que a opção caixa entrada e saídas 
dos produtos junto com outras funções que não se tem real necessidade de 
descrever neste tópico. 
 
 As outras opções do software são as seguintes a opção “Finanças” que faz o 
controle financeiro da clínica; a opção “Estoque” faz o controle de estoque dos 
produtos que entram e que saiam da clínica; a opção de “Gerencial” que faz os 
gráficos de lucratividade da clínica; a opção “Cadastros” que faz o cadastro de tudo 
em geral ou seja de clientes, animais, fornecedores, funcionários e tudo mais. Por 
fim tem a opção ferramentas que faz o envio de SMS e manipula o Banco de Dados 
software que pode ser utilizado até em rede. Todos os aspectos do software foram 
descritos agora no próximo tópico será colocado as imagens de todas as opções. 
 
 
 
 
 
 
 
 
53 
 
 
5.6 – Software Clivet interface gráfica 
 
 
 
 
Figura 41 – Software Clivet interface “Acesso ao sistema”. 
Fonte: Autoria Própria 
 
 
 
 
 
Figura 42 – Software Clivet interface “Agendamentos”. 
Fonte: Autoria Própria 
 
 
 
 
54 
 
 
 
 
Figura 43 – Software Clivet interface “Agendamento completo”. 
Fonte: Autoria Própria 
 
 
 
 
Figura 44 – Software Clivet interface “Agendamento simplificado”. 
Fonte: Autoria Própria 
 
 
 
 
55 
 
 
 
 
 
Figura 45 – Software Clivet interface “Consultas”. 
Fonte: Autoria Própria 
 
 
 
 
Figura 46 – Software Clivet interface “Ficha clínica”. 
Fonte: Autoria Própria 
 
 
 
 
 
56 
 
 
 
 
Figura 47 – Software Clivet interface “Consultas” (Documentos). 
Fonte: Autoria Própria 
 
 
 
 
Figura 48 – Software Clivet interface “Atestado de Saúde Animal”. 
Fonte: Autoria Própria 
 
 
 
 
 
57 
 
 
 
 
Figura 49 – Software Clivet interface “Controle de vacinações”. 
Fonte: Autoria Própria 
 
 
 
 
 
Figura 50 – Software Clivet interface “Pré-Vendas”. 
Fonte: Autoria Própria 
 
 
 
 
 
58 
 
 
 
 
 
Figura 51 – Software Clivet interface “Caixa”. 
Fonte: Autoria Própria 
 
 
 
 
 
Figura 52 – Software Clivet interface “Finanças”. 
Fonte: Autoria Própria 
 
 
 
 
 
59 
 
 
 
 
Figura 53 – Software Clivet interface “Finanças” (Contas a receber). 
Fonte: Autoria Própria 
 
 
 
 
Figura 54 – Software Clivet interface “Relatórios financeiros”. 
Fonte: Autoria Própria 
 
 
 
 
 
 
60 
 
 
 
 
Figura 55 – Software Clivet interface “Estoque”. 
Fonte: Autoria Própria 
 
 
 
 
Figura 56 – Software Clivet interface “Estoque” (Saídas). 
Fonte: Autoria Própria 
 
 
 
 
 
 
61 
 
 
 
 
 
Figura 57 – Software Clivet interface “Estoque” (Ajustes). 
Fonte: Autoria Própria 
 
 
 
 
 
Figura 58 – Software Clivet interface “Relatórios estoque”. 
Fonte: Autoria Própria 
 
 
 
 
62 
 
 
 
Figura 59 – Software Clivet interface “Gerencial”.Fonte: Autoria Própria 
 
 
 
 
Figura 60 – Software Clivet interface “Imprimir”. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
63 
 
 
 
 
 
 
 
Figura 61 – Software Clivet interface “Cadastros”. 
Fonte: Autoria Própria 
 
 
 
Figura 62 – Software Clivet interface “Ferramentas”. 
Fonte: Autoria Própria 
 
 
 
 
 
 
 
64 
 
 
REFERÊNCIAS 
Livro Texto. SOMMERVILLE, Ian. Engenharia de Software. 9ª ed. São Paulo: 
Elsevier, 2013. 
 
Modelos. Disponível em: 
< http://brainstormdeti.wordpress.com/2010/05/25/uma-comparacao-entremodelo-
agil-e-cascata/> Acesso em: 4 Abril. 2014 
 
 
Engenharia de Software. Disponível em: 
 http://www.ic.unicamp.br/~ariadne/mc436/1s2013/modulo1-v.pdf> Acesso em: 4 
Abril. 2014 
 
 
Metodologias Ágeis. Disponível em: 
 < http://www.brq.com/metodologias-ageis/> Acesso em: 4 de Abril. 2014 
 
 
Engenharia de software. Disponível em: 
< http://pt.wikipedia.org/wiki/Engenharia_de_software> acesso em 4 de abril de 2014 
 
Modelos de ciclo de vida. Disponível em: 
<http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida> acesso em 4 de abril de 2014 
 
Processos de desenvolvimento de software. Disponível em: 
< http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula02.pdf> 
acesso em 4 de abril de 2014 
 
Diagrama de classes. Disponível em: 
< http://pt.wikipedia.org/wiki/Diagrama_de_classes> acesso em 25 de maio de 2014 
 
Diagrama de casos de uso. Disponível em: 
< http://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso> acesso em 25 de maio de 
2014 
 
Diagrama de sequência. Disponível em: 
< http://pt.wikipedia.org/wiki/Diagrama_de_sequência> acesso em 25 de maio de 
2014 
 
Diagrama de atividade. Disponível em: 
< http://pt.wikipedia.org/wiki/Diagrama_de_atividade> acesso em 25 de maio de 
2014