CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Especificação e Análise de Requisitos
Especificação de Requisitos
Equipe:
Edemilson Dantas
Eudes Cavalcanti
Leonardo Batista
Osman Torres
1
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Sumário
1. Introdução............................................................................................................................4
1.1. Motivação.....................................................................................................................4
1.2. Problema identificado..................................................................................................4
1.3. Solução proposta..........................................................................................................5
1.4. Convenções para Identificação dos Requisitos.........................................................6
1.5. Convenções para Identificação dos Casos de Uso.....................................................6
1.5.1. Estrutura dos casos de uso.................................................................................6
1.5.2. Prioridades dos casos de uso.............................................................................7
1.5.3. Descrição dos Atores..........................................................................................7
2. Requisitos Organizacionais...................................................................................................7
3. Requisitos Funcionais...........................................................................................................8
3.1. Sistema do Usuário Final..............................................................................................8
3.2. Sistema do Administrador de Contato.........................................................................9
3.3. Sistema do Operador de Chamado.............................................................................12
3.4. Sistema do Administrador do Sistema........................................................................13
3.5. Comunicação..............................................................................................................15
3.6. Busca de Chamados....................................................................................................15
3.7. Acesso........................................................................................................................17
4. Requisitos Não-Funcionais.................................................................................................17
4.1. Requisitos de produto................................................................................................17
4.1.1 Usabilidade................................................................................................................17
4.1.2 Controle de acesso....................................................................................................18
4.1.3 Segurança..................................................................................................................19
4.2. Requisitos de processo...............................................................................................20
4.3 Requisitos externos....................................................................................................21
5. Modelagem Organizacional................................................................................................22
5.1. Modelagem de Dependência Estratégica.................................................................22
2
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
5.2. Modelo Estratégico da Razão...................................................................................23
6. Modelagem de Requisitos Funcionais (Casos de Uso)....................................................24
6.1. Sistema do Usuário Final............................................................................................24
6.2. Sistema do Administrador de Contato.......................................................................25
6.3. Sistema do Operador de Chamado.............................................................................26
6.4. Sistema do Administrador do Sistema........................................................................27
6.5. Comunicação..............................................................................................................28
6.6. Busca de Chamados....................................................................................................29
6.7. Acesso ao Sistema......................................................................................................30
7. Modelagem de Requisitos Não-Funcionais (NFR Framework)........................................30
8. Conclusão...........................................................................................................................32
9. Referências.........................................................................................................................32
Apêndice A – Contexto Atual.....................................................................................................33
Apêndice B – Técnicas Utilizadas na Coleta de Dados................................................................35
Apêndice C – Casos de uso.........................................................................................................36
Apêndice D – Glossário..............................................................................................................55
3
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1. Introdução
O objetivo deste documento é descrever o problema que foi identificado e especificar os requisitos para a solução encontrada durante a fase de estudo de viabilidade realizada previamente. Essa solução tem como centro um sistema de informação que deve ser construído a partir das informações capturadas pela utilização de algumas técnicas descritas adiante.
1.1. Motivação
Várias organizações têm seus processos que definem como procedimentos devem ser realizados. Quanto maior a organização, mais bem definidos devem ser os processos. Uma vez que isso esteja definido, sistemas de informação podem mediar a realização das tarefas e atividades dessas organizações.
No estudo de viabilidade descrito neste documento procuramos propor alternativas de sistemas de informação que solucionem o problema da Universidade Federal de Pernambuco na gestão do relacionamento entre alunos e professores com suas secretarias e coordenadorias.
1.2. Problema identificado
Atualmente, na Universidade Federal de Pernambuco (UFPE), alunos, professores e outras pessoas ligadas à universidade que tem algum problema ou dúvida relacionada à graduação, pós-graduação, mestrado ou doutorado estabelecem um contato com os possíveis solucionadores desse problema das seguintes formas:
Telefone: Um usuário final, como um aluno, pode entrar em contato com a sua secretaria, por exemplo, para reportar um problema sobre suas notas ou de acesso ao SIG@.
Presencial: Esse mesmo aluno pode ir a uma secretaria reportar um problema. Email: Um aluno, com conhecimento do endereço de email do coordenador do seu
curso, pode lhe mandar uma mensagem sobre um determinado problema.
Mais informações sobre o ambiente atual no Apêndice A.
De acordo com as entrevistas realizadas entre a equipe e o cliente José Queiroz, diretor do NTI (Núcleo de Tecnologia da Informação da UFPE), e a analista de Tecnologia da Informação, Ana Paula e Marcela do SIG@tende, foi percebido que não há nenhum outro meio, exceto por telefone ou presencial, em que os alunos ou professores possam tirar suas dúvidas ou reportar problemas em relação a informações gerais sobre a UFPE ou ao SIG@.
Foi notada no processo citado acima a presença de três tipos de atores envolvidos nesse relacionamento entre alunos/professores e solucionadores do problema ou dúvidas dos usuários finais. São eles:
4
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Usuário final: trata-se do aluno, professor ou outra qualquer pessoas que tenha alguma dúvida ou problema relacionado às suas atividades dentro da universidade (UFPE).
Administrador de chamado: São as pessoas do administrativo da universidade, diretores ou coordenadores de cursos no qual os usuários finais podem entrar em contato para reportar um problema ou dúvida. Qualquer forma de contato realizado pelos usuários finais nós classificamos neste documento como ‘chamado’. Sendo assim, o ator descrito como ‘administrador de chamado’ é basicamente o responsável por atender o usuário final.
Operador de chamado: No ambiente atual, esse é o ator responsável por resolver/solucionar o chamado de um usuário final. O administrador de chamado pode ser classificado também como Operador de Chamado caso o chamado possa ser solucionado dentro da sua área de trabalho na universidade.
Mais informações sobre atores no Apêndice A.
Tendo em vista esse contexto de procedimentos e atores, podemos perceber problemas que afetam principalmente os usuários finais e os administradores de chamado.
Para o usuário final, há a dificuldade inicial de saber quem pode ser o solucionador do seu problema. E também foi observado que na universidade não é claro, nem mesmo para os administradores de chamado, quem é o responsável por resolver um determinado problema do usuário final. Isso faz com que o aluno ou professor se perca e não saiba para qual departamento ou secretaria da universidade eles devem entrar em contato ou se deslocar para solucionar a sua situação.
Uma vez realizado o contato e o chamado seja aberto pelos administradores de chamado, há uma ineficiência na gerência para uma devida solução do problema. Dentro da estrutura organizacional com vários papéis não bem definidos de quem são os devidos operadores de chamado, muitas vezes a solução de um problema se perde e não chega a ser reportado ao usuário final da melhor forma possível ou em um tempo satisfatório.
No geral os chamados não são facilmente realizados pelos usuários finais e não são gerenciados/resolvidos da forma mais adequada pelos administradores e operadores de chamado. Trata-se, basicamente, de um problema de gestão da informação.
1.3. Solução proposta
A nossa idéia é encontrar uma maneira de obter de qualquer meio utilizado pelos usuários finais as opiniões, sugestões e problemas sobre o SIG@, trazendo essas informações de uma maneira mais fácil para o sistema e para os administradores de um chamado. Para isso propomos o SIG@ contato: uma plataforma de suporte ao atendimento do usuário e gestão de chamados.
5
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Os seguintes atores podem ser identificados no sistema: usuário final (alunos, professores, etc), administrador de contato (secretarias, coordenadores, etc), operadores de chamado (SIG@ atende, NTI, etc) e administrador do sistema.
Os usuários finais podem entrar em contato através da interface do sistema (mensagens ou chat) ou dos meios de comunicação pessoais (email pessoal, perfis de redes sociais e chats).
O administrador de contato receberá mensagens de um usuário final e vai abrir um chamado para solucionar o problema. Ele é o único que terá contato com o usuário que solicitou algo e terá o papel de gerenciar o andamento do chamado em aberto. Esse ator não é o solucionador do problema do usuário final, mas é quem será sempre cobrado, por esse mesmo usuário, por alguma resposta.
Os operadores de chamado são alocados pelo administrador de contato para resolver um chamado que foi aberto. Ele deverá reportar a solução do problema para que o administrador comunique ao usuário que entrou em contato. Administradores de contato podem ser operadores de chamado, mas para que isso fique claro, tal papel deverá ser definido no sistema.
O administrador do sistema é o responsável por cadastrar os administradores de contato e os operadores de chamado, tendo cada um deles seus níveis de permissão no sistema.
Os usuários finais poderão então se conectar através de redes sociais (Facebook, Twitter, etc) e outros canais de entrada para resolver algum problema. Além de poderem dar suas opiniões e reclamações, eles receberiam também o resultado desses chamados de maneira mais rápida e prática.
1.4. 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.5. 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.5.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;
6
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
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.5.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.5.3. Descrição dos Atores
Os atores são aqueles que interagem de alguma forma com o sistema. Eles são membros da Universidade Federal de Pernambuco. De alunos e professores até administradores e coordenadores de curso.
2. Requisitos Organizacionais
Tais requisitos têm a responsabilidade de atender as necessidades do cliente (organização), além de, é claro, mostrar por qual razão a solução é necessária. Veja-os:
Aproximar o problema da solução: fazer com que o usuário consiga resolver seu problema da forma mais rápida possível;
Aumentar o conhecimento do usuário em relação à organização: fazer com que através dessa solução, se conheça mais como a organização é formada, bem como ela funciona;
Manter os cargos da organização úteis: fazer com que a devida responsabilidade em resolver o problema seja dada a parte cabível da organização, assim evitando que essa seja “jogada” para quem não tem jurisdição sobre a mesma.
7
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
3. Requisitos Funcionais
Nesta seção trataremos dos requisitos funcionais do Sig@ Contato. Esses são os requisitos que descrevem as funcionalidades do sistema desejadas pelos clientes, ou seja, o que o software fará. Os requisitos foram agrupados em categorias para facilitar o entendimento e a manutenção da documentação do sistema. Os casos de uso correspondentes estão descritos no Apêndice C. Para facilitar o entendimento, tanto os requisitos funcionais quanto os casos de uso correspondentes foram divididos em 7 pacotes de acordo com as funcionalidades: sistema do usuário final, sistema do administrador de contato, sistema do operador de chamado, sistema do administrador do sistema, comunicação, busca de chamados e acesso ao sistema.
3.1. Sistema do Usuário Final
Identificação: [RF01] Visualizar chamados/soluções publicados
Casos de Uso relacionados: [UC01]
Descrição:
Permite que o usuário final possa visualizar soluções de chamados tornados público para o sistema. Tal usuário terá no seu perfil todas essas informações publicadas pelo sistema.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF02] Buscar contato por lista
Casos de Uso relacionados: [UC02]
Descrição:
Permite que o usuário final possa encontrar o administrador de contato com quem ele pode estabelecer contato enviando uma mensagem pelo sistema, realizando um chat (bate-papo) ou fazendo uma ligação. Essa busca se dá através de uma página contendo uma lista com todos os contatos possíveis. Dependendo do número de contatos presentes no sistema essa lista estará em ordem alfabética e em páginas numeradas.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF03] Buscar contato por pesquisa
Casos de Uso relacionados: [UC03]
Descrição: Permite que o usuário final possa encontrar o administrador
8
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
de contato com quem ele pode estabelecer contato enviando uma mensagem pelo sistema, realizando um chat (bate-papo) ou fazendo uma ligação. Essa busca se dá através de uma pesquisa através de um campo de busca geral.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
3.2. Sistema do Administrador de Contato
Identificação: [RF04] Editar configurações de contato
Casos de Uso relacionados: [UC04]
Descrição:
Todos os administradores de contato podem alterar suas próprias informações de contato. Eles podem atualizar dados como contas de email, chat (bate-papo) e contas de redes sociais.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF05] Publicar chamados/solução
Casos de Uso relacionados: [UC05]
Descrição:
Os administradores de chamado podem tornar públicas mensagens associadas com propostas de soluções para que o usuário final descubra as respostas para as dúvidas mais freqüentes. A pergunta realizada pelo usuário final que for publicada não acompanha o seu nome ou qualquer tipo de identificação.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF06] Solicitar cadastro de operador de chamado
Casos de Uso relacionados: [UC06]Descrição: Um administrador de contato (AC) pode solicitar ao
administrador do sistema (OS) o cadastro de um novo operador de chamado (OC) que será responsável por resolver o problema do usuário final. O AC pode achar necessário tal procedimento caso ele não encontre no
9
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
sistema algum OC que ele considere capaz de ser responsável por resolver o chamado/problema. Essa solicitação se dá através de uma mensagem enviada para o OS.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF07] Abrir chamado
Casos de Uso relacionados: [UC07]
Descrição:
Após estabelecer contato com o usuário final através de troca de mensagem, chat (bate-papo) ou telefonema, o administrador de contato (AC) poderá decidir pela abertura de um chamado no qual ele alocará um operador de chamado que reportará posteriormente uma solução. Nessa abertura é essencial o AC inserir dados como informações para identificar o usuário final, tipo de chamado, urgência do chamado e responsáveis pelo contato/solução.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF08] Registrar usuário final
Casos de Uso relacionados: [UC08]
Descrição:
O administrador de contato deve registrar informações que identifique de forma única o usuário final e deixe claro qual a forma de contato com o mesmo. Cada usuário final que pode ser cadastrado no sistema é identificado pelo seu número de registro na universidade.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF09] Classificar urgência
Casos de Uso relacionados: [UC09]
Descrição:
O administrador de contato (AC) deve registrar o grau de urgência do chamado para deixar claro para todos que a acessam o sistema a pendência dos problemas não resolvidos. A classificação pode será: muito urgente, urgente, normal, pouco urgente, muito pouco urgente.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
10
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Identificação: [RF10] Classificar tipo de chamado
Casos de Uso relacionados: [UC10]
Descrição:O administrador de contato (AC) deve registrar o tipo de chamado para facilitar a categorização do mesmo no sistema e busca por algum chamado desejado.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF11] Alocar administrador
Casos de Uso relacionados: [UC11]
Descrição:
Na abertura de um chamado, o administrador de contato (AC) deve registrar ele como o AC responsável por realizar contatos posteriores com usuário final. Em caso da não possibilidade de ser o AC responsável, ele pode registrar uma outra pessoa no seu lugar.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF12] Alocar operadores
Casos de Uso relacionados: [UC12]
Descrição:
Na abertura de um chamado, o administrador de contato (AC) deve registrar um ou mais operadores de chamados (OC) para um mesmo chamado inserido no sistema. No caso de mais de um OC for alocado apenas um deles será marcado como o OC responsável pelo problema.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF13] Restringir visualização de dados do operador
Casos de Uso relacionados: [UC13]
Descrição:
Nesse procedimento, o administrador de contato poderá editar o nível de responsabilidade de cada operador de chamado (OC) alocado. Isso restringe que tipo de informação do usuário final o OC poderá visualizar.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
11
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Identificação: [RF14] Atualizar chamado aberto
Casos de Uso relacionados: [UC14]
Descrição:O administrador de contato poderá atualizar todas as informações inseridas no procedimento do requisito “[RF07] Abrir chamado”.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF15] Finalizar chamado
Casos de Uso relacionados: [UC15]
Descrição:
O administrador de contato (AC) deve sempre buscar finalizar um chamado e entrar em contato com o usuário final lhe entregando a proposta de solução enviada pelo operador de chamado (OC). Esse contato final com usuário se dá através email ou telefone. Uma vez que o OC reportar a solução ou a inviabilidade da solução o AC poderá decidir por finalizar um chamado. Esse acompanhamento do chamado se dá através de uma thread de mensagens trocadas entre o AC e o OC.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
3.3. Sistema do Operador de Chamado
Identificação: [RF16] Reportar solução do chamado
Casos de Uso relacionados: [UC16]
Descrição:
O operador de chamado (OC) será constantemente cobrado pelo administrador de contato (AC) através de uma thread de mensagens e o OC reportará uma solução ou a inviabilidade da solução para o AC .
Prioridade: þ Essencial ¨ Importante ¨ Desejável
12
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
3.4. Sistema do Administrador do Sistema
Identificação: [RF17] Inserir operador de chamado
Casos de Uso relacionados: [UC17]
Descrição:
Após ser solicitado pelo administrador de contato (OC) através de uma mensagem (contendo as informações necessárias para o procedimento) o administrador do sistema (OS) poderá inserir ou não o operador de chamado solicitado.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF18] Inserir administrador de contato
Casos de Uso relacionados: [UC18]
Descrição:O administrador do sistema (OS) poderá inserir ou não um administrador de contato no sistema. A solicitação para esse procedimento não é mediado pelo sistema.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF19] Atualizar operador de chamado
Casos de Uso relacionados: [UC19]
Descrição:
O administrador do sistema (OS) poderá atualizar informações sobre um operador de chamado sempre que solicitado. A solicitação para esse procedimento não é mediado pelo sistema.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF20] Atualizar administrador de contato
Casos de Uso relacionados: [UC20]
Descrição:
O administrador do sistema (OS) poderá atualizar informações sobre um administrador de contato. A solicitação para esse procedimento não é mediado pelo sistema.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
13
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Identificação: [RF21] Remover operador de chamado
Casos de Uso relacionados: [UC21]
Descrição:O administrador do sistema (OS) poderá remover um operador de chamado. A solicitação para esse procedimento não é mediado pelo sistema.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF22] Remover administrador de contato
Casos de Uso relacionados: [UC22]
Descrição:O administrador do sistema (OS) poderá remover um administrador de contato. A solicitação para esse procedimento não é mediado pelo sistema.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF23] Buscar administradores/operadores por pesquisa
Casos de Uso relacionados: [UC23]
Descrição:
Para ajudar os procedimentos de atualização e remoção de administradores/operadores, o administrador do sistema poderá fazer uma pesquisa através de um campo de busca que retornará um possível administradores/operadores previamente inserido no sistema.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF24] Buscar administradores/operadores por lista
Casos de Uso relacionados: [UC24]
Descrição:
Para ajudar os procedimentos de atualização e remoção de administradores/operadores, o administrador do sistema poderá fazer uma busca através de uma página contendo uma lista com todos os administradores/operadores possíveis. Dependendo do número de administradores/operadores presentes no sistema essa lista estará em ordem alfabética e em páginas numeradas.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
14
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
3.5. Comunicação
Identificação: [RF25] Enviar mensagem
Casos de Uso relacionados: [UC25]
Descrição:
O usuário final poderá entrar em contato com o administrador de contato através do envio de uma mensagem inserida em um formulário contendo o ‘assunto’, ‘conteúdo da mensagem’ e um email obrigatório do usuário.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF26] Ler mensagem recebida
Casos de Uso relacionados: [UC26]
Descrição:O administrador de contato poderá ler as mensagens destinadas a ele através de uma caixa de entrada contendo novas mensagens não lidas e mensagens lidas.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF27] Fazer chat
Casos de Uso relacionados: [UC27]
Descrição:
Nesse requisito o usuário final poderá realizar um chat (bate-papo) com o administrador de contato (AC) que estiver online no sistema (basta o AC estar logado no sistema). Esse procedimento se dá após o usuário final buscar o administrador de contato desejado. Apenas o usuário final poderá iniciar um chat.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
3.6. Busca de Chamados
Identificação: [RF28] Buscar por usuário final
Casos de Uso relacionados: [UC28]
15
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Descrição:Essa busca pode ser realizada pelo administrador de contato e operador de chamado para encontrar um determinado chamado de um usuário final específico.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF29] Buscar por urgência
Casos de Uso relacionados: [UC29]
Descrição:Essa busca pode ser realizada pelo administrador de contato e operador de chamado para encontrar chamados classificados com uma determinada urgência.
Prioridade: ¨ Essencial þ Importante ¨ Desejável
Identificação: [RF30] Buscar por tipo
Casos de Uso relacionados: [UC30]
Descrição:
Essa busca pode ser realizada pelo usuário final, administrador de contato e operador de chamado para encontrar chamados classificados com um determinado tipo previamente inserido no sistema.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
Identificação: [RF31] Buscar por lista
Casos de Uso relacionados: [UC31]
Descrição:
Essa busca pode ser realizada pelo usuário final, administrador de contato e operador de chamado para encontrar um chamado presente em uma lista com vários outros chamados. Dependendo do número de chamados presentes no sistema essa lista estará em ordem alfabética de tipo e em páginas numeradas.
Prioridade: ¨ Essencial ¨ Importante þ Desejável
16
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
3.7. Acesso
Identificação: [RF32] Efetuar login
Casos de Uso relacionados: [UC32]
Descrição:Todos os atores do sistema têm que efetuar login no sistema para ter acesso aos serviços oferecidos para cada um de acordo com os níveis de permissão.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
Identificação: [RF33] Deslogar
Casos de Uso relacionados: [UC33]
Descrição:Uma vez logado no sistema, os atores podem finalizar a sessão no sistema clicando no botão destinado a essa tarefa.
Prioridade: þ Essencial ¨ Importante ¨ Desejável
4. Requisitos Não-Funcionais
Neste momento, serão descritos os requisitos não-funcionais segundo a classificação do livro , Requirements Engineering : Processes and Techniques de Ian Sommerville. Tal autor divide os requisitos não-funcionais em três categorias: de produto; de processo e externo.
4.1. Requisitos de produto
4.1.1 Usabilidade
[NFR001] Diagramação Bem Estruturada de Interface Identificação: [NFR001] Diagramação Bem Estruturada de Interface
Casos de Uso relacionados: Todos.
Descrição:O sistema deverá contar com uma diagramação bem estruturada, para que seja possível a agregação da arquitetura de informação com a usabilidade.
Prioridade: Desejável Importante Essencial
17
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
[NFR002] Boa Navegação Identificação: [NFR002] Boa Navegação
Casos de Uso relacionados: Todos.
Descrição:As metas do usuário devem ser atingidas em poucos passos no sistema.
Prioridade: Desejável Importante Essencial
[NFR003] Bom Design de InterfaceIdentificação: [NFR002] Bom Design de Interface
Casos de Uso relacionados: Todos.
Descrição:A mecânica de um bom estilo de interface do usuário deverá ser aplicada ao sistema no sentido de torná-lo mais amigável. O que provoca uma maior aceitação por parte do usuário.
Prioridade: Desejável Importante Essencial
[NFR004] Interface de Fácil MemorizaçãoIdentificação: [NFR002] Interface de Fácil Memorização
Casos de Uso relacionados: Todos.
Descrição:Por ser um sistema que não será utilizado com muita freqüência, sua interface deverá apresentar procedimentos de fácil memorização.
Prioridade: Desejável Importante Essencial
4.1.2 Controle de acesso
[NFR005] Clareza na Hierarquia de AcessoIdentificação: [NFR005] Clareza na Hierarquia de Acesso
Casos de Uso relacionados: Todos.
Descrição: O sistema deve especificar as funcionalidades que concernem a
18
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
cada tipo diferente de usuário.Prioridade: Desejável Importante Essencial
4.1.3 Segurança
[NFR006] PrivacidadeIdentificação: [NFR006] Privacidade
Casos de Uso relacionados: Todos.
Descrição: Os dados referentes ao usuário não serão distribuídos sem o conhecimento do mesmo.
Prioridade: Desejável Importante Essencial
[NFR007] Autenticar UsuárioIdentificação: [NFR007] Autenticar Usuário
Casos de Uso relacionados: Todos.
Descrição:O sistema deve confirmar a legitimidade do usuário. Essa confirmação é feita no momento em que o usuário inserir seu login e senha. Também haverá a opção de assinatura digital.
Prioridade: Desejável Importante Essencial
[NFR008] IntegridadeIdentificação: [NFR008] Integridade
Casos de Uso relacionados: Todos.
Descrição:Os dados que serão manipulados através do sistema devem apresentar integridade, ou seja, aparecer de forma completa e precisa.
Prioridade: Desejável Importante Essencial
[NFR008] Backup do Banco de DadosIdentificação: [NFR008] Backup do Banco de Dados
Casos de Uso relacionados: Todos.
Descrição: Com a finalidade de aumentar o nível de segurança do sistema, o banco de dados deverá passar por um processo de compilação para um
19
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
servidor a parte. E esse procedimento deverá ocorrer constantemente.
Prioridade: Desejável Importante Essencial
[NFR010] Resistência a ataquesIdentificação: [NFR010] Resistência a ataques
Casos de Uso relacionados: Todos.
Descrição:A solução deve estar segura (pelo menos) aos ataques mais comuns a sistemas desse tipo (web). Técnicas de criptografia de dados, bem como a realização periódica de testes contribuem à resistência a ataques.
Prioridade: Desejável Importante Essencial
4.2. Requisitos de processo
[NFR011] Fazer uso do Banco de dados OracleIdentificação: [NFR011] Banco de dados Oracle
Casos de Uso relacionados: Todos.
Descrição:Esse é o sistema de banco de dados já utilizado pelo atualmente e, a fim de evitar inconsistências essa nova parte que será integrada ao sistema deverá fazer uso desse mesmo tipo de banco.
Prioridade: Desejável Importante Essencial
[NFR012] Fazer uso do Java para WebIdentificação: [NFR012] Java para Web
Casos de Uso relacionados: Todos.
Descrição:O sistema atual já faz uso da linguagem Java para Web e, a fim de evitar inconsistências essa nova parte que será integrada ao sistema deverá fazer uso desse mesmo tipo de linguagem.
Prioridade: Desejável Importante Essencial
[NFR013] Fazer uso da metodologia ScrumIdentificação: [NFR013] Java para Web
20
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Casos de Uso relacionados: Todos.
Descrição: Por se tratar de uma solução web, a metodologia Scrum tornasse a mais adequada, além de ser ágil por definição.
Prioridade: Desejável Importante Essencial
4.3 Requisitos externos
[NFR014] ManutençãoIdentificação: [NFR014] Manutenção
Casos de Uso relacionados: Todos.
Descrição: Possíveis atualizações do sistema devem estar previstas no contrato.
Prioridade: Desejável Importante Essencial
[NFR015] Tempo total do desenvolvimentoIdentificação: [NFR015] Orçamento
Casos de Uso relacionados: Todos.
Descrição:Devido à aceitação do estudo de viabilidade feito anteriormente, este projeto não deverá ultrapassar o valor estimado no mesmo.
Prioridade: Desejável Importante Essencial
[NFR016] OrçamentoIdentificação: [NFR016] Orçamento
Casos de Uso relacionados: Todos.
Descrição:Devido à aceitação do estudo de viabilidade feito anteriormente, este projeto não deverá ultrapassar o tempo estimado de desenvolvimento em 5,8%.
Prioridade: Desejável Importante Essencial
21
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
5. Modelagem Organizacional
Foi utilizada a notação i* (i estrela) para construir os diagramas abaixo.
5.1. Modelagem de Dependência Estratégica
22
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
5.2. Modelo Estratégico da Razão
23
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6. Modelagem de Requisitos Funcionais (Casos de Uso)
Dividimos a modelagem dos Requisitos Funcionais em 7 diagramas de Casos de Uso para que o entendimento fosse mais fácil. Assim, para cada diagrama foi feita a mesma divisão da seção 3 dividindo as funcionalidades em pacotes. No Apêndice C temos a descrição detalhada de cada caso de uso.
6.1. Sistema do Usuário Final
24
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6.2. Sistema do Administrador de Contato
25
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6.3. Sistema do Operador de Chamado
26
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6.4. Sistema do Administrador do Sistema
27
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6.5. Comunicação
28
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6.6. Busca de Chamados
29
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
6.7. Acesso ao Sistema
7. Modelagem de Requisitos Não-Funcionais (NFR Framework)
O diagrama abaixo modela os requisitos não-funcionais, onde as nuvens claras representam soft-goals que são atendidas pelas operacionalizações (nuvens escuras).
30
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
31
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
8. Conclusão
O documento de especificação de requisitos é uma ferramenta essencial dentro do processo de desenvolvimento do software. A introdução contém o problema a ser resolvido e uma descrição da solução que será implementada. Além disso, contém todos os requisitos organizacionais, funcionais e não-funcionais do sistema. Que são apresentados de forma bem estruturada e com detalhes.
A importância desse documento é evidenciada, no sentido de que serve como um meio de comunicação entre o projetista do software e o usuário, a fim de estabelecer um “acordo” acerca do software pretendido.
9. Referências
[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and Techniques , John Wiley & Sons, 1998.
[Wikipédia] Wikipédia. A enciclopédia livre. Disponível em: <http://www.wikipedia.org>. Acesso em: 20 nov. 10.
[Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br>. Acesso em: 31 jul. 07.
32
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Apêndice A – Contexto Atual
As informações abaixo são resultado de observações e entrevistas realizadas com José Queiroz, diretor do NTI (Núcleo de Tecnologia da Informação da UFPE), e a analista de Tecnologia da Informação, Ana Paula e Marcela do SIG@tende.
Destacamos neste Apêndice exemplos sobre o ambiente analisado no qual o problema se encontra.
Secretarias e Coordenações
Quando um aluno ou professor tem algum problema referente ao curso em que esses usuários finais estão vinculados, geralmente, as secretarias e os coordenadores de cursos são os primeiros atores que entram em contato com a pessoa portadora do problema.
Atualmente, não há registro em algum sistema ligado ao SIG@ dos problemas que são expostos pelos usuários finais. Isso acarreta em informações válidas que não são arquivadas pelo SIG@ para uma gestão de conhecimento importante para o uso do sistema por todos os usuários. Outro problema percebido, que é conseqüência da falta desse registro, é uma não administração de um problema que não foi ainda devidamente solucionado. Ou seja, problemas ficam em aberto, sem nenhum responsável alocado para a solução do mesmo e os usuários finais ficam perdidos sem saber quem deve realmente resolver a sua situação. Um cenário muito comum é, por exemplo, um aluno procurar por conta própria dentro da organização UFPE pelo possível solucionador do seu problema.
NTI@tende
O Núcleo de Tecnologia da Informação (NTI) é o órgão suplementar da UFPE responsável por realizar a gestão de infra-estrutura de software e hardware da UFPE, além de planejar e executar a política de informática da universidade. O NTI também tem a responsabilidade de pesquisar, desenvolver, executar e participar de projetos em Tecnologia de Informação e serviços de informática, além da captação de recursos através de projetos, consultoria e serviços.
Além de ter uma atuação voltada para a comunidade acadêmica, o NTI realiza ações para toda a sociedade. Um exemplo disso é o projeto Praça de Informação, implantado em 2002. A iniciativa disponibiliza aos cidadãos, mesmo que não sejam alunos ou professores da UFPE, computadores ligados à Internet como forma de propagar a inclusão digital.
O NTI@tende, antigo Help-Desk, é um serviço que oferece ajuda no esclarecimento das dúvidas sobre a Rede UFPE e sobre todos os serviços ligados à Tecnologia da Informação da Universidade. O atendimento ao usuário é feito através do telefone 2126-7777. Diferentemente das secretarias e coordenações o NTI@tende registra os chamados recebidos pelo telefone em um sistema que auxilia os próprios atendentes em uma proposta de solução mais rápida de um problema.
33
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Uma das situações percebidas é a ausência de uma rede interna que conecte os principais recebedores de chamados feitos pelos usuários finais. Esse é um dos motivos de muitas vezes não existir um papel bem definido de quem é o solucionador de um determinado tipo de problema, além de deixar os usuários finais em dúvida em relação a quem eles devem entrar em contato.
SIG@tende
O SIG@tende é gerenciado pelo Mantis Bug Tracker, uma ferramenta web que tem como principal objetivo gerenciar os bugs de outros softwares.
Os usuários com acesso a este sistema, chamados de relatores, podem abrir solicitações de atualização, otimização ou correção no sistema. Todos os chamados feitos podem ser classificados entre os seguintes tipos: atribuídos, não atribuídos, a concluir e em andamento. Além disso, o relator poderá acompanhar o andamento de seus chamados através de uma barra em degradê, com várias colorações, que irá mostrar o status em que se encontram os seus chamados. Estes podem assumir os valores de: registrado, analisado, em desenvolvimento, testado, validado, incluído no sistema, entre outros. Essas cores darão visão ao relator para ele acompanhe em que passo e fluxo de trabalho o seu chamado se encontra. Desta maneira bem visual, a tarefa se torna bem intuitiva. Pensando na possível dificuldade que os usuários teriam ao utilizar o sistema, foi escrito um manual visando esclarecer as possíveis dúvidas.
O sistema também conta com um módulo de feedback. Isto é, após um problema ser resolvido, o relator tem um retorno do resultado de chamada. Por exemplo, se o problema foi algum defeito no sistema, significa que o bug foi consertado. Quando um chamado é adicionado, muda de status ou é concluído, o relator também recebe um e-mail de aviso.
Antigamente, não se tinha controle das alterações de código do SIG@. Foi pensando nisso que foi criado o SIG@tende. A finalidade do SIG@tende é fazer uma gestão de solicitações de forma que o projeto (o SIG@) cresça de forma controlada. Quando um chamado é registrado, é possível saber quais os pontos do projeto que aquele chamado alterou, pois ele é integrado a um sistema de controle de versões (CVS). Com isso pode-se controlar o nível de crescimento do projeto. Além da organização no nível de gerentes, é possível extrair métricas, elaborar relatórios e calcular desempenhos. O SIG@tende não é usado somente para reportar problemas, mas sim todo tipo de alteração no sistema, tanto de informação no nível de coordenação, como alteração de calendário, eventos, perfis, entre outros.
Apenas um grupo restrito de usuários é considerado os clientes do SIG@tende. São eles: o corpo discente da UFPE e os responsáveis pelo controle acadêmico. São essas pessoas que podem reportar problemas no sistema e sugerir melhorias. Estima-se que a quantidade de usuários com permissão de usar esse sistema gire em torno de trinta.
34
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Apêndice B – Técnicas Utilizadas na Coleta de Dados
As técnicas de coleta de dados utilizadas foram três: Entrevista estruturada, Entrevista semi-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 aluno.
Entrevista semi-estruturada
A entrevista semi-estruturada não possui roteiro e é caracterizada pelo fato do pesquisador se guiar apenas pelos objetivos da pesquisa.
A coleta de informações, na entrevista semi-estruturada, ocorre de forma conversacional informalmente de um indivíduo ou grupo, sobre uma determinada situação, fato ou fenômeno.
A comunicação com os especialistas foi bastante interativa, o que possibilitou a completa exploração das informações desejadas, como foi observado no Apêndice A.
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 alunos interagem com a UFPE para resolver seus problemas. A insatisfação dos alunos em relação ao Sig@ foi notada quando passamos a acompanhar suas atualizações em redes sociais, que serviam para reportarem reclamações e problemas de caráter geral ao sistema da instituição.
35
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Apêndice C – Casos de uso
Sistema do Usuário Final
Identificador: [UC01] Visualizar chamados/soluções publicados
Descrição: Permite que o usuário final possa visualizar soluções de chamados tornados público para o sistema. Tal usuário terá no seu perfil todas essas informações publicadas pelo sistema.
Ator: Usuário Final
Prioridade: Desejável
Pré-condições: Buscar o chamado desejado.
Pós-condições: Visualização do chamado e solução que interessa ao usuário.
Fluxo de Eventos Principal
1. Entrar na lista com os chamados publicados2. Navegar pelas páginas numeradasRequisitos Não Funcionais Específicos -
Identificador: [UC02] Buscar contato por lista
Descrição: Permite que o usuário final possa encontrar o administrador de contato com quem ele pode estabelecer contato enviando uma mensagem pelo sistema, realizando um chat (bate-papo) ou fazendo uma ligação. Essa busca se dá através de uma página contendo uma lista com todos os contatos possíveis. Dependendo do número de contatos presentes no sistema essa lista estará em ordem alfabética e em páginas numeradas.
Ator: Usuário Final
Prioridade: Desejável
Pré-condições: Estar logado no sistema.
Pós-condições: Contato desejado.
Fluxo de Eventos Principal
1. Entrar na lista com os contatos2. Navegar pelas páginas numeradas
36
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Requisitos Não Funcionais Específicos -
Identificador: [UC03] Buscar contato por pesquisa
Descrição: Permite que o usuário final possa encontrar o administrador de contato com quem ele pode estabelecer contato enviando uma mensagem pelo sistema, realizando um chat (bate-papo) ou fazendo uma ligação. Essa busca se dá através de uma pesquisa através de um campo de busca geral.
Ator: Usuário Final
Prioridade: Importante
Pré-condições: Estar logado no sistema.
Pós-condições: Contato desejado.
Fluxo de Eventos Principal
1. Inserir no campo de pesquisa o nome do contato desejado2. Realizar busca apertando ‘ok’3. Verificar resultado da buscaRequisitos Não Funcionais Específicos -
Sistema do Administrador de Contato
Identificador: [UC04] Editar configurações de contato
Descrição: Todos os administradores de contato podem alterar suas próprias informações de contato. Eles podem atualizar dados como contas de email, chat (bate-papo) e contas de redes sociais.
Ator: Administrador de Contato
Prioridade: Importante
Pré-condições: Estar logado no sistema.
Pós-condições: Configurações de contato do administrador atualizadas.
Fluxo de Eventos Principal
37
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1. Acessar a área de edição de configurações contato2. Modificar as informações dos campos de texto editáveis3. Confirmar atualização das informações
Fluxo Secundário 1
1. Acessar a área de edição de configurações contato2. Modificar as informações dos campos de texto editáveis3. Cancelar atualização das informaçõesRequisitos Não Funcionais Específicos -
Identificador: [UC05] Publicar chamados/solução
Descrição: Os administradores de chamado podem tornar públicas mensagens associadas com propostas de soluções para que o usuário final descubra as respostas para as dúvidas mais freqüentes. A pergunta realizada pelo usuário final que for publicada não acompanha o seu nome ou qualquer tipo de identificação.
Ator: Administrador de Contato
Prioridade: Desejável
Pré-condições: Buscar o chamado desejado.
Pós-condições: Informações sobre os chamados e soluções disponíveis para o usuário final.
Fluxo de Eventos Principal
1. Clicar no ícone para publicar chamado presente ao lado do título do chamado encontrado
Requisitos Não Funcionais Específicos -
Identificador: [UC06] Solicitar cadastro de operador de chamado
Descrição: Um administrador de contato (AC) pode solicitar ao administrador do sistema (OS) o cadastro de um novo operador de chamado (OC) que será responsável por resolver o problema do usuário final. O AC pode achar necessário tal procedimento caso ele não encontre no sistema algum OC que ele considere capaz de ser responsável por resolver o chamado/problema. Essa solicitação se dá através de uma mensagem enviada para o OS.
Ator: Administrador de Contato
38
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Prioridade: Importante
Pré-condições: Estar logado no sistema.
Pós-condições: Pedido de cadastro em espera pela confirmação de cadastro do operador pelo administrador do sistema.
Fluxo de Eventos Principal
1. Entrar na página de solicitação de cadastro de operador2. Preencher campo com a mensagem contendo os dados necessários para o cadastro
do operador3. Enviar mensagem
Fluxo Secundário 1
1. Entrar na página de solicitação de cadastro de operador2. Preencher campo com a mensagem contendo os dados necessários para o cadastro
do operador3. Cancelar envio de mensagemRequisitos Não Funcionais Específicos -
Identificador: [UC07] Abrir chamado
Descrição: Após estabelecer contato com o usuário final através de troca de mensagem, chat (bate-papo) ou telefonema, o administrador de contato (AC) poderá decidir pela abertura de um chamado no qual ele alocará um operador de chamado que reportará posteriormente uma solução. Nessa abertura é essencial o AC inserir dados como informações para identificar o usuário final, tipo de chamado, urgência do chamado e responsáveis pelo contato/solução.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Estar logado no sistema, Registrar o usuário final que fez o chamado, classificar a urgência do chamado, classificar o tipo de chamado, alocar o administrador de contato responsável pelo chamado e alocar os operadores que irão resolver o problema do usuário final.
Pós-condições: Chamado aberto para acompanhamento posterior pelo administrador de contato responsável.
Fluxo de Eventos Principal
39
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1. Entrar na página de abrir contato2. Preencher todos os campos editáveis do formulário de abrir chamado3. Apertar em “Abrir chamado”
Fluxo Secundário 1
1. Entrar na página de abrir contato2. Preencher de forma incompleta os campos do formulário de abrir chamado3. Cancelar procedimento
Requisitos Não Funcionais Específicos -
Identificador: [UC08] Registrar usuário final
Descrição: O administrador de contato deve registrar informações que identifique de forma única o usuário final e deixe claro qual a forma de contato com o mesmo. Cada usuário final que pode ser cadastrado no sistema é identificado pelo seu número de registro na universidade.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Estar logado no sistema e usuário ter entrado em contato.
Pós-condições: Usuário final registrado no sistema e associado ao chamado em aberto.
Fluxo de Eventos Principal
1. Preencher todos os campos editáveis do formulárioRequisitos Não Funcionais Específicos -
Identificador: [UC09] Classificar urgência
Descrição: O administrador de contato (AC) deve registrar o grau de urgência do chamado para deixar claro para todos que a acessam o sistema a pendência dos problemas não resolvidos. A classificação pode será: muito urgente, urgente, normal, pouco urgente, muito pouco urgente.
Ator: Administrador de Contato
Prioridade: Importante
Pré-condições: Estar logado no sistema e usuário ter entrado em contato.
40
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Pós-condições: Chamado classificado de acordo com o tipo de urgência.
Fluxo de Eventos Principal
1. Escolher as opções de tipos de urgênciaRequisitos Não Funcionais Específicos -
Identificador: [UC10] Classificar tipo de chamado
Descrição: O administrador de contato (AC) deve registrar o tipo de chamado para facilitar a categorização do mesmo no sistema e busca por algum chamado desejado.
Ator: Administrador de Contato
Prioridade: Importante
Pré-condições: Estar logado no sistema e usuário ter entrado em contato.
Pós-condições: Chamado classificado de acordo com seu tipo.
Fluxo de Eventos Principal
1. Preencher campo de texto destinado à categorização do chamado com a categoria desejada.
Requisitos Não Funcionais Específicos -
Identificador: [UC11] Alocar administrador
Descrição: Na abertura de um chamado, o administrador de contato (AC) deve registrar ele como o AC responsável por realizar contatos posteriores com usuário final. Em caso da não possibilidade de ser o AC responsável, ele pode registrar outra pessoa no seu lugar.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Estar logado no sistema e usuário ter entrado em contato.
Pós-condições: Administrador de contato alocado para administrar o chamado.
41
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Fluxo de Eventos Principal
1 Acessar lista de administradores de contato2 Escolher administrador desejado clicando no seu nomeRequisitos Não Funcionais Específicos -
Identificador: [UC12] Alocar operadores
Descrição: Na abertura de um chamado, o administrador de contato (AC) deve registrar um ou mais operadores de chamados (OC) para um mesmo chamado inserido no sistema. No caso de mais de um OC for alocado apenas um deles será marcado como o OC responsável pelo problema.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Estar logado no sistema e usuário ter entrado em contato.
Pós-condições: Operadores responsáveis alocados para darem uma solução ao chamado.
Fluxo de Eventos Principal
1 Acessar lista de operadores de contato2 Escolher operador de contato desejado clicando no seu nomeRequisitos Não Funcionais Específicos -
Identificador: [UC13] Restringir visualização de dados do operador
Descrição: Nesse procedimento, o administrador de contato poderá editar o nível de responsabilidade de cada operador de chamado (OC) alocado. Isso restringe que tipo de informação do usuário final o OC poderá visualizar.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Estar logado no sistema e ter alocado o operador para o chamado.
Pós-condições: Nível de permissão definido para o operador no sistema.
Fluxo de Eventos Principal
42
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1 Acessar lista de operadores de contato clicando em “restrições de operadores”2 Escolher o nível de permissão desejado ao lado do nome do operador3 Confirmar procedimento
Fluxo Secundário 1
1 Acessar lista de operadores de contato clicando em “restrições de operadores”2 Escolher o nível de permissão desejado ao lado do nome do operador3 Cancelar procedimentoRequisitos Não Funcionais Específicos -
Identificador: [UC14] Atualizar chamado aberto
Descrição: O administrador de contato poderá atualizar todas as informações inseridas no procedimento do requisito “[RF07] Abrir chamado”.
Ator: Administrador de Contato
Prioridade: Importante
Pré-condições: Buscar o chamado desejado.
Pós-condições: Informações sobre o chamado atualizadas.
Fluxo de Eventos Principal
1. Após buscar chamado, clicar em “editar chamado”2. Preencher todos os campos editáveis do formulário com informações inseridas3. Apertar em “Atualizar”
Fluxo Secundário 1
1. Após buscar chamado, clicar em “editar chamado”2. Preencher todos os campos editáveis do formulário com informações inseridas3. Apertar em “cancelar”Requisitos Não Funcionais Específicos -
Identificador: [UC15] Finalizar chamado
Descrição: O administrador de contato (AC) deve sempre buscar finalizar um chamado e entrar em contato com o usuário final lhe entregando a proposta de solução enviada pelo operador de chamado (OC). Esse contato final com usuário se dá através email ou telefone. Uma vez que o OC reportar a solução ou a inviabilidade da solução o AC poderá decidir por finalizar um chamado. Esse acompanhamento do chamado se dá através de uma thread
43
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
de mensagens trocadas entre o AC e o OC.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Buscar o chamado desejado e receber a solução do chamado por parte do operador alocado.
Pós-condições: Chamado finalizado e solução informada ao usuário final.
Fluxo de Eventos Principal
1. Após a busca do chamado, verificar proposta de solução enviada pelo operador de chamado
2. Marcar chamado como finalizado caso a solução seja adequada
Fluxo Secundário 1
1. Após a busca do chamado, verificar proposta de solução enviada pelo operador de chamado
2. Não marcar chamado como finalizado caso a solução não seja adequadaRequisitos Não Funcionais Específicos -
Sistema do Operador de Chamado
Identificador: [UC16] Reportar solução do chamado
Descrição: O operador de chamado (OC) será constantemente cobrado pelo administrador de contato (AC) através de uma thread de mensagens e o OC reportará uma solução ou a inviabilidade da solução para o AC .
Ator: Operador de Chamado
Prioridade: Essencial
Pré-condições: Buscar o chamado desejado.
Pós-condições: Solução do problema informada ao administrador de contato.
Fluxo de Eventos Principal
1. Acessar página para o envio da mensagem2. Preencher a mensagem com a proposta de solução3. Clicar em “enviar”
Fluxo Secundário 1
44
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1. Acessar página para o envio da mensagem2. Preencher a mensagem com a proposta de solução3. Clicar em “cancelar”Requisitos Não Funcionais Específicos -
Sistema do Administrador do Sistema
Identificador: [UC17] Inserir operador de chamado
Descrição: Após ser solicitado pelo administrador de contato (OC) através de uma mensagem (contendo as informações necessárias para o procedimento) o administrador do sistema (OS) poderá inserir ou não o operador de chamado solicitado.
Ator: Administrador do Sistema
Prioridade: Importante
Pré-condições: Estar logado no sistema e receber solicitação por parte do administrador de contato.
Pós-condições: Operador cadastrado no sistema.
Fluxo de Eventos Principal
1. Verificar solicitação de inserção de operador de chamado2. Confirmar inserção após a leitura das informações
Fluxo Secundário 1
1. Verificar solicitação de inserção de operador de chamado2. Cancelar inserção após a leitura das informaçõesRequisitos Não Funcionais Específicos -
Identificador: [UC18] Inserir administrador de contato
Descrição: O administrador do sistema (OS) poderá inserir ou não um administrador de contato no sistema. A solicitação para esse procedimento não é mediado pelo sistema.
Ator: Administrador do Sistema
Prioridade: Importante
Pré-condições: Estar logado no sistema.
45
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Pós-condições: Administrador cadastrado no sistema.
Fluxo de Eventos Principal
1. Inserir dados do administrador de contato2. Confirmar inserção no sistema
Fluxo Secundário 1
1. Inserir dados do administrador de contato2. Cancelar inserção no sistemaRequisitos Não Funcionais Específicos -
Identificador: [UC19] Atualizar operador de chamado
Descrição: O administrador do sistema (OS) poderá atualizar informações sobre um operador de chamado sempre que solicitado. A solicitação para esse procedimento não é mediado pelo sistema.
Ator: Administrador do Sistema
Prioridade: Desejável
Pré-condições: Buscar o operador desejado.
Pós-condições: Informações do operador atualizadas.
Fluxo de Eventos Principal
1. Após a busca de operador de chamado, editar as informações desse usuário2. Confirmar atualização das informações
Fluxo Secundário 1
1. Após a busca de operador de chamado, editar as informações desse usuário2. Cancelar atualização das informaçõesRequisitos Não Funcionais Específicos -
Identificador: [UC20] Atualizar administrador de contato
Descrição: O administrador do sistema (OS) poderá atualizar informações sobre um administrador de contato. A solicitação para esse procedimento não é mediado pelo sistema.
Ator: Administrador do Sistema
46
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Prioridade: Desejável
Pré-condições: Buscar o administrador desejado.
Pós-condições: Informações do administrador atualizadas.
Fluxo de Eventos Principal
1. Após a busca de administrador de contato, editar as informações desse usuário2. Confirmar atualização das informações
Fluxo Secundário 1
1. Após a busca de administrador de contato, editar as informações desse usuário2. Cancelar atualização das informaçõesRequisitos Não Funcionais Específicos -
Identificador: [UC21] Remover operador de chamado
Descrição: O administrador do sistema (OS) poderá remover um operador de chamado. A solicitação para esse procedimento não é mediado pelo sistema.
Ator: Administrador do Sistema
Prioridade: Desejável
Pré-condições: Buscar o operador desejado.
Pós-condições: Operador removido do sistema.
Fluxo de Eventos Principal
1. Após a busca de operador de chamado, clicar em remover usuário2. Confirmar remoção
Fluxo Secundário 1
1. Após a busca de operador de chamado, clicar em remover usuário2. Cancelar remoçãoRequisitos Não Funcionais Específicos -
Identificador: [UC22] Remover administrador de contato
Descrição: O administrador do sistema (OS) poderá remover um administrador de contato. A solicitação para esse procedimento não é mediado pelo sistema.
47
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Ator: Administrador do Sistema
Prioridade: Desejável
Pré-condições: Buscar o administrador desejado.
Pós-condições: Administrador removido do sistema.
Fluxo de Eventos Principal
1. Após a busca de administrador de contato, clicar em remover usuário2. Confirmar remoção
Fluxo Secundário 1
1. Após a busca de administrador de contato, clicar em remover usuário2. Cancelar remoçãoRequisitos Não Funcionais Específicos -
Identificador: [UC23] Buscar administradores/operadores por pesquisa
Descrição: Para ajudar os procedimentos de atualização e remoção de administradores/operadores, o administrador do sistema poderá fazer uma pesquisa através de um campo de busca que retornará um possível administradores/operadores previamente inserido no sistema.
Ator: Administrador do Sistema
Prioridade: Importante
Pré-condições: Estar logado no sistema.
Pós-condições: Administrador ou operador desejado.
Fluxo de Eventos Principal
1. O ator informa o ID do administrador ou operador; 2. As informações do administrador ou operador são disponibilizadas.
Fluxo Secundário 1
1. No passo 2 um aviso é exibido ao ator que fez a busca caso não exista administrador ou operador cadastrado no sistema com o ID informado.
Requisitos Não Funcionais Específicos -
Identificador: [UC24] Buscar administradores/operadores por lista
48
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Descrição: Para ajudar os procedimentos de atualização e remoção de administradores/operadores, o administrador do sistema poderá fazer uma busca através de uma página contendo uma lista com todos os administradores/operadores possíveis. Dependendo do número de administradores/operadores presentes no sistema essa lista estará em ordem alfabética e em páginas numeradas.
Ator: Administrador do Sistema
Prioridade: Desejável
Pré-condições: Estar logado no sistema.
Pós-condições: Administrador ou operador desejado.
Fluxo de Eventos Principal
1. O ator clica para exibir a lista de administradores ou operadores;2. Na lista em ordem alfabética e com paginação, o ator escolhe o administrador ou
operador desejado.
Fluxo Secundário 1
1. No passo 1 um aviso é exibido ao ator que fez a busca caso não exista nenhum administrador ou operador no sistema.
Requisitos Não Funcionais Específicos -
Comunicação
Identificador: [UC25] Enviar mensagem
Descrição: O usuário final poderá entrar em contato com o administrador de contato através do envio de uma mensagem inserida em um formulário contendo o ‘assunto’, ‘conteúdo da mensagem’ e um email obrigatório do usuário.
Ator: Usuário Final
Prioridade: Desejável
Pré-condições: Buscar o contato que se deseja enviar a mensagem.
Pós-condições: Mensagem enviada para a espera de uma resposta por parte do contato.
Fluxo de Eventos Principal
49
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1. Acessar formulário de envio de mensagem escolhendo o contato desejado2. Preencher campo de texto de mensagem3. Enviar mensagem
Fluxo Secundário 1
1. Acessar formulário de envio de mensagem escolhendo o contato desejado2. Preencher campo de texto de mensagem3. Cancelar envio de mensagemRequisitos Não Funcionais Específicos -
Identificador: [UC26] Ler mensagem recebida
Descrição: O administrador de contato poderá ler as mensagens destinadas a ele através de uma caixa de entrada contendo novas mensagens não lidas e mensagens lidas.
Ator: Administrador de Contato
Prioridade: Essencial
Pré-condições: Estar logado no sistema e o usuário final ter enviado a mensagem.
Pós-condições: Mensagem lida para posterior ação pelo administrador de contato.
Fluxo de Eventos Principal
1. Acessar caixa de entrada2. Visualizar mensagemRequisitos Não Funcionais Específicos -
Identificador: [UC27] Fazer chat
Descrição: Nesse requisito o usuário final poderá realizar um chat (bate-papo) com o administrador de contato (AC) que estiver online no sistema (basta o AC estar logado no sistema). Esse procedimento se dá após o usuário final buscar o administrador de contato desejado. Apenas o usuário final poderá iniciar um chat.
Ator: Usuário Final, Administrador de Contato
Prioridade: Desejável
Pré-condições: Estar logado no sistema e o usuário final entrar em contato pelo chat.
Pós-condições: Conversa realizada com o usuário final para posterior ação pelo
50
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
administrador de contato.
Fluxo de Eventos Principal
1. Verificar se administrador de contato está online2. Iniciar conversaRequisitos Não Funcionais Específicos -
Busca de Chamados
Identificador: [UC28] Buscar por usuário final
Descrição: Essa busca pode ser realizada pelo administrador de contato e operador de chamado para encontrar um determinado chamado de um usuário final específico.
Ator: Administrador de Contato, Operador de Chamado
Prioridade: Essencial
Pré-condições: Estar logado no sistema.
Pós-condições: Chamado desejado de determinado usuário final.
Fluxo de Eventos Principal
1. O ator informa o ID do usuário para buscar os chamados relacionados a ele;2. Os chamados relacionados ao usuário são disponibilizados.
Fluxo Secundário 1
1. No passo 2 um aviso é exibido ao ator que fez a busca caso o usuário não exista no banco de dados do sistema.
Requisitos Não Funcionais Específicos -
Identificador: [UC29] Buscar por urgência
Descrição: Essa busca pode ser realizada pelo administrador de contato e operador de chamado para encontrar chamados classificados com uma determinada urgência.
Ator: Administrador de Contato, Operador de Chamado
51
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
Prioridade: Importante
Pré-condições: Estar logado no sistema.
Pós-condições: Chamado desejado de acordo com as opções de urgência.
Fluxo de Eventos Principal
1. O ator informa o tipo de urgência entre as opções disponibilizadas na busca; 2. Os chamados com a urgência escolhida são disponibilizados.
Fluxo Secundário 1
3. No passo 2 um aviso é exibido ao ator que fez a busca caso não exista chamado com a urgência escolhida.
Requisitos Não Funcionais Específicos -
Identificador: [UC30] Buscar por tipo
Descrição: Essa busca pode ser realizada pelo usuário final, administrador de contato e operador de chamado para encontrar chamados classificados com um determinado tipo previamente inserido no sistema.
Ator: Usuário Final, Administrador de Contato, Operador de Chamado
Prioridade: Desejável
Pré-condições: Estar logado no sistema.
Pós-condições: Chamado desejado de acordo seu tipo.
Fluxo de Eventos Principal
1. O ator informa o tipo de chamado entre as opções disponibilizadas na busca; 2. Os chamados com o tipo escolhido são disponibilizados.
Fluxo Secundário 1
1. No passo 2 um aviso é exibido ao ator que fez a busca caso não exista chamado com o tipo escolhida.
Requisitos Não Funcionais Específicos -
Identificador: [UC31] Buscar por lista
Descrição: Essa busca pode ser realizada pelo usuário final, administrador de contato e operador de chamado para encontrar um chamado presente em uma lista
52
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
com vários outros chamados. Dependendo do número de chamados presentes no sistema essa lista estará em ordem alfabética de tipo e em páginas numeradas.
Ator: Usuário Final, Administrador de Contato, Operador de Chamado
Prioridade: Desejável
Pré-condições: Estar logado no sistema.
Pós-condições: Chamado desejado de acordo com a lista mostrada no sistema.
Fluxo de Eventos Principal
1. O ator clica para exibir a lista de chamados do sistema; 2. Na lista em ordem alfabética e com paginação, o ator escolhe o chamado desejado.
Fluxo Secundário 1
2. No passo 1 um aviso é exibido ao ator que fez a busca caso não exista nenhum chamado cadastrado no sistema.
Requisitos Não Funcionais Específicos -
Acesso
Identificador: [UC32] Efetuar login
Descrição: Todos os atores do sistema têm que efetuar login no sistema para ter acesso aos serviços oferecidos para cada um de acordo com os níveis de permissão.
Ator: Usuário Final, Administrador de Contato, Operador de Chamado, Administrador do Sistema
Prioridade: Essencial
Pré-condições: -
Pós-condições: O sistema inicia uma sessão e o ator tem disponível as funções de acordo com o seu tipo de usuário
Fluxo de Eventos Principal
1. O ator entra no sistema2. O ator vê o tipo de autenticação que está sendo exigido3. O ator segue os passos para autenticação4. A sessão é iniciada
Fluxo Secundário 1
53
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
1. No passo 3, se os dados não forem válidos o ator não entra no sistema2. O sistema retorna para a tela de loginRequisitos Não Funcionais Específicos NFR007
Identificador: [UC33] Deslogar
Descrição: Uma vez logado no sistema, os atores podem finalizar a sessão no sistema clicando no botão destinado a essa tarefa.
Ator: Usuário Final, Administrador de Contato, Operador de Chamado, Administrador do Sistema
Prioridade: Essencial
Pré-condições: Estar logado no sistema
Pós-condições: Sessão no sistema finalizada
Fluxo de Eventos Principal
1. O ator clica no botão sair2. A sessão é finalizada e o sistema retorna para a tela de loginRequisitos Não Funcionais Específicos -
Apêndice D – Glossário
Banco de dados Oracle: O Oracle é o principal banco de dados atualmente, sendo responsável pelo armazenamento de boa parte das informações das principais organizações ao redor do
54
CIn UFPE Projeto de Especificação e Análise de Requisitos
25/11/2010 Especificação de Requisitos
mundo. O Oracle é muito robusto e exige bastante hardware para um boa performance. Outro fator importante é o gerenciamento, onde são exigidos profissionais bastante capacitados para este fim.
Facebook - é um website de relacionamento social lançado em 4 de fevereiro de 2004. O website possui mais de 120 milhões de usuários ativos, a posição do Facebook no ranking de tráfego de visitantes do Alexa, subiu do 60º lugar para 7º lugar.
FAQ - é o acrônimo para a expressão em inglês Frequently Asked Questions, ou em português, Perguntas Frequentes. É uma lista de perguntas e respostas que são frequentes em um determinado contexto, pertencentes a um determinado tópico.
Help desk - é um termo da língua inglesa que designa o serviço de apoio a usuários para suporte e resolução de problemas técnicos em informática, telefonia e tecnologias de informação. Este apoio pode ser tanto dentro de uma empresa (profissionais que cuidam da manutenção de equipamentos e instalações dentro da empresa), quanto externamente (prestação de serviços à usuários).
Login: Trata-se de uma seqüência de caracteres utilizada para identificar um usuário de forma única.
Notação i*: Abordagem criada por John Mylopoulos e EricYu, na Universidade de Toronto para descrição de requisitos organizacionais.
NTI - Núcleo de Tecnologia da Informação da UFPE responsável pela gerencia de TI da universidade.
SIG@ - Sistema de Informação da UFPE para a gestão de informações acadêmicas
SIG@tende - Núcleo técnico estabelecido no NTI responsável pelo SIG@.
Twitter - Twitter (pronuncia-se "tuíter") é uma rede social e servidor para microblogging que permite aos usuários enviar e receber atualizações pessoais de outros contatos (em textos de até 140 caracteres, conhecidos como "tweets"), por meio do website do serviço, por SMS e por softwares específicos de gerenciamento.
55