_____________________________________________________________________________________________________
HISTÓRICO DE REVISÕES
Revisão
Data
Descrição
01
04/11
Levantamento dos requisitos
02
06/11
Reunião para
Requisitos
03
10/11
Elaboração do capítulo 1
bpn
04
12/06
Elaboração do capítulo 2
bpn,jcblc
05
16/11
Elaboração do capítulo 3
bpn,jcblc
06
18/11
Elaboração do capítulo 4
bpn,jcblc
04
20/11
Elaboração do capítulo 5
bpn,jcblc
05
24/11
Elaboração dos capítulo 6 e 7
bpn,jcblc
06
26/06
Organização dos Anexos
bpn,jcblc
07
27/11
Revisão Final do documento
bpn,jcblc
Estruturação
Autor (Login)
Jcblc
do
documento
de
bpn, Jcblc
_____________________________________________________________________________________________________
-2-
_____________________________________________________________________________________________________
SUMÁRIO
1. Introdução ....................................................................................................................................... - 4 1.1. Sobre a Organização................................................................................................................. - 4 1.2. O Problema Identificado .......................................................................................................... - 4 1.3. Convenções para Identificação de Requisitos.......................................................................... - 5 1.4. Convenções para Identificação de Casos de Uso ..................................................................... - 5 1.4.1. Estrutura de Casos de Uso ................................................................................................ - 5 1.4.2. Prioridades dos Casos de Uso ........................................................................................... - 6 1.4.3. Atores do Sistema ............................................................................................................. - 6 2. Requisitos ........................................................................................................................................ - 7 2.1. Requisitos da Organização ....................................................................................................... - 7 2.2. Requisitos Não-Funcionais ....................................................................................................... - 7 2.2.1. Requisitos de Produto ....................................................................................................... - 7 2.2.2. Requisitos de Processos .................................................................................................... - 8 2.2.3. Requisitos Externos ........................................................................................................... - 8 2.3. Requisitos Funcionais ............................................................................................................... - 8 3. Modelagem Organizacional .......................................................................................................... - 10 3.1. Modelagem de Dependência Estratégica .............................................................................. - 10 4. Modelagem de requisitos funcionais – casos de uso .................................................................... - 11 5. Modelagem de requisitos não-funcionais – NFR framework........................................................ - 12 6. Conclusão ...................................................................................................................................... - 13 7. Referências .................................................................................................................................... - 14 Anexos ............................................................................................................................................... - 15 Anexo A: Relatório da Equipe........................................................................................................ - 16 Anexo B: Dinâmica Empresarial .................................................................................................... - 17 Anexo C: Levantamento de Requisitos ......................................................................................... - 18 Anexo D: Detalhamento dos Requisitos Funcionais...................................................................... - 19 Anexo E: Diagrama do Modelo de Dependência Estratégica ........................................................ - 28 Anexo F: Diagrama de Requisitos Funcionais - Casos de Uso ....................................................... - 29 -
_____________________________________________________________________________________________________
-3-
_____________________________________________________________________________________________________
1. INTRODUÇÃO
De acordo com dados do ministério da saúde, de 2002 a 2008 o número de equipes de saúde
bucal formadas por cirurgiões-dentistas e profissionais auxiliares, pulou de 4.261, em 2002, para
16.756. Isso demonstra a crescente demanda por profissionais da área. Além disso, como forma de
incentivar os profissionais de odontologia, o ministério da saúde criou em 2004 o programa Brasil
Sorridente. Este programa propiciou a criação de 1.159 consultórios odontológicos, 551 Centros de
Especialidades Odontológicas (CEOs) e 310 Laboratórios de Prótese Dentária.
O cenário exposto acima demonstra o forte potencial econômico da área. Onde cada vez
mais novos profissionais surgirão e com eles um grande volume de dados a serem processados.
Dados estes que muitas vezes são tratados de forma manual e ineficiente. Além disso, alguns dos
softwares desenvolvidos para cumprirem este papel pecam por não atenderem as necessidades dos
usuários.
1.1. Sobre a Organização
O consultório odontológico da Dra Ivoneide Zimmerman, localizado na Avenida Santos
Dumont, Nº 435, Sala 02, Recife. É um consultório que funciona nos dois turnos para atendimento
particular ou por planos de saúde. O consultório possui quatro dependências – uma sala de espera,
uma sala de atendimento, um banheiro e um pequeno almoxarifado – e três funcionários: uma
secretária, uma auxiliar odontológica, e a própria odontologista. Dra Ivoneide é especialista em
Odontopediatria/Ortodontia e Ortopedia Facial.
1.2. O Problema Identificado
Toda seqüência de procedimentos envolvidos no atendimento a um paciente não possui
nenhuma forma de automatização e os dados do mesmo estão em um grande arquivo de papel
[Anexo B].
_____________________________________________________________________________________________________
-4-
_____________________________________________________________________________________________________
A busca pelos dados do paciente é realizada no início da manhã, antes de qualquer
atendimento, para não atrapalhar os atendimentos. A cada vez que um novo paciente chega ao
consultório, cria-se um novo envelope com seus dados e este é adicionado ao Arquivo. Porém, no
caso de um atendimento por encaixe ou uma emergência, essa busca pode atrapalhar a seqüência de
procedimentos para os outros pacientes. E, de tempos em tempos, a pilha de pastas com os dados
dos pacientes atendidos é recolhida da Sala de Atendimento, o que pode atrapalhar o Odontologista.
Todos os procedimentos odontológicos que são realizados são adicionados num relatório, também
em papel, e adicionados ao envelope do paciente.
Esse processo é lento e inseguro, podendo se perder ou danificar-se com o tempo e uso
continuado, uma vez que a mídia utilizada é o papel. Além de que está armazenado em grande
Arquivo de metal, que ocupa um bom espaço e tem que ser reorganizado de tempos em tempos,
caso a reposição dos envelopes com os dados dos pacientes não for bem gerenciada.
1.3. Convenções para Identificação de Requisitos
Os requisitos expostos neste documento serão todos abreviados, para não só facilitar a
identificação, bem como, para o seu posterior rastreamento. Para isso, foi adotada a nomenclatura
[RO-XX] para requisitos Organizacionais, [RF-XX] para requisitos Funcionais e [RNF-XX] para requisitos
Não-Funcionais, no qual o termo XX representa o número do requisito.
1.4. Convenções para Identificação de Casos de Uso
Seguindo o mesmo padrão adotado para os requisitos, os Casos de Uso serão abreviados na
forma [UC-XX], onde UC é uma referência ao inglês Use Case. O termo XX representa o número do
caso de uso.
1.4.1. Estrutura de Casos de Uso
Atores: São a representação dos usuários que farão uso do sistema;
Entradas: São as variáveis que estimularão o sistema;
Fluxo de eventos: Representa a maneira como os eventos serão desencadeados de acordo
com as ações dos usuários. Também pode fazer uso de fluxos de eventos secundários e/ou
alternativos;
Prioridade: Prioridade para execução do Caso de Uso;
_____________________________________________________________________________________________________
-5-
_____________________________________________________________________________________________________
Pré-condições: São as condições que devem ser satisfeitas para que o Caso de Uso citado
possa ser executado;
Pós-condições: São as condições que deverão ser satisfeitas após o Caso de Uso ser
finalizado;
Saídas: Representam os resultados que o sistema deverá fornecer após o Caso de Uso citado
seja executado.
1.4.2. Prioridades dos Casos de Uso
Os casos de uso foram classificados de três maneiras distintas de acordo com sua
importância.
Fundamental: É indispensável para o funcionamento do sistema.
Relevante: Apesar de não ser indispensável, é um caso de uso que é considerado importante
para o cliente.
Desejável: É o caso de uso que não é tão relevante quanto os anteriores e que pode ser
desenvolvido em versões posteriores do sistema.
1.4.3. Atores do Sistema
São aqueles que, de alguma maneira, interagem com o sistema. São todos os funcionários
que utilizarão o programa: os Pacientes, que desejam ter uma consulta odontológica; os Atendentes
que vão recepcionar o paciente, cadastrá-los e agendar consultas; o Odontologista, que verifica a
ficha do paciente e adiciona os procedimentos realizados; e o Administrador do Sistema, que
adiciona ou remove novos funcionários e mantém o sistema operante.
_____________________________________________________________________________________________________
-6-
_____________________________________________________________________________________________________
2. REQUISITOS
Nessa sessão estarão definidas e documentadas todas as propriedades e funções que o
Sistema deverá prover. Esses requisitos foram divididos em Requisitos da Organização, Requisitos
Funcionais e Requisitos Não-Funcionais.
2.1. Requisitos da Organização
Código
RO-01
RO-02
RO-03
RO-04
Descrição
A aplicação será desenvolvida sobre a plataforma Windows XP.
Os clientes não terão acesso ao sistema. O acesso fica restrito ao administrador do
sistema e ao secretário.
As operações envolvem confirmação por parte do usuário a fim de garantir a integridade
dos dados.
Para a fase de desenvolvimento, toda a documentação do sistema será acompanhada.
Tabela 1: Requisitos Organizacionais.
2.2. Requisitos Não-Funcionais
2.2.1. Requisitos de Produto
Código
RNF-01
RNF-02
RNF-03
RNF-04
RNF-05
Descrição
O tempo de retorno de consultas e inserção de dados no sistema não deve ser superior a
cinco segundos.
O tempo para a busca de um histórico de um cliente não deve ser superior a dez
segundos.
O software deve permitir ao usuário facilidades de uso, com uma interface gráfica
intuitiva, garantindo que todas as funcionalidades do programa estão facilmente
acessíveis.
O sistema deve ser robusto, garantindo que entradas inválidas sejam tratadas.
Um sistema bem modularizado garantirá que atualizações do software sejam feitas de
forma objetivas, rápidas e seguras.
Tabela 2: Requisitos do Produto.
_____________________________________________________________________________________________________
-7-
_____________________________________________________________________________________________________
2.2.2. Requisitos de Processos
Código
RNF-06
RNF-07
Descrição
O sistema será desenvolvido na linguagem de programação Java.
Será desenvolvida uma documentação apresentando diagrama de classes e o códigofonte do software.
Tabela 3: Requisitos do Processo.
2.2.3. Requisitos Externos
Código
RNF-08
Descrição
O software não deve exigir muito dos recursos de hardware uma vez que será usado em
máquinas que possuem limitações
Tabela 4: Requisitos Externos.
2.3. Requisitos Funcionais
Os requisitos funcionais descrevem as ações do sistema, isto é, as funções necessárias para
alcançar os objetivos do sistema. Abaixo, são listados sucintamente os requisitos funcionais do
Sistema de Gerenciamento de consultório odontológico. Um melhor detalhamento deles encontra-se
no Anexo D.
Código
RF-01
RF-02
RF-03
RF-04
RF-05
RF-06
RF-07
RF-08
RF-09
RF-10
RF-11
RF-12
RF-13
RF-14
RF-15
RF-16
RF-17
RF-18
RF-19
Nome
Cadastrar paciente
Atualizar dados no perfil do paciente
Remover paciente
Ver lista completa de pacientes
Buscar paciente por cpf
Buscar paciente por nome
Visualizar perfil do paciente
Verificar agenda de consultas de pacientes
Marcar consultas
Desmarcar consultas
Remover vários pacientes simultaneamente
Editar bloco de lembretes
Ver lista de pacientes em débito
Registro de pagamento de consulta
Editar anotação de consulta
Cadastrar dentista
Cadastrar atendente
Cadastrar outros tipos de funcionários
Visualizar perfil do funcionário
Prioridade
Fundamental
Fundamental
Fundamental
Relevante
Fundamental
Fundamental
Fundamental
Fundamental
Fundamental
Fundamental
Desejável
Desejável
Desejável
Fundamental
Fundamental
Fundamental
Fundamental
Relevante
Fundamental
_____________________________________________________________________________________________________
-8-
_____________________________________________________________________________________________________
RF-20
RF-21
RF-22
RF-23
Atualizar dados no perfil do funcionário
Remover funcionário
Logar no sistema
Deslogar do sistema
Fundamental
Fundamental
Fundamental
Fundamental
Tabela 5: Requisitos Funcionais.
_____________________________________________________________________________________________________
-9-
_____________________________________________________________________________________________________
3. MODELAGEM ORGANIZACIONAL
Aqui serão descritos os processos envolvendo os vários atores, utilizando a modelagem
conceitual i*, que utiliza uma representação gráfica na forma de rede de relacionamentos entre os
vários atores do processo, tendo assim o Modelo de Dependência Estratégica (Modelo SD).
3.1. Modelagem de Dependência Estratégica
O Modelo SD [Anexo E] descreve relações de dependência entre os atores da organização. Os
atores identificados são: o Paciente, o Atendente, o Odontologista e o Administrador do Sistema.
O Paciente deseja Marcar ou Desmarcar uma Consulta, mas que depende do Atendente para
que essa tarefa seja realizada. O Atendente, para Cadastrar um Paciente, Atualizar seus dados ou
Registrar um pagamento depende do Paciente. Porém, para um Atendente Remover um Paciente do
Sistema, ele depende o Odontologista. Para Visualizar o perfil de um Paciente e Verificar a Agenda de
Consultas, o Odontologista depende de que o Atendente tenha feito um cadastro do mesmo e tenha
marcado consultas. O Administrador depende do Atendente para Gerar Lista de Pacientes e Buscar
um Paciente, bem como para Visualizar o perfil de um Funcionário e para manter seus Dados
Atualizados.
_____________________________________________________________________________________________________
- 10 -
_____________________________________________________________________________________________________
4. MODELAGEM DE REQUISITOS FUNCIONAIS – CASOS DE USO
Os Casos de Uso representam uma unidade funcional provida pelo sistema. Cada Caso
descreve um cenário de possível iteração do Sistema, estando assim associado a um requisito
funcional. Um melhor detalhamento dos Casos de Uso está no Anexo D.
O diagrama de Casos de Uso [Anexo F] mostra como cada requisito funcional interage com os
atores do sistema e como eles interagem entre si.
_____________________________________________________________________________________________________
- 11 -
_____________________________________________________________________________________________________
5. MODELAGEM DE REQUISITOS NÃO-FUNCIONAIS – NFR FRAMEWORK
Cada requisito não-funcional está relacionado ao uso da uso do Sistema em termos de
desempenho, usabilidade, confiabilidade e tecnologias envolvidas.
De acordo com os requisitos definidos na Seção 2.2, foi construído um diagrama
demonstrando o relacionamento de cada requisito não-funcional com as restrições da aplicação.
Figura 1: Diagrama de Requisitos Não-Funcionais.
_____________________________________________________________________________________________________
- 12 -
_____________________________________________________________________________________________________
6. CONCLUSÃO
A crescente demanda por profissionais da área de odontologia junto ao incentivo do Governo
Federal demonstra o forte potencial econômico desse setor de prestação de serviços.
Através de entrevistas e leituras de documentos, foi possível levantar todos os requisitos
necessários para desenvolver um Sistema Informatizado para Gerenciamento de Consultórios
Odontológicos. Esses requisitos foram relacionados através de modelos como o i* e o NFR
Framework, o que permite uma visualização mais completa de todo o cenário para o qual o sistema
está sendo desenvolvido.
A solução proposta para o problema de gerenciamento de pacientes em um consultório
odontológico, o SIG-Odonto, é capaz de gerenciar as informações sobre todos os pacientes e de
fornecer relatórios úteis tanto ao Administrador do sistema como ao Odontologista, tudo isso de
forma automatizada e de acordo com as necessidades dos usuários do sistema.
_____________________________________________________________________________________________________
- 13 -
_____________________________________________________________________________________________________
7. REFERÊNCIAS
Disciplina de Especificação de Requisitos e Validação de Sistemas, http://www.cin.ufpe.br/~if716
KOTONYA, G.; SOMMERVILLE, I.; “Requirements Engineering: Processes and Techniques,
John Wiley & Sons”, 1998.
i* - An Agent-oriented Modelling Framework. Acesso em: 10 Novembro de 2009. Disponível
em: <http://www.cs.toronto.edu/km/istar/>.
CHUNG, L.; et. al.; “Non-Functional Requirements in Software Engineering”. Disponíivel em:
<http://www.utd.edu/~chung/BOOK/book.html> . Acesso em: 10 de Novembro de 2009.
_____________________________________________________________________________________________________
- 14 -
_____________________________________________________________________________________________________
ANEXOS
_____________________________________________________________________________________________________
- 15 -
_____________________________________________________________________________________________________
Anexo A: Relatório da Equipe
A tabela a seguir mostra o desempenho de cada integrante da equipe. A porcentagem
denota quantos por cento do trabalho o integrante contribuiu.
Nome
Bruno Pessôa Neves (bpn)
Esforço
50%
João Cléber B. Libório (jcblc)
50%
Assinatura
_____________________________________________________________________________________________________
- 16 -
_____________________________________________________________________________________________________
Anexo B: Dinâmica Empresarial
O consultório visitado foi o que pertence ao casal Rogério e Ivoneide Zimmermann, situado
na Avenida Santos Dumont, Nº 435, Sala 02, Recife. É um consultório que funciona nos dois turnos –
no período da manhã, é o turno da Dra. Ivoneide, e o da tarde, do Dr. Rogério. O atendimento é
particular ou por planos de saúde.
O consultório possui quatro dependências: uma sala de espera com recepção; uma sala de
atendimento clínico, onde são realizados os procedimentos odontológicos; um banheiro e um
pequeno almoxarifado, onde fica um grande arquivo de metal com as fichas clínicas de todos os
pacientes.
Além do casal, no Consultório trabalham: uma Atendente, que recepciona os pacientes e
agenda as consultas; e uma Auxiliar de Odontologia, para prestar assistência aos procedimentos.
Quando um paciente chega ao consultório, ele vai até a Atendente e preenche uma ficha,
contendo dados pessoais, como nome, endereço, telefone etc. Essa ficha é colocada dentro de um
envelope com o nome do paciente, e este envelope é colocado num arquivo de metal. As consultas
são anotadas numa agenda comum, no dia e horário combinados com o paciente.
De manhã cedo, para não atrapalhar a dinâmica de atendimentos, a Atendente verifica o
nome de todos os pacientes agendados para o dia todo, vai até o arquivo e separa os envelopes
contendo todos os dados dele, e empilha na ordem de agendamento. Quando o paciente entra na
sala do Odontologista para atendimento, a Atendente leva seu envelope para o Odontologista.
Durante o atendimento, os Odontologistas escrevem relatórios descrevendo os
procedimentos odontológicos realizados, para o futuro acompanhamento do paciente. Esses
relatórios são adicionados ao envelope contendo os dados do paciente.
Ao fim do dia, a pilha de envelopes retorna ao arquivo, e a Atendente deve ordená-los de
forma correta para facilitar a busca no dia seguinte.
_____________________________________________________________________________________________________
- 17 -
_____________________________________________________________________________________________________
Anexo C: Levantamento de Requisitos
As técnicas utilizadas para levantamento dos requisitos foram a Entrevista, e a Leitura de
Documentos. Nossa entrevistada foi a Dra Ivoneide Zimmermann, que é especialista em
Odontopediatria/Ortodontia e Ortopedia Facial. Os documentos lidos foram apenas a ficha cadastral
do paciente e alguns relatórios de procedimentos odontológicos.
Foram coletadas informações como dificuldades, expectativas de como o sistema deveria se
comportar e também sugestões de interface de modo a deixá-la mais amigável. As mesmas estão
armazenadas em mídia digital para futuras consultas.
_____________________________________________________________________________________________________
- 18 -
_____________________________________________________________________________________________________
Anexo D: Detalhamento dos Requisitos Funcionais
RF-01
Nome:
Cadastrar paciente
Descrição:
Permite ser realizado no sistema o cadastro de novos pacientes do consultório.
Esse cadastro é composto do nome, CPF, endereço, data de nascimento, telefone
residencial e/ou celular.
Atores:
Atendente
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22), nome, CPF, algum telefone para
contato, data de nascimento e endereço.
Saídas e pós-condições:
O paciente cadastrado no sistema.
Fluxos de eventos
Fluxo principal:
1. O atendente informa os dados do paciente necessários para a
realização do cadastro. Itens não obrigatórios citados acima também
podem ser informados;
2. O sistema verifica se o paciente já possui cadastro;
3. O sistema armazena os dados do paciente no repositório e informa
que o cadastro foi realizado com sucesso.
Fluxo secundário:
No item 2 do fluxo principal, caso o paciente já é cadastro, o sistema
deve informar isso ao usuário e retornar ao item 1 do fluxo principal.
RF-02
Nome:
Atualizar dados no perfil do paciente
Descrição:
O sistema deve permitir a alteração de informações do cadastro de um paciente.
Atores:
Atendente
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Visualizar perfil do paciente (RF-07)
Saídas e pós-condições:
O paciente com seu cadastro atualizado.
Fluxos de eventos
Fluxo principal:
1. O atendente informa os dados do paciente necessários para a
realização da atualização;
2. O sistema armazena os dados do paciente no repositório e informa
que a atualização foi realizada com sucesso.
Fluxo secundário:
No fluxo principal 2, caso o paciente já esteja cadastrado, o sistema
exibe uma mensagem informando o ocorrido, voltando ao passo 1.
RF-03
Nome:
Descrição:
Atores:
Remover paciente
O sistema deverá permitir a exclusão um paciente de seu banco de dados.
Atendente
_____________________________________________________________________________________________________
- 19 -
_____________________________________________________________________________________________________
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-03, RNF-04.
Entradas e pré-condições:
Visualizar perfil do paciente (RF-07)
Saídas e pós-condições:
O paciente removido do sistema.
Fluxos de eventos
Fluxo principal:
1. O atendente remove o paciente clicando no botão de excluir no
perfil dele;
2. O sistema solicita confirmação de exclusão;
3. O atendente confirma exclusão;
4. O sistema remove o paciente da base de dados.
Fluxo secundário:
No fluxo principal 3, caso o atendente não confirme a exclusão, o
sistema voltará ao passo 1 do fluxo principal.
RF-04
Nome:
Ver lista completa de pacientes
Descrição:
O sistema deverá permitir a visualização da lista completa dos pacientes da clínica.
Atores:
Atendente e Odontologista
Prioridade: Relevante
Requisitos Não Funcionais Associados: RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22)
Saídas e pós-condições:
A lista de todos os pacientes do consultório.
Fluxos de eventos
Fluxo principal:
1. O usuário clica no botão paciente para ir para aba dos pacientes;
2. O usuário solicita a lista completa clicando no botão listar pacientes;
3. A lista é apresentada na tela;
Fluxo secundário:
No fluxo principal 1, caso não haja pacientes cadastrados, o usuário
deverá ser informado disso.
RF-05
Nome:
Buscar paciente por cpf
Descrição:
O sistema deverá permitir a localização de um paciente através do CPF.
Atores:
Atendente e Dentista
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-01, RNF-03, RNF-04.
Entradas e pré-condições:
CPF do paciente e Logar no sistema (RF-22)
Saídas e pós-condições:
O perfil do paciente
Fluxos de eventos
Fluxo principal:
1. O usuário informa o CPF do paciente;
2. Os dados do paciente são exibidos;
Fluxo secundário:
No fluxo principal 1, caso não haja algum paciente com o CPF
informado, uma mensagem deverá ser gerada informando o paciente.
_____________________________________________________________________________________________________
- 20 -
_____________________________________________________________________________________________________
RF-06
Nome:
Buscar paciente por nome
Descrição:
O sistema deverá permitir a localização de um paciente através do nome.
Atores:
Atendente e Dentista
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-01, RNF-03, RNF-04.
Entradas e pré-condições:
Nome do paciente e Logar no sistema (RF-22)
Saídas e pós-condições:
O perfil do paciente
Fluxos de eventos
Fluxo principal:
1. O usuário informa o nome do paciente;
2. O usuário seleciona o paciente desejado;
3. Os dados do paciente são exibidos.
Fluxo secundário 1:
No fluxo principal 1, caso não haja algum paciente com o nome
informado, uma mensagem deverá ser gerada informando o paciente.
Fluxo secundário 2:
No fluxo principal 2, caso haja mais de um paciente cadastrado com o
mesmo nome, o usuário deverá selecionar o paciente com base no
CPF
RF-07
Nome:
Visualizar perfil do paciente
Descrição:
O sistema deverá permitir a visualização do perfil do paciente
Atores:
Atendente e Dentista
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03.
Entradas e pré-condições:
Buscar cliente por CPF (RF-05) ou Buscar cliente por nome
(RF-06) ou Ver lista completa de pacientes (RF-04) ou
Cadastrar paciente (RF-01)
Saídas e pós-condições:
Os dados do paciente solicitado.
Fluxos de eventos
Fluxo principal:
1. O ator clica no botão de acesso ao perfil do paciente desejado
RF-08
Nome:
Verificar agenda de consultas de pacientes
Descrição:
O sistema deverá permitir a visualização das consultas marcadas na agenda
Atores:
Atendente, Dentista e Administrador
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22)
Saídas e pós-condições:
Painel de consultas atualizado por dia
Fluxos de eventos
Fluxo principal:
1. Navegar pelos dois botões que passam para frente e para trás os
dias da agenda ou clicar diretamente no mês desejado
_____________________________________________________________________________________________________
- 21 -
_____________________________________________________________________________________________________
RF-09
Nome:
Marcar consultas
Descrição:
O sistema deverá permitir ao atendente marcar consultas para os pacientes.
Atores:
Atendente
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03.
Entradas e pré-condições:
Visualizar perfil do paciente (RF-07), Escolher tipo de
consulta
Saídas e pós-condições:
Agenda de consultas e perfil do paciente modificado
Fluxos de eventos
Fluxo principal:
1. O atendente escolhe o tipo de consulta;
2. O atendente digita o horário da consulta;
3. O atendente finaliza o procedimento.
Fluxo secundário 1:
No fluxo principal, caso haja choque de horário o sistema acusará
choque e o atendente fornecerá um novo horário ou irá cancelar o
procedimento.
RF-10
Nome:
Desmarcar consultas
Descrição:
O sistema deverá permitir ao atendente desmarcar consultas para os pacientes.
Atores:
Atendente
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-03.
Entradas e pré-condições:
Visualizar perfil do paciente (RF-07)
Saídas e pós-condições:
Agenda de consultas e perfil do paciente modificado
Fluxos de eventos
Fluxo principal:
1. O atendente clica no botão de cancelar no registro da consulta no
perfil do paciente;
2. O sistema solicita confirmação do cancelamento;
3. O atendente confirma cancelamento;
4. O sistema remove a consulta da base de dados.
Fluxo secundário:
No fluxo principal 3, caso o atendente não confirme a exclusão, o
sistema voltará ao passo 1 do fluxo principal.
RF-11
Nome:
Remover vários pacientes simultaneamente
Descrição:
O sistema deverá permitir ao atendente remover vários pacientes
Atores:
Atendente
Prioridade: Desejável
Requisitos Não Funcionais Associados: RNF-03.
Entradas e pré-condições:
Ver lista completa de pacientes (RF-04)
Saídas e pós-condições:
O sistema atualiza a lista de pacientes
Fluxos de eventos
Fluxo principal:
1. O atendente seleciona um bloco de pacientes;
_____________________________________________________________________________________________________
- 22 -
_____________________________________________________________________________________________________
Fluxo secundário:
2. O sistema solicita confirmação de exclusão;
3. O atendente confirma exclusão;
4. O sistema remove os pacientes da base de dados.
No fluxo principal 3, caso o atendente não confirme a exclusão, o
sistema voltará ao passo 1 do fluxo principal.
RF-12
Nome:
Editar bloco de lembretes
Descrição:
O sistema deverá permitir ao atendente editar as anotações em uma caixa de texto.
Atores:
Atendente
Prioridade: Desejável
Requisitos Não Funcionais Associados: RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22)
Saídas e pós-condições:
As anotações serão atualizadas
Fluxos de eventos
Fluxo principal:
1. Ampliar o bloco de lembretes presente na tela do atendente;
2. Editar o seu conteúdo;
3. Minimizar o bloco de lembretes.
RF-13
Nome:
Ver lista de pacientes em débito
Descrição:
O sistema deverá permitir a visualização de uma lista de pacientes com débito.
Atores:
Atendente e Administrador
Prioridade: Desejável
Requisitos Não Funcionais Associados: RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22)
Saídas e pós-condições:
Uma lista é apresentada com o nome do paciente e o
débito
Fluxos de eventos
Fluxo principal:
1. Apertar no botão de listar pacientes com débito
Fluxo secundário:
No fluxo principal, caso não haja paciente com débito uma aviso é
retornado.
RF-14
Nome:
Registro de pagamento de consulta
Descrição:
O sistema deverá permitir ao atendente quitar débitos de pacientes
Atores:
Atendente
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Visualizar perfil do paciente (RF-07)
Saídas e pós-condições:
Perfil do paciente tem o campo de débito atualizado
Fluxos de eventos
Fluxo principal:
1. Zerar campo de débito confirmando o pagamento
_____________________________________________________________________________________________________
- 23 -
_____________________________________________________________________________________________________
RF-15
Nome:
Editar anotações de consulta
Descrição:
O sistema permite que o dentista registre anotações em consultas
Atores:
Dentista
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Visualizar perfil do paciente (RF-07)
Saídas e pós-condições:
Quadro de anotações atualizado
Fluxos de eventos
Fluxo principal:
1. Ampliar o bloco de anotação da respectiva consulta;
2. Editar o conteúdo;
3. Minimizar o bloco de anotação.
RF-16
Nome:
Cadastrar dentista
Descrição:
O sistema permite o cadastro de um dentista
Atores:
Administrador
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22) e Nome, CPF, CRO, endereço,
telefones, data de nascimento, tipos de consulta que
realiza, preço da consulta, login e senha.
Saídas e pós-condições:
Perfil do dentista atualizado.
Fluxos de eventos
Fluxo principal:
1. O administrador informa os dados do dentista necessários para a
realização do cadastro;
2. O sistema verifica se o dentista já está cadastrado;
3. O sistema armazena os dados do dentista no repositório e informa
que o cadastro foi realizado com sucesso.
Fluxo secundário:
No fluxo principal 2, caso o dentista já esteja cadastrado, o sistema
exibe uma mensagem informando o ocorrido, voltando ao passo 1.
RF-17
Nome:
Cadastrar atendente
Descrição:
O sistema permite o cadastro de um atendente
Atores:
Administrador
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22) e Nome, CPF, endereço,
telefones, data de nascimento, salário, login e senha.
Saídas e pós-condições:
Perfil do atendente atualizado.
Fluxos de eventos
_____________________________________________________________________________________________________
- 24 -
_____________________________________________________________________________________________________
Fluxo principal:
Fluxo secundário:
1. O administrador informa os dados do atendente necessários para a
realização do cadastro;
2. O sistema verifica se o atendente já está cadastrado;
3. O sistema armazena os dados do atendente no repositório e
informa que o cadastro foi realizado com sucesso.
No fluxo principal 2, caso o atendente já esteja cadastrado, o sistema
exibe uma mensagem informando o ocorrido, voltando ao passo 1.
RF-18
Nome:
Descrição:
Cadastrar outros tipos de funcionários
O sistema permite o cadastro de dos funcionários que não terão acesso a esse
sistema
Atores:
Administrador
Prioridade: Relevante
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22) e Nome, CPF, endereço,
telefones, data de nascimento, salário.
Saídas e pós-condições:
Perfil do funcionário atualizado
Fluxos de eventos
Fluxo principal:
1. O administrador informa os dados do funcionário necessários para a
realização do cadastro;
2. O sistema verifica se o funcionário já está cadastrado;
3. O sistema armazena os dados do funcionário no repositório e
informa que o cadastro foi realizado com sucesso.
Fluxo secundário:
No fluxo principal 2, caso o funcionário já esteja cadastrado, o sistema
exibe uma mensagem informando o ocorrido, voltando ao passo 1.
RF-19
Nome:
Visualizar perfil do funcionário
Descrição:
O sistema permite a remoção de um funcionário
Atores:
Administrador
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03, RNF-04.
Entradas e pré-condições:
Logar no sistema (RF-22)
Saídas e pós-condições:
Exibição do perfil do funcionário
Fluxos de eventos
Fluxo principal:
1. O administrador seleciona o funcionário;
2. O sistema exibe uma aba com o perfil do funcionário.
RF-20
Nome:
Descrição:
Atores:
Atualizar dados no perfil do funcionário
O sistema permite atualizar os dados cadastrados no seu perfil
Administrador
_____________________________________________________________________________________________________
- 25 -
_____________________________________________________________________________________________________
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RFN-01, RNF-03
Entradas e pré-condições:
Vizualizar perfil do funcionário (RF-19)
Saídas e pós-condições:
Perfil do funcionário atualizado
Fluxos de eventos
Fluxo principal:
1. O administrador informa os dados do funcionário necessários para a
realização da atualização;
2. O sistema armazena os dados do funcionário no repositório e
informa que a atualização foi realizada com sucesso.
Fluxo secundário:
No fluxo principal 2, caso o funcionário já esteja cadastrado, o sistema
exibe uma mensagem informando o ocorrido, voltando ao passo 1.
RF-21
Nome:
Remover funcionário
Descrição:
O sistema permite a remoção de um funcionário
Atores:
Administrador
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-03,
Entradas e pré-condições:
Ver perfil do funcionário (RF-19)
Saídas e pós-condições:
Lista de funcionários no perfil do administrador atualizada
Fluxos de eventos
Fluxo principal:
1. O administrador remove da lista de funcionários a pessoa
selecionada clicando no botão de excluir;
2. O sistema solicita confirmação de exclusão;
3. O administrador confirma exclusão;
4. O sistema remove o funcionário da base de dados.
Fluxo secundário:
No fluxo principal 3, caso o usuário não confirme a exclusão, o sistema
voltará ao passo 1 do fluxo principal.
RF-22
Nome:
Logar no sistema
Descrição:
O sistema permite acesso aos seus recursos com determinados níveis de retrição
Atores:
Atendente, administrador e Dentista
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-03, RNF-04
Entradas e pré-condições:
Informar login e senha
Saídas e pós-condições:
Acesso ao sistema
Fluxos de eventos
Fluxo principal:
1. O usuário informa o login e senha;
2. Confirmar acesso ao sistema.
Fluxo secundário:
Caso uma das informações estejam erradas o sistema avisa erro e
volta ao fluxo principal.
_____________________________________________________________________________________________________
- 26 -
_____________________________________________________________________________________________________
RF-23
Nome:
Deslogar do sistema
Descrição:
O sistema permite ao usuário sair
Atores:
Atendente, administrador e Dentista
Prioridade: Fundamental
Requisitos Não Funcionais Associados: RNF-03,
Entradas e pré-condições:
Logar no sistema (RF-22)
Saídas e pós-condições:
Um débito é removido.
Fluxos de eventos
Fluxo principal:
1. Clicar no botão se sair;
2. Confirmar saída do sistema.
_____________________________________________________________________________________________________
- 27 -
_____________________________________________________________________________________________________
Anexo E: Diagrama do Modelo de Dependência Estratégica
_____________________________________________________________________________________________________
- 28 -
- 29 -
Buscar Paciente
Include
Editar anotações de consulta
Visualizar Perfil do Paciente
Extend
Extend
Buscar Paciente por CPF
Buscar Paciente por nome
Editar bloco de Lembretes
Desmarcar consultas
Atualizar Dados do Paciente
Cadastra outros Funcionários
Extend
Odontologista
Include
Verificar agenda de consulta do Paciente
Atendente
Marcar Consultas
Paciente
Cadastrar odontologista
Extend
Logar no sistema
Cadastrar Funcionários
Extend
Ver lista de paciente em débito
Deslogar do Sistema
Remover Paciente
Cadastra Atendente
Regsitro de pagamento de consulta
Remover Funcionário
Include
Cadastrar Paciente
Include
Visualizar perfil do Funcionário
Administrador
Atualizar perfil do Funcionário
_____________________________________________________________________________________________________
Anexo F: Diagrama de Requisitos Funcionais - Casos de Uso
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
AUTO-AVALIAÇÃO
Segue abaixo uma avaliação feita pelos membros da equipe sobre o trabalho de seus
companheiros de trabalho. Foi atribuído uma nota que varia de 0 até 10.
Nome do Integrante (login)
Avaliação
Bruno Pessôa Neves (bpn)
10,0
João Cleber B. Libório Correia (jcblc)
10,0
Para demonstrar que a avaliação acima está condizente com a situação vivenciada pela
equipe durante o processo de desenvolvimento da análise apresentada nesse documento, os
integrantes devem assinar nos locais indicados abaixo na intenção de atestar a veracidade e validade
do resultado.
___________________________________
Bruno Pessôa Neves
___________________________________
João Cleber B. Libório Correia
_____________________________________________________________________________________________________
- 30 -