histÓrico de revisÕes - cin.ufpe.brif716/projetos/projetos2009-2/requisitosii_v1.pdf · ro-01 a...

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 2 -

HISTÓRICO DE REVISÕES

Revisão Data Descrição Autor (Login)

01 04/11 Levantamento dos requisitos Jcblc

02 06/11 Reunião para Estruturação do documento de Requisitos bpn, Jcblc

03 10/11 Elaboração do capítulo 1 bpn

04 12/06 Elaboração do capítulo 2 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

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 3 -

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 -

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 4 -

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].

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 5 -

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;

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 6 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 7 -

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 Descrição

RO-01 A aplicação será desenvolvida sobre a plataforma Windows XP. RO-02 Os clientes não terão acesso ao sistema. O acesso fica restrito ao administrador do

sistema e ao secretário. RO-03 As operações envolvem confirmação por parte do usuário a fim de garantir a integridade

dos dados. RO-04 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 Descrição

RNF-01 O tempo de retorno de consultas e inserção de dados no sistema não deve ser superior a cinco segundos.

RNF-02 O tempo para a busca de um histórico de um cliente não deve ser superior a dez segundos.

RNF-03 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.

RNF-04 O sistema deve ser robusto, garantindo que entradas inválidas sejam tratadas. RNF-05 Um sistema bem modularizado garantirá que atualizações do software sejam feitas de

forma objetivas, rápidas e seguras. Tabela 2: Requisitos do Produto.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 8 -

2.2.2. Requisitos de Processos

Código Descrição

RNF-06 O sistema será desenvolvido na linguagem de programação Java. RNF-07 Será desenvolvida uma documentação apresentando diagrama de classes e o código-

fonte do software. Tabela 3: Requisitos do Processo.

2.2.3. Requisitos Externos

Código Descrição

RNF-08 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 Nome Prioridade

RF-01 Cadastrar paciente Fundamental RF-02 Atualizar dados no perfil do paciente Fundamental RF-03 Remover paciente Fundamental RF-04 Ver lista completa de pacientes Relevante RF-05 Buscar paciente por cpf Fundamental RF-06 Buscar paciente por nome Fundamental RF-07 Visualizar perfil do paciente Fundamental RF-08 Verificar agenda de consultas de pacientes Fundamental RF-09 Marcar consultas Fundamental RF-10 Desmarcar consultas Fundamental RF-11 Remover vários pacientes simultaneamente Desejável RF-12 Editar bloco de lembretes Desejável RF-13 Ver lista de pacientes em débito Desejável RF-14 Registro de pagamento de consulta Fundamental RF-15 Editar anotação de consulta Fundamental RF-16 Cadastrar dentista Fundamental RF-17 Cadastrar atendente Fundamental RF-18 Cadastrar outros tipos de funcionários Relevante RF-19 Visualizar perfil do funcionário Fundamental

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 9 -

RF-20 Atualizar dados no perfil do funcionário Fundamental RF-21 Remover funcionário Fundamental RF-22 Logar no sistema Fundamental RF-23 Deslogar do sistema Fundamental

Tabela 5: Requisitos Funcionais.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 10 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 11 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 12 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 13 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 14 -

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.

http://www.cin.ufpe.br/~if716

http://www.cs.toronto.edu/km/istar/

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 15 -

ANEXOS

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 16 -

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 Esforço Assinatura

Bruno Pessôa Neves (bpn) 50%

João Cléber B. Libório (jcblc) 50%

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 17 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 18 -

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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 19 -

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



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: Remover paciente

Descrição:

O sistema deverá permitir a exclusão um paciente de seu banco de dados.

Atores: Atendente

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 20 -


Requisitos Não Funcionais Associados: RNF-03, RNF-04.


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


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


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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 21 -

RF-06

Nome: Buscar paciente por nome

Descrição: O sistema deverá permitir a localização de um paciente através do nome.



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



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




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

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 22 -

RF-09

Nome: Marcar consultas

Descrição: O sistema deverá permitir ao atendente marcar consultas para os pacientes.

Atores: Atendente


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


Requisitos Não Funcionais Associados: RNF-03.


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.


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;

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 23 -

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.


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




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




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




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

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 24 -

RF-15

Nome: Editar anotações de consulta

Descrição: O sistema permite que o dentista registre anotações em consultas

Atores: Dentista




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



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




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

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 25 -

Fluxo principal: 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.

Fluxo secundário: 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: Cadastrar outros tipos de funcionários

Descrição: O sistema permite o cadastro de dos funcionários que não terão acesso a esse sistema


Prioridade: Relevante


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





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: Atualizar dados no perfil do funcionário

Descrição: O sistema permite atualizar os dados cadastrados no seu perfil


_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 26 -


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



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


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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 27 -

RF-23

Nome: Deslogar do sistema

Descrição: O sistema permite ao usuário sair

Atores: Atendente, administrador e Dentista


Requisitos Não Funcionais Associados: RNF-03,


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.

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 28 -

Anexo E: Diagrama do Modelo de Dependência Estratégica

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 29 -

Anexo F: Diagrama de Requisitos Funcionais - Casos de Uso

Aten

den

te

Od

on

to

log

ista

Ad

min

istra

do

r

Pacie

nte

Ca

da

str

ar

Pa

cie

nte

Atu

aliza

r D

ad

os d

o P

acie

nte

Re

mo

ve

r P

acie

nte

Bu

sca

r P

acie

nte

Vis

ua

liza

r P

erf

il d

o P

acie

nte

Ve

rifi

ca

r a

ge

nd

a d

e c

on

su

lta

do

Pa

cie

nte

Ma

rca

r C

on

su

lta

s

De

sm

arc

ar

co

nsu

lta

s

Ed

ita

r b

loco

de

Le

mb

rete

sV

er

lista

de

pa

cie

nte

em

dé

bit

o

Re

gsit

ro d

e p

ag

am

en

to d

e c

on

su

lta

Ed

ita

r a

no

taçõ

es d

e c

on

su

lta

Ca

da

str

ar

od

on

tolo

gis

ta

Ca

da

str

a A

ten

de

nte

Ca

da

str

ar

Fu

ncio

ná

rio

s

Vis

ua

liza

r p

erf

il d

o F

un

cio

ná

rio

Atu

aliza

r p

erf

il d

o F

un

cio

ná

rio

Re

mo

ve

r Fu

ncio

ná

rio

Lo

ga

r n

o s

iste

ma

De

slo

ga

r d

o S

iste

ma

Extend

Extend

Ca

da

str

a o

utr

os F

un

cio

ná

rio

s

Extend

Include

Include

Include

Include

Bu

sca

r P

acie

nte

po

r n

om

e

Bu

sca

r P

acie

nte

po

r C

PFExtend

Extend

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ - 30 -

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

histÓrico de revisÕes - cin.ufpe.brif716/projetos/projetos2009-2/requisitosii_v1.pdf · ro-01 a...

Documents