Upload
dinhhuong
View
213
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
Documento de Requisitos Grupo Prosintese-E1
Recife, Novembro de 2009
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
Documento de Requisitos Grupo Prosintese-E1
Recife, 26 de Novembro de 2009
. Trabalho apresentado à disciplina de Especificação de Requisitos e Validação de Sistemas do Centro de Informática da Universidade Federal de Pernambuco pelos alunos Adriano Melo, Douglas Queiroz, Luiz Felipe Libório e Tiago Bernardo.
ÍNDICE
CAPÍTULO 1: ................................................................................................................................... 5
INTRODUÇÃO ................................................................................................................................. 5
1. Motivação .......................................................................................................................... 5
2. O Problema ........................................................................................................................ 5
3. Convenções ........................................................................................................................ 6
3.1. Classificação dos Requisitos ...................................................................................... 6
3.2. Classificação dos Casos de Uso .................................................................................. 6
4. Atores ................................................................................................................................ 7
5. Levantamento de Dados .................................................................................................... 7
5.1. Entrevista ................................................................................................................... 7
5.2. Questionário .............................................................................................................. 8
CAPÍTULO 2: ................................................................................................................................... 9
REQUISITOS ORGANIZACIONAIS .................................................................................................... 9
1. Modelagem dos Requisitos Organizacionais ..................................................................... 9
1.1. Modelo de Dependência Estratégica ......................................................................... 9
1.2. Modelo Racional Estratégico ................................................................................... 10
CAPÍTULO 3: ................................................................................................................................. 12
REQUISITOS FUNCIONAIS ............................................................................................................ 12
1. Lista dos Requisitos Funcionais ....................................................................................... 12
1.1. Login ........................................................................................................................ 12
1.2. Hospitais .................................................................................................................. 13
1.3. Pacientes .................................................................................................................. 16
1.4. Funcionários ............................................................................................................ 19
1.5. Cirurgias ................................................................................................................... 22
1.6. Planos de Saúde ....................................................................................................... 25
1.7. Notas Fiscais ............................................................................................................ 28
1.8. Relatórios ................................................................................................................. 31
1.9. Autenticação ............................................................................................................ 34
2. Diagrama de Casos de Uso .............................................................................................. 35
CAPÍTULO 4: ................................................................................................................................. 37
REQUISITOS NÃO-FUNCIONAIS ................................................................................................... 37
1. Requisitos de Processo .................................................................................................... 37
2. Requisitos de Produto ..................................................................................................... 38
2.1. Segurança ................................................................................................................ 38
2.2. Confiabilidade .......................................................................................................... 39
2.3. Usabilidade .............................................................................................................. 40
2.4. Interoperabilidade ................................................................................................... 41
2.5. Performance ............................................................................................................ 41
2.6. Robustez .................................................................................................................. 42
3. Requisitos de Externos .................................................................................................... 42
4. Modelagem dos Requisitos Não-Funcionais ................................................................... 43
CONCLUSÃO ................................................................................................................................. 45
REFERÊNCIAS ............................................................................................................................... 46
RELATÓRIO DA EQUIPE ................................................................................................................... i
CAPÍTULO 1:
INTRODUÇÃO
A construção de tal documento tem como objetivo descrever o problema identificado e
especificar os requisitos que construirão a sua solução. Solução essa encontrada durante fase preliminar
de estudo de viabilidade. Temos como objeto de estudo acadêmico o grupo empresarial Prosintese-E1.
1. Motivação
O crescimento empresarial obriga muitas empresas a adotar práticas do tipo d i v i d i r p a r ac o n q u i s t a r
. Acordos comerciais limitam o campo de atuação das empresas objetivando o foco maior em
determinado setor da economia, para que esses acordos não façam com que a empresa reduza seu
campo de atuação, ela cria novas empresas dentro do seu grupo para ocupar dentro do mercado a
parcela que lhe foi anteriormente restrita. Essa prática se assemelha bastante com a de H o l d i n g s e é
observada, por exemplo, nos grupos de concessionárias na região metropolitana do Recife. A Fiori, do
grupo Parvi, vende apenas veículos novos da Fiat e a Bremen (Volkswagen), América (Ford), Pedragon
(Chevrollet), Rivoli (Peugeot), Toyolex (Toyota) e Fiori Motos (Dafra) compõem o resto do grupo com
outras marcas de veículos.
2. O Problema
O Grupo Prosintese é formado por 11 empresas espalhadas por todo o país. Ele comercializa
materiais cirúrgicos ortopédicos vendendo-os diretamente a pacientes, planos de saúde e Hospitais.
Desde meados da década de 1990 ele vende no Brasil os produtos da Biomet Inc. que são de origem
Norte Americana e Européia principalmente. No ano de 2009, novos acordos com a Biomet, com o
objetivo de aumentar a participação da empresa no mercado brasileiro, fizeram com que a Prosintese (a
marca) fosse limitada a vender determinadas linhas de produtos. Para que isso não reduzisse a grande
participação da empresa em todo o território nacional, novas empresas foram criadas para que as linhas
"proibidas" pudessem ser vendidas. Em Recife a empresa E1 foi criada e funciona legal e fiscalmente de
maneira independente da Prosintese, porém é comum observar a mescla de suas atividades.
De acordo com conversas que o grupo teve com o Diretor da E1-Prosintese e com funcionários
das empresas, foi observado que há problemas no agendamento de cirurgias e controle de faturamento.
O ERP hoje implantado na empresa só pode ser utilizado pela E1, e não pela Prosintese, fazendo com
que as vendas da Prosintese não sejam totalmente controladas, causando diversos tipos de problemas
para o grupo. O obejetivo maior do sistema por nós proposto é prover maior controle empresarial,
porém o mesmo também pode mudar a forma da empresa funcionar atualmente com o objetivo de
melhorar seus resultados. A utilização principal será feita por parte dos funcionários internos do grupo,
porém também é quisto que ele possa ser alimentado pelos clientes das empresas; os clientes irão fazer
solicitações às empresas através do sistema. Assim sendo, além de agendamento e controle de
faturamento, o sistema iria fazer controle de orçamentos e autorizações de cirurgias. Relatórios de
faturamento, agendamento e orçamentos devem também ser gerados pelo sistema.
3. Convenções 3.1. Classificação dos Requisitos
Para que os requisitos sejam identificados corretamente, iremos utilizar as seguintes
notações para classificá-los em nosso documento: [ R F x x ] N o m e d o R e q u i s i t o : Utilizado em Requisitos Funcionais onde o xx se refere ao
número daquele requisito; [ R N F x x ] N o m e d o R e q u i s i t o : Utilizado em Requisitos Não Funcionais onde o xx também
se refere ao número daquele requisito.
O nome do requisito será uma referência ao nome do caso de uso que corresponde a
ele, por exemplo, [ R F x x ] E f e t u a r L o g i n .
3.2. Classificação dos Casos de Uso
Assim como nos requisitos, utilizaremos um código para identificar os casos de uso do
sistema. Tal código será [ U C x x ] N o m e d o C a s o d e U s o , onde o xx se refere ao número daquele
caso de uso.
3.2.1. Estruturação dos Casos de Uso
Os casos de uso especificados neste documento serão formados pelos seguintes
componentes:
• Atores: Especifica os agentes que utilizarão o caso de uso;
• Prioridade: Seta a prioridade de implementação do caso de uso;
• Entradas: Os dados de entrada necessários que deverão ser inseridos ao sistema;
• Pré-condições: Condições prévias que deverão ser satisfeitas antes da execução
do caso de uso;
• Fluxo de Eventos: É o passo a passo das ações realizadas pelo caso de uso para a
sua correta conclusão, nele serão identificados os f l u x o s d e e v e n t o s p r i n c i p a i s
e f l u x o s d e e v e n t o s s e c u n d á r i o s e / o u a l t e r n a t i v o s;
• Saídas: Serão os dados que o sistema deverá retornar quando o caso de uso for
corretamente finalizado;
• Pós-condições: Condições que devem ser satisfeitas quando a execução do caso
de uso for corretamente finalizada.
3.2.2. Descrição das Prioridades dos Casos de Uso
Os casos de uso especificados neste documento deverão ser assim classificados:
• Essencial: É aquele caso de uso indispensável ao funcionamento do sistema. Ele
deve ser implementado independentemente de tudo, se não for, o projeto
perderá sua utilidade;
• Importante: Os casos de uso com essa classificação não fazem com que o sistema
se torne inutilizado, porém a sua presença traz satisfação ao cliente;
• Desejável: Casos de Uso desejáveis serão aqueles que, se não implementados não
alteram as funcionalidades básicas do sistema, porém sua implementação, talvez
futura, traz maior valor a ele. Tais casos de uso são os primeiros na escala de
dispensa, caso exista algum imprevisto.
4. Atores
Os atores são usuários e/ou outros dispositivos externos que desenvolvem algum papel em
relação ao sistema. Dispositivos externos podem ser hardwares e/ou softwares que, como os usuários,
geram informações para o sistema ou necessitam de informações que são geradas pelo sistema. No
sistema proposto teremos como atores três níveis de usuários:
• Operadores (Atores Operacionais): Funcionários de nível operacional da empresa que irão
inserir os dados críticos no sistema;
• Supervisores: Funcionários de nível tático da empresa que consultarão e inserirão dados
no sistema com nível de acesso pouco restrito;
• Diretor: Funcionário de nível estratégico da empresa que fará consultas aos relatórios do
sistema sem nenhum tipo de restrição de acesso.
5. Levantamento de Dados
Os dados que basearam tal documento foram levantados pelos membros do grupo tanto de forma quantitativa como de forma qualitativa. As entrevistas tiveram o objetivo de levantar informações de modo uniforme para todos distinguindo as funções de cada entrevistado dentro do processo. A entrevista, juntamente com as conversas informais, forma a parcela qualitativa de levantamento de dados. Outro método utilizado foi o de questionários objetivos que tiveram o intuito maior de valorar de modo justo os dados obtidos através dos tipos qualitativos. Tal método forma a parcela quantitativa de obtenção de dados.
5.1. Entrevista
Segue abaixo a lista de perguntas que formaram o questionário que foi respondido por todos os
envolvidos no processo de elicitação de requisitos e os objetivos de cada pergunta:
1) A atual estrutura de intercâmbio de informações dentro do grupo empresarial é agradável? Esse questionamento tem como objetivo saber se a atual estrutura agrada o funcionário da empresa.
2) Quais pontos positivos e negativos da estrutura atual de controle da empresa podem ser destacados? O objetivo dessa pergunta é o levantamento das visões que as partes envolvidas têm do processo atual, comparando principalmente as pessoas do mesmo nível organizacional.
3) Um novo sistema de controle detalhado independente do ERP utilizado hoje pelo grupo ajudaria o trabalho de intercâmbio dentro do grupo? Tal pergunta teve o objetivo de verificar se existe algum tipo de reação negativa à utilização de mais um sistema pelos funcionários.
4) Quais são as principais características que tal sistema deverá possuir? O objetivo dessa pergunta é levantar os principais requisitos do sistema, os que os usuários consideram mais importantes.
5) Cite um episódio em que o sistema atual falhou ocasionando algum tipo de transtorno? As falhas graves do sistema deverão ser expostas nessas respostas para fazer com que elas sejam impedidas pelo novo sistema.
5.2. Questionário
São observadas abaixo a lista de perguntas objetivas que estavam presentes no questionário
que compôs os artefatos de coleta de dados de nosso estudo. Tal questionário objetiva basicamente
quantificar os dados obtidos através da entrevista, torná-los exatos e não distingui-los de acordo com as
parcelas organizacionais, além de obter novos:
1) Qual nota você dá ao atual processo de intercâmbio de informações entre as empresas do grupo? Escala de 1 (Péssimo) a 5 (Ótimo)
2) Qual a visão que você crê, de acordo com o seu trabalho, que os outros tem do sistema atual? Escala de 1 (Péssimo) a 5 (Ótimo)
3) Qual a importância de um novo sistema independente de controle dessas atividades? Escala de 1 (Nenhuma) a 5 (Muita)
4) Quais características deve ter o novo sistema? Cite três. a) Cadastro de Notas Fiscais b) Relatório de Envio de Notas c) Relatório de Pendências d) Controle de Acesso e) Cadastro de Pacientes f) Cadastro de Cirurgias
g) Backup h) Interface Amigável i) Mensagens de Erro j) Ajuda k) Cronograma l) Suporte a Orçamentos
CAPÍTULO 2:
REQUISITOS ORGANIZACIONAIS
Os requisitos organizacionais são aqueles que dizem respeito às metas da empresa, suas
políticas, suas estratégias adotadas e os relacionamentos entre os atores e tais objetivos. Esses
requisitos no projeto desenvolvido para a Prosintese-E1 são:
• Facilitar comunicação entre a E1 e a Prosintese São Paulo: Tornar a comunicação entre as partes mais ágil, tranqüila e documentada;
• Fornecer informações específicas sobre as relações entre as duas empresas: Tornar mais transparentes as relações entre as empresas, as atividades que competem a ambas;
• Diminuir o erro no faturamento de cirurgias: Tal sistema trará meios para que os erros de emissão de notas fiscais sejam diminuídos;
• Diminuir o tempo na execução dos processos: Tornar os processos mais rápidos através da colaboração entre as partes envolvidas nas duas empresas;
• Promover maior controle dos processos comuns: Tornar os processos mais visíveis e mais bem acompanhados tanto por quem o faz como por quem o coordena.
1. Modelagem dos Requisitos Organizacionais 1.1. Modelo de Dependência Estratégica
Esse modelo descreve como o sistema estaria inserido dentro da empresa E1. Ele visa detalhar,
do ponto de vista de todos os atores (pessoas ou sistemas que interagem com o sistema a ser
modelado), as ações, tarefas e objetivos que a organização espera atingir/realizar, de maneira
superficial. Ele também serve para mostrar em com se configuram as dependências com relação aos
objetivos dos atores (ou seja, quem fornece e quem é dependente da ação a ser realizada).
1.2. Modelo Racional Estratégico
Esse tipo de modelo mostra, para um ator específico, como ele se organiza de modo a atingir os
objetivos traçados pela empresa. Mostra como cada objetivo se relaciona com as tarefas referentes a
ele, inclusive com a definição (herdada do diagrama anterior) das dependências entre os elementos do
diagrama.
Neste caso, temos o modelo do ator Prosintese-E1, que é o próprio sistema. Vemos como o
sistema distribui e compõe grupos de tarefas visando atender aos objetivos de todos os que se
relacionam com ele, ou seja, de alguma forma fornecem ou recebem dados dele.
CAPÍTULO 3:
REQUISITOS FUNCIONAIS
Podemos definir requisitos funcionais como aqueles que descrevem comportamentos do
sistema, as ações que ele executará para cada entrada, ou seja, é aquilo que descreve “o que” tem que
ser feito pelo sistema. Esses requisitos podem ser definidos como o cérebro do projeto, já que
descrevem as funcionalidades que o sistema deve dispor.
1. Lista dos Requisitos Funcionais 1.1. Login
[UC01]: Efetuar Login
Identificação Descrição
[UC01] Autenticar usuário no sistema.
Prioridade: Essencial
Atores:
Ator Operacional, Supervisor e Diretor.
Entradas:
- Nome de usuário e senha.
Pré-condições:
O usuário não pode ter efetuado o login no sistema.
O usuário já deve estar cadastrado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário seleciona a opção de efetuar login na tela principal da
aplicação.
2. O sistema pede que seja informado o login e a senha do usuário.
3. O usuário informa os dados ao sistema e clica no botão "Entrar".
4. O sistema valida os dados e permite o acesso do usuário ao sistema,;caso contrário, algum fluxo
secundário ou de erro entra em ação.
Fluxos Secundários:
Fluxo secundário S1:
1. O sistema não consegue validar os dados do ator, pois ele entrou com dados desconhecidos.
2. Uma mensagem de "Usuário inexistente" é mostrada na tela e o fluxo principal (a partir do
passo 2) volta a ser executado.
Fluxo Secundário S2:
1. O usuário pode cancelar a operação a qualquer momento.
2. O caso de uso é encerrado.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC02]: Efetuar Logoff
Identificação Descrição
[UC02] Finaliza o acesso do usuário ao sistema.
Prioridade: Essencial
Atores:
Ator Operacional, Supervisor e Diretor.
Entradas:
- Nenhuma entrada precisa ser dada.
Pré-condições:
O funcionário tem que estar autenticado no sistema.
Fluxo Principal:
1. O usuário se direciona a sessão de autenticação e clica no botão sair.
2. Uma mensagem de "Você realmente deseja sair do sistema?" é exibida na tela para que ele confirme
sua solicitação.
3. Caso confirme, a sessão é encerrada e ele perde o acesso as informações do sistema até que efetue
um novo login.
4. Caso não seja confirmada sua saída, o sistema volta para sua tela principal e espera alguma ação do
usuário.
Fluxos Secundários:
- Não se aplica.
Fluxos de erro:
- Não se aplica.
Requisitos não funcionais específicos:
-
1.2. Hospitais
[UC03]: Cadastrar Hospital
Identificação Descrição
[UC03] Um novo hospital é inserido na base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome do hospital, endereço, telefone e diretor.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de cadastros e escolhe
a opção de cadastrar hospital.
2. O sistema pede que sejam informadas todas as entradas necessárias.
3. O usuário clica em "inserir" para que o hosital que ele acabou passar as inormações seja inserido na
base de dados da aplicação.
4. Uma mensagem dando um feedback positivo/negativo é mostrada na tela.
Fluxos Secundários:
Fluxo secundário S1:
1. O hospital que o funcionário deseja inserir já está cadastrado no sistema.
2. Uma mensagem de "Hosital já cadastrado" é mostrada na tela.
3. A janela de cadastrar hospital é reativada para que o usuário faça um novo cadastro ou
encerre a ação.
Fluxo Secundário S2:
1. O usuário não informa todos os dados necessários para realizar o cadastro e clica no botão
"inserir".
2. Uma mensagem de "Alguns campos necessitam de ser preenchidos" é mostrada na tela.
3. O usuário clica no botão "Ok" que aparecerá junto com a mensagem.
4. A tela de cadastro é liberada novamente para que ele preencha o que estava em branco ou
para que ele desista da ação requisitada.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC04]: Remover Hospital
Identificação Descrição
[UC04] Um hospital é retirado da base de dados do sistema da E1-Prosintese.
Prioridade: Essencial
Atores:
Supervisor
Entradas:
- Nome do hospital
Pré-condições:
O usuário deve está logado e o hospital deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à remoção, lá ele deve escolher: remover hospital.
2. Uma janela com uma lista dos nomes dos hospitais cadastrados no sistema será mostrada.
3. O usuário seleciona o nome do hospital que deseja remover e em seguida clica no botão "remover".
4. Uma janela de diálogo é aberta, perguntando se é realmente aquilo que o usuário deseja fazer.
5. O usuário confirma a solicitação e a ação é executada.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão remover sem antes ter selecionado o hospital.
2. Uma mensagem de "Selecione um hospital para que seja possível efetuar a ação requisitada"
é mostrada na tela.
3. A tela de remover hospital é ativada para que o usuário prossiga com sua solicitação.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC05]: Visualizar Hospital
Identificação Descrição
[UC05] São mostradas todas as informações cadastradas sobre o hospital requisitado.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome do hospital
Pré-condições:
O usuário deve está logado e o hospital deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai na caixa de texto que está localizada na tela principal do sistema, digita o nome do
hospital e marca o campo hospital para que a busca seja devidamente realizada.
2. Após ter digitado o nome do hospital ele clica no botão "visualizar".
3. Todas as informações cadastradas do hospital solicitado são exibidas na tela do programa. Nesse
momento, o usuário pode também imprimir o resultado da sua consulta.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário digita um nome inexistente para o sistema.
2. Uma mensagem de "O hospital requisitado não foi encontrado na base de dados do sistema"
é mostrada na tela.
3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.
Fluxo secundário S2:
1. O usuário digita um nome no campo de busca, mas não marca o campo hospital antes de
clicar em "Vizualizar".
2. Uma mensagem de "Você não selecionou nenhum campo para efetuar a consulta" é
mostrada na tela.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC06]: Listar Hospitais
Identificação Descrição
[UC06] São mostrados todos os hospitais cadastrados no sistema da E1-Prosintese.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- Não se aplica
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à listagem, lá ele deve escolher: listar hospitais.
2. Uma janela com uma lista dos nomes dos hospitais cadastrados no sistema será mostrada.
3. O usuário pode selecionar um hospital e solicitar a exibição dos dados referentes a esse hospital
clicando no botão "visualizar".
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão "visualizar" sem antes ter selecionado um hospital.
2. Uma mensagem de "Selecione um hospital para que seja possível efetuar a ação requisitada"
é mostrada na tela.
3. A tela de listagem de hospitais é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxo secundário S2:
1. O usuário seleciona um dos hospitais listados e seleciona a opção “Remover”, para excluir
um hospital do cadastro.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.3. Pacientes
[UC07]: Cadastrar Paciente
Identificação Descrição
[UC07] Um novo paciente é inserido na base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome do paciente, cpf, data de nascimento, tipo sanguíneo, endereço, telefone.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de cadastros e escolhe
a opção de cadastrar paciente.
2. O sistema pede que sejam informadas todas as entradas necessárias.
3. O usuário clica em "inserir" para que o paciente que ele acabou passar as inormações seja inserido na
base de dados da aplicação.
4. Uma mensagem dando um feedback positivo/negativo é mostrada na tela.
Fluxos Secundários:
Fluxo secundário S1:
1. O cpf que o funcionário informou já está cadastrado no sistema.
2. Uma mensagem de "Paciente já cadastrado" é mostrada na tela.
3. A janela de cadastrar paciente é reativada para que o usuário faça um novo cadastro ou
encerre a ação.
Fluxo Secundário S2:
1. O usuário não informa todos os dados necessários para realizar o cadastro e clica no botão
"inserir".
2. Uma mensagem de "Alguns campos necessitam de ser preenchidos" é mostrada na tela.
3. O usuário clica no botão "Ok" que aparecerá junto com a mensagem.
4. A tela de cadastro é liberada novamente para que ele preencha o que estava em branco ou
desista da ação requisitada.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC08]: Remover Paciente
Identificação Descrição
[UC08] Um paciente é retirado da base de dados do sistema da E1-Prosíntese.
Referências: RF-08
Prioridade: Essencial
Atores:
Supervisor.
Entradas:
- Nome do paciente
Pré-condições:
O usuário deve está logado e o paciente deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à remoção, lá ele deve escolher: remover
paciente.
2. Uma janela com uma lista dos nomes dos pacientes cadastrados no sistema será mostrada.
3. O usuário seleciona o nome do paciente que deseja remover e em seguida clica no botão "remover".
4. Uma janela de diálogo é aberta, perguntando se é realmente aquilo que o usuário deseja fazer.
5. O usuário confirma a solicitação e a ação é executada.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão remover sem antes ter selecionado o paciente.
2. Uma mensagem de "Selecione um paciente para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de remover paciente é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC09]: Visualizar Paciente
Identificação Descrição
[UC09] São mostradas todas as informações cadastradas sobre o paciente requisitado.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome do paciente ou cpf.
Pré-condições:
O usuário deve está logado e o paciente deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai na caixa de texto que está localizada na tela principal do sistema, digita o nome do
paciente ou seu cpf e marca o campo paciente para que a busca seja devidamente realizada.
2. Após ter digitado o nome do paciente ele clica no botão "visualizar".
3. Todas as informações cadastradas do paciente solicitado são exibidas na tela do programa. Nesse
momento, o usuário pode também imprimir o resultado da sua consulta.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário digita um cpf ou nome inexistente para o sistema.
2. Uma mensagem de "O paciente requisitado não foi encontrado na base de dados do
sistema" é mostrada na tela.
3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.
Fluxo secundário S2:
1. O usuário digita o cpf ou o nome do paciente no campo de busca, mas não marca o campo
paciente antes de clicar em "Vizualizar".
2. Uma mensagem de "Você não selecionou nenhum campo para efetuar a consulta" é
mostrada na tela.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC10]: Listar Pacientes
Identificação Descrição
[UC10] São mostrados todos os pacientes cadastrados no sistema da E1-Prosintese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Não se aplica
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à listagem, lá ele deve escolher: listar pacientes.
2. Uma janela com uma lista dos nomes dos pacientes cadastrados no sistema será mostrada.
3. O usuário pode selecionar um paciente e solicitar a exibição dos dados referentes a esse paciente
clicando no botão "visualizar".
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão "visualizar" sem antes ter selecionado um paciente.
2. Uma mensagem de "Selecione um paciente para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de listagem de pacientes é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxo secundário S2:
1. O usuário seleciona um dos pacientes listados e seleciona a opção “Remover”, para excluir
um paciente do cadastro.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.4. Funcionários
[UC11]: Cadastrar Funcionário
Identificação Descrição
[UC11] Um novo funcionário é inserido na base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome do funcionário, cpf, data de nascimento, endereço, telefone.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de cadastros e escolhe
a opção de cadastrar funcionário.
2. O sistema pede que sejam informadas todas as entradas necessárias.
3. O usuário clica em "inserir" para que o funcionário que ele acabou passar as inormações seja inserido
na base de dados da aplicação.
4. Uma mensagem dando um feedback positivo/negativo é mostrada na tela.
Fluxos Secundários:
Fluxo secundário S1:
1. O cpf que o funcionário informou já está cadastrado no sistema.
2. Uma mensagem de "Funcionário já cadastrado" é mostrada na tela.
3. A janela de cadastrar funcionário é reativada para que o usuário faça um novo cadastro ou
encerre a ação.
Fluxo Secundário S2:
1. O usuário não informa todos os dados necessários para realizar o cadastro e clica no botão
"inserir".
2. Uma mensagem de "Alguns campos necessitam de ser preenchidos" é mostrada na tela.
3. O usuário clica no botão "Ok" que aparecerá junto com a mensagem.
4. A tela de cadastro é liberada novamente para que ele preencha o que estava em branco ou
desista da ação requisitada.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC12]: Remover Funcionário
Identificação Descrição
[UC12] Um funcionário é retirado da base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Supervisor.
Entradas:
- Nome do Funcionário
Pré-condições:
O usuário deve está logado e o funcionário deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à remoção, lá ele deve escolher: remover
funcionário.
2. Uma janela com uma lista dos nomes dos funcionários cadastrados no sistema será mostrada.
3. O usuário seleciona o nome do funcionário que deseja remover e em seguida clica no botão
"remover".
4. Uma janela de diálogo é aberta, perguntando se é realmente aquilo que o usuário deseja fazer.
5. O usuário confirma a solicitação e a ação é executada.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão remover sem antes ter selecionado o funcionário.
2. Uma mensagem de "Selecione um funcionário para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de remover funcionário é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC13]: Visualizar Funcionário
Identificação Descrição
[UC13] São mostradas todas as informações cadastradas sobre o funcionário requisitado.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome do hospital ou cpf
Pré-condições:
O usuário deve está logado e o funcionário deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai na caixa de texto que está localizada na tela principal do sistema, digita o nome do
funcionário ou seu cpf e marca o campo funcionário para que a busca seja devidamente realizada.
2. Após ter digitado o nome do funcionário ele clica no botão "visualizar".
3. Todas as informações cadastradas do funcionário solicitado são exibidas na tela do programa. Nesse
momento, o usuário pode também imprimir o resultado da sua consulta.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário digita um cpf ou nome inexistente para o sistema.
2. Uma mensagem de "O funcionário requisitado não foi encontrado na base de dados do
sistema" é mostrada na tela.
3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.
Fluxo secundário S2:
1. O usuário digita o nome ou o cpf de um funcionário no campo de busca, mas não marca o
campo funcionário antes de clicar em "Vizualizar".
2. Uma mensagem de "Você não selecionou nenhum campo para efetuar a consulta" é
mostrada na tela.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC14]: Listar Funcionários
Identificação Descrição
[UC14] São mostrados todos os funcionários cadastrados no sistema da E1-Prosintese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Não se aplica
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à listagem, lá ele deve escolher: listar
funcionários.
2. Uma janela com uma lista dos nomes dos funcionários cadastrados no sistema será mostrada.
3. O usuário pode selecionar um funcionário e solicitar a exibição dos dados referentes a esse paciente
clicando no botão "visualizar".
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão "visualizar" sem antes ter selecionado um funcionário.
2. Uma mensagem de "Selecione um funcionário para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de listagem de funcionários é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxo secundário S2:
1. O usuário seleciona um dos funcionários listados e seleciona a opção “Remover”, para excluir
um funcionário do cadastro.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.5. Cirurgias
[UC15]: Cadastrar Cirurgias
Identificação Descrição
[UC15] Uma nova cirurgia é inserida na base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- ID da cirurgia, nome da cirurgia, médico responsável, paciente, hospital onde o procedimento será
realizado, materiais requisitados.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de cadastros e escolhe
a opção de cadastrar cirurgia.
2. O sistema pede que sejam informadas todas as entradas necessárias.
3. O usuário recebe na tela as listas de pacientes, hospitais e planos de saúde já cadastrados no sistema,
para poder escolher entre eles.
4. O usuário clica em "inserir" para que a cirurgia que ele acabou passar as inormações seja inserida na
base de dados da aplicação.
5. Uma mensagem dando um feedback positivo/negativo é mostrada na tela.
Fluxos Secundários:
Fluxo secundário S1:
1. O ID da cirurgia que o funcionário informou já está cadastrado no sistema.
2. Uma mensagem de "Cirurgia já cadastrada" é mostrada na tela.
3. A janela de cadastrar cirurgia é reativada para que o usuário faça um novo cadastro ou
encerre a ação.
Fluxo Secundário S2:
1. O usuário não informa todos os dados necessários para realizar o cadastro e clica no botão
"inserir".
2. Uma mensagem de "Alguns campos necessitam de ser preenchidos" é mostrada na tela.
3. O usuário clica no botão "Ok" que aparecerá junto com a mensagem.
4. A tela de cadastro é liberada novamente para que ele preencha o que estava em branco ou
desista da ação requisitada.
Fluxo Secundário S3:
1. O hospital onde a cirurgia vai ser realizada pode não estar cadastrado no sistema. Então, o
usuário tem a possibilidade de cadastrar um hospital enquanto agenda uma cirurgia.
Fluxo Secundário S4:
1. O paciente que vai passar pela cirurgia vai ser realizada pode não estar cadastrado no
sistema. Então, o usuário tem a possibilidade de cadastrar um paciente enquanto agenda uma
cirurgia.
Fluxo Secundário S5:
1. O plano de saúde do paciente que irá passar pela cirurgia pode não estar cadastrado no
sistema. Então, o usuário tem a possibilidade de cadastrar um plano de saúde enquanto agenda
uma cirurgia.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC16]: Remover Cirurgia
Identificação Descrição
[UC16] Uma cirurgia é retirada da base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Supervisor.
Entradas:
- ID da cirurgia.
Pré-condições:
O usuário deve está logado e a cirurgia deve deve estar cadastrada no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à remoção, lá ele deve escolher: remover cirurgia.
2. Uma janela com uma lista dos IDs das cirurgias cadastrados no sistema será mostrada.
3. O usuário seleciona a cirurgia que deseja remover e em seguida clica no botão "remover".
4. Uma janela de diálogo é aberta, perguntando se é realmente aquilo que o usuário deseja fazer.
5. O usuário confirma a solicitação e a ação é executada.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão remover sem antes ter selecionado a cirurgia.
2. Uma mensagem de "Selecione uma cirurgia para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de remover cirurgia é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC17]: Visualizar Cirurgia
Identificação Descrição
[UC17] São mostradas todas as informações cadastradas sobre a cirurgia requisitada.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- ID da cirurgia
Pré-condições:
O usuário deve está logado e a cirurgia deve estar cadastrada no sistema.
Fluxo Principal:
1. O usuário vai na caixa de texto que está localizada na tela principal do sistema, digita o ID da cirurgia e
marca o campo cirurgia para que a busca seja devidamente realizada.
2. Após ter digitado o código da cirurgia ele clica no botão "visualizar".
3. Todas as informações cadastradas da cirurgia solicitada são exibidas na tela do programa. Nesse
momento, o usuário pode também imprimir o resultado da sua consulta.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário digita um ID inexistente para o sistema.
2. Uma mensagem de "O funcionário requisitado não foi encontrado na base de dados do
sistema" é mostrada na tela.
3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.
Fluxo secundário S2:
1. O usuário digita um ID no campo de busca, mas não marca o campo cirurgia antes de clicar
em "Vizualizar".
2. Uma mensagem de "Você não selecionou nenhum campo para efetuar a consulta" é
mostrada na tela.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC18]: Listar Cirurgias
Identificação Descrição
[UC18] São mostradas todas as cirurgias cadastradas no sistema da E1-Prosintese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Não se aplica
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à listagem, lá ele deve escolher: listar cirurgias.
2. Uma janela com uma lista dos IDs e os nomes das cirurgias cadastradas no sistema será mostrada.
3. O usuário pode selecionar uma cirurgia e solicitar a exibição dos dados referentes a esse paciente
clicando no botão "visualizar".
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão "visualizar" sem antes ter selecionado uma cirurgia.
2. Uma mensagem de "Selecione uma cirurgia para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de listagem de cirurgias é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxo secundário S2:
1. O usuário seleciona uma das cirurgia listados e seleciona a opção “Remover”, para excluir
uma cirurgia do cadastro.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.6. Planos de Saúde
[UC19]: Cadastrar Plano de Saúde
Identificação Descrição
[UC19] Um novo plano de saúde é inserido na base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Nome, endereço, responsável e telefone da empresa.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de cadastros e escolhe
a opção de cadastrar plano de saúde.
2. O sistema pede que sejam informadas todas as entradas necessárias.
3. O usuário clica em "inserir" para que o plano de saúde que ele acabou passar as inormações seja
inserida na base de dados da aplicação.
4. Uma mensagem dando um feedback positivo/negativo é mostrada na tela.
Fluxos Secundários:
Fluxo secundário S1:
1. O plano de saúde que o funcionário informou já está cadastrado no sistema.
2. Uma mensagem de "Plano de saúde já cadastrado" é mostrada na tela.
3. A janela de cadastrar plano de saúde é reativada para que o usuário faça um novo cadastro
ou encerre a ação.
Fluxo Secundário S2:
1. O usuário não informa todos os dados necessários para realizar o cadastro e clica no botão
"inserir".
2. Uma mensagem de "Alguns campos necessitam de ser preenchidos" é mostrada na tela.
3. O usuário clica no botão "Ok" que aparecerá junto com a mensagem.
4. A tela de cadastro é liberada novamente para que ele preencha o que estava em branco ou
desista da ação requisitada.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina..
Requisitos não funcionais específicos:
-
[UC20]: Remover Plano de Saúde
Identificação Descrição
[UC20] Um plano de saúde é retirado da base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Supervisor.
Entradas:
- Nome da empresa de plano de saúde.
Pré-condições:
O usuário deve está logado e o plano de saúde deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à remoção, lá ele deve escolher: remover plano de
saúde.
2. Uma janela com uma lista dos nomes dos planos de saúde cadastrados no sistema será mostrada.
3. O usuário seleciona o plano de saúde que deseja remover e em seguida clica no botão "remover".
4. Uma janela de diálogo é aberta, perguntando se é realmente aquilo que o usuário deseja fazer.
5. O usuário confirma a solicitação e a ação é executada.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão remover sem antes ter selecionado o plano de saúde.
2. Uma mensagem de "Selecione um plano de saúde para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de remover plano de saúde é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC21]: Visualizar Plano de Saúde
Identificação Descrição
[UC21] São mostradas todas as informações cadastradas sobre o plano de saúde
requisitado.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- ID da cirurgia
Pré-condições:
O usuário deve está logado e o plano de saúide deve estar cadastrado no sistema.
Fluxo Principal:
1. O usuário vai na caixa de texto que está localizada na tela principal do sistema, digita o nome do
plano de saúde e marca o campo plano de saúde para que a busca seja devidamente realizada.
2. Após ter digitado o nome do plano de saúde ele clica no botão "visualizar".
3. Todas as informações cadastradas do plano de saúde solicitado são exibidas na tela do programa.
Nesse momento, o usuário pode também imprimir o resultado da sua consulta.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário digita um nome de plano de saúde inexistente para o sistema.
2. Uma mensagem de "O plano de saúde requisitado não foi encontrado na base de dados do
sistema" é mostrada na tela.
3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.
Fluxo secundário S2:
1. O usuário digita o nome de um plano de saúde no campo de busca, mas não marca o campo
plano de saúde antes de clicar em "Vizualizar".
2. Uma mensagem de "Você não selecionou nenhum campo para efetuar a consulta" é
mostrada na tela.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC22]: Listar Planos de Saúde
Identificação Descrição
[UC22] São mostrados todos os planos de saúde cadastrados no sistema da E1-Prosintese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Não se aplica
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à listagem, lá ele deve escolher: listar planos de
saúde.
2. Uma janela com uma lista dos nomes dos planos de saúde cadastrados no sistema será mostrada.
3. O usuário pode selecionar um plano de saúde e solicitar a exibição dos dados referentes a esse plano
de saúde clicando no botão "visualizar".
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão "visualizar" sem antes ter selecionado um plano de saúde.
2. Uma mensagem de "Selecione um plano de saúde para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de listagem de planos de saúde é novamente ativada para que o usuário prossiga com
sua solicitação.
Fluxo secundário S2:
1. O usuário seleciona um dos planos de saúde listados e seleciona a opção “Remover”, para
excluir um plano de saúde do cadastro.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.7. Notas Fiscais
[UC23]: Cadastrar Notas Fiscais
Identificação Descrição
[UC23] Uma nova nota fiscal é inserida na base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- ID da nota fiscal, nome do cliente, endereço do cliente, valor, materiais.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de cadastros e escolhe
a opção de cadastrar nota fiscal.
2. O sistema pede que sejam informadas todas as entradas necessárias.
3. O usuário clica em "inserir" para que a nota fiscal que ele acabou de passar as inormações seja
inserida na base de dados da aplicação.
4. Uma mensagem dando um feedback positivo/negativo é mostrada na tela.
Fluxos Secundários:
Fluxo secundário S1:
1. A nota fiscal que o funcionário informou já está cadastrada no sistema.
2. Uma mensagem de "Nota fiscal já cadastrada" é mostrada na tela.
3. A janela de cadastrar nota fiscal é reativada para que o usuário faça um novo cadastro ou
encerre a ação.
Fluxo Secundário S2:
1. O usuário não informa todos os dados necessários para realizar o cadastro e clica no botão
"inserir".
2. Uma mensagem de "Alguns campos necessitam de ser preenchidos" é mostrada na tela.
3. O usuário clica no botão "Ok" que aparecerá junto com a mensagem.
4. A tela de cadastro é liberada novamente para que ele preencha o que estava em branco ou
desista da ação requisitada.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC24]: Remover Nota Fiscal
Identificação Descrição
[UC24] Uma nota fiscal é retirada da base de dados do sistema da E1-Prosíntese.
Prioridade: Essencial
Atores:
Supervisor.
Entradas:
- ID da nota fiscal
Pré-condições:
O usuário deve está logado e a nota fiscal deve estar cadastrada no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à remoção, lá ele deve escolher: remover nota
fiscal.
2. Uma janela com uma lista das notas fiscais cadastradas no sistema será mostrada.
3. O usuário seleciona a nota fiscal que deseja remover e em seguida clica no botão "remover".
4. Uma janela de diálogo é aberta, perguntando se é realmente aquilo que o usuário deseja fazer.
5. O usuário confirma a solicitação e a ação é executada.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão remover sem antes ter selecionado a nota fiscal.
2. Uma mensagem de "Selecione uma nota fiscal para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de remover nota fiscal é novamente ativada para que o usuário prossiga com sua
solicitação.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC25]: Visualizar Nota Fiscal
Identificação Descrição
[UC25] São mostradas todas as informações cadastradas sobre a nota fiscal requisitada.
Prioridade: Importante
Atores:
Ator Operacional e Supervisor.
Entradas:
- ID da nota fiscal
Pré-condições:
O usuário deve está logado e a nota fiscal deve está cadastrada no sistema.
Fluxo Principal:
1. O usuário vai na caixa de texto que está localizada na tela principal do sistema, digita o ID da nota
fiscal e marca o campo nota fiscal para que a busca seja devidamente realizada.
2. Após ter digitado o ID da nota fiscal ele clica no botão "visualizar".
3. Todas as informações cadastradas da nota fiscal solicitada são exibidas na tela do programa. Nesse
momento, o usuário pode também imprimir o resultado da sua consulta.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário digita um ID inexistente para o sistema.
2. Uma mensagem de "A nota fiscal requisitada não foi encontrado na base de dados do
sistema" é mostrada na tela.
3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.
Fluxo secundário S2:
1. O usuário digita o ID de uma nota fiscal no campo de busca, mas não marca o campo nota
fiscal antes de clicar em "Vizualizar".
2. Uma mensagem de "Você não selecionou nenhum campo para efetuar a consulta" é
mostrada na tela.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC26]: Listar Notas Fiscais
Identificação Descrição
[UC26] São mostradas todas as notas fiscais cadastradas no sistema da E1-Prosintese.
Prioridade: Essencial
Atores:
Ator Operacional e Supervisor.
Entradas:
- Não se aplica
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O usuário vai no menu e escolhe a opção referente à listagem, lá ele deve escolher: listar notas fiscais.
2. Uma janela com uma lista dos IDs da nota fiscal cadastradas no sistema será mostrada.
3. O usuário pode selecionar uma nota fiscal e solicitar a exibição dos dados referentes a ela clicando no
botão "visualizar".
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário clica no botão "visualizar" sem antes ter selecionado uma nota fiscal.
2. Uma mensagem de "Selecione uma nota fiscal para que seja possível efetuar a ação
requisitada" é mostrada na tela.
3. A tela de listagem de notas fiscaise é novamente ativada para que o usuário prossiga com
sua solicitação.
Fluxo secundário S2:
1. O usuário seleciona uma dos notas fiscais listadas e seleciona a opção “Remover”, para
excluir uma nota fiscal do cadastro.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.8. Relatórios
[UC27]: Relatório de Vendas
Identificação Descrição
[UC27] É gerado um documento com o histórico de vendas realizadas pela empresa em um
dado período.
Prioridade: Essencial
Atores:
Diretor.
Entradas:
- Período.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de relatórios e escolhe a
opção de gerar relatório de vendas.
2. O sistema pede que seja informada a entrada necessária.
3. O usuário clica no botão "gerar relatório" para que ele possa ter acesso a todas as vendas que
ocorreram no período fornecido por ele.
4. O relatório além de ser mostrado na tela é gerado nos formatos pdf ou doc.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário não fornece nenhum período e clica em "gerar relatório".
2. Uma mensagem de "Forneça um período para poder gerar o relatório" é mostrada na tela.
3. A tela de gerar relatório é liberada novamente para que ele preencha o campo que estava
em branco e assim possa concluir a geração do relatório.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC28]: Relatório de Fluxo de Caixa
Identificação Descrição
[UC28] É gerado um documento com o balanço financeiro (faturamento, despesas,...) da
empresa em um dado período.
Prioridade: Essencial
Atores:
Diretor.
Entradas:
- Período.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de relatórios e escolhe
a opção de gerar relatório de fluxo.
2. O sistema pede que seja informada a entrada necessária.
3. O usuário clica no botão "gerar relatório" para que ele possa ter acesso ao fluxo de caixa da empresa
no período fornecido por ele.
4. O relatório além de ser mostrado na tela é gerado nos formatos pdf ou doc.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário não fornece nenhum período e clica em "gerar relatório".
2. Uma mensagem de "Forneça um período para poder gerar o relatório" é mostrada na tela.
3. A tela de gerar relatório é liberada novamente para que ele preencha o campo que estava
em branco e assim possa concluir a geração do relatório.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC29]: Relatório de Pendências
Identificação Descrição
[UC29] São mostradas todas as contas que a empresa tem para receber.
Prioridade: Essencial
Atores:
Supervisor e Diretor.
Entradas:
- Não se Aplica.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de relatórios e escolhe
a opção de gerar relatório de pendências.
2. O usuário clica no botão "gerar relatório" para que ele possa ter acesso a todas as contas que a
empresa tem a receber no momento.
3. O relatório além de ser mostrado na tela é gerado nos formatos pdf ou doc.
Fluxos Secundários:
- Não se aplica.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
[UC30]: Relatório de Cirurgia
Identificação Descrição
[UC30] É gerado um relatório contendo todas as informações, envolvidas numa cirurgia, que sejam do interesse da E1-Prosíntese, tais como: o hospital onde o procedimento será realizado e os materias utilizados no procedimento cirúrgico.
Prioridade: Essencial
Atores:
Supervisor e Diretor.
Entradas:
- ID da cirurgia.
Pré-condições:
O usuário deve está logado no sistema.
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário vai no menu do programa, na sessão de relatórios e escolhe a opção de gerar relatório de cirurgia. 2. O sistema pede que seja informada a entrada necessária. 3. O usuário clica no botão "gerar relatório" para que ele possa ter acesso ao relatório da cirurgia
solicitada. 4. O relatório além de ser mostrado na tela é gerado nos formatos pdf ou doc.
Fluxos Secundários:
Fluxo secundário S1: 1. O usuário fornece um ID inválido e clica em "gerar relatório". 2. Uma mensagem de "Cirurgia não localizada" é mostrada na tela. 3. A tela de gerar relatório é liberada novamente para que ele preencha o campo corretamente e assim possa concluir a geração do relatório.
Fluxo secundário S2: 1. O usuário não fornece nenhum ID e clica em "gerar relatório". 2. Uma mensagem de "Forneça um ID para poder gerar o relatório" é mostrada na tela. 3. A tela de gerar relatório é liberada novamente para que ele preencha o campo corretamente e assim possa concluir a geração do relatório.
Fluxos de erro:
Fluxo de erro E1: 1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve ser apresentada. 2. O usuário confirma a mensagem. 3. O caso de uso termina.
Requisitos não funcionais específicos:
-
1.9. Autenticação
[UC31]: Autenticar Usuário
Identificação Descrição
[UC31] O sistema faz a verificação dos dados do usuário para permitir ou não o acesso do
mesmo ao sistema.
Prioridade: Essencial
Atores:
Supervisor e Diretor.
Entradas:
- ID do usuário e senha.
Pré-condições:
Nenhuma
Fluxo Principal:
1. O caso de uso inicia-se quando o usuário digita sua identificação e senha quando for efetuar o login
no sistema
2. O sistema busca no cadastro de usuários e verifica a existência do usuário.
3. O sistema compara os dados fornecidos com os dados previamente armazenados.
4. Se forem iguais, o sistema autentica o usuário. Se não, o fluxo secundário S3 é acionado.
Fluxos Secundários:
Fluxo secundário S1:
1. O usuário fornece um ID inválido e clica em "Logar".
2. Uma mensagem de "Identificação Inválida" é mostrada na tela.
3. A tela de logar é liberada novamente para que ele preencha o campo corretamente e assim
possa concluir a geração do relatório.
Fluxo secundário S2:
1. O usuário não fornece nenhum ID e clica em "Logar".
2. Uma mensagem de "Forneça um ID para poder entrar no sistema" é mostrada na tela.
3. A tela de logar é liberada novamente para que ele preencha o campo corretamente e assim
possa entrar no sistema.
Fluxo secundário S3:
1. O usuário um ID e com uma senha que não confere e clica em "Logar".
2. Uma mensagem de "Senha Incorreta." é mostrada na tela.
3. A tela de logar é liberada novamente para que ele preencha o campo corretamente e assim
possa entrar no sistema.
Fluxos de erro:
Fluxo de erro E1:
1. Caso o sistema não consiga se conectar com o banco de dados, uma mensagem de erro deve
ser apresentada.
2. O usuário confirma a mensagem.
3. O caso de uso termina.
Requisitos não funcionais específicos:
-
2. Diagrama de Casos de Uso
O objetivo do diagrama de casos de uso é estruturar graficamente os casos de uso do sistema
para facilitar o entendimento do seu funcionamento e tentar extrair funcionalidades mais genéricas ou
que possam ser compartilhadas entre os casos de uso.
Acima observamos o diagrama construído a partir dos requisitos funcionais do sistema
proposto ao grupo Prosintese-E1 onde cada elipse corresponde a uma funcionalidade do sistema (caso
de uso), os bonecos representam os atores do sistema, ou seja, quem interage diretamente com ele, e
as setas representam as interações entre as partes.
CAPÍTULO 4:
REQUISITOS NÃO-FUNCIONAIS
Os requisitos não funcionais são aqueles que expressam como deve ser feito o sistema, estão
ligados, geralmente, a padrões de qualidade como confiabilidade, performance e robustez. São de
grande importância devido ao fato de definem se o sistema será eficiente para a tarefa que se propõe a
fazer ou não. Um sistema ineficiente certamente não será usado. Neles também são apresentados
restrições e especificações de uso para os requisitos funcionais.De acordo com Sommerville, os
requisitos não-funcionais podem ser divididos em três categorias.
• Requisitos de Processo: Restrições relacionadas com o processo de desenvolvimento do
sistema;
• Requisitos de Produto: especificam as características desejadas que um sistema deve fornecer;
• Requisitos Externos: baseados em informações sobre o domínio de aplicação, considerações
organizacionais, restrições de projeto.
1. Requisitos de Processo
Identificação: [NFR01] Desenvolvimento em PHP.
Casos de Uso relacionados: Todos.
Descrição: A linguagem utilizada para o desenvolvimento deve ser PHP, devido à sua fácil integração com banco de dados e sua comunidade de usuários.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR02] Banco de Dados MySQL
Casos de Uso relacionados: Todos.
Descrição: O banco de dados utilizado deve ser MySQL, deivdo ao seu baixo custo e possuir todos os recursos que o projeto necessita.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR03] Padrão MVC
Casos de Uso relacionados: Todos.
Descrição: A arquitetura do sistema deve seguir o padrão MVC, separando a implementação da interface da implementação do sistema em si.
Prioridade: � Essencial � Importante � Desejável
2. Requisitos de Produto 2.1. Segurança
Identificação: [NFR04] Backup Automático
Casos de Uso relacionados: Todos.
Descrição:
O sistema deve fazer um backup dos dados a cada 5 dias, para
proteger os dados de falhas no sistema e no servidor do banco de
dados.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR05] Atomicidade de Transações
Casos de Uso relacionados: Todos.
Descrição:
Cada transação deve ser gerenciada individualmente, para evitar
dependências entre elas, e, conseqüentemente, que erros em
transações não afetem outras desnecessariamente.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR06] Proteção de Domínio
Casos de Uso relacionados: Todos.
Descrição:
Cada empresa deve acessar apenas os dados que são do seu
domínio, para evitar corrupção nos dados que não competem à
cada empresa.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR07] Criptografia
Casos de Uso relacionados: Todos.
Descrição:
Dados referentes a pessoas devem ser criptografados, para evitar
vazamentos de informações confidenciais durante transações do
sistema.
Prioridade: � Essencial � Importante � Desejável
2.2. Confiabilidade
Identificação: [NFR08] Recuperação
Casos de Uso relacionados: Todos.
Descrição:
O sistema deve ser capaz de retornar ao seu último estado válido
ao ocorrer uma falha. Para isso, um log do sistema é mantido no
banco de dados para posterior recuperação.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR09] Disponibilidade
Casos de Uso relacionados: Todos.
Descrição:
O sistema deve estar disponível 95% do tempo. Erros de usuário e
de rede devem ser tratados de forma que não comprometam o
funcionamento do sistema.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR10] Isolamento de Erros
Casos de Uso relacionados: Todos.
Descrição: Erros do usuário não podem implicar em falhas de sistema, o que
poderia afetar a confiabilidade e a disponibilidade do sistema.
Prioridade: � Essencial � Importante � Desejável
2.3. Usabilidade
Identificação: [NFR11] Interface Amigável
Casos de Uso relacionados: Todos.
Descrição: A interface do sistema como um todo deve ser simples de
navegar, com funções objetivas e bem definidas
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR12] Seqüência de Passos Máxima
Casos de Uso relacionados: Todos.
Descrição:
As telas do sistema devem conter o essencial para a utilização do
sistema, com um número máximo de passos a serem seguidos.
Quantidades muito grandes de passos comprometem a
usabilidade do sistema.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR13] Mensagens de Erro
Casos de Uso relacionados: Todos.
Descrição: Todo erro deve ser reportado com clareza ao usuário, através de
mensagens de aviso na tela.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR14] Ajuda
Casos de Uso relacionados: Todos.
Descrição:
O sistema deve possuir um sistema de ajuda, acessível de
qualquer parte do sistema, que seja capaz de solucionar dúvidas
surgidas na utilização do sistema.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR15] Orientações contra erros
Casos de Uso relacionados: Todos.
Descrição: Se o usuário cometer algum erro, o sistema prontamente avisa e
orienta o procedimento correto.
Prioridade: � Essencial � Importante � Desejável
2.4. Interoperabilidade
Identificação: [NFR16] Interoperabilidade
Casos de Uso relacionados: Todos.
Descrição:
As duas empresas devem ser capazes de utilizar o sistema, de
forma que coordene as suas atividades simultaneamente. As
informações compartilhadas pelas empresas devem ser
organizadas e exibidas de forma que sejam entendidas por ambas.
Prioridade: � Essencial � Importante � Desejável
2.5. Performance
Identificação: [NFR17] Tempo de Resposta
Casos de Uso relacionados: Todos.
Descrição: O sistema não pode demorar mais de 5 s para dar ao usuário uma
resposta sobre alguma solicitação feita.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR18] Throughput
Casos de Uso relacionados: Todos.
Descrição: O sistema deve suportar 30 acessos simultâneos, provenientes de
ambas as empresas.
Prioridade: � Essencial � Importante � Desejável
2.6. Robustez
Identificação: [NFR19] Monitoramento de Rede
Casos de Uso relacionados: Todos.
Descrição: O sistema deve monitorar constantemente a rede para ser capaz
de informar se dados podem ou não ser transferidos.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR20] Checagem de Servidores
Casos de Uso relacionados: Todos.
Descrição: O sistema deve suportar 30 acessos simultâneos, provenientes de
ambas as empresas.
Prioridade: � Essencial � Importante � Desejável
3. Requisitos de Externos
Identificação: [NFR21] Orçamento
Casos de Uso relacionados: Todos.
Descrição: O orçamento tem que estar dentro das estimativas do Estudo de
Viabilidade.
Prioridade: � Essencial � Importante � Desejável
Identificação: [NFR22] Cronograma
Casos de Uso relacionados: Todos.
Descrição: O cronograma estimado no Estudo de Viabilidade deve ser
seguido com, no máximo, uma semana de acréscimo.
Prioridade: � Essencial � Importante � Desejável
4. Modelagem dos Requisitos Não-Funcionais
Esse diagrama descreve os requisitos não-funcionais do projeto segundo o framework NFR. Ele
mostra todos os RNF, juntamente com suas operacionalizações (a ação necessária para que o requisito
seja atendido) e as contribuições entre eles, tanto positivas quanto negativas. Como RNF principais,
temos requisitos de segurança, interoperabilidade, robustez, performance , usabilidade e confiabilidade.
O diagrama mostra a contribuição positiva dos requisitos de segurança e robustez na
confiabilidade do sistema, embora essa robustez do sistema tenha um custo de performance associado.
A segurança também contribui para a interoperabilidade do sistema. Já a usabilidade pode afetar a
performance visando tornar o sistema mais atraente para o usuário.
CONCLUSÃO
A construção desse projeto deu oportunidade aos membros da equipe de exercitarem todo o
conhecimento teórico obtido ao longo da disciplina. Foram realizadas tarefas de elicitação de requisitos
e sua conseqüente análise para que tal documento fosse concluído de acordo com o esperado. O
intercâmbio de informações entre os membros da equipe e os funcionários da empresa E1-Prosintese
criou o ambiente propício à evolução da aprendizagem de todos.
REFERÊNCIAS
1. Laudon, Kenneth C.. Sistemas de Informações gerenciais : administrando a empresa digital. São Paulo.
2. Padovoze, Clóvis Luís. Sistemas de informações contábeis: fundamentos e análise. São Paulo.
3. Sommerville, Ian. Software Engineering, Addison-Wesley, 6a. edição.
4. G. Kotonya. I. Sommerville. Requirements Engineering: Processes and Techniques, John Wiley & Sons,
1998.