Documento de Requisitos

 

_{UNIVERSIDADE FEDERAL DE PERNAMBUCO} 

CENTRO DE INFORMÁTICA 

GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO 

             

 

Documento de Requisitos 

Sistema Gerenciador de Atendimento  

de Chamados Técnicos 

                Grupo: 

Luiz Augusto Zelaquett de Souza – [email protected] 

Sumário 

1.1.  Visão Geral ... 5  1.2.  Convenções, termos e abreviações ... 5  1.3.  Identificação dos requisitos ... 5  Prioridades dos requisitos ... 5  1.4.  Motivação ... 5  1.5.  Problema identificado ... 6  1.6.  Solução Proposta ... 6  1.7.  Convenções para Identificação dos Requisitos ... 6  1.8.  Convenções para Identificação dos Casos de Uso ... 6  1.8.1.  Estrutura dos casos de uso ... 6  1.8.2.  Prioridades dos casos de uso ... 7  1.8.3.  Descrição dos Atores ... 7  2.  Requisitos Organizacionais ... 8  3.  Requisitos Funcionais (Casos de uso) ... 8  3.1.  [RF001] Login no sistema ... 8  3.2.  [RF002] Logout no sistema ... 8  3.3.  [RF003] Abrir chamado técnico ... 8  3.4.  [RF004] Visualizar chamados ... 9  3.5.  [RF005] Registrar modificação no status dos chamados ... 9  3.6.  [RF006] Repassar chamados ... 9  3.7.  [RF007] Fechar chamados abertos ... 9  3.8.  [RF008] Listar chamados abertos ... 10  3.9.  [RF009] Listar chamados em atendimento ... 10  3.10.  [RF010] Listar chamados fechados ... 10  3.11.  [RF011] Reabrir chamados fechados ... 10  3.12.  [RF012] Adicionar comentários ao chamado aberto ou em atendimento ... 11  3.13.  [RF013] Adicionar novo grupo solucionador ... 11  3.14.  [RF014] Remover grupo solucionador ... 11  3.15.  [RF015] Alterar grupo solucionador ... 11  3.16.  [RF016] Adicionar Funcionário apto ao atendimento ... 12  3.17.  [RF017] Remover Funcionário apto ao atendimento... 12  3.18.  [RF018] Listar Funcionários aptos ao atendimento ... 12  3.19.  [RF019] Avaliação do atendimento ... 12 

3.20.  [RF020] Adicionar permissão de leitura de relatórios ... 13  3.21.  [RF021] Gerar relatórios de atendimento ... 13  4.  Requisitos Não‐Funcionais ... 14  4.1.  Requisitos de Processo ... 14  4.1.1.  [RNF01] Utilizar Extreme Programming como Metodologia de Desenvolvimento  14  4.1.2.  [RNF02] Utilizar linguagem PHP ... 14  4.1.3.  [RNF03] Utilizar Banco de Dados MySQL ... 14  4.2.  Requisitos de Produto ... 15  4.2.1.  Confiabilidade ... 15  4.2.1.1.  [RNF04] Disponibilidade do sistema ... 15  4.2.1.2.  [RNF05] Número conexões ao sistema ... 15  4.2.2.  Desempenho ... 15  4.2.2.1.  [RNF06] Tempo de Resposta ... 15  4.2.2.2.  [RNF07] Espaço de armazenamento ... 15  4.2.3.  Usabilidade ... 16  4.2.3.1.  [RNF08] Interface amigável ... 16  4.2.4.  Segurança ... 16  4.2.4.1.  [RNF09] Controle de acesso ... 16  4.2.4.2.  [RNF10] Integridade ... 16  4.2.4.3.  [RNF11] Backup ... 16  4.2.4.4.  [RNF12] Privacidade ... 17  4.3.  Requisitos Externos ... 17  4.3.1.  [RNF13] Orçamento ... 17  4.3.2.  [RNF14] Tempo de desenvolvimento ... 17  5.  Modelagem organizacional ... 18  5.1.  Modelagem de Dependência Estratégica ... 18  5.2.  Modelo Estratégico da Razão ... 19  5.2.1.  Atendente Expandido ... 19  5.2.2.  Solucionador Expandido ... 19  6.  Modelagem de Requisitos Funcionais (Casos de Uso) ... 20 

Entrevista estruturada ... 24  Observação direta ... 24  Anexo B – Casos de Uso ... 25  Cliente ... 25       

1.1. Visão Geral 

Este documento especifica os requisitos do Sistema Gerenciador de Atendimento de  Chamados Técnicos, fornecendo aos desenvolvedores as informações necessárias para o  projeto e implementação, assim como para a realização dos testes e homologação do sistema. 

1.2. Convenções, termos e abreviações 

A correta interpretação deste documento exige o conhecimento de algumas convenções e  termos específicos, que são descritos a seguir. 

1.3. Identificação dos requisitos 

Por convenção, a referência a requisitos é feita através do identificador do requisito, de acordo  com a especificação a seguir:  [identificador do requisito]  Os requisitos devem ser identificados com um identificador único. A numeração inicia com o  identificador [RF001] ou [RNF001] e prossegue sendo incrementada à medida que forem  surgindo novos requisitos.  Prioridades dos requisitos  Para estabelecer a prioridade dos requisitos, foram adotadas as denominações “essencial”,  “importante” e “desejável”.  

 Essencial  é  o  requisito  sem  o  qual  o  sistema  não  entra  em  funcionamento.  Requisitos  essenciais  são  requisitos  imprescindíveis,  que  têm  que  ser  implementados  impreterivelmente. 

 Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não  satisfatória.  Requisitos  importantes  devem  ser  implementados,  mas,  se  não  forem,  o  sistema poderá ser implantado e usado mesmo assim. 



Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é,  o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis podem ser  deixados  para  versões  posteriores  do  sistema,  caso  não  haja  tempo  hábil  para  implementá‐los na versão que está sendo especificada.  

1.4. Motivação 

Este projeto surge da necessidade de gerenciar os chamados técnicos do Tribunal de Justiça de  Pernambuco. A melhoria da gerência dos chamados vai conferir maior agilidade no  atendimento das necessidades dos usuários que solicitaram sua abertura, e  consequentemente um usuário mais feliz.     

1.5. Problema identificado 

Foi detectado que todo o processo de abertura, repasse e fechamento dos chamados técnicos  demorava muito tempo e poderia ser otimizado.  Alguns problemas encontrados:  ‐ A demora nos atendimentos;  ‐ Envio de equipes para solucionar um problema em uma determinada localidade,  tento outro problema a ser solucionado não comunicado à equipe;  ‐ Não exitência de um feedback do atendimento;   

1.6. Solução Proposta 

Desenvolvimento de um sistema web para gerenciar todos os chamados técnicos do TJPE[2].   

1.7. Convenções para Identificação dos Requisitos 

 

Por  convenção,  os  requisitos  são  indicados  e  referenciados  por  um  indicador  no  formato  [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se  refere  ao  número  do  requisito.  Os  requisitos  também  possuirão  os  nomes  dos  casos  de  uso  relacionados. 

 

1.8. Convenções para Identificação dos Casos de Uso 

 

Por  convenção,  os  casos  de  uso  são  indicados  e  referenciados  por  um  indicador  no  formato  [UCxx], onde xx se refere ao número do caso de uso.        1.8.1. Estrutura dos casos de uso    Cada caso de uso terá o seguinte formato:     Atores: Os modelos de usuário que utilizarão o caso de uso;   Prioridade: Prioridade de implementação deste caso de uso;   Entradas: Variáveis que serão passadas ao sistema; 

 Pré‐condições:  Condições  que  devem  ser  satisfeitas  antes  de  o  caso  de  uso  ser  executado; 

 Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso seja  concluído, podendo incluir fluxos de eventos secundários e/ou alternativos; 

 Saídas:  Saídas  que  devem  ser  fornecidas  pelo  sistema  quando  o  caso  de  uso  for  executado; 

 Pós‐condições:  Condições  que  devem  ser  satisfeitas  depois  de  o  caso  de  uso  ser  finalizado. 

1.8.2. Prioridades dos casos de uso   

Os casos de uso são classificados como:   

 Essencial: É  o caso de uso indispensável ao funcionamento do sistema. Esse tipo de  caso  de  uso  deve  ser  implementado  impreterivelmente,  caso  contrário,  o  projeto  perderá sua utilidade. 

 Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado. Contudo,  essa utilização se dá de forma não satisfatória pelo cliente. 

 Desejável: Esse tipo de caso de uso poderá ser implementado em versões posteriores  do  sistema,  visto  que,  mesmo  sem  a  sua  implementação,  o  sistema  atende  as  suas  funcionalidades básicas.    1.8.3. Descrição dos Atores  Os atores são aqueles que interagem de alguma forma com o sistema.  No sistema existem 4 atores, o Usuário Fim, que solicita e avalia os serviços prestados,  o  Usuário Atendente que repassa os chamados, que gerencia os novos solucionadores, gerentes,  o Usuário Solucionador, que realiza os atendimentos técnicos e o Gerente, que tem todas  atribuições de um solucionador adicionado as dos atendentes. 

 

 

 

2. Requisitos Organizacionais 

Os requisitos organizacionais devem satisfazer os objetivos da organização e definir  porque o sistema é necessário. Esses requisitos são: 

 Tornar  a  abertura  de  chamados  técnico  eficaz  e  que  satisfaça  os  usuários  que  solicitaram o serviço; 

  Obter  informações  sobre  o  tempo  gasto  para  todos  os  atendimentos  e  tornar  o  serviço ainda melhor;     

3. Requisitos Funcionais (Casos de uso) 

  A seguir serão detalhados os casos de uso do sistema de gerência de aplicações. O sistema  desenvolvido deve permitir a execução de cada caso de uso com o funcionamento desejado.   

3.1. [RF001] Login no sistema 

Permite ao usuário informar um login e uma senha para entrar no sistema. Tal usuário terá ao  seu perfil, seja ele atendente ou  solucionador.    Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.2. [RF002] Logout no sistema 

Permite ao usuário sair do sistema.    Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.3. [RF003] Abrir chamado técnico 

Permite ao usuário atendente abrir um chamado técnico.  Caso de uso relacionado: Todos    Prioridade:  

3.4. [RF004] Visualizar chamados 

Permite que o usuário solucionador, visualise os chamados técnicos que estão sob sua  responsabilidade ou os chamados que estão atrelados a outros usuários solucionadores.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante  Desejável 

 

3.5. [RF005] Registrar modificação no status dos chamados 

Desde a abertura até o fechamento de um chamado, os comentários e também algum outro  tipo de atividade que houver no chamado, será resistrada a hora e data desde acontecimento.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante  Desejável 

 

3.6. [RF006] Repassar chamados 

Permite aos usuários atendente ou usuários solucionadores que repassem o chamado aberto  para outra pessoa ou outra equipe.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.7. [RF007] Fechar chamados abertos 

Permite ao usuário solucionador que feche chamados abertos, que já foi atendido por ele.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.8. [RF008] Listar chamados abertos 

Permite aos usuários solucionadores ou usuários atendentes que visualizem os chamados  abertos para sua equipe solucionadora, no caso, se ser um usuário solucionador ou para todas  as equipes, no caso, de usuários atendentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.9. [RF009] Listar chamados em atendimento 

Permite aos usuários solucionadores ou usuários atendentes que visualizem os chamados em  atendimento para sua equipe solucionadora, no caso se ser um usuário solucionador ou para  todas as equipes, no caso, de usuários atendentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.10. [RF010] Listar chamados fechados 

Permite aos usuários solucionadores ou usuários atendentes que visualizem os chamados  fechados para sua equipe solucionadora, no caso, se ser um usuário solucionador ou para  todas as equipes, no caso, de usuários atendentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.11. [RF011] Reabrir chamados fechados 

Permite aos usuários solucionadores ou usuários atendentes que reabram os chamados  fechados para sua equipe solucionadora, no caso, se ser um usuário solucionador ou para  todas as equipes, no caso, de usuários atendentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

   

3.12. [RF012] Adicionar comentários ao chamado aberto ou em 

atendimento 

Permite aos usuários solucionadores ou usuários atendentes que adicionem comentários os  chamados fechados para sua equipe solucionadora, no caso, se ser um usuário solucionador  ou para todas as equipes, no caso, de usuários atendentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.13. [RF013] Adicionar novo grupo solucionador 

Permite que os usuários de atendimento adicionem novos grupos de solucionadores.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.14. [RF014] Remover grupo solucionador 

Permite que os usuários de atendimento removam grupos existentes de solucionadores.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.15. [RF015] Alterar grupo solucionador 

Permite que os usuários de atendimento alterem funções e descrições de grupos existentes de  solucionadores.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.16. [RF016] Adicionar Funcionário apto ao atendimento 

Permite que os usuários de atendimento adicionem novos funcionários em um dos grupos de  solucionadores existentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.17. [RF017] Remover Funcionário apto ao atendimento 

Permite que os usuários de atendimento removam funcionários em um dos grupos de  solucionadores existentes.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.18. [RF018] Listar Funcionários aptos ao atendimento 

Permite que os usuários de atendimento ou usuários técnicos listem todos os funcionários  existentes em um grupo solucionador.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.19. [RF019] Avaliação do atendimento 

Permite que os usuários avaliem os serviços prestados pela equipe de solucionadores, através  da resposta de um email enviado automaticamente após o fechamento do chamado técnico.  Caso de uso relacionado:    Prioridade:  

 Essencial   Importante   Desejável 

 

3.20. [RF020] Adicionar permissão de leitura de relatórios 

Permite que usuários solucionadores recebam credenciais de gerente, para que possam avaliar  o desempenho dos atendimentos através da emissão de relatórios, como o relatório de tempo  de atendimento.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

 

3.21. [RF021] Gerar relatórios de atendimento 

Permite que gerentes possam gerar relatórios sobre os atendimentos dos chamados.  Caso de uso relacionado: Todos    Prioridade:  

 Essencial   Importante   Desejável 

   

4. Requisitos Não­Funcionais 

Este capítulo descreve requisitos relacionados com restrições e aspectos de qualidade. A  classificação desses requisitos segue o autor [Sommerville], que agrupa os mesmos em três  grupos, a saber: requisitos de processo, requisitos de produto e requisitos externos. 

 

4.1. Requisitos de Processo 

 

4.1.1. [RNF01] Utilizar Extreme Programming como Metodologia de 

Desenvolvimento 

  O XP será a metodologia empregada, pois permite agilidade e participação ativa dos  stakeholders. Além disso, como o sistema é relativamente pequeno e de fácil utilização,  não será necessária a geração de uma documentação formal extensa.  Prioridade:  

 Essencial   Importante   Desejável 

 

4.1.2. [RNF02] Utilizar linguagem PHP  

  A aplicação deverá ser toda desenvolvida em PHP.    Prioridade:  

Essencial   Importante   Desejável 

   

4.1.3. [RNF03] Utilizar Banco de Dados MySQL 

  Esse sistema de banco de dados oferece os recursos básicos necessários à aplicação e é  economicamente viável.  Prioridade:  

 Essencial   Importante   Desejável 

   

4.2. Requisitos de Produto 

 

4.2.1. Confiabilidade 

4.2.1.1. [RNF04] Disponibilidade do sistema 

O sistema deve ficar disponível das 8:00 até as 20:00 todos os dias da semana, inclusive  feriados, pois a abertura de chamados pode acontecer fora do horário de expediente normal.  Prioridade:  

 Essencial   Importante   Desejável 

 

4.2.1.2. [RNF05] Número conexões ao sistema 

O sistema deve prover um número de conexões que atenda ao número de usuários que irão  utilizar o sistema. O número exato de conexões disponíveis só será melhor mensurado quando  o sistema estiver em execução, mas a princípio o número de conexões será de 100 conexões  ao sistema.    Prioridade:  

 Essencial   Importante   Desejável 

   

4.2.2. Desempenho 

 

4.2.2.1. [RNF06] Tempo de Resposta 

O sistema deve permitir a alteração do status dos chamados ou adição de comentário de  forma rápida, não deve demorar mais do que 1 segundo, para que o novo status ou  comentário esteja disponível para todos usuários técnicos ou de atendimento.  Prioridade:  

 Essencial   Importante   Desejável 

 

4.2.2.2. [RNF07] Espaço de armazenamento 

O espaço de armazenamento utilizado para guardar as informações do sistema não deve  exceder 85% da capacidade de armazenamento do servidor. 

4.2.3. Usabilidade 

 

4.2.3.1. [RNF08] Interface amigável 

  O sistema deve ter uma interface amigável e de fácil utilização, e que não torne o trabalho  diário dos que utilizarão o sistema diariamente.  Prioridade:  

 Essencial   Importante   Desejável 

   

4.2.4. Segurança 

 

4.2.4.1. [RNF09] Controle de acesso 

  O sistema só deve permitir o acesso aos usuários solicionadores e aos usuários de  atendimento.  Prioridade:  

 Essencial   Importante   Desejável 

 

4.2.4.2. [RNF10] Integridade 

  Os dados armazenados e consultados deverão estar corretos em relação aos dados  fornecidos ao sistema.  Prioridade:  

 Essencial   Importante   Desejável 

 

4.2.4.3. [RNF11] Backup 

  A cópia de segurança do banco de dados para recuperação ou armazenamento deve ser  realizada numa periodicidade de cada semana.  Prioridade:  

 Essencial   Importante   Desejável 

 

4.2.4.4. [RNF12] Privacidade 

 

Apenas os Gerentes e Operadores podem gerar o relatório.  Prioridade:  

 Essencial   Importante   Desejável 

     

4.3. Requisitos Externos 

 

4.3.1. [RNF13] Orçamento 

  O custo, com o desenvolvimento do sistema, não poderá superar o estimado no Estudo de  Viabilidade.  Prioridade:  

 Essencial   Importante   Desejável 

   

4.3.2. [RNF14] Tempo de desenvolvimento 

  O tempo com o desenvolvimento do sistema não poderá superar em mais de 30% o  estimado no Estudo de Viabilidade.   Prioridade:  

 Essencial   Importante   Desejável 

   

5. Modelagem organizacional 

  A modelagem organizacional utilizada é feita com base na notação i* (i estrela).   

5.1. Modelagem de Dependência Estratégica 

           

 

5.2. Modelo Estratégico da Razão 

 

5.2.1. Atendente Expandido 

 

5.2.2. Solucionador Expandido 

 

6. Modelagem de Requisitos Funcionais (Casos de Uso) 

  Neste capítulo, os requisitos descritos anteriormente são modelados através de diagramas de  caso de uso. O detalhamento dos casos de uso encontra‐se no Anexo C deste documento.     

7. Modelagem de Requisitos Não­Funcionais (NFR Framework) 

  Este capítulo contém os refinamentos dos requisitos não‐funcionais, descreve suas  interdependências e operacionalizações.         

 

8. Conclusão 

  Através do documento de requisitos, foi possível entender, através de uma breve descrição  nos capítulos 1 e 2, o problema a ser resolvido com o Sistema Gerenciador de Atendimento de  Chamados.   Em seguida, no capítulo 3 foram apresentados todos os requisitos funcionais do sistema, isto  é, todos os serviços que o Sistema Gerenciador de Atendimento de Chamados Técnicos deve  oferecer aos seus usuários.  Seguindo os requisitos funcionais, no capítulo 4 foram apresentados os requisitos não  funcionais, que definem restrições de como o sistema irá funcionar baseado em seus  requisitos funcionais.   No capítulo 5, foi abordada a modelagem organizacional do sistema usando a notação i*, em  que foram incluídos os modelos de dependência estratégica (SD) e o modelo estratégico de  razão (SR) com os atores Atendente e  Solucionador.  No capítulo 6, dando continuidade à modelagem de requisitos funcionais, através do diagrama  de casos de uso, foram descritos os casos de uso do sistema, incluindo seus fluxos de eventos e  dependências entre si.  Finalmente, no capítulo 7, foi feita a modelagem dos requisitos não funcionais utilizando a  plataforma NFR, mostrando os refinamentos deles, explicitando operacionalizações e  interdependências entre eles.     

9. Referências 

  [1] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and        Techniques ,  John Wiley & Sons, 1998.  [2] Disciplina de Especificação de Requisitos e Validação de Sistemas. Disponível em:  <http://www.cin.ufpe.br/~if716>. Acesso em: 25 mai. 2011.     

Apêndice A – Técnicas Utilizadas na Coleta de Dados 

 

As  técnicas  de  coleta  de  dados  utilizadas  foram  três:  Entrevista  estruturada  e  Observação  direta. Seguem as descrições de cada técnica.  

 

Entrevista estruturada 

 

A  entrevista  pode  ser  definida  como  um  processo  de  interação  social  entre  duas  pessoas  na  qual  uma  delas,  o  entrevistador,  tem  por  objetivo  a  obtenção  de  informações  por  parte  do  outro,  o  entrevistado.  Quando  o  pesquisador  faz  um  roteiro  a  ser  seguido,  a  entrevista  é  chamada  estruturada.  Este  roteiro  deve  conter  uma  lista  de  pontos  ou  tópicos  previamente  estabelecidos de acordo com a problemática central da pesquisa, bem como de acordo com os  objetivos específicos previamente propostos.   Utilizamos essa técnica para coletar informações importantes de um ator primário do sistema:  O usário a quem será prestado o serviço.    

Observação direta 

 

Essa  técnica  tem  como  função  a  coleta  de  informações  de  forma  observacional,  formal  ou  informalmente,  de  um  indivíduo  ou  grupo  em  um  determinado  ambiente  sobre  um  determinado fato ou situação. Como a observação foi realizada pelos próprios pesquisadores,  ela é dita direta.    A situação observada foi a forma como os técnicos manipulavam os chamados técnicos, desde  sua abertura até seu fechamento.      

Anexo B – Casos de Uso 

 

Cliente 

  Identificador:  [UC 01]  Solicitar abertura de chamado  Descrição:  Cadastra um novo Gerente.  Ator:  Usuário fim, atendente, gerente ou solucionador.  Prioridade:  Essencial  Pré‐condições:   Ligar para a central de telefônica de abertura de chamados  Pós‐condições:  Protocolo de abertura aberto 

Fluxo de Eventos Principal  

1. Usuário fim liga para a central de abertura de chamados;  2. Usuário fim informa o problema técnico existente;  3. Atendente protocola o chamado. 

Requisitos Não Funcionais Específicos -

  Identificador:  [UC 02]  Logar no sistema  Descrição:  Autentica o usuário no sistema.  Ator:  Usuário atendente, gerente ou usuário solucionador.  Prioridade:  Essencial  Pré‐condições:  Usuário conectado a internet, acessa a página do sistema.  Pós‐condições:  Usuário logado no sistema. 

Fluxo de Eventos Principal  

  Identificador:  [UC 03]  Sair do sistema  Descrição:  Sair do sistema.  Ator:  Usuário atendente, gerente ou usuário solucionador.  Prioridade:  Essencial  Pré‐condições:  Está logando no sistema.  Pós‐condições:  Ir para a tela de login do sistema. 

Fluxo de Eventos Principal  

1. Aperta o botão Sair do sistema;  2. Ir para a tela de login do sistema. 

Requisitos Não Funcionais Específicos -

  Identificador:  [UC 04]  Abrir chamado  Descrição:  Abrir um chamado técnico  Ator:  Usuário atendente, gerente ou usuário solucionador.  Prioridade:  Essencial  Pré‐condições:  Não ser usuário fim.  Pós‐condições:  Chamado aberto 

Fluxo de Eventos Principal   1. Acessa o site do sistema;  2. Insere o login e senha;  3. Acessa o sistema;  4. Abre o chamado.   

Requisitos Não Funcionais Específicos -

   

    Identificador:  [UC 05]  Atender chamado  Descrição:  Atender os chamados definidos para um usuário solucionador.  Ator:  Usuário solucionador.  Prioridade:  Essencial  Pré‐condições:  Está logado no sistema;  O chamado está assinalado para o usuário solucionador em questão.  Pós‐condições:  Habilitado a atender o chamado. 

Fluxo de Eventos Principal  

1. Verifica as necessidades para atender o chamado;  2. Vai atender o chamado. 

Requisitos Não Funcionais Específicos -

    Identificador:  [UC 06]  Adicionar comentário ao chamado  Descrição:  Possibilita adicionar comentários aos chamados, informando dificuldades, ou  quaisquer outras informações pertinentes ao atendimento do chamado.  Ator:  Usuário atendente, gerente ou usuário solucionador.  Prioridade:  Essencial  Pré‐condições:  Está logado no sistema;  O chamado está assinalado para o usuário solucionador em questão  Pós‐condições:  Comentário adicionado. 

Identificador:  [UC 07]  Modificar status do chamado  Descrição:  Alterar o status entre aberto, em atendimento, aguardando avaliação,  fechado.  Ator:  Usuário atendente, gerente ou usuário solucionador.  Prioridade:  Essencial  Pré‐condições:  Selecionar o chamado em questão.  Pós‐condições:  Status do chamado alterado. 

Fluxo de Eventos Principal  

1. Seleciona o chamado em que se deseja adicionar o comentário;  2. Adição do novo status do chamado; 

3. Status alterado. 

Requisitos Não Funcionais Específicos -

    Identificador:  [UC 08]  Avaliar atendimento  Descrição:  O Usuário fim vai poder avaliar a qualidade do serviço prestado pelo  solucionador.  Ator:  Usuário fim e gerente.  Prioridade:  Essencial  Pré‐condições:  Chamado atendido e aguardando avaliação.  Pós‐condições:  Chamado avaliador e finalizado. 

Fluxo de Eventos Principal  

1. O chamado foi atendido pelo usuário solucionador; 

2. O usuário fim recebeu um email para avaliar o atendimento;  3. O usuário fim responde o  email e o gerente recebe esse email; 

4. O gerente define pela reabertura do chamado ou fechamento do mesmo.l  Requisitos Não Funcionais Específicos -

Identificador:  [UC 09]  Finalizar chamado  Descrição:  O gerente recebe o email de avaliação de atendimento do chamado, enviado  pelo usuário fim, e define pelo fechamento do chamado.  Ator:  Gerente.  Prioridade:  Essencial  Pré‐condições:  O gerente recebe o email de avaliação do atendimento do chamado.  Pós‐condições:  Chamado fechado ou reaberto, dependendo da avaliação dada pelo usuário  fim. 

Fluxo de Eventos Principal  

1. O gerente recebe email para da avaliação do atendimento;  2. O gerente analisa se o chamado deverá ser fechado ou reaberto;  Requisitos Não Funcionais Específicos -

    Identificador:  [UC 10]  Gerenciar grupo solucionador  Descrição:  Cadastrar, Procurar e Remover grupo solucionador  Ator:  Usuário atendente ou gerente.  Prioridade:  Essencial  Pré‐condições:  O gerente dá o ok, sobre a gerência de um novo grupo solucionador ao  atendente, ou ele mesmo, o gerente, realiza as tarefas desejadas.  Pós‐condições:  O grupo solucionador é  gerenciado. 

Fluxo de Eventos Principal  

1. O gerente habilita um usuário atendente a poder gerenciar momentaneamente um grupo  solucionador, ou ele mesmo faz essa tarefa; 

    Identificador:  [UC 11]  Gerenciar funcionário  Descrição:  Cadastrar, Procurar e Remover funcionários  Ator:  Usuário atendente ou gerente.  Prioridade:  Essencial  Pré‐condições:  O gerente dá o ok, sobre a gerência de um funcionário, ao atendente, ou ele  mesmo, o gerente, realiza as tarefas desejadas.  Pós‐condições:  O funcionário é gerenciado. 

Fluxo de Eventos Principal  

1. O  gerente  habilita  um  usuário  atendente  a  poder  gerenciar  momentaneamente  o  funcionário, ou ele mesmo faz essa tarefa; 

2. O funcionário é gerenciado.   

Requisitos Não Funcionais Específicos -

  Identificador:  [UC 12]  Gerar relatório  Descrição:  O gerente pode gerar relatórios sobre o atendimento, contendo os  comentários e o tempo de atendimento, e também informações  consolidadas como a quantidade de chamados num período, por exemplo.  Ator:  Gerente  Prioridade:  Essencial  Pré‐condições:  Ser gerente.  Pós‐condições:  Relatórios gerados. 

Fluxo de Eventos Principal  

1. Seleciona a abertura de relatórios no sistema.  2. Os relatórios são gerados em PDF. 

Identificador:  [UC 13]  Autorizar gerência de grupo solucionador  Descrição:  O gerente pode habilitar um atendente a administrar a gerência de um grupo  solucionador.  Ator:  Usuário atendente ou gerente.  Prioridade:  Essencial  Pré‐condições:  O gerente ver a necessidade de gerenciar um grupo solucionador.  Pós‐condições:  Gerência do grupo solucionador poderá ser efetivada. 

Fluxo de Eventos Principal  

1. O gerente solicita que seja liberado o acesso de gerência a um atendente, para que esse  efetue as modificações necessárias. 

Requisitos Não Funcionais Específicos -

  Identificador:  [UC 14]  Autorizar gerência de funcionários  Descrição:  O gerente pode habilitar um atendente a administrar a gerência de um  funcionário.  Ator:  Usuário atendente ou gerente.  Prioridade:  Essencial  Pré‐condições:  O gerente ver a necessidade de gerenciar um funcionário.  Pós‐condições:  Gerência de um funcionário poderá ser efetivada. 

Fluxo de Eventos Principal  

1. O gerente solicita que seja liberado o acesso de gerência a um atendente, para que esse  efetue as modificações necessárias. 

Requisitos Não Funcionais Específicos -