UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE...

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


[UC02] Finaliza o acesso do usuário ao sistema.


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.


- Não se aplica.

Fluxos de erro:

- Não se aplica.


-

1.2. Hospitais

[UC03]: Cadastrar Hospital


[UC03] Um novo hospital é inserido na base de dados do sistema da E1-Prosíntese.


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.



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.


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:


ser apresentada.




-

[UC04]: Remover Hospital


[UC04] Um hospital é retirado da base de dados do sistema da E1-Prosintese.


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.



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:


ser apresentada.




-

[UC05]: Visualizar Hospital


[UC05] São mostradas todas as informações cadastradas sobre o hospital requisitado.

Prioridade: Importante

Atores:


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.



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"


3. A tela principal é novamente ativada para que o usuário prossiga com sua solicitação.


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:


ser apresentada.




-

[UC06]: Listar Hospitais


[UC06] São mostrados todos os hospitais cadastrados no sistema da E1-Prosintese.


Atores:


Entradas:

- Não se aplica

Pré-condições:


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



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"


3. A tela de listagem de hospitais é novamente ativada para que o usuário prossiga com sua

solicitação.


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:


ser apresentada.




-

1.3. Pacientes

[UC07]: Cadastrar Paciente


[UC07] Um novo paciente é inserido na base de dados do sistema da E1-Prosíntese.


Atores:


Entradas:

- Nome do paciente, cpf, data de nascimento, tipo sanguíneo, endereço, telefone.

Pré-condições:


Fluxo Principal:


a opção de cadastrar paciente.


3. O usuário clica em "inserir" para que o paciente que ele acabou passar as inormações seja inserido na





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.



"inserir".




desista da ação requisitada.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC08]: Remover Paciente


[UC08] Um paciente é retirado da base de dados do sistema da E1-Prosíntese.

Referências: RF-08


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





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:


ser apresentada.




-

[UC09]: Visualizar Paciente


[UC09] São mostradas todas as informações cadastradas sobre o paciente requisitado.


Atores:


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:


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




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.



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


mostrada na tela.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC10]: Listar Pacientes


[UC10] São mostrados todos os pacientes cadastrados no sistema da E1-Prosintese.


Atores:


Entradas:

- Não se aplica

Pré-condições:


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




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


3. A tela de listagem de pacientes é novamente ativada para que o usuário prossiga com sua

solicitação.


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:


ser apresentada.




-

1.4. Funcionários

[UC11]: Cadastrar Funcionário


[UC11] Um novo funcionário é inserido na base de dados do sistema da E1-Prosíntese.


Atores:


Entradas:

- Nome do funcionário, cpf, data de nascimento, endereço, telefone.

Pré-condições:


Fluxo Principal:


a opção de cadastrar funcionário.


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.




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.



"inserir".





Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC12]: Remover Funcionário


[UC12] Um funcionário é retirado da base de dados do sistema da E1-Prosíntese.


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





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


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:


ser apresentada.




-

[UC13]: Visualizar Funcionário


[UC13] São mostradas todas as informações cadastradas sobre o funcionário requisitado.


Atores:


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:


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




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




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


mostrada na tela.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC14]: Listar Funcionários


[UC14] São mostrados todos os funcionários cadastrados no sistema da E1-Prosintese.


Atores:


Entradas:

- Não se aplica

Pré-condições:


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




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


3. A tela de listagem de funcionários é novamente ativada para que o usuário prossiga com sua

solicitação.


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:


ser apresentada.




-

1.5. Cirurgias

[UC15]: Cadastrar Cirurgias


[UC15] Uma nova cirurgia é inserida na base de dados do sistema da E1-Prosíntese.


Atores:


Entradas:

- ID da cirurgia, nome da cirurgia, médico responsável, paciente, hospital onde o procedimento será

realizado, materiais requisitados.

Pré-condições:


Fluxo Principal:


a opção de cadastrar cirurgia.


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





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.



"inserir".






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.


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.


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:


ser apresentada.




-

[UC16]: Remover Cirurgia


[UC16] Uma cirurgia é retirada da base de dados do sistema da E1-Prosíntese.


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





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


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:


ser apresentada.




-

[UC17]: Visualizar Cirurgia


[UC17] São mostradas todas as informações cadastradas sobre a cirurgia requisitada.


Atores:


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




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




1. O usuário digita um ID no campo de busca, mas não marca o campo cirurgia antes de clicar

em "Vizualizar".


mostrada na tela.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC18]: Listar Cirurgias


[UC18] São mostradas todas as cirurgias cadastradas no sistema da E1-Prosintese.


Atores:


Entradas:

- Não se aplica

Pré-condições:


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




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


3. A tela de listagem de cirurgias é novamente ativada para que o usuário prossiga com sua

solicitação.


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:


ser apresentada.




-

1.6. Planos de Saúde

[UC19]: Cadastrar Plano de Saúde


[UC19] Um novo plano de saúde é inserido na base de dados do sistema da E1-Prosíntese.


Atores:


Entradas:

- Nome, endereço, responsável e telefone da empresa.

Pré-condições:


Fluxo Principal:


a opção de cadastrar plano de saúde.


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.




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.



"inserir".





Fluxos de erro:

Fluxo de erro E1:


ser apresentada.


3. O caso de uso termina..


-

[UC20]: Remover Plano de Saúde


[UC20] Um plano de saúde é retirado da base de dados do sistema da E1-Prosíntese.


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





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


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:


ser apresentada.




-

[UC21]: Visualizar Plano de Saúde


[UC21] São mostradas todas as informações cadastradas sobre o plano de saúde

requisitado.


Atores:


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:


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.



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




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


mostrada na tela.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC22]: Listar Planos de Saúde


[UC22] São mostrados todos os planos de saúde cadastrados no sistema da E1-Prosintese.


Atores:


Entradas:

- Não se aplica

Pré-condições:


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



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


3. A tela de listagem de planos de saúde é novamente ativada para que o usuário prossiga com

sua solicitação.


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:


ser apresentada.




-

1.7. Notas Fiscais

[UC23]: Cadastrar Notas Fiscais


[UC23] Uma nova nota fiscal é inserida na base de dados do sistema da E1-Prosíntese.


Atores:


Entradas:

- ID da nota fiscal, nome do cliente, endereço do cliente, valor, materiais.

Pré-condições:


Fluxo Principal:


a opção de cadastrar nota fiscal.


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.




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.



"inserir".





Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC24]: Remover Nota Fiscal


[UC24] Uma nota fiscal é retirada da base de dados do sistema da E1-Prosíntese.


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





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


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:


ser apresentada.




-

[UC25]: Visualizar Nota Fiscal


[UC25] São mostradas todas as informações cadastradas sobre a nota fiscal requisitada.


Atores:


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




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




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


mostrada na tela.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC26]: Listar Notas Fiscais


[UC26] São mostradas todas as notas fiscais cadastradas no sistema da E1-Prosintese.


Atores:


Entradas:

- Não se aplica

Pré-condições:


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



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


3. A tela de listagem de notas fiscaise é novamente ativada para que o usuário prossiga com

sua solicitação.


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:


ser apresentada.




-

1.8. Relatórios

[UC27]: Relatório de Vendas


[UC27] É gerado um documento com o histórico de vendas realizadas pela empresa em um

dado período.


Atores:

Diretor.

Entradas:

- Período.

Pré-condições:


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.



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:


ser apresentada.




-

[UC28]: Relatório de Fluxo de Caixa


[UC28] É gerado um documento com o balanço financeiro (faturamento, despesas,...) da

empresa em um dado período.


Atores:

Diretor.

Entradas:

- Período.

Pré-condições:


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.




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:


ser apresentada.




-

[UC29]: Relatório de Pendências


[UC29] São mostradas todas as contas que a empresa tem para receber.


Atores:

Supervisor e Diretor.

Entradas:

- Não se Aplica.

Pré-condições:


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.



- Não se aplica.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

[UC30]: Relatório de Cirurgia


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


Atores:


Entradas:

- ID da cirurgia.

Pré-condições:


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.


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.


-

1.9. Autenticação

[UC31]: Autenticar Usuário


[UC31] O sistema faz a verificação dos dados do usuário para permitir ou não o acesso do

mesmo ao sistema.


Atores:


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.



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.


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.


possa entrar no sistema.


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.


possa entrar no sistema.

Fluxos de erro:

Fluxo de erro E1:


ser apresentada.




-

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


Descrição: O banco de dados utilizado deve ser MySQL, deivdo ao seu baixo custo e possuir todos os recursos que o projeto necessita.


Identificação: [NFR03] Padrão MVC


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.


2. Requisitos de Produto 2.1. Segurança

Identificação: [NFR04] Backup Automático


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.


Identificação: [NFR05] Atomicidade de Transações


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.


Identificação: [NFR06] Proteção de Domínio


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.


Identificação: [NFR07] Criptografia


Descrição:

Dados referentes a pessoas devem ser criptografados, para evitar

vazamentos de informações confidenciais durante transações do

sistema.


2.2. Confiabilidade

Identificação: [NFR08] Recuperação


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.


Identificação: [NFR09] Disponibilidade


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.


Identificação: [NFR10] Isolamento de Erros


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.


2.3. Usabilidade

Identificação: [NFR11] Interface Amigável


Descrição: A interface do sistema como um todo deve ser simples de

navegar, com funções objetivas e bem definidas


Identificação: [NFR12] Seqüência de Passos Máxima


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.


Identificação: [NFR13] Mensagens de Erro


Descrição: Todo erro deve ser reportado com clareza ao usuário, através de

mensagens de aviso na tela.


Identificação: [NFR14] Ajuda


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.


Identificação: [NFR15] Orientações contra erros


Descrição: Se o usuário cometer algum erro, o sistema prontamente avisa e

orienta o procedimento correto.


2.4. Interoperabilidade

Identificação: [NFR16] Interoperabilidade


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.


2.5. Performance

Identificação: [NFR17] Tempo de Resposta


Descrição: O sistema não pode demorar mais de 5 s para dar ao usuário uma

resposta sobre alguma solicitação feita.


Identificação: [NFR18] Throughput


Descrição: O sistema deve suportar 30 acessos simultâneos, provenientes de

ambas as empresas.


2.6. Robustez

Identificação: [NFR19] Monitoramento de Rede


Descrição: O sistema deve monitorar constantemente a rede para ser capaz

de informar se dados podem ou não ser transferidos.


Identificação: [NFR20] Checagem de Servidores


Descrição: O sistema deve suportar 30 acessos simultâneos, provenientes de

ambas as empresas.


3. Requisitos de Externos

Identificação: [NFR21] Orçamento


Descrição: O orçamento tem que estar dentro das estimativas do Estudo de

Viabilidade.


Identificação: [NFR22] Cronograma


Descrição: O cronograma estimado no Estudo de Viabilidade deve ser

seguido com, no máximo, uma semana de acréscimo.


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.

RELATÓRIO DA EQUIPE

Aluno: Esforço da Equipe (%): Assinatura:

Adriano Silva Tavares de Melo 25%

Douglas do Nascimento Queiroz 25%

Luiz Felipe de Oliveira Libório 25%

Tiago Oliveira Bernardo 25%

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE...

Documents

Transcript of UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE...