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 lazs@cin.ufpe.br RECIFE, JUNHO DE 2011 1

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 2

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 7. Modelagem de Requisitos Não Funcionais (NFR Framework)... 21 8. Conclusão... 22 9. Referências... 23 Apêndice A Técnicas Utilizadas na Coleta de Dados... 24 3

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

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

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

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

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. 3.2. [RF002] Logout no sistema Permite ao usuário sair do sistema. 3.3. [RF003] Abrir chamado técnico Permite ao usuário atendente abrir um chamado técnico. 8

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. 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. 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. 3.7. [RF007] Fechar chamados abertos Permite ao usuário solucionador que feche chamados abertos, que já foi atendido por ele. 9

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

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. 3.13. [RF013] Adicionar novo grupo solucionador Permite que os usuários de atendimento adicionem novos grupos de solucionadores. 3.14. [RF014] Remover grupo solucionador Permite que os usuários de atendimento removam grupos existentes de solucionadores. 3.15. [RF015] Alterar grupo solucionador Permite que os usuários de atendimento alterem funções e descrições de grupos existentes de solucionadores. 11

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. 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. 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. 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: Essencial Importante Desejável 12

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. Essencial Importante Desejável 3.21. [RF021] Gerar relatórios de atendimento Permite que gerentes possam gerar relatórios sobre os atendimentos dos chamados. Essencial Importante Desejável 13

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. 4.1.2. [RNF02] Utilizar linguagem PHP A aplicação deverá ser toda desenvolvida em PHP. 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. 14

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

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. 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. 4.2.4.2. [RNF10] Integridade Os dados armazenados e consultados deverão estar corretos em relação aos dados fornecidos ao sistema. 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. 16

4.2.4.4. [RNF12] Privacidade Apenas os Gerentes e Operadores podem gerar o relatório. 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. 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. Essencial Importante Desejável 17

5. Modelagem organizacional A modelagem organizacional utilizada é feita com base na notação i* (i estrela). 5.1. Modelagem de Dependência Estratégica 18

5.2. Modelo Estratégico da Razão 5.2.1. Atendente Expandido 5.2.2. Solucionador Expandido 19

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

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

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

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

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

Anexo B Casos de Uso Cliente Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 01] Solicitar abertura de chamado Cadastra um novo Gerente. Usuário fim, atendente, gerente ou solucionador. Essencial Ligar para a central de telefônica de abertura de chamados 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: Descrição: Ator: Pré condições: Pós condições: [UC 02] Logar no sistema Autentica o usuário no sistema. Usuário atendente, gerente ou usuário solucionador. Essencial Usuário conectado a internet, acessa a página do sistema. Usuário logado no sistema. Fluxo de Eventos Principal 1. Acessa o site. 2. Logado no sistema. Requisitos Não Funcionais Específicos - 25

Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 03] Sair do sistema Sair do sistema. Usuário atendente, gerente ou usuário solucionador. Essencial Está logando no sistema. 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: Descrição: Ator: Pré condições: Pós condições: [UC 04] Abrir chamado Abrir um chamado técnico Usuário atendente, gerente ou usuário solucionador. Essencial Não ser usuário fim. 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 - 26

Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 05] Atender chamado Atender os chamados definidos para um usuário solucionador. Usuário solucionador. Essencial Está logado no sistema; O chamado está assinalado para o usuário solucionador em questão. 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: Descrição: Ator: Pré condições: Pós condições: [UC 06] Adicionar comentário ao chamado Possibilita adicionar comentários aos chamados, informando dificuldades, ou quaisquer outras informações pertinentes ao atendimento do chamado. Usuário atendente, gerente ou usuário solucionador. Essencial Está logado no sistema; O chamado está assinalado para o usuário solucionador em questão Comentário adicionado. Fluxo de Eventos Principal 1. Seleciona o chamado em que se deseja adicionar o comentário; 2. Adiciona o comentário. Requisitos Não Funcionais Específicos - 27

Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 07] Modificar status do chamado Alterar o status entre aberto, em atendimento, aguardando avaliação, fechado. Usuário atendente, gerente ou usuário solucionador. Essencial Selecionar o chamado em questão. 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: Descrição: Ator: Pré condições: Pós condições: [UC 08] Avaliar atendimento O Usuário fim vai poder avaliar a qualidade do serviço prestado pelo solucionador. Usuário fim e gerente. Essencial Chamado atendido e aguardando avaliação. 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 - 28

Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 09] Finalizar chamado O gerente recebe o email de avaliação de atendimento do chamado, enviado pelo usuário fim, e define pelo fechamento do chamado. Gerente. Essencial O gerente recebe o email de avaliação do atendimento do chamado. 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: Descrição: Ator: Pré condições: Pós condições: [UC 10] Gerenciar grupo solucionador Cadastrar, Procurar e Remover grupo solucionador Usuário atendente ou gerente. Essencial 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. 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; 2. O grupo solucionador é gerenciado. Requisitos Não Funcionais Específicos - 29

Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 11] Gerenciar funcionário Cadastrar, Procurar e Remover funcionários Usuário atendente ou gerente. Essencial O gerente dá o ok, sobre a gerência de um funcionário, ao atendente, ou ele mesmo, o gerente, realiza as tarefas desejadas. 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: Descrição: Ator: Pré condições: Pós condições: [UC 12] Gerar relatório 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. Gerente Essencial Ser gerente. 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. Requisitos Não Funcionais Específicos - 30

Identificador: Descrição: Ator: Pré condições: Pós condições: [UC 13] Autorizar gerência de grupo solucionador O gerente pode habilitar um atendente a administrar a gerência de um grupo solucionador. Usuário atendente ou gerente. Essencial O gerente ver a necessidade de gerenciar um grupo solucionador. 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: Descrição: Ator: Pré condições: Pós condições: [UC 14] Autorizar gerência de funcionários O gerente pode habilitar um atendente a administrar a gerência de um funcionário. Usuário atendente ou gerente. Essencial O gerente ver a necessidade de gerenciar um funcionário. 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 - 31