if716/projetos/projetos20102/Projeto… · Web viewOs usuários com acesso a este sistema, chamados...

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



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



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



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



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



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



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



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


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.


Identificação: [RF03] Buscar contato por pesquisa


Descrição: Permite que o usuário final possa encontrar o administrador

8



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


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.


Identificação: [RF05] 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.


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



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.


Identificação: [RF07] 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.

Prioridade: þ Essencial ¨ Importante ¨ Desejável

Identificação: [RF08] 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.


Identificação: [RF09] 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.


10



Identificação: [RF10] 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.


Identificação: [RF11] 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 uma outra pessoa no seu lugar.


Identificação: [RF12] 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.


Identificação: [RF13] 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.


11



Identificação: [RF14] Atualizar chamado aberto


Descrição:O administrador de contato poderá atualizar todas as informações inseridas no procedimento do requisito “[RF07] Abrir chamado”.


Identificação: [RF15] 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 de mensagens trocadas entre o AC e o OC.


3.3. Sistema do Operador de Chamado

Identificação: [RF16] 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 .


12



3.4. Sistema do Administrador do Sistema

Identificação: [RF17] 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.


Identificação: [RF18] 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.


Identificação: [RF19] 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.


Identificação: [RF20] 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.


13



Identificação: [RF21] 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.


Identificação: [RF22] 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.


Identificação: [RF23] 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.


Identificação: [RF24] Buscar administradores/operadores por lista


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.


14



3.5. Comunicação

Identificação: [RF25] 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.


Identificação: [RF26] 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.


Identificação: [RF27] 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.


3.6. Busca de Chamados

Identificação: [RF28] Buscar por usuário final


15



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.


Identificação: [RF29] 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.


Identificação: [RF30] 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.


Identificação: [RF31] 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 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.


16



3.7. Acesso

Identificação: [RF32] 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.


Identificação: [RF33] 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.


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



[NFR002] Boa Navegação Identificação: [NFR002] Boa Navegação


Descrição:As metas do usuário devem ser atingidas em poucos passos no sistema.


[NFR003] Bom Design de InterfaceIdentificação: [NFR002] Bom Design de Interface


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.


[NFR004] Interface de Fácil MemorizaçãoIdentificação: [NFR002] Interface de Fácil Memorização


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.


4.1.2 Controle de acesso

[NFR005] Clareza na Hierarquia de AcessoIdentificação: [NFR005] Clareza na Hierarquia de Acesso


Descrição: O sistema deve especificar as funcionalidades que concernem a

18



cada tipo diferente de usuário.Prioridade: Desejável Importante Essencial

4.1.3 Segurança

[NFR006] PrivacidadeIdentificação: [NFR006] Privacidade


Descrição: Os dados referentes ao usuário não serão distribuídos sem o conhecimento do mesmo.


[NFR007] Autenticar UsuárioIdentificação: [NFR007] Autenticar Usuário


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.


[NFR008] IntegridadeIdentificação: [NFR008] Integridade


Descrição:Os dados que serão manipulados através do sistema devem apresentar integridade, ou seja, aparecer de forma completa e precisa.


[NFR008] Backup do Banco de DadosIdentificação: [NFR008] Backup do Banco de Dados


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



servidor a parte. E esse procedimento deverá ocorrer constantemente.


[NFR010] Resistência a ataquesIdentificação: [NFR010] Resistência a ataques


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.


4.2. Requisitos de processo

[NFR011] Fazer uso do Banco de dados OracleIdentificação: [NFR011] Banco de dados Oracle


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.


[NFR012] Fazer uso do Java para WebIdentificação: [NFR012] Java para Web


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.


[NFR013] Fazer uso da metodologia ScrumIdentificação: [NFR013] Java para Web

20




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.


4.3 Requisitos externos

[NFR014] ManutençãoIdentificação: [NFR014] Manutenção


Descrição: Possíveis atualizações do sistema devem estar previstas no contrato.


[NFR015] Tempo total do desenvolvimentoIdentificação: [NFR015] Orçamento


Descrição:Devido à aceitação do estudo de viabilidade feito anteriormente, este projeto não deverá ultrapassar o valor estimado no mesmo.


[NFR016] OrçamentoIdentificação: [NFR016] Orçamento


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


21



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



5.2. Modelo Estratégico da Razão

23



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



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

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



31



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

http://www.cin.ufpe.br/

http://www.wikipedia.org/



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



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



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



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.



Pré-condições: Estar logado no sistema.

Pós-condições: Contato desejado.


1. Entrar na lista com os contatos2. Navegar pelas páginas numeradas

36



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.


Prioridade: Importante


Pós-condições: Contato desejado.


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



Pós-condições: Configurações de contato do administrador atualizadas.


37



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.




Pós-condições: Informações sobre os chamados e soluções disponíveis para o usuário final.


1. Clicar no ícone para publicar chamado presente ao lado do título do chamado encontrado


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.


38





Pós-condições: Pedido de cadastro em espera pela confirmação de cadastro do operador pelo administrador do sistema.


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.


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.


39



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


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.



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.


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.




40



Pós-condições: Chamado classificado de acordo com o tipo de urgência.


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.




Pós-condições: Chamado classificado de acordo com seu tipo.


1. Preencher campo de texto destinado à categorização do chamado com a categoria desejada.


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.




Pós-condições: Administrador de contato alocado para administrar o chamado.

41




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.




Pós-condições: Operadores responsáveis alocados para darem uma solução ao chamado.


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.



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.


42



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




Pós-condições: Informações sobre o chamado atualizadas.


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



de mensagens trocadas entre o AC e o OC.



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.


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



Pós-condições: Solução do problema informada ao administrador de contato.


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



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


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.


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.




45



Pós-condições: Administrador cadastrado no sistema.


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.



Pré-condições: Buscar o operador desejado.

Pós-condições: Informações do operador atualizadas.


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.


46




Pré-condições: Buscar o administrador desejado.

Pós-condições: Informações do administrador atualizadas.


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.



Pré-condições: Buscar o operador desejado.

Pós-condições: Operador removido do sistema.


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





Pré-condições: Buscar o administrador desejado.

Pós-condições: Administrador removido do sistema.


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.




Pós-condições: Administrador ou operador desejado.


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.


Identificador: [UC24] Buscar administradores/operadores por lista

48



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.




Pós-condições: Administrador ou operador desejado.


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.


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.



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.


49



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.



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.


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


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



administrador de contato.


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



Pós-condições: Chamado desejado de determinado usuário final.


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.


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





Pós-condições: Chamado desejado de acordo com as opções de urgência.


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.


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



Pós-condições: Chamado desejado de acordo seu tipo.


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.


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



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



Pós-condições: Chamado desejado de acordo com a lista mostrada no sistema.


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.


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


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


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



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


Pré-condições: Estar logado no sistema

Pós-condições: Sessão no sistema finalizada


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



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

if716/projetos/projetos20102/Projeto… · Web viewOs usuários com acesso a este sistema, chamados...

Documents

Transcript of if716/projetos/projetos20102/Projeto… · Web viewOs usuários com acesso a este sistema, chamados...