Trabalho_Psicologia_interfaces

Prévia do material em texto

PROJETO DA ARQUITETURA DO SOFTWARE DE GERENCIAMENTO 
CLÍNICO DE PSICOLOGIA 
 
 
 
 
 
 
 
 
 
 
 
 
Goiânia 
2018 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PROJETO DA ARQUITETURA DO SOFTWARE DE GERENCIAMENTO 
CLÍNICO DE PSICOLOGIA 
 
 
 
 
 
 
 
 
 
 
 
 
 
Goiânia 
2018 
 
SUMÁRIO 
 
1. Documento Visão .......................................................................................................................... 4 
2. Modelo de domínio ....................................................................................................................... 8 
3. EOR .............................................................................................................................................. 9 
4. Documento de Arquitetura(IEEE 1471) ..................................................................................... 41 
5. Projeto de componentes .............................................................................................................. 50 
6. Projeto de interface ..................................................................................................................... 77 
7. Projeto de dados .......................................................................................................................... 81 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. Documento Visão 
 
 
Data Descrição Autores 
01/06/2018 Criação do documento visão Pedro 
Gabriel 
Suet 
 
Índice 
 ................................................................................................................................................................ 
1.1 Introdução ...................................................................................................................................... 4 
1.2 Posicionamento .............................................................................................................................. 4 
1.3 Descrição dos interessados ............................................................................................................. 4 
1.4 Visão geral do produto ................................................................................................................... 6 
1.5 Resumo das características do sistema ........................................................................................... 7 
1.6 Outros Requisitos e Restrições ...................................................................................................... 7 
 
1.1 Introdução 
 
Imaginamos a aplicação de gerenciamento clínico de psicologia para controle de agendamento de 
sessões, financeiro e da própria sessão. 
 
1.2 Posicionamento 
 
Oportunidade de negócio 
 
Os produtos já existentes no mercado, em sua grande maioria, gerenciam apenas o controle do 
agendamento de consultas e das sessões dos pacientes. Normalmente, esses sistemas são locais 
(desktop), o que compromete a relação do usuário com o mesmo. 
 
Definição do problema 
 
Sistemas de controle clínico normalmente são locais, o que dificulta o acesso aos dados pelo 
psicólogo, além de serem intolerantes a falhas, de difícil aprendizado e complexos. 
 
Definição da posição do produto 
 
O produto é destinado às clínicas de psicologia a fim de melhorar o relacionamento 
paciente/psicólogo no que se refere ao controle de agendamento de consultas e sessões, agregando a 
parte financeira. 
 
1.3 Descrições dos interessados 
 
Resumo dos interessados (não-usuários) 
 
Nome Descrição Responsabilidade 
 
 
Equipe de desenvolvimento Estudantes da PUC-GO da 
disciplina de Arquitetura e 
Design de Software 
Desenvolver o software descrito 
neste documento 
Clientes Clínicas de Psiquiatria Requisitar as funcionalidades 
do projeto e vislumbrar seu 
escopo 
 
 
Resumo dos usuários 
 
Nome Descrição 
Psicólogo Terá acesso a todos os dados dos pacientes 
Secretária Pessoa que controla o agendamento e cadastro 
dos pacientes 
Paciente Pessoa que pode agendar, remarcar e cancelar 
sessões 
 
 
 
 
 
Objetivos-chave de alto nível e problemas dos interessados 
 
 
Objetivo de Alto Nível Prioridade Problemas e 
Preocupações 
Soluções Correntes 
Gerenciamento das 
Consultas 
Alta Manter o cadastro dos 
clientes sempre 
atualizado. 
Perda de dados se há 
falhas nos 
componentes. 
Produtos já existentes 
no mercado fornecem o 
gerenciamento das 
sessões, mas não tratam 
esses problemas 
Processar o pagamento 
das consultas 
Alta Transtornos na 
realização do 
pagamento por causa 
da não integração com 
os sistemas já 
existentes de 
contabilidade. 
Produtos já existentes 
no mercado, em sua 
maioria, não fornecem 
o processamento do 
pagamento no 
software. 
 
 
 
Ambiente do usuário 
 
O software será uma plataforma web responsiva que irá se adaptar a tamanhos de tela, ou seja, o 
usuário poderá acessar a plataforma pela maioria dos computadores, tablet ou smartphones que 
possuam um navegador compatível e acesso à internet. 
 
 
 
 
 
 
 
1.4 Visão geral do produto 
 
Perspectiva do produto 
 
O sistema oferecerá uma melhor maneira de controlar o agendamento de consultas, trazendo mais 
conforto e organização tanto para os clientes quanto para as clínicas. 
 
 
 
 
 
Resumo dos benefícios 
 
Benefícios para o cliente Recurso de Suporte 
Facilidade no gerenciamento das consultas Site online 7 dias da semana, 24 horas por dia. 
Facilidade no pagamento Integrado com a conta do banco. 
 
 
1.5 Resumo das características do sistema 
• Administração do sistema: usuários, segurança, códigos 
• Agendar sessão 
• Desmarcar sessão 
• Verificar sessões dos pacientes 
• Verificar sessões por dia 
• Agendar encaixe de emergência 
• Controlar fila de espera 
• Enviar aviso de consulta 
• Remarcar sessão 
 
1.6 Outros Requisitos e Restrições 
 
Requisitos não-funcionais 
 Requisitos de Suportabilidade 
• A aplicação deve possibilitar acesso através de navegadores web 
• A aplicação deve ser utilizada através da internet 
 Requisitos de Design 
• O sistema deve possuir uma aplicação que possibilite uma interação do usuário de 
forma prática e intuitiva. Para isso o sistema contará com uma interface de fácil 
compreensão por parte do usuário. 
 Requisitos de Segurança 
• O sistema garantirá o sigilo dos dados dos usuários. 
 Requisitos de Desempenho 
• O sistema deverá retornar uma nova página para o usuário em menos de 5 segundos 
 
 
 
 
 
2. Modelo de Domínio 
 
Data Descrição Autores 
06/06/2018 Criação do Modelo de Domínio Vitor 
Miranda 
 
 
 
 
 
 
3. EOR 
 
 
Data Descrição Autor 
23/05/201
8 
*Criação do documento do EOR Matheus 
Cardosos 
e 
Guilherme 
Neves 
 
Conteúdo 
Introdução .......................................................................................................................................... 10 
Objetivos ........................................................................................................................................ 10 
1.1. Público Alvo ............................................................................................................................ 10 
1. Informações de Suporte ................................................................................................................. 10 
Definições ...................................................................................................................................... 10 
Termos – definições ....................................................................................................................... 11 
Descrição das funcionalidades do Modelo de Especificação de requisitos ................................... 11 
2. Elicitação de Requisitos .................................................................................................................12 
3. Requisitos do Cliente (RCLI) ........................................................................................................ 12 
4. Casos de Uso .................................................................................................................................. 13 
4.1. Atores ...................................................................................................................................... 13 
4.2. Lista de casos de uso ............................................................................................................... 14 
4.3. Descrição de Casos de Uso ..................................................................................................... 14 
Requisitos e restrições funcionais (RFUN) ........................................................................................ 29 
 ............................................................................................................................................................ 29 
Requisitos e restrições não funcionais (RNF) .................................................................................... 31 
Requisitos Futuros (RFUT) ................................................................................................................ 38 
Rastreabilidade ................................................................................................................................... 38 
Abordagem Multi-dimensional de Requisitos X Casos de Uso; - Vertical .................................... 39 
Abordagem Multi-dimensional Requisitos X Requisitos funcionais; - Horizontal ....................... 39 
Aprovação formal .............................................................................................................................. 39 
Anexos ............................................................................................................................................... 40 
• Introdução 
◦ Objetivos 
Este documento tem o objetivo de levantar e documentar requisitos de uma clínica de psicologia 
online, O produto final é um software que gerência clínica psicológica, agenda sessão, guarda 
histórico das sessões e controla contas a pagar e receber. Hoje a clínica funciona com uma agenda e 
 
 
com cadernos para anotações das sessões e para controle financeiro. O software a ser desenvolvido 
só atenderá para uso de um único psicólogo. 
.1. Público Alvo 
 
● Psicologia: São profissionais que apoiam o cliente mentalmente na área que precisam. Para 
isso contam com anotações das sessões para fazer o acompanhamento da evolução. 
● Secretaria: São profissionais que apoiam no agendamento e no controle dos atendimentos. 
 
● Administrador: São profissionais que ficam na parte do controle financeiro. 
 
1. Informações de Suporte 
◦ Definições 
 
CSU - Casos de uso. 
RFA00 - Requisitos funcionais de Adequação. 
RFSA00 - Requisitos funcionais de Segurança de acesso. 
RRAC00 - Requisitos funcionais de Acurácia. 
RFI00 - Requisitos funcionais de Interoperabilidade. 
RFC00 - Requisitos funcionais de Conformidade. 
RMT00 – Requisitos não funcionais de Maturidade. 
RTOL00 – Requisitos não funcionais de Tolerância a Falhas. 
RREC00 – Requisitos não funcionais de Recuperabilidade. 
RCRC00 – Requisitos não funcionais de Conformidade relacionada à confiabilidade. 
RI00 – Requisitos não funcionais de Inteligibilidade. 
RAPR00 – Requisitos não funcionais de Apreensibilidade. 
ROPE00 – Requisitos não funcionais de Operacionalidade. 
RATR00 - Requisitos não funcionais de Atratividade. 
RCRUS00 - Requisitos não funcionais de Conformidade relacionada à usabilidade. 
RCRT00 - Requisitos não funcionais de Comportamento em relação ao tempo. 
RUR00 - Requisitos não funcionais de Utilização de recursos. 
RCRE00 - Requisitos não funcionais de Conformidade relacionada à eficiência. 
RANA00 - Requisitos não funcionais de Analisabilidade. 
RMOD00 - Requisitos não funcionais de Modificabilidade. 
REST00 - Requisitos não funcionais de Estabilidade. 
RTES00 - Requisitos não funcionais de Testabilidade. 
RCRM00 - Requisitos não funcionais de Conformidade relacionada à manutenibilidade. 
RAD00 - Requisitos não funcionais de Adaptabilidade. 
RCI00 - Requisitos não funcionais de Capacidade para ser instalado. 
RCS00 - Requisitos não funcionais de Capacidade para substituir. 
RCOE00 - Requisitos não funcionais de Coexistência. 
RCRP00 – Requisitos não funcionais de Conformidade relacionada à portabilidade. 
 
 
 
◦ Termos – definições 
 
 
 
 
◦ Descrição das funcionalidades do Modelo de Especificação de requisitos 
A seguir são apresentados os campos do Modelo de Especificação de Requisitos utilizado nesta 
documentação. Os campos apresentados nos requisitos do cliente são os mesmos especificados nos 
requisitos funcionais e não-funcionais, a diferença está no fato do cliente ser responsável por 
preenchê-lo. 
A seguir, é descrito definições e importâncias dos campos do modelo de requisitos. 
ID: Cada requisito deve possuir um identificador único para atender o quesito de rastreabilidade, 
pelo qual facilita o referenciamento de cada requisito, ou seja, sua localização. Item importante para 
organização. Também tem o objetivo de identificar o tipo do requisito, exemplo: caso o código 
inicia com RFUN seguido por uma numeração sequência, se trata de um requisito funcional; caso o 
código inicia por RIEX seguido por uma numeração sequencial, se trata de um requisito não-
funcional de Interface Externa. 
Nome: Curta descrição do requisito. Sua importância está na identificação de cada requisito 
(Rastreabilidade). 
Importância: É definida assinalando uma das opções a seguir: 
• Essencial: requisito imprescindível, sem o qual o sistema não entra em 
funcionamento ou não possui um mínimo das características desejáveis; 
• Desejável: requisito sem o qual o sistema entra em funcionamento, porém de forma 
não satisfatória; 
• Opcional: requisitos opcionais, sem os quais o sistema entra em funcionamento de 
forma satisfatória; 
Complexidade: identifica o requisito por grau de complexidade. Importante para controle do 
analista, pois será um requisito que pode levar mais tempo de conclusão, necessitando assim maior 
atenção, por exemplo, para que os prazos não sejam ultrapassados e possuir preferência em 
reuniões. A mensuração é feita na escolha de uma das opções: Difícil, Médio e Fácil. 
Prioridade: identificar o requisito por prioridade, auxilia o Stakeholders identificar os requisitos 
que devem ter preferências na sua elaboração, por exemplo, dando exclusividade ou prioridade em 
reuniões. Auxilia também os projetistas escolherem a arquitetura do sistema de acordo com os 
requisitos de maior prioridade. Além de poder definir quais requisitos devem ser implementados 
primeiro por necessidade ou pressão do cliente. A mensuração é feita na escolha de uma das opções: 
Alto, Médio e Baixo. É importante identificar um prazo limite para conclusão do requisito, 
principalmente para os requisitos de maior prioridade, ou seja, que possui urgência de serem 
entregues, auxiliando o controle do analista. 
Origem do requisito: facilita a rastreabilidade da origem do requisito, por exemplo, importante 
para tirar dúvidas ou complementações em relação ao requisito, mesmo após o fim do projeto. 
Descrição: mostra uma longa e detalhada especificação do requisito. Campo mais importante, pois 
através de suas especificações que o produto de software será construído. 
Justificativa: importante para justificar a utilização deste requisito, para verificar se faz parte do 
escopo do programa. 
Critério de verificação: Um requisito é verificável se e somente se, existir algum processo de 
custo-efetivo com o qual a pessoa ou máquina pode checar que o produto de software encontra o 
requisito. Em geral qualquer requisito ambíguo não é verificável. Importante para definir como 
garantir a qualidadedo requisito. 
Documentos relacionados: tem a função de indicar, como localizar e quais documentos que 
serviram de base pra sua elaboração, tais como normas de desenvolvimento de software, leis que 
justifiquem decisões de projeto, etc. 
Histórico: Os requisitos podem ser orientados por sua data de criação, suas mudanças ou exclusão, 
descrevendo também sucintamente o que foi alterado ou porque o requisito foi rejeitado. Esta 
 
 
funcionalidade é útil, pois reduz os desgastes provocados por discussões muitas vezes sem 
fundamento durante o processo de desenvolvimento de software. 
 
 
 
1. Elicitação de Requisitos 
Para identificar as necessidades, a elicitação terá a seguinte programação: 
14/03/2018 análise de sistema de psicologia psicomanager 
14/03/2018 análise de sistema de psicologia Iclinic 
19/03/2018 Entrevista com Psicólogo 
12/04/2018 Validação com lista de requisitos especificados 
10/03/2018 Brainstorming 
 
 
2. Requisitos do Cliente (RCLI) 
As necessidades e expectativas, restrições do cliente são traduzidas em neste tópico. 
ID: RFA-01 
Nome : Manter Paciente 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Brainstorming com a equipe, Entrevista. 
Descrição: Este Permite o cadastramento, atualização e inativação lógica dos Pacientes no sistema. 
Justificativa: É Importante ter o cadastramento de pacientes para gerenciar os agendamentos. 
Critério de verificação: Usuário cadastrar, alterar e inativa o cadastro de um paciente. 
Documentos relacionados: Brainstorming com a equipe, Entrevista. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RFA-02 
Nome : Agendar Sessão. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( x ) Médio ( ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Análise de Sistema Iclinic, Entrevista. 
Descrição: Este permite fazer o agendamento das consultas dos pacientes. 
Justificativa: É Importante ter controle sob horários marcados. 
Critério de verificação: Usuário agenda uma sessão para um paciente cadastrado. 
Documentos relacionados: Análise de Sistema Iclinic, Entrevista. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
ID: RFA-03 
Nome : Desmarcar Sessão. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( x ) Médio ( ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Análise de Sistema Iclinic, Entrevista. 
Descrição: Este permite desmarcar consultas já agendadas. 
Justificativa: É Importante ter controle sob horários marcados. 
Critério de verificação: Usuário cancela o agendamento de uma sessão para um paciente cadastrado 
e com horário agendado. 
Documentos relacionados: Análise de Sistema Iclinic, Entrevista. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
1. Casos de Uso 
1.1. Atores 
Cliente – pessoas que cobraram pizza pelo site. 
Administrador – pessoas que são funcionários da pizzaria 
 
1.2. Lista de casos de uso 
Lista de todos os casos de uso do software. Identificados em entrevista. 
 
Ref. Descrição Atores 
CSU01 Manter Paciente Atendente e 
Psicólogo 
CSU02 Agendar Sessão Atendente e 
Psicólogo 
CSU03 Desmarcar Sessão Atendente e 
Psicólogo 
CSU 04 Verificar Sessões do Paciente Atendente e 
Psicólogo 
CSU05 Verificar Sessões por dia Atendente e 
Psicólogo 
CSU06 Agendar Encaixe de Emergência Atendente e 
Psicólogo 
CSU07 Controlar Fila de Espera Atendente e 
Psicólogo 
CSU08 Enviar Aviso de Consulta Atendente e 
Psicólogo 
CSU09 Bloquear Agenda Psicólogo 
 
 
CSU10 Manter Usuário Administrador 
CSU11 Logar no Sistema Administrador, 
Atendente e 
Psicólogo 
CSU12 Remarcar Sessão Atendente e 
Psicólogo 
CSU13 Manter Convênio Atendente e 
Psicólogo 
 
1.3. Descrição de Casos de Uso 
Identificar e descrever cada caso de uso listado anteriormente. 
Os casos de uso deverão ser descritos preferencialmente no formato de alto nível, mas dependendo 
da sua importância ou da sua complexidade eles poderão ser descritos no formato essencial 
expandido. Casos de uso essenciais são aqueles que não referenciam aspectos de soluções 
tecnológicas adotadas ao contrário dos casos de uso reais. 
Para descrever casos de uso deve-se considerar os seguintes elementos: 
• Fluxo principal - descreve uma seqüência de ações que serão executadas 
considerando que nada de errado acontecerá durante a execução das ações; 
• Fluxos Alternativos – descrevem o que acontece quando o ator (papel que interage 
com o sistema) faz uma escolha alternativa, diferente da descrita no fluxo principal, 
para alcançar seu objetivo. Fluxos alternativos podem descrever escolhas exclusivas 
entre si; 
• Fluxos de Exceção – correspondem à descrição das situações de exceção, quando 
algo inesperado ocorre na interação com o sistema; 
• Pré-condição – define que hipóteses são assumidas como verdadeiras para que o 
cenário tenha início. Deve ser usada em casos de uso cuja realização não faz sentido 
em qualquer momento, mas somente quando o sistema está em um determinado 
estado com certas propriedades; 
• Pós-condição – estado que o sistema alcança após o caso de uso ter sido realizado. 
 
 
Caso de Uso CSU01: Manter Paciente 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Atendente: deseja ter os dados mais atualizados do paciente para poder entrar em contato 
ou para fazer cobranças. 
-Psicólogo: deseja ter os dados mais atualizados do paciente para ajudar nas sessões e no 
tratamento do mesmo. 
 
 
-Paciente: deseja poder fazer agendamentos de sessões e ter mais facilidade no pagamento 
das mesmas. 
-Clínica: deseja ter os dados registrados do paciente e quer garantir a integridade do 
mesmo. 
Pré-Condições: Estar logado no sistema 
Garantia de Sucesso: Nenhuma. 
Cenário de Sucesso Principal: 
 
1. O Ator solicita cadastrar paciente. 
2. Sistema exibe a tela de cadastrar paciente, com a lista dos clientes existentes e permite o 
Ator Alterar, inutilizar e Incluir um paciente. 
3. O Ator fecha tela. 
 
Extensões: 
 
2a. Ator clica no botão Novo. 
1. Sistema disponibiliza os campos para inclusão de um paciente. 
2. Ator preenche os campos e clica no botão Salvar. 
3. Sistema confirma a gravação dos dados, atualiza a lista de pacientes e retorna ao passo 2. 
3a. Sistema verifica que campos obrigatórios não estão preenchidos. 
1.O sistema informa que os Campos obrigatórios não estão preenchidos e 
não permite salvar. 
2.Ator volta para o preenchimento dos campos. 
 
2b. Ator clica no botão alterar Cliente 
1. Ator clica no botão Alterar da linha do paciente que deseja efetuar as alterações. 
2. Sistema disponibiliza os campos para alteração do paciente. 
3. Ator altera nos campos desejados e clica no botão Salvar. 
4. Sistema confirma a gravação dos dados, atualiza a lista de pacientes e retorna ao passo 2. 
4a. Sistema verifica que campos obrigatórios não estão preenchidos. 
1.O sistema informa que os Campos obrigatórios não estão preenchidos e 
não permite salvar. 
2.Ator volta para o preenchimento dos campos. 
2c. Ator clica no botão inutilizar Cliente 
1. Ator clica no botão Inutilizar da linha do paciente que deseja efetuar a inutilização 
2. Sistema solicita a confirmação da Inutilização. 
3. Ator confirma a inutilização. 
4. Sistema exclui o paciente, atualiza a lista de pacientes e retorna ao passo 2. 
 
 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
2a e 2b:Oscampos que o sistema deve ter como obrigatório: Nome, Telefone(s), Sexo, E-
mail, CPF, RG, Endereço e Data de nascimento. Os outros campos: Convênio, Valor padrão 
por sessão, Observações, Sexo, Grau de Escolaridade, Profissão, 
Responsável, N° Cartão convênio, Data de Expiração do Cartão do convênio. 
Frequência de Ocorrência: Não é muito frequente. 
Diversos: 
 
 
Caso de Uso CSU02: Agendar Sessão 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Atendente: deseja organizar as sessões dos pacientes para dar um melhor atendimento ao 
paciente. 
-Psicólogo: deseja saber quais são as sessões que ele tem marcada para um determinado 
período de tempo. 
-Paciente: deseja poder fazer agendamentos de sessões e ter mais facilidade no pagamento 
das mesmas. 
-Clínica: deseja ter o controle das sessões que os psicólogos estão fazendo com os 
pacientes. 
Pré-Condições: Ter pelo menos um paciente cadastrado no sistema. Além disso deve ter 
liberado na data e hora que a sessão quer ser marcada. Ator deve estar logado no sistema na 
tela de sessões. 
Garantia de Sucesso: O sistema deve informar ao usuário que a sessão foi marcada com 
sucesso. 
Cenário de Sucesso Principal: 
 
1. Ator clica no botão Agendar nova Sessão. 
2. Sistema deve mostrar uma tela com os campos a ser informados para agenda nova 
sessão. 
3. Ator deve fornecer os campos pedidos. 
4. Ator clica no botão salvar. 
5. Sistema verifica informações estão de acordo e salva. 
 
 
 
Extensões: 
 
5a. Sistema verifica que a data e horário está indisponível. 
1. Sistema informa para o usuário que horário está indisponível e pede para fornecer uma 
nova data e horário para poder salvar sessão. 
2. Ator preenche nova data e horário e clica em salvar. 
3. Sistema volta ao passo 5. 
 
5b. Sistema verifica que não foi informado o paciente. 
1. Sistema informa para o usuário que precisa informar o paciente que deseja marcar a 
sessão. 
2. Ator informar o paciente da sessão. 
3. Sistema volta ao passo 5. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
5a e 5b:.Os dados que precisarão para este caso de uso são: Uma data e horário para 
sessão; O paciente da sessão; Se a sessão e de retorno ou normal; Observação da sessão. 
Frequência de Ocorrência: Muito frequente. 
Diversos: 
 
Caso de Uso CSU03: Desmarcar Sessão 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Atendente / Psicólogo: deseja realizar o controle das sessões, atendendo a imprevistos no 
ambiente clínico, bem como manter o paciente informado. 
-Paciente: deseja possuir como alternativa o cancelamento da sessão para atender 
imprevistos que podem ocorrer em seu dia-a-dia. 
Pré-Condições: A sessão deve estar na Agenda como “Agendada”. 
Garantia de Sucesso: O horário na agenda deve ser liberado. 
Cenário de Sucesso Principal: 
 
 
 
1. Ator seleciona a sessão para ser desmarcada. 
2. Sistema pede a confirmação para desmarcar a sessão. 
3. Ator confirma a escolha. 
4. Sistema solicita uma justificativa para o cancelamento e disponibiliza o preenchimento 
de observações a respeito do cancelamento. 
5. Ator seleciona a justificativa mais apropriada e preenche a observação caso necessário 
6. Sistema libera o horário na agenda para uma nova sessão. 
7. Sistema informa ao paciente o cancelamento da sessão. 
8. Sistema informa ao sucesso da operação. 
 
Extensões: 
 
6a. Sistema não canais validos para informar ao paciente o cancelamento da sessão. 
1. Sistema informa para o Ator que não foi possível informar o paciente sobre o 
cancelamento. 
2. Ator informar o paciente da sessão. 
3. Sistema continua com o passo 7. 
 
Requisitos Especiais: Caso o ator selecione a justificativa “Outros” o campo de 
observação deve ser OBRIGATORIAMENTE preenchido. 
Lista de Variantes Tecnológicas e de Dados: 
4. As justificativas são previamente cadastradas e a observação não possui preenchimento 
obrigatório. 
 
Frequência de Ocorrência: Relativamente frequente. 
Diversos: 
 
 
Caso de Uso CSU04: Verificar Sessões do Paciente 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Atendente: deseja verificar todas as sessões agendadas para um determinado paciente. 
-Psicólogo: deseja verificar todas as sessões agendadas para um determinado paciente. 
 
 
-Paciente: deseja poder verificar todas as suas sessões agendadas. 
-Clínica: deseja ter os registros de todas as sessões agendadas por paciente. 
Pré-Condições: Estar logado no sistema 
Garantia de Sucesso: Sistema exibe as sessões marcadas do pacientes. 
Cenário de Sucesso Principal: 
 
1. O Ator seleciona um paciente. 
2. Solicita verificar sessões do paciente. 
3. Sistema exibe as sessões marcadas do paciente em formato de lista categorizada. 
 
Extensões: 
 
3a. Sistema verifica que não existe nenhuma sessão marcada para paciente. 
1. Sistema informa que não há nenhuma sessão marcada. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
Nenhum 
Frequência de Ocorrência: Muito frequente. 
Diversos: 
 
Caso de Uso CSU05: Verificar Sessões por dia 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Atendente: deseja verificar as consultas marcadas para um dia. 
-Psicólogo: deseja saber quais são as sessões que ele tem marcada para o dia. 
-Clínica: deseja ter o controle das sessões concluídas no dia. 
Pré-Condições: Ter marcações de pacientes na data. Ator deve estar logado no sistema 
na tela de sessões. 
 
 
Garantia de Sucesso: Nenhuma 
Cenário de Sucesso Principal: 
 
1. Ator clica no botão Verificar consultas por dia. 
2. Sistema deve mostrar uma tela com um calendário. 
3. Ator deve selecionar um dia do calendário. 
4. Sistema deve exibir as sessões marcadas para aquele dia. 
 
Extensões: 
 
4a. Sistema verifica que não existe nenhuma sessão marcada para paciente. 
1. Sistema informa que não há nenhuma sessão marcada. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
Nenhum 
Frequência de Ocorrência: Muito frequente. 
Diversos: 
 
 
Caso de Uso CSU06: Agendar Encaixe de Emergência 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Paciente: deseja fazer um agendamento de consulta de emergência. 
-Atendente: deseja atender requisição do paciente. 
Pré-Condições: Estar logado no sistema e Paciente possuir cadastro no sistema. 
Garantia de Sucesso: O sistema deve informar ao usuário que o encaixe foi efetuado com 
sucesso. 
Cenário de Sucesso Principal: 
 
1. O Ator solicita encaixe de emergência. 
 
 
2. Ator deve fornecer o campo pedido. 
3. Ator clica no botão agendar. 
4. Sistema verifica se o cadastro do paciente existe e coloca o paciente em questão em 
primeiro lugar da lista de espera. 
5. O Ator fecha tela. 
 
Extensões: 
 
4a. Ator clica no botão Agendamento de horários e na tela de agendamento clica no botão 
Agendamento de Emergência. 
1. Sistema pede o CPF do paciente. 
2. Ator preenche o campo de CPF e clica no botão agendar. 
3. Sistema coloca paciente na primeira posição da lista de espera. 
3a. Sistema verifica que campos obrigatórios não estão preenchidos. 
1.O sistema informa que os campos obrigatórios não estão preenchidos e 
não permite agendar. 
2.Ator volta para o preenchimento dos campos. 
 3b.Sistema verifica que o cadastro do pacientenão existe. 
 1.O sistema informa que o cadastro não existe e não permite agendar. 
 2.Ator volta para o preenchimento dos campos. 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
4a: O campo que o sistema deve ter como obrigatório: CPF. 
Frequência de Ocorrência: Não é muito frequente. 
Diversos: 
 
 
Caso de Uso CSU07: Controlar Fila de Espera 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Paciente: deseja fazer um agendamento em um determinado dia mas todos os horários no 
dia em questão estão ocupados. 
-Atendente: deseja organizar as sessões dos pacientes para dar um melhor atendimento ao 
paciente. 
 
 
-Atendente: deseja possuir uma fila de espera para que não fiquem horários vagos. 
Pré-Condições: Estar logado no sistema e Paciente possuir cadastro no sistema. 
Garantia de Sucesso: O sistema deve informar ao usuário que paciente foi colocado na 
lista de espera. 
Cenário de Sucesso Principal: 
 
1. O Ator solicita adicionar à lista de espera. 
2. Ator deve fornecer o campo pedido. 
3. Ator clica no botão adicionar. 
4. Sistema verifica se o cadastro do paciente existe e coloca o paciente em questão na lista 
de espera. 
5. O Ator fecha tela. 
 
Extensões: 
 
4a. Ator clica no botão Agendamento de horários e na tela de agendamento clica no botão 
Lista de Espera, na tela da lista de espera o ator clica em Adicionar Paciente. 
1. Sistema pede o CPF do paciente. 
2. Ator preenche o campo de CPF e clica no botão adicionar. 
3. Sistema coloca paciente na lista de espera. 
3a. Sistema verifica que campos obrigatórios não estão preenchidos. 
1.O sistema informa que os campos obrigatórios não estão preenchidos e 
não permite adicionar. 
2.Ator volta para o preenchimento dos campos. 
 3b.Sistema verifica que o cadastro do paciente não existe. 
 1.O sistema informa que o cadastro não existe e não permite adicionar. 
 2.Ator volta para o preenchimento dos campos. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
4a:O campo que o sistema deve ter como obrigatório: CPF. 
Frequência de Ocorrência: Não é muito frequente. 
Diversos: 
 
 
Caso de Uso CSU08: Enviar Aviso de Consulta 
 
 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Subfunção 
Ator Principal: Paciente 
Interessados e Interesses: 
-Atendente: manter o paciente atualizado/informado do dia da consulta. 
-Psicólogo: deseja que o paciente não se esqueça do dia e hora da consulta para que não 
falte. 
-Paciente: deseja ser lembrado/alertado da proximidade do dia da consulta. 
-Clínica: deseja que o paciente esteja sempre ciente dos seus compromissos. 
Pré-condições: É ter o e-mail do paciente e uma sessão do paciente agendada. 
Garantia de Sucesso: Nenhuma. 
Cenário de Sucesso Principal: 
 
1. Sistema verifica todas sessões que faltam três dias para consulta e ainda não foram 
enviados. 
2. Sistema envia um e-mail alertando sobre a respectiva consulta de cada paciente. 
3. O paciente mantém-se informado e atualizado do dia da consulta. 
 
Extensões: 
 
2a. Paciente cadastrado com e-mail errado. 
1. Sistema informa como notificação para o usuário que um paciente está com email 
inválido. 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
2a e 2b: Foi utilizado nesse caso de uso as sessões agendas mais o email de contato do 
paciente. 
Frequência de Ocorrência: Muito frequente. 
Diversos: 
 
 
 
Caso de Uso CSU09: Bloquear Agenda 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do psicólogo 
Ator Principal: Psicólogo 
Interessados e Interesses: 
-Psicólogo: deseja desabilitar, dentro de sua agenda, horário que foram previamente 
disponibilizados por um determinado período de tempo. 
-Clínica: deseja desabilitar horários de diferentes psicólogos para, por exemplo, organizar 
reuniões com vários psicólogos. 
Pré-Condições: Possuir horário livre na agenda. 
Garantia de Sucesso: Nenhuma. 
Cenário de Sucesso Principal: 
 
1. O Psicólogo seleciona o horário a ser bloqueado. 
2. O sistema solicita confirmação da ação. 
3. O psicólogo confirma o bloqueio do horário. 
4. O sistema solicita o período em que o bloqueio estará ativo. 
5. O psicólogo informa o período de efetivação do bloqueio. 
6. O sistema conclui o bloqueio, indisponibiliza o horário para o agendamento de 
novas sessões e informa ao psicólogo o sucesso da operação. 
Extensões: 
 
2a: O sistema verifica que o horário que será bloqueado está agendado ou que há paciente 
na fila de espera para o horário. 
1. O sistema informa ao psicólogo que não e possível bloquear o horário com a 
mensagem “Horário está agendado” 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
4. O psicólogo poderá selecionar um horário definido ou selecionar o bloqueio permanente 
do horário. 
Frequência de Ocorrência: Não é muito frequente. 
Diversos: 
 
 
 
 
Caso de Uso CSU10: Manter Usuário 
Escopo: Controle de Configuração da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Administrador 
Interessados e Interesses: 
-Atendente: deseja ter um usuário no sistema. 
-Psicólogo: deseja ter um usuário no sistema. 
-Clínica: deseja ter os dados registrados do usuários e quer garantir a integridade do 
mesmo. 
Pré-Condições: Estar logado no Sistema. 
Garantia de Sucesso: Nenhuma. 
Cenário de Sucesso Principal: 
 
1. O Ator solicita cadastrar usuário . 
2. Sistema exibe a tela de cadastrar usuário , com a lista dos usuários existentes e permite o 
Ator Alterar, Inutilizar e Incluir um usuário . 
3. O Ator fecha tela. 
 
Extensões: 
 
2a. Ator clica no botão Novo. 
1. Sistema disponibiliza os campos para inclusão de um usuário. 
2. Ator preenche os campos e clica no botão Salvar. 
3. Sistema confirma a gravação dos dados, atualiza a lista de usuários e retorna ao passo 2. 
3a. Sistema verifica que campos obrigatórios não estão preenchidos. 
1.O sistema informa que os Campos obrigatórios não estão preenchidos e 
não permite salvar. 
2.Ator volta para o preenchimento dos campos. 
 
2b. Ator clica no botão alterar Usuário. 
1. Ator clica no botão Alterar da linha do usuário que deseja efetuar as alterações. 
2. Sistema disponibiliza os campos para alteração do usuário. 
3. Ator altera nos campos desejados e clica no botão Salvar. 
4. Sistema confirma a gravação dos dados, atualiza a lista de usuários e retorna ao passo 2. 
4a. Sistema verifica que campos obrigatórios não estão preenchidos. 
1.O sistema informa que os Campos obrigatórios não estão preenchidos e 
não permite salvar. 
 
 
2.Ator volta para o preenchimento dos campos. 
2c. Ator clica no botão inutilizar Usuário. 
1. Ator clica no botão Inutilizar da linha do usuário que deseja efetuar a inutilização 
2. Sistema solicita a confirmação da Inutilização. 
3. Ator confirma a inutilização. 
4. Sistema exclui o paciente, atualiza a lista de usuários e retorna ao passo 2. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
2a e 2b:Os campos que o sistema deve ter como obrigatório: Nome, Telefone(s), E-mail, 
CPF, RG, Endereço, Tipo Empregado, Data de nascimento, e Senha. Os outros campos: 
Observações, Sexo, Grau de Escolaridade, Salário, Nome do Pai, Nome da Mãe, Data do 
Início da Contratação, .Data do Final da Contratação. 
. 
Frequência de Ocorrência: Não é muito frequente. 
Diversos: 
 
 
Caso de Uso CSU11: Logar no Sistema 
Escopo: Controle de Configuração da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Administrador, Atendente e Psicólogo 
Interessadose Interesses: 
-Atendente: deseja entrar no sistema. 
-Psicólogo: deseja entrar no sistema. 
-Clínica: deseja manter restrito que pode mexer no seu sistema. 
Pré-Condições: Nenhuma 
Garantia de Sucesso: O Usuário estará logado no sistema 
Cenário de Sucesso Principal: 
 
1. O Ator solicita entrar no sistema . 
2. Sistema exibe a tela com o campo nome e senha. 
3. Ator preenche os campos. 
4. O sistema verifica que existe senha com esse usuário e loga o usuário ao sistema. 
 
 
 
Extensões: 
 
4a. Sistema verifica que não existe o usuário 
1. Sistema informa que o usuário não existe. 
 
4b. Sistema verifica que o usuário existe mas que a senha está incorreta 
1. Sistema informa que a senha está incorreta. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
2a e 2b:Os campos que o sistema deve ter como obrigatório:Nome e Senha. 
. 
Frequência de Ocorrência: É muito frequente. 
Diversos: 
 
 
Caso de Uso CSU12: Remarcar Sessão 
Escopo: Controle do Agendamento da Aplicação de Gestão de Clínica Psicologia 
Nível: Objetivo do usuário 
Ator Principal: Atendente e Psicólogo 
Interessados e Interesses: 
-Atendente: deseja remarca as sessões dos pacientes para dar um melhor atendimento ao 
paciente. 
-Psicólogo: deseja remarca as sessões dos pacientes para dar um melhor atendimento ao 
paciente. 
-Paciente: deseja poder mudar o dia das sessões. 
-Clínica: deseja ter o controle das sessões que os psicólogos estão fazendo com os 
pacientes. 
Pré-Condições: Ter pelo menos um paciente cadastrados no sistema. Além disso deve ter 
liberado na data e hora que a sessão quer ser marcada. Ator deve estar logado no sistema na 
tela de sessões. Além disso deve existir já uma sessão marcada para o paciente. 
Garantia de Sucesso: O sistema deve informar ao usuário que a sessão foi remarcada com 
sucesso. 
Cenário de Sucesso Principal: 
 
 
 
1. Ator clica em uma sessão é solicita remarcar a mesma. 
2. Sistema deve mostrar uma tela com os campos para preencher a nova data e hora. 
3. Ator deve fornecer a nova data e hora. 
4. Ator clica no botão salvar. 
5. Sistema verifica informações estão de acordo e salva. 
 
Extensões: 
 
5a. Sistema verifica que a data e horário está indisponível. 
1. Sistema informa para o usuário que horário está indisponível e pede para fornecer uma 
nova data e horário para poder salvar sessão. 
2. Ator preenche nova data e horário e clica em salvar. 
3. Sistema volta ao passo 5. 
 
Requisitos Especiais: Nenhum 
Lista de Variantes Tecnológicas e de Dados: 
5a e 5b:.Os dados que precisarão para este caso de uso são: Uma data e horário para 
sessão; O paciente da sessão; 
Frequência de Ocorrência: Não é muito frequente. 
Diversos: 
 
 
 
• Requisitos e restrições funcionais (RFUN) 
 
Esta lista representa as funções que o software deve prover. 
 
ID: RFA-04 
Nome : Verificar Sessões do Paciente. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Análise de Sistema Iclinic. 
Descrição: Este permite verificar todas as sessões agendadas para o paciente solicitado. 
Justificativa: É Importante ter controle sob horários marcados. 
Critério de verificação: Usuário pede ao sistema todos os horários agendados de um paciente e o 
sistema deve retornar tais horários. 
Documentos relacionados: Análise de Sistema Iclinic. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
ID: RFA-05 
Nome : Verificar Sessões do dia. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Análise de Sistema Iclinic. 
Descrição: Este permite verificar as sessões agendadas do dia. 
Justificativa: É Importante ter controle sob horários marcados. 
Critério de verificação: Usuário pede ao sistema todos os horários agendados no dia e o sistema 
deve retornar tais horários. 
Documentos relacionados: Análise de Sistema Iclinic. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
ID: RFA-06 
Nome : Agendar Encaixe de Emergência. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Análise de Sistema Iclinic. 
Descrição: Este permite criar uma sessão de emergência que tem prioridade de atendimento. 
Justificativa: É Importante ter controle sob horários marcados. 
 
 
Critério de verificação: Usuário pede ao sistema um encaixe de emergência e o sistema deve 
colocar o paciente em questão como primeiro na lista de espera. 
Documentos relacionados: Análise de Sistema Iclinic. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
ID: RFA-07 
Nome : Fila de Espera. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Análise de Sistema Iclinic. 
Descrição: Este é Responsável por fazer o controle da fila de espera. 
Justificativa: É Importante ter controle sob horários marcados. 
Critério de verificação: Usuário deve verificar a integridade da fila de espera. 
Documentos relacionados: Análise de Sistema Iclinic. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
ID: RFA-08 
Nome : Enviar Aviso de Consulta. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Brainstorming com a equipe 
Descrição: Este permite que o paciente seja notificado da sua consulta via e-mail. 
Justificativa: É Importante lembrar o paciente de horários marcados. 
Critério de verificação: Cliente deve verificar se recebeu e-mail referente a consultas marcadas. 
Documentos relacionados: Brainstorming com a equipe 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
ID: RFA-09 
Nome : Bloquear Agenda. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Complexidade: Difícil ( ) Médio ( x ) Fácil ( ) 
Prioridade: Alto ( ) Médio ( x ) Baixo ( ) 
Dada limite para conclusão: 16/ 06/ 2018 
Origem do Requisito: Brainstorming com a equipe 
Descrição: Este permite que o administrador do sistema bloqueia o agendamento de consultas em 
certos dias e horários. 
Justificativa: É Importante para não serem agendadas consultas em horários fora do período de 
atendimento. 
 
 
Critério de verificação: Deve ser verificado se o horários bloqueado realmente não está aceitando 
agendamentos. 
Documentos relacionados: Brainstorming com a equipe 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
• Requisitos e restrições não funcionais (RNF) 
Caso necessário, pode ser incluído novos tipos de requisitos não funcionais. 
 
ID: RMT-01 
Nome : Maturidade. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O software deve passar pelos testes especificados antes de distribuído. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RTOL-01 
Nome : Tolerância a Falhas. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O software deve possuir tratamento de exceção.Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RREC-01 
Nome : Recuperabilidade. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: Durante a operação, o sistema deve armazenar as informações pré-operação para caso 
haja falhas. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RI-01 
Nome : Inteligibilidade. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
 
 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: Todos os elementos devem possuir orientação em relação à sua função. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RAPR-01 
Nome : Apreensibilidade. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: Toda tela de cadastro tem um help explicativo. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
 
 
 
 
 
 
 
ID: ROPE-01 
Nome : Operações Necessárias. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O sistema deve realizar as funções em, no máximo sete operações. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: ROPE-02 
Nome : Andamento de operações. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O sistema deve informar o andamento das operações. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
ID: ROPE-03 
Nome : Teste de consistência. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O sistema deve ter testes de consistência. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: ROPE-04 
Nome : Entrada de Dados Otimizada. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O sistema sempre que possível deve ter entrada de dados otimizada. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: ROPE-05 
Nome : Padronização de Dados Otimizada. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O sistema sempre que possível deve ter forma padronizada de entrada de dados. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RATR-01 
Nome : Manipulação Agradável. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O sistema deve ser agradável de manipular. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
 
 
 
 
 
 
 
 
ID: RATR-02 
Nome : Cores Agradáveis. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( ) Baixo ( ) Muito Baixo ( x ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O sistema deve ter cores que não forcem a vista do usuário. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RCRUS-01 
Nome : Função de Ajuda. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: A tecla F1 representa uma função de ajuda. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RCRT-01 
Nome : Tempo de Resposta. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O tempo de respostas de consulta não deve ultrapassar 5 segundos. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
 
 
ID: RUR-01 
Nome : Requisitos de Sistema. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( ) Baixo ( x ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
 
 
Descrição: O sistema deve precisar de um servidor que no mínimo tenha 4 gigas de memória, um 
processador I3 da quinta geração e um espaço de 500 gigas de HD. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RCRE-01 
Nome : Limite de Tempo de Resposta. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O tempo de reposta não ultrapassa 2 segundos a 5 segundos. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RANA-01 
Nome : Organização de Software. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O código do software de estar bem organizado. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
 
ID: RANA-02 
Nome : Comentários de Código. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O código do software de ter comentários esclarecedores. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RMOD-01 
Nome : Identação de Código. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
 
 
Descrição: O código de ter uma boa identação. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RMOD-02 
Nome : Linguagem de Desenvolvimento. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( ) Baixo ( x ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O software deve ser desenvolvido sem MVC. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
 
 
ID: RMOD-03 
Nome : Localização de Funções. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( ) Baixo ( x ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: Localização de partes de código que se referem às funções a serem alteradas ou 
atualizadas. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: REST-01 
Nome : Controle de Versionamento. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( ) Baixo ( x ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O software deve ter um controle de versionamento. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RTES-01 
Nome : Especificação de Requisitos. 
Importância: Essencial( x ) Desejável( ) Opcional() 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
 
 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O software deve ter a especificação dos requisitos corretas. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
 
ID: RAD-01 
Nome : Plataformas do Sistema. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( x ) Alto ( ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O sistema deve ser suportado em plataforma mobile e web. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RCI-01 
Nome : Instalação e Desinstalação. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Brainstorming com a equipe. 
Descrição: O software deve ter Instalação e desinstalação automatizadas. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RCI-02 
Nome : Ambientes de Instalação. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( x ) Médio ( ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O software deve se permitir instalar tanto ambiente Linux com Windows. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
 
 
ID: RCS-01 
Nome : Migração de Sistema. 
Importância: Essencial( ) Desejável( x ) Opcional( ) 
 
 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O software deve possibilidade de coletar arquivos txt com padrão de dados formatado 
para facilitar a migração de sistemas. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
 
ID: RCOE-01 
Nome : Manipulação do Sistema. 
Importância: Essencial( x ) Desejável( ) Opcional( ) 
Prioridade: Muito Alto ( ) Alto ( ) Médio ( x ) Baixo ( ) Muito Baixo ( ) 
Origem do Requisito: Análise de Documento. 
Descrição: O software pode ser manipulado juntamente com outros softwares abertos. 
Histórico: 
• Data de criação: 12/ 04/ 2018. 
 
• Requisitos Futuros (RFUT) 
Os requisitos que poderão ser especificados em uma nova versão do produto. 
 
RFUT 01 - Programa de fidelização de cliente, indicação, desconto. 
 
RFUT 02 - Venda de pizza, com pagamento através do site. requisito de importância alto. 
• Rastreabilidade 
Horizontal: 
 
 RFA-
01 
RFA-
02 
RFA-
03 
RFA-
04 
RFA-
05 
RFA-
06 
RFA-
07 
RFA-
08 
RFA-
09 
RFA-
01 
\ X X X X 
RFA-
02 
X \ X X X X X 
RFA-
03 
 X \ 
RFA-
04 
X \ 
RFA-
05 
 X \ 
RFA-
06 
X \ X 
RFA-
07 
X X X \ 
RFA-
08 
 X \ 
RFA-
09 
 X \ 
 
 
 
Vertical: 
 CSU01 CSU02 CSU03 CSU04 CSU05 CSU06 CSU07 CSU08 CSU09 CSU10 CSU11 CSU1
2 
RFA-
01 
X X X 
RFA-
02 
 X X 
RFA-
03 
 X X 
RFA-
04 
 X 
RFA-
05 
 X 
RFA-
06 
 X 
RFA-
07 
 X 
RFA-
08 
 X 
RFA-
09 
 X 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
• Aprovação formal 
 
 
Versão baseline: 
Goiânia, __/__/__ 
De acordo, 
 
_________________________ _________________________ 
 
 
 
 
 
 Gerente de Desenvolvimento Cliente 
 
 
 
 
 
 
 
Anexos 
 
01 – Gravação de entrevista, elicitação de requisitos interação 1 
02 – Diagrama de caso de uso Cliente UC-01 
03 – Diagrama de caso de uso Administrador UC-02 
 
 
 
 
 
 
4. Documento de Arquitetura (IEEE 1471) 
 
 
Data Descrição Responsável 
01/06/2018 Definição de documento 
de arquitetura 
Guilherme Neves e Flávio 
Amaral 
 
Índice 
Introdução .......................................................................................................................................... 41 
Steakholders e Suas Preocupações ..................................................................................................... 42 
Documentação Suplementar .............................................................................................................. 42 
Requisitos de Confiabilidade: ........................................................................................................ 42 
Requisitos de Usabilidade: ............................................................................................................. 43 
Requisitos de Eficiência: ................................................................................................................ 44 
Requisitos de Manutenibilidade: .................................................................................................... 44 
Requisitos de Portabilidade:........................................................................................................... 45 
Visão Lógica ...................................................................................................................................... 45 
Visão Desenvolvimento ..................................................................................................................... 48 
 
 
Introdução 
Escopo 
 Este documento tem a prioridade de documentar a arquitetura do projeto de software de 
gerenciamento clínico de psicologia. Este pretende documentar a arquitetura na visão logica e de 
desenvolvimento. Sendo que na visão lógica o modelo conceitual e a visão de desenvolvimento a 
organização de como o software será desenvolvido. 
 
Estrutura do Documento 
• Steakholders e suas preocupações – Indentificação dos Steakholders e suas preocupações. 
• Documentação suplementar – Requisitos não funcionais atendidos pela arquitetura. 
• Visão lógica – A visão conceitual do sistema. 
• Visão de Desenvolvimento – É a organização do desenvolvimento do sistema. 
• Correlação das visões – Onde será mostrado as ligações entre as visões. 
 
Glossário 
RMT00 – Requisitos não funcionais de Maturidade. 
RTOL00 – Requisitos não funcionais de Tolerância a Falhas. 
RREC00 – Requisitos não funcionais de Recuperabilidade. 
RCRC00 – Requisitos não funcionais de Conformidade relacionada à confiabilidade. 
RI00 – Requisitos não funcionais de Inteligibilidade. 
 
 
RAPR00 – Requisitos não funcionais de Apreensibilidade. 
ROPE00 – Requisitos não funcionais de Operacionalidade. 
RATR00 - Requisitos não funcionais de Atratividade. 
RCRUS00 - Requisitos não funcionais de Conformidade relacionada à usabilidade. 
RCRT00 - Requisitos não funcionais de Comportamento em relação ao tempo. 
RUR00 - Requisitos não funcionais de Utilização de recursos. 
RCRE00 - Requisitos não funcionais de Conformidade relacionada à eficiência. 
RANA00 - Requisitos não funcionais de Analisabilidade. 
RMOD00 - Requisitos não funcionais de Modificabilidade. 
REST00 - Requisitos não funcionais de Estabilidade. 
RTES00 - Requisitos não funcionais de Testabilidade. 
RCRM00 - Requisitos não funcionais de Conformidade relacionada à manutenibilidade. 
RAD00 - Requisitos não funcionais de Adaptabilidade. 
RCI00 - Requisitos não funcionais de Capacidade para ser instalado. 
RCS00 - Requisitos não funcionais de Capacidade para substituir. 
RCOE00 - Requisitos não funcionais de Coexistência. 
RCRP00 – Requisitos não funcionais de Conformidade relacionada à portabilidade. 
 
Steakholders e Suas Preocupações 
 
• Psicólogo: A preocupação deste Steakholder é no controle das sessões agendadas. 
Querendo ter um maior controle sobre os agendamentos, permitindo o mesmo 
especificar os horários e os dias que não terá agendamento. Além disso ele se preocupa 
em verificar a quantidade de sessões que terá no dia. 
• Secretária: Esta tem a preocupação de organizar a agenda das sessões do psicólogo 
querendo ter uma facilidadede visualização sobre as sessões marcadas. 
• Paciente: Este tem a preocupação de poder marcar uma consulta e ser atendido no 
horário marcado. 
• Desenvolvedor e Gerente de Projeto: Este tem a preocupação de entregar um software 
que atende a parte de atendimento de uma clínica de psicologia. 
 
Documentação Suplementar 
Acurácia: 
 
Ref. Descrição Origem 
RRAC
01 
O sistema deve ter precisão de duas casas para 
parte financeira. 
Brainstorming com a 
equipe 
 
Interoperabilidade: 
 
Ref. Descrição Origem 
RFI0
1 
O Sistema deve se comunicar com o convênio do 
ipasgo. 
Brainstorming com a 
equipe 
 
Conformidade: 
 
 
 
Ref. Descrição Origem 
RFC
01 
O sistema deve guarda todos os dados das Sessões 
pelo menos por cinco anos. 
Brainstorming com a 
equipe 
 
Requisitos de Confiabilidade: 
 
Maturidade: 
 
Ref. Descrição Origem 
RMT
01 
O software deve passar pelos testes especificados 
antes de distribuído 
Brainstorming com a 
equipe 
 
Tolerância a falhas: 
 
Ref. Descrição Origem 
RTOL
01 
O software deve possuir tratamento de 
exceção 
Brainstorming com a 
equipe 
 
Recuperabilidade: 
 
Ref. Descrição Origem 
RREC
01 
Durante a operação, o sistema deve armazenar as 
informações pré-operação para caso haja falhas 
Brainstorming com 
a equipe 
 
Conformidade relacionada à confiabilidade: 
 
Ref. Descriçã
o 
Orige
m 
RCRC
01 
 
 
Requisitos de Usabilidade: 
 
Inteligibilidade: 
 
Ref
. 
Descrição Origem 
RI0
1 
Todos os elementos devem possuir orientação em 
relação à sua função 
Brainstorming com a 
equipe 
 
Apreensibilidade: 
 
Ref. Descrição Origem 
RAPR
01 
Toda tela de cadastro tem um help 
explicativo 
Brainstorming com a 
equipe 
 
Operacionalidade: 
 
 
 
Ref. Descrição Origem 
ROPE
01 
O sistema deve realizar as funções em, no máximo 
sete operações 
Brainstorming com a 
equipe 
ROPE
02 
O sistema deve informar o andamento das 
operações 
Análise de 
Documento 
ROPE
03 
O sistema deve ter testes de consistência Análise de 
Documento 
ROPE
04 
O sistema sempre que possível deve ter entrada de 
dados otimizada 
Análise de 
Documento 
ROPE
05 
O sistema sempre que possível deve ter forma 
padronizada de entrada de dados 
Análise de 
Documento 
 
Atratividade: 
 
Ref. Descrição Origem 
RATR
01 
O sistema deve ser agradável de manipular Análise de Documento 
RATR
02 
O sistema dever ter cores que não forcem a vista 
do usuário 
Brainstorming com a 
equipe 
 
Conformidade relacionada à usabilidade: 
Ref. Descrição Origem 
RCRUS
01 
A tecla F1 representa uma função de 
ajuda 
Análise de 
Documento 
 
Requisitos de Eficiência: 
 
Comportamento em relação ao tempo: 
 
Ref. Descrição Origem 
RCRT
01 
O tempo de respostas de consulta não deve 
ultrapassar 5 segundos. 
Brainstorming com a 
equipe 
 
Utilização de recursos: 
 
Ref. Descrição Origem 
RUR
01 
O sistema deve precisar de um servidor que no mínimo 
tenha 4 Giga de memória, um processador I3 da quinta 
geração e um espaço de 500 Giga de HD 
Brainstorming 
com a equipe 
 
Conformidade relacionada à eficiência: 
 
Ref. Descrição Origem 
RCRE
01 
O tempo de reposta não ultrapassa 2 segundos a 5 
segundos 
Análise de 
Documento 
 
Requisitos de Manutenibilidade: 
 
 
 
Analisabilidade: 
 
Ref. Descrição Origem 
RANA
01 
O código do software de estar bem organizado Análise de 
Documento 
RANA
02 
O código do software de ter comentários 
esclarecedores 
Análise de 
Documento 
 
Modificabilidade: 
 
Ref. Descrição Origem 
RMOD
01 
O código de ter uma boa edentação Análise de 
Documento 
RMOD
02 
O software deve ser desenvolvido sem MVC Brainstorming com 
a equipe 
RMOD
03 
Localização de partes de código que se referem às 
funções a serem alteradas ou atualizadas 
Análise de 
Documento 
 
Estabilidade: 
 
Ref. Descrição Origem 
REST
01 
O software deve ter um controle de 
versionamento 
Brainstorming com a 
equipe 
 
Testabilidade: 
 
Ref. Descrição Origem 
RTES
01 
O software deve ter a especificação dos 
requisitos corretas 
Brainstorming com a 
equipe 
 
Conformidade relacionada à manutenibilidade: 
 
Ref. Descriçã
o 
Orige
m 
RCRM
01 
 
 
Requisitos de Portabilidade: 
 
Adaptabilidade: 
 
Ref. Descrição Origem 
RAD
01 
O sistema deve ser suportado em plataforma 
mobile e web 
Brainstorming com a 
equipe 
 
Capacidade para ser instalado: 
 
Ref. Descrição Origem 
 
 
RCI
01 
O software deve ter Instalação e desinstalação 
automatizadas 
Análise de 
Documento 
RCI
02 
O software deve se permitir instalar tanto ambiente 
Linux com Windows 
Brainstorming com a 
equipe 
 
Capacidade para substituir: 
 
Ref. Descrição Origem 
RCS
01 
O software deve possibilidade de coletar arquivos txt 
com padrão de dados formatado para facilitar a 
migração de sistemas 
Brainstorming 
com a equipe 
 
Coexistência: 
 
Ref. Descrição Origem 
RCOE
01 
O software pode ser manipulado com outros 
Softwares abertos 
Análise de 
Documento 
 
Conformidade relacionada à portabilidade: 
 
Ref. Descriçã
o 
Orige
m 
RCRP
01 
 
 
Visão Lógica 
Stakeholder a ser endereçado pela visão: Usuário Final, Desenvolvedor e Arquiteto de Softwares. 
Explicação da visão: É uma visão voltada para orientação objeto e requisitos funcionais. Nessa visão 
o sistema é decomposto em classes ou objetos a partir do domínio do problema. Os artefatos mais 
comuns da visão é o diagrama de classe e o diagrama de banco de dados. 
Preocupações a serem endereçadas pela visão: Está visão tem a preocupação com as 
funcionalidades do sistema e com a organização do mesmo em classes. Além disse está preocupada 
na modelagem do sistema no sentido conceitual. 
Linguagem, técnica de modelagem a ser utilizado na construção da visão: O diagrama utilizado 
nessa visão será o diagrama de classe, visto que ele é perfeito para a modelagem conceitual do sistema. 
Notação do diagrama: 
A notação do diagrama que será utilizada será apenas duas a classe e os relacionamento entre as 
classes. 
Classe: 
 
Relacionamento entre classes: 
 
 
 
Raciocínio da visão com as preocupações dos stakeholders: 
 
Diagrama: 
 
Foi montado por cima do projeto de dados, onde as entidades viraram classes e o as tabelas próprias 
também. 
 
 
 
 
Visão Desenvolvimento 
Stakeholder a ser endereçado pela visão: Desenvolvedor e Arquiteto de Softwares. 
Explicação da visão: É uma visão que divide o software em partes menores para facilitar o 
desenvolvimento. Está visão tenta representar o sistema por meio de módulos e subsistemas além 
disso mostra os relacionamentos que esses possuem entre si. 
Preocupações a serem endereçadas pela visão: Está visão tem a preocupação com a organização 
do software para o desenvolvimento. 
Linguagem, técnica de modelagem a ser utilizado na construção da visão: O diagrama utilizado 
nessa visão será o diagrama de componente. 
Notação do diagrama: 
Nessa visão será usado do diagrama os componentes e suas dependências. Além disso será separada 
por uma caixa as camadas do sistema. 
 
 
Componente: 
 
Dependência: 
 
Raciocínio da visão com as preocupações dos stakeholders: 
O estilo arquitetural escolhido do sistema é o N Camadas, onde estamos dividindo o sistema 
em três camadas com funções bem definidas. A camada de apresentação ficou com a responsabilidade 
das interfaces web do sistema. Nessa camada foram representadas as interfaces do sistema por meio 
de componentes. Alguns componentes possuem componentes internos, visto que são interfaces que 
possuem outras interfaces internas. A camada de regra de negócio ficou com os componentes que tem 
a responsabilidade do controle de funções da interface e da comunicação das camadas de dados com 
a de interface. Foi escolhido criar um componente nessa camada negócio, para cada conjuntode 
interface definida na camada de apresentação. A última camada é a de dados que tem a 
responsabilidade de comunicação com o banco de dado. Nessa camada foi escolhido criar um 
componente para cada classe que possuímos nosso sistema, visando dar mais organização. O nosso 
componente Agenda visto na camada de regra de negócio e apresentação é a junção de duas classes 
do nosso sistema que, é a classe sessão e bloqueios. Foi feito dessa maneira, visto que queríamos que 
os sistemas tivessem uma abordagem de agendamento baseada nessas duas classes para o 
gerenciamento e não uma classe somente de agenda. 
 
 
 
 
5. Projeto de Componentes 
Revisões 
 
Data Descrição Autores 
06/06/2018 *Criação do projeto de componentes Flávio 
Amaral e 
Pedro 
Gabriel 
Suet 
 
Índice 
Introdução .......................................................................................................................................... 50 
Público Alvo ....................................................................................................................................... 50 
 Glossário ........................................................................................................................................... 50 
Diagrama de Componentes ................................................................................................................ 51 
Descrição dos Pacotes de Trabalho .................................................................................................... 51 
 
• Introdução 
Este documento apresenta os componentes que fazem parte do software de gerenciamento 
clínico de psicologia. Será detalhado o nível de acoplamento e coesão e as classes de cada 
componente neste projeto. 
 
• Público Alvo 
Nome Descrição Responsabilidade 
Equipe de desenvolvimento Estudantes da PUC-GO da 
disciplina de Arquitetura e 
Design de Software 
Desenvolver o software descrito 
neste documento 
Arquiteto de software Estudantes da PUC-GO da 
disciplina de Arquitetura e 
Design de Software 
Gerenciar a arquitetura do 
software descrito neste 
documento 
• Glossário 
• Web: Página HTML; 
• Camada de Apresentação: Camada preocupada com interface; 
• Camada de Regra de Negócio: Camada preocupada com as operações do sistema; 
• Camada de Dados: Camada preocupada com o acesso ao banco de dados; 
• Banco de Dados: Um arquivo gerenciado que contem guardado tabelas pertinentes 
do sistema; 
 
 
Diagrama de Componentes 
 
 
 
 
 
• Descrição dos Pacotes de Trabalho 
Camada de Apresentação 
 
Componente: Login; 
Métodos: 
● Nenhum; 
Interfaces: 
● UsuárioControle: 
o ValidarAcessoUsuário: 
▪ Parâmetros: String Nome, String Senha; 
▪ Retorno: Bool Sucesso; 
o Acoplamento: Dados; 
Coesão: Funcional; 
Estrutura de Dados usada: 
● Nenhuma; 
 
 
 
 
Componente: PaginaInicial; 
Métodos: 
● Nenhum; 
Interfaces: 
● Navegação para Index Usuário, Convênio, Paciente e Agenda; 
 
Coesão: Funcional; 
Estrutura de Dados usada: 
● Nenhuma; 
 
Componente: IndexUsuario; 
Métodos: 
● PreencherListaUsuario 
o Parâmetros: Vazio; 
o Retorno: List<Usuario>; 
o Descrição: Lista os Usuários do sistema, com opção de Editar e Excluir; 
o Retorno de Erro pela Interface: Mensagem de erro de conexão; 
Interfaces: 
● Navegação para CriarUsuario, AlterarUsuario e DeletarUsuario; 
● UsuarioControle: 
o ListarUsuário: 
▪ Parâmetros: Vazio; 
▪ Retorno: List<Usuario>; 
o Acoplamento: Vazio e Imagem (Respectivamente); 
 
Coesão: Funcional; 
Estrutura de Dados usada: 
● Usuario 
 
Componente: CriarUsuario; 
Métodos: 
● ValidaEnvio: 
o Parâmetros: Vazio; 
o Retorno: Vazio; 
o Descrição: Chama todas as validações para verificar se o formulário foi preenchido 
corretamente e, se sim, envia para interface do componente do UsuarioControle e se 
retornar verdadeiro para envio, informar para o usuário que tarefa foi executada com 
êxito; 
o Retorno de Erro pela Interface: Mensagem de não envio por dados incompletos ou 
errados; 
● ValidaCampoObrigatório: 
o Parâmetros: Usuário usuario 
o Retorno: Bool Sucesso; 
 
 
o Descrição: Valida se os campos obrigatórios do objeto Usuário estão preenchidos; 
o Retorno de Erro pela Interface: Campos obrigatórios ficam contorno vermelho; 
● ValidaNome: 
o Parâmetros: String Nome; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se o nome não tem caracteres especiais; 
o Retorno de Erro pela Interface: Mensagem de uso inválido de caracteres especiais; 
● ValidaCPF: 
o Parâmetros: String CPF; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se o CPF está no padrão; 
o Retorno de Erro pela Interface: Mensagem de CPF inválido; 
● ValidaEmail: 
o Parâmetros: String Email; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se o E-mail está no padrão; 
o Retorno de Erro pela Interface: Mensagem de E-mail inválido; 
● ValidaSenha: 
o Parâmetros: String Senha, String SenhaConfirmada; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se a senha digitada duas vezes é igual; 
o Retorno de Erro pela Interface: Mensagem de senhas não compatíveis; 
Interfaces: 
● UsuarioControle: 
o CadastrarUsuário: 
▪ Parâmetros: Usuario usuario; 
▪ Retorno: Bool Sucesso; 
o Acoplamento: Imagem e Controle (Respectivamente); 
Coesão: Lógica; 
Estrutura de Dados usada: 
● Usuario; 
 
Componente: AlterarUsuario; 
Métodos: 
● PreencheCampos: 
o Parâmetros: Usuario usuario; 
o Retorno: Vazio; 
o Descrição: Preenche o campo da tela com o objeto passado por parâmetro; 
o Retorno de Erro pela Interface: Mensagem de erro de conexão com servidor; 
● ValidaEnvio: 
o Parâmetros: Vazio; 
o Retorno: Vazio; 
 
 
o Descrição: Chama todas as validações para verificar se o formulário foi preenchido 
corretamente e, se sim, envia para interface do componente do UsuarioControle e se 
retornar verdadeiro para envio, informar para o usuário que tarefa foi executada com 
êxito; 
o Retorno de Erro pela Interface: Mensagem de não envio por dados incompletos ou 
errados; 
● ValidaCampoObrigatório: 
o Parâmetros: Usuário usuario 
o Retorno: Bool Sucesso; 
o Descrição: Valida se os campos obrigatórios do objeto Usuário estão preenchidos; 
o Retorno de Erro pela Interface: Campos obrigatórios ficam contorno vermelho; 
● ValidaNome: 
o Parâmetros: String Nome; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se o nome não tem caracteres especiais; 
o Retorno de Erro pela Interface: Mensagem de uso inválido de caracteres especiais; 
● ValidaCPF: 
o Parâmetros: String CPF; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se o CPF está no padrão; 
o Retorno de Erro pela Interface: Mensagem de CPF inválido; 
● ValidaEmail: 
o Parâmetros: String Email; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se o E-mail está no padrão; 
o Retorno de Erro pela Interface: Mensagem de E-mail inválido; 
● ValidaSenha: 
o Parâmetros: String Senha, String SenhaConfirmada; 
o Retorno: Bool Sucesso; 
o Descrição: Valida se a senha digitada duas vezes é igual; 
o Retorno de Erro pela Interface: Mensagem de senhas não compatíveis; 
Interfaces: 
● UsuarioControle: 
o AlterarUsuário: 
▪ Parâmetros: Usuario usuario; 
▪ Retorno: Bool Sucesso; 
o Acoplamentos: Imagem e Controle (Respectivamente); 
o BuscarUsuário: 
▪ Parâmetros: Int codigo; 
▪ Retorno: Usuario usuario; 
o Acoplamento: Dados e Imagem (Respectivamente); 
 
Coesão: Lógica; 
 
 
Estrutura de Dados usada: 
● Usuario; 
 
 
 
Componente: DeletarUsuario; 
Métodos: 
● PreencheInformacoes: 
o Parâmetros: Usuario usuario; 
o Retorno: Vazio; 
o Descrição: Preenche os dados da tela com o objeto passado por parâmetro; 
o Retorno de Erro pela Interface: Mensagem de erro de conexão com servidor; 
● ConfirmacaoExclusao: 
o Parâmetros: Int codigo; 
o Retorno: Bool Sucesso; 
o Descrição: Envia a ordem de exclusão do item ao servidor; 
o Retorno de Erro pela Interface: Mensagem de erro de conexão com servidor; 
 
Interfaces: