Especificação de Requisitos e Validação de Sistemas

Sistema de Suporte à Gestão de Telemática Projeto I - iStar e BPMN

Professor: Jaelson de Castro Equipe: Bruno Jorge (bjnb)

Kennedy Bezerra (kbsl) Marília Isabelly (mirn) Thalles Cezar (tcrl)

Recife - Setembro de 2017

SUMÁRIO 1. Introdução ................................................................................................................................. 2

1.1. A Organização .............................................................................................................. 2 1.2. Descrição do problema ................................................................................................ 2 1.3. Stakeholders ................................................................................................................ 3 1.4. Sistema proposto .......................................................................................................... 3 1.5. Metodologia .................................................................................................................. 3

2. Requisitos organizacionais ...................................................................................................... 3 2.1. Requisitos funcionais ................................................................................................... 4 2.2. Requisitos não funcionais ............................................................................................ 5

3. Modelagens ............................................................................................................................... 6 3.1. Modelagem i* (i-star) .................................................................................................. 6

3.1.1. Modelagem As-Is ............................................................................................. 6 3.1.2. Modelagem To-Be ............................................................................................. 10

3.2. Modelagem de processos de negócios (BPMN) ......................................................... 14 3.2.1. Modelagem As-Is .............................................................................................. 14 3.2.2. Modelagem To-Be ............................................................................................. 16

4. Conclusão .................................................................................................................................. 17 5. Apêndice .................................................................................................................................... 18 6. Relatório da Equipe ................................................................................................................. 19

1

1. Introdução

O trabalho visa aplicar os conceitos e técnicas do iStar e BPMN vistos em sala de aula em um problema real de uma entidade pública do estado de Pernambuco. Dentro desse contexto, nasceu o Sistema de Suporte à Gestão de Telemática, tendo como base a Agência Estadual de Meio Ambiente, popularmente conhecida como CPRH. 1.1. A Organização

A CPRH é uma autarquia estadual responsável pelas questões ambientais do estado de

Pernambuco. Ela é vinculada à Secretaria de Meio Ambiente e Sustentabilidade (SEMAS) e possui aproximadamente trezentos e cinquenta funcionários, incluindo servidores, terceirizados e estagiários. As principais atividades da organização são a emissão de licenças ambientais após análise de processo, a fiscalização ambiental mediante denúncias e o monitoramento das empresas que já foram licenciadas. A CPRH também é responsável por emitir relatório semanal sobre a qualidade da água das praias de Pernambuco, informando quais pontos não estão propícios para banho. A organização possui uma coordenadoria de TIC, composta por quatro servidores concursados e seis empresas que prestam serviços relacionados à infraestrutura de redes, atendimento à usuários, desenvolvimento de sistemas, segurança de redes, dentre outras. 1.2. Descrição do Problema

Recentemente foi criado um novo setor na CPRH que será responsável por gerenciar as questões

relacionadas aos telefones fixos e telefones móveis do órgão. Esse setor chama-se ‘Telemática’ e o gerente do setor é nomeado como ‘Gestor de Telemática’.

O papel do Gestor de telemática é receber as demandas dos funcionários que estão com problemas nos telefones corporativos (fixo e móvel) e sanar este problema. Para isso, o gestor conta com o apoio de uma equipe de especialistas técnicos que fazem parte de uma empresa terceirizada chamada PEConectado.

Atualmente os usuários solicitam atendimento do gestor de telemática através de um formulário impresso, preenchendo alguns campos e informando qual o problema. O gestor analisa o problema e caso precise acionar a PEConectado ele envia um e-mail para o suporte da empresa e fica aguardando a visita técnica. Após a visita técnica, a empresa gera uma Ordem de Serviço que deve conter o Parecer Técnico gerado pela PEConectado e que é arquivada em uma pasta física.

Com o atual procedimento podemos verificar alguns problemas como: ● O usuário solicita atendimento através de um papel e não possui uma forma eficiente de

acompanhar o andamento da solicitação; ● O histórico das solicitações não é registrado; ● Dificuldade na geração de relatório por parte do gestor; ● O Parecer Técnico é enviado fisicamente à empresa.

2

1.3. Stakeholders

No fluxo do problema identificado foram identificados os seguintes stakeholders: ● Funcionário: O funcionário da empresa tem um problema de telemática que precisa ser

resolvido. Para isso ele deve encaminhar uma solicitação de atendimento à Gestão de Telemática.

● Gestor de Telemática: O Gestor é responsável por recolher e analisar as solicitações de atendimento. Caso julgue necessário, ele é responsável por acionar a empresa terceirizada (PEConectado) para resolver o problema técnico.

● PEConectado: É a empresa terceirizada que tem um contrato de prestação de serviços com a CPRH. Ao receber uma solicitação de atendimento ela é responsável por enviar um técnico à empresa para resolver o problema.

1.4. Sistema proposto

Tendo identificado o problema, propusemos um Sistema para automatizar o encaminhamento das solicitações dos funcionários à empresa de apoio técnico. O Sistema substitui a comunicação entre o Funcionário e o Gestor de Telemática e entre o Gestor e a PEConectado.

Através do Sistema o Funcionário é capaz de criar solicitações de atendimento que são analisadas pelo Gestor de Telemática. Com as solicitações criadas, o Gestor pode aprová-las para o Sistema encaminhá-las à PEConectado. Ao ser notificada, a PEConectado pode acessar o detalhamento das solicitações pelo Sistema e realizar a visita técnica à CPRH para atender o problema. Ao ser concluído o atendimento, é possível subir o arquivo de Parecer Técnico para ser registrado nas informações da solicitação e acessado pelo Gestor de Telemática. Durante ou após o atendimento é possível acompanhar o status da solicitação e obter suas informações detalhadas. O Gestor pode obter através do Sistema relatórios das solicitações passadas assim como suas Ordens de Serviço subidas pelo PEConectado. 1.5. Metodologia

Dentre as opções de empresas a analisar foi escolhida a CPRH pois é a empresa onde o membro da equipe Kennedy Bezerra trabalha atualmente e tem conhecimento sobre o processo a ser modelado por ser o próprio Gestor do setor de Telemática da empresa. A modelagem i* inicial foi feita por Kennedy utilizando a ferramenta OME3 e baseada no seu conhecimento do processo. Em seguida refinamos a modelagem, tanto SD como SR através de conversas e validações com o Gestor de Telemática. Em paralelo à modelagem i* do processo To-Be também foram definidos os requisitos organizacionais. Ao concluir a primeira modelagem, ela foi utilizada como base para a criação do BPMN, considerando os requisitos levantados e ainda sendo validado com o Gestor, além de seguir recomendações do professor Camilo.

2. Requisitos Organizacionais

Os requisitos do sistema proposto são descritos abaixo. Cada um possui um identificador, uma descrição e sua prioridade dentre as três especificadas:

● Essencial: Define um requisito crucial para o funcionamento do sistema. Sem os requisitos essenciais o sistema é incapaz de cumprir seu objetivo.

3

● Importante: Define um requisito que não é crucial para o funcionamento do sistema, porém caso não seja implementado o sistema não funcionará totalmente como planejado.

● Desejável: Define um requisito que não é essencial para o cumprimento dos objetivos do Sistema. Caso não seja implementado o sistema continua totalmente operante e cumprindo todos os objetivos, mas se presente fará do sistema mais rico.

2.1. Requisitos Funcionais 2.1.1. [RF001] Tipos de usuário

Descrição O Sistema deve possuir três tipos de usuário: Funcionário, Gestor e Suporte Técnico.

Prioridade Essencial

2.1.2. [RF002] Solicitar atendimento

Descrição O Sistema deve permitir um Funcionário ou Gestor cadastrar um problema a ser resolvido.

Prioridade Essencial

2.1.3. [RF003] Acompanhar solicitação

Descrição O Sistema deve permitir um usuário visualizar o status e detalhes de uma solicitação a qual ele/ela tem acesso.

Prioridade Importante

2.1.4. [RF004] Acesso às solicitações

Descrição Um usuário do tipo Funcionário poderá acessar apenas as solicitações de sua autoria. Um usuário Gestor tem acesso a todas as solicitações. Um usuário do tipo Suporte Técnico tem acesso apenas às solicitações aprovadas.

Prioridade Importante

2.1.5. [RF005] Notificar o Gestor

Descrição Ao ser criada uma nova solicitação o Sistema deve notificar o(s) Gestor(es) que há uma nova solicitação.

Prioridade Desejável

4

2.1.6. [RF006] Aprovar solicitação

Descrição Um Gestor deve ser capaz de validar e aprovar as solicitações recém-criadas para que sejam encaminhadas ao Suporte Técnico.

Prioridade Essencial

2.1.7. [RF007] Encaminhar solicitação

Descrição Assim que uma solicitação for aprovada por um Gestor ela deve ser encaminhada ao Suporte Técnico, gerando uma notificação ao mesmo.

Prioridade Essencial

2.1.8. [RF008] Atualizar solicitação

Descrição Um usuário Gestor deve ser capaz de atualizar manualmente o status de uma solicitação.

Prioridade Desejável

2.1.9. [RF009] Status de solicitação

Descrição Uma solicitação pode estar em um dos seguintes estados: “Pendente”, “Aprovada”, “Encaminhada”, “Em atendimento”, “Atendida” ou “Concluída”.

Prioridade Importante

2.1.10. [RF010] Upload de Parecer Técnico

Descrição Ao atender uma solicitação, um usuário de Suporte Técnico deve ser capaz de subir no Sistema o documento de Parecer Técnico associado à solicitação.

Prioridade Importante

2.2 Requisitos não funcionais 2.2.1 [RNF001] Relevância das informações fornecidas

Descrição Ao criar uma solicitação o Sistema deve solicitar informações relevantes ao usuário de forma que estas sejam suficientes para a resolução do problema.

Prioridade Importante

5

2.2.2 [RNF002] Clareza das informações

Descrição As informações disponibilizadas das solicitações devem estar claras para os usuários, com suas devidas descrições caso necessário.

Prioridade Importante

2.2.3 [RNF003] Compatibilidade dos arquivos

Descrição O sistema deve armazenar os arquivos de Parecer Técnico nos formatos adequados utilizados pelo Gestor e Suporte Técnico.

Prioridade Importante

2.2.4 [RNF004] Garantia de entrega

Descrição Deve ser garantida a entrega das solicitações aprovadas ao Suporte Técnico, com confirmação de recebimento.

Prioridade Essencial

3. Modelagens 3.1 Modelagem i* (i-star) 3.1.1 Modelagem As-Is

Para a modelagem do processo atual foram utilizados três atores, que representam os três Stakeholders identificados. O Funcionário tem relações de dependência com o Gestor de Telemática , que por sua vez tem dependências com a PEConectado .

3.1.1.1 Strategic Dependency (SD)

A seguir estão especificadas as dependências entre os atores. O modelo completo pode ser visto na Figura A.1 no Apêndice.

6

Figura 3.1: Dependências entre Funcionário e Gestor de Telemática

Na Figura 3.1 é mostrado que o Funcionário têm o objetivo de ter a solicitação de de resolução do

problema de telemática atendida. Para isso ele depende das ações do Gestor de Telemática. Para atingir este objetivo, o Funcionário precisa realizar a atividade d e relatar o problema à gestão de telemática, e ao fazer isso ele espera que seu atendimento seja o mais ágil possível. Para que o Gestor de telemática realize suas atividades ele precisa do Formulário de atendimento, que é um recurso provido pelo funcionário.

Figura 3.2: Dependências entre Gestor de Telemática e PeConectado

Na Figura 3.2 é mostrado que o objetivo do Gestor de Telemática é atender a solicitação gerada

pelo funcionário. Para isso ele depende da PEConectado para solicitar um atendimento técnico de forma mais ágil possível. O atendimento é realizado por um Técnico, descrito como um recurso que a PEConectado possui e envia à empresa. Ao concluir o atendimento, a PEConectado emite um Parecer Técnico para a Gestão de Telemática.

7

3.1.1.2. Strategic Rationale (SR) A seguir está definido o detalhamento lógico das atividades de cada ator. O modelo completo pode

ser visto na Figura A.2.

Figura 3.3: SR do ator Funcionário no modelo As-Is

Na Figura 3.3 podemos ver a interação entre as dependências do ator Funcionário. Para que

cumprir o objetivo de ter sua solicitação atendida o Funcionário tem a opção de Reportar o problema à gestão. Isso é feito imprimindo o formulário de atendimento, preenchendo-o e então entregando o formulário ao gestor. Como a única opção do formulário é imprimir o formulário físico e preenchê-lo à mão, isso afeta negatividade a rapidez com que seu problema será resolvido.

Na Figura 3.4 estão detalhadas as dependências do Gestor de Telemática. Para cumprir seu objetivo de atender às solicitações ele deve Encaminhar o problema à empresa PEConectado. Para isso é necessário que o Gestor receba o formulário de atendimento do funcionário, e solicite o atendimento pela empresa de suporte. Esta solicitação pode ser realizada por e-mail ou por telefone. Além disso, também é necessário que o Gestor realize o acompanhamento da visita do técnico à empresa (modelado como um recurso vindo da PEConectado), que tem a intenção de ser realizada de forma mais rápida possível.

8

Figura 3.4: SR do ator Gestor de Telemática no modelo As-Is

Figura 3.5: SR do ator PEConectado no modelo As-Is

9

Na Figura 3.5 são detalhadas as atividades realizadas pela PEConectado. A empresa tem o objetivo de cumprir seu contrato de serviço firmado com a CPRH. Para isso ela deve resolver os problemas de telemática recebidas. Esta atividade é realizada por receber as solicitações de atendimento da Gestão de Telemática e enviar um técnico para resolver o problema relatado. Essa visita técnica tem o objetivo de ser o mais ágil possível, pois afeta a agilidade nos outros atores. Ao ser realizada a visita técnica a empresa também é responsável por emitir um Parecer Técnico para concluir a resolução do problema solicitado. 3.1.2 Modelagem To-Be

Para modelar as dependências do sistema proposto foi incluído um novo ator no diagrama de dependências: o próprio Sistema , com o qual os três Stakeholders interagem. 3.1.2.1 Strategic Dependency (SD)

Na Figura 3.6 abaixo são mostradas as dependências associadas ao novo ator incluído no modelo proposto. O diagrama completo, com os outros três atores anteriores, pode ser visto na Figura A.3.

Figura 3.6: Dependências associadas ao Sistema no modelo proposto. À esquerda estão as dependências

com o Funcionário, abaixo com o Gestor de Telemática e à direita com a PEConectado.

Com a inclusão de um Sistema na modelagem todos os Stakeholders interagem com ele. O Funcionário agora depende do Sistema para ter sua solicitação atendida. Para isso ele cria a solicitação de atendimento através do próprio Sistema e tem a opção de acompanhar o andamento das solicitações criadas. Ao fazer isso ele espera que os dados obtidos estejam consistentes. Já o Gestor de Telemática agora tem o objetivo de melhor gerenciar as solicitações dos funcionários. Para isso ele é capaz de

10

aprovar as solicitações criadas e atualizar o andamento das mesmas. O Gestor também tem acesso a Relatórios criados pelo Sistema e o Parecer Técnico das solicitações concluídas. Da mesma forma que o funcionário, o Gestor espera que o Sistema mantenha os dados das solicitações consistentes. Já o Sistema, ao ter uma solicitação aprovada, é responsável em notificar a PEConectado, que por sua vez depende do Sistema para obter as informações sobre o problema relatado e, ao final, emitir o Parecer Técnico digitalmente.

3.1.2.2. Strategic Rationale (SR)

A seguir estão descritos os detalhes lógicos de cada ator no modelo do sistema proposto. O diagrama completo pode ser visto na Figura A.4.

Figura 3.7: SR do ator Funcionário no modelo To-Be

Como é mostrado na Figura 3.7, o Funcionário continua com o objetivo de ter seu problema

resolvido, mas para isso agora basta ele relatar o problema no Sistema. Ao fazer isso é necessário que ele

11

forneça informações relevantes para a solução do problema e ele espera que seu problema seja atendido rapidamente. Além disso, um Funcionário tem um novo objetivo de Acompanhar o andamento de suas solicitações. Para isso ele pode solicitar os detalhes das solicitações ao Sistema, e espera que os dados mostrados sejam consistentes.

Figura 3.8: SR do ator Gestor de Telemática no modelo To-Be

Para atender às solicitações dos funcionários agora basta ao gestor aprovar as solicitações feitas

pelo sistema. Para isso é necessário que o Gestor analise as informações fornecidas sobre a solicitação, as aprove para encaminhamento caso necessário e então realize o acompanhamento da visita técnica da PEConectado. Em contraste com a alternativa as-is de encaminhar o problema à PEConectado, necessidade de apenas aprovar a solicitação no sistema para que ela seja encaminhada contribui positivamente para a agilidade do atendimento. O Gestor agora também tem o objetivo de melhor gerenciar as solicitações feitas. Para isso é possível obter e controlar informações detalhadas que estão registradas no sistema, como solicitar um histórico das solicitações, atualizar seus status e ter acesso ao Parecer Técnico das solicitações concluídas. Ao atualizar as informações das solicitações é necessário que seja mantida a consistência dos dados informados.

12

Figura 3.9: SR do ator PEConectado no modelo To-Be

Na Figura 3.9 vemos o detalhamento da empresa de suporte técnico. Em contraste com o modelo

as-is, para resolver os problemas de telemática agora é necessário receber as informações do problema através do Sistema. Ao concluir o atendimento, a empresa também pode enviar o parecer técnico através do Sistema, e não diretamente ao Gestor de Telemática.

Na Figura 3.10 é detalhada a lógica das dependências do Sistema. Para fazer a criação das solicitações o Sistema deve encaminhá-las do funcionário à PEConectado. Para isso é necessário que seja feita a coleta de informações na criação da solicitação e então a aprovação feita pelo Gestor. Assim que aprovada, a solicitação é encaminhada à PEConectado. Na criação da solicitação é necessário que os dados coletados sejam relevantes para o problema. O Sistema também tem outro objetivo de manter o progresso das solicitações. Para isso existem quatro atividades que podem ser realizadas. O Gestor pode atualizar as informações das solicitações, onde é preciso manter a consistência dos dados. Também é possível gerar um histórico das solicitações, que pode ser consultado por um funcionário ou exportado em relatórios para o Gestor. Também é possível informar o detalhamento das informações para a PEConectado e registrar o Parecer Técnico no Sistema, que pode ser acessado pelo Gestor.

13

Figura 3.10: SR do ator Sistema no modelo To-Be

3.2 Modelagem BPMN

Na notação BPMN, o processo de negócio é representado em um diagrama que é fácil de ler tanto para os usuários técnicos quanto para os usuários de negócios. É intuitivo e permite a representação de detalhes complexos do processo. BPMN serve como uma linguagem padrão, colocando um fim na lacuna de comunicação entre a modelagem do processo e sua execução. 3.2.1 Modelagem As-Is

Na figura 3.11 o fluxo de atividades está descrito de forma objetiva, onde funcionário e Gestor

de Telemática fazem parte da mesma piscina (CPRH) por se tratar de elementos de uma mesma empresa. Já em outra piscina (PeConectado), é descrito de forma detalhada a comunicação entre o atendimento da empresa e o técnico responsável por resolver o problema da empresa CPRH.

De acordo com o fluxo, o processo se inicia pelo funcionário sendo necessário a impressão do formulário e preenchimento pelo mesmo. Esse formulário é entregue ao gestor que tem como função analisar o formulário e decidir se possui a necessidade de um técnico especializado. Caso não precise, o problema é resolvido internamente pelo gestor, caso contrário, o Gestor envia uma requisição a empresa terceirizada PeConectado e a mesma processa a solicitação e envio do técnico especializado. Quando o técnico chega a empresa o Gestor de Telemática é responsável em acompanhar essa visita técnica. Depois disso, a empresa terceirizada emite uma ordem de serviço que é enviada para a CPRH, onde o Gestor tem a função de arquivar em pasta física esse parecer (ordem de serviço) e o processo é finalizado.

14

Figura 3.11: Modelo BPMN do As-Is

15

3.2.2 Modelagem To-Be

Na figura 3.12 o fluxo de atividades está descrito de forma objetiva onde funcionário , Gestor de Telemática e o sistema fazem parte da mesma piscina (CPRH) por se tratar de elementos de uma mesma empresa. Já em outra piscina (PEConectado), é descrito de forma detalhada a comunicação entre o atendimento da empresa e o técnico responsável por resolver o problema da empresa CPRH.

O processo se inicia com o funcionário que reporta o problema criando uma solicitação, enviando para o sistema para registrar a solicitação do problema, em seguida o gestor verifica a solicitação e se for preciso um apoio técnico, modifica-se o status da solicitação no sistema. O sistema notifica a PEConectado encaminhando a solicitação , caso contrário resolve o problema internamente e em paralelo é modificado o status no sistema.

O atendimento do PEConectado recebe a mensagem de aviso e envia um técnico para a empresa e realiza a visita que será acompanhada pelo gestor, então resolve-se o problema e elabora um parecer técnico (ordem de serviço) e o atendimento emite uma ordem de serviço que é encaminhado para o CPRH no qual é verificado pelo gestor após acompanhar a visita técnica. Se o problema for resolvido, então finaliza a solicitação no sistema caso contrário informar o problema não resolvido para o técnico para resolver os problemas pendentes. Logo após o gestor atualizar o sistema, este envia uma notificação para o funcionário e o mesmo recebe a atualização e finaliza a solicitação.

Figura 3.12 : Modelo BPMN To-Be

16

4. Conclusão

Das opções de empresas consideradas foi escolhida a CPRH por haver um contato mais fácil pelos membros da equipe e já haver conhecimento do problema atacado. Através de conversas com o Gestor de Telemática, principal stakeholder no problema atacado, e utilizando conhecimentos obtidos em sala de aula foram criadas modelagens do ambiente onde ocorre o problema e da solução proposta para atacá-lo.

O primeiro tipo de modelagem utilizado foi a modelagem i*, que serviu para definir inicialmente as relações de dependências entre os principais atores no modelo do ambiente. Em seguida foram modelados os fluxos dos processos de negócio utilizando BPMN. Esta segunda modelagem foi útil para refinar e definir de forma mais clara o fluxo seguido pelas atividades do processo.

Através do projeto a equipe foi capaz de desenvolver suas habilidades de identificação e especificação de requisitos para as etapas iniciais de um projeto.

17

5. Apêndice

Figura A.1: Modelo SD (i*) As-Is

Figura A.2: Modelo SR (i*) As-Is

Figura A.3: Modelo SD (i*) To-Be

18

Figura A.4: Modelo SR (i*) To-Be

6. Relatório da equipe

Nome do integrante Papéis Assinatura

Bruno Jorge Batista ● BPMN ● Relatório

Kennedy Bezerra Lins ● Contato da empresa; ● I-star; ● Relatório

Marília Isabelly Nogueira ● BPMN ● Relatório

Thalles Cezar de Lima ● i-star; ● Requisitos; ● Relatório

19