UFPE · Web view4.1.4[NFR04] Utilizar Java Server Faces(JSF)16 4.1.5[NFR05] Utilizar Java Database...

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

Pós-graduação em Ciência da Computação

SIG@FTAEspecificação de Requisitos

Professor: Jaelson Freire Brelaz de Castro

Equipe: Fernanda Nóbrega de Medeiros Martins

Mayara Benício de Barros Souza

Suzane Mendes da Silva

Yane Wanderley dos Santos Rodrigues

{fnmm, mbbs, sms5, ywsr} @cin.ufpe.br

Recife, 18 de Outubro de 2011

SIG@FTA Versão: 2.0EspecificacaoRequisitos.doc Data da versão: 24/10/201

Histórico de Revisões

Revisão Data Descrição Autor

01 23/09 Início do Documento de Requisitos. fnmm, mbbs, sms5 e ywsr.

02 26/09Continuação do documento. Adicionando Introdução, Requisitos Organizacionais e Requisitos Não-Funcionais

fnmm, mbbs, sms5 e ywsr.

03 29/09Continuação do documento. Correção e adição de Requisitos Funcionais. Correção e adição de Requisitos Não-Funcionais.

fnmm, mbbs, sms5 e ywsr.

04 02/10Continuação do documento. Editando Introdução e correção de Requisitos Funcionais. ywsr

05 03/10Continuação do documento. Correção de Requisitos Funcionais. ywsr

06 04/10 Continuação do documento. sms5

07 05/10Correções de todo o documento através do feedback do cliente fnmm e mbbs

08 05/10 Criação do UC02, UC03, UC04 fnmm e mbbs

09 05/10Criação do Anexo E com o UC01 de Infraestrutura do SIG@Processo fnmm e sms5

10 09/10 Correção dos casos de uso sms5

11 10/10 Revisão do documento fnmm e mbbs

12 14/10 Primeira versão do modelo de caso de uso mbbs e sms5

13 14/10 Alterações nos requisitos e nos casos de uso ywsr

14 18/10 Primeira versão do modelo SR e SD fnmm e mbbs

15 22/10Modificações aos modelos SR, SD e de caso de uso ywsr

16 23/10 Modificações no documento ywsr

17 24/10 Revisão final do documento sms5

fnmm, mbbs, sms5, ywsr Página 2 24/10/2011


Índice1. INTRODUÇÃO...............................................................................................................................7

1.1 MOTIVAÇÃO..............................................................................................................................7

1.2 PROBLEMA IDENTIFICADO........................................................................................................7

1.3 SOLUÇÃO ENCONTRADA..........................................................................................................7

1.4 A ORGANIZAÇÃO......................................................................................................................8

1.5 CONVENÇÕES PARA IDENTIFICAÇÃO DOS REQUISITOS..........................................................8

1.6 CONVENÇÕES PARA IDENTIFICAÇÃO DOS CASOS DE USO....................................................8

1.6.1 Estrutura dos casos de uso..........................................................................................81.6.2 Prioridades dos casos de uso......................................................................................91.6.3 Descrição dos Atores....................................................................................................9

2. REQUISITOS ORGANIZACIONAIS..........................................................................................9

3. REQUISITOS FUNCIONAIS......................................................................................................10

3.1 CADASTRO DO FLUXO DE TRAMITAÇÃO AUTOMÁTICO (FTA).............................................10

3.1.1 [RF01] Inserir FTA.......................................................................................................103.1.2 [RF02] Consultar FTA.................................................................................................103.1.3 [RF03] Alterar FTA.......................................................................................................103.1.4 [RF04] Remover FTA..................................................................................................11

3.2 INFRAESTRUTURA DO SIG@PROCESSO..............................................................................11

3.2.1 [RF05] Registrar processo com FTA........................................................................113.2.2 [RF06] Receber processo com FTA.........................................................................113.2.3 [RF07] Enviar processo com FTA.............................................................................123.2.4 [RF08] Interromper FTA..............................................................................................123.2.5 [RF09] Voltar FTA........................................................................................................133.2.6 [RF10] Solicitar parecer..............................................................................................133.2.7 [RF11] Emitir parecer..................................................................................................133.2.8 [RF12] Arquivar processo com FTA..........................................................................143.2.9 [RF13] Inserir Tipo de Despacho..............................................................................143.2.10 [RF14] Consultar Tipo de Despacho........................................................................143.2.11 [RF15] Alterar Tipo de Despacho..............................................................................143.2.12 [RF16] Remover Tipo de Despacho.........................................................................14

4. REQUISITOS NÃO-FUNCIONAIS...........................................................................................15

4.1 REQUISITOS DE PROCESSO...................................................................................................15

4.1.1 [NFR01] Utilizar Scrum como Metodologia de Desenvolvimento........................15



4.1.2 [NFR02] Plataforma Web............................................................................................154.1.3 [NFR03] Utilizar Linguagem Java para Web (J2EE)..............................................154.1.4 [NFR04] Utilizar Java Server Faces(JSF)................................................................164.1.5 [NFR05] Utilizar Java Database Connectivity (JDBC)...........................................164.1.6 [NFR06] Utilizar Sistema de Gerenciamento de Banco de Dados Oracle.........164.1.7 [NFR07] Utilizar Apache Tomcat...............................................................................16

4.2 REQUISITOS DE PRODUTO.....................................................................................................17

4.2.1 Usabilidade...................................................................................................................174.2.1.1 - [NFR08] Mensagens de Feedback...................................................................174.2.1.2 - [NFR09] Facilidade de Utilização......................................................................174.2.1.3 - [NFR10] Facilidade de aprendizado.................................................................174.2.1.4 - [NFR11] Numero reduzido de dados informados pelo usuário....................184.2.1.5 - [NFR12] Consistência.........................................................................................18

4.2.2 Confiabilidade...............................................................................................................184.2.2.1 - [NFR13] Tolerância a falhas..............................................................................184.2.2.2 - [NFR14] Heterogeneidade de Conhecimento.................................................19

4.2.3 Disponibilidade.............................................................................................................194.2.3.1 - [NFR15] Disponibilidade.....................................................................................19

4.2.4 Segurança.....................................................................................................................194.2.4.1 - [NFR16] Autenticação.........................................................................................194.2.4.2 - [NFR17] Integridade............................................................................................204.2.4.3 - [NFR18] Confidencialidade................................................................................20

4.2.4.4 - [NFR19] Conexão Segura..................................................................................20

4.2.5 Extensibilidade.............................................................................................................214.2.5.1 - [NFR20] Extensibilidade.....................................................................................21

4.2.6 Desempenho................................................................................................................214.2.6.1 - [NFR21] Tempo de Resposta............................................................................21

4.3 REQUISITOS EXTERNOS.........................................................................................................21

4.3.1 [NFR22] Orçamento....................................................................................................214.3.2 [NFR23] Tempo de desenvolvimento.......................................................................214.3.3 [NFR24] Restrições Legais........................................................................................224.3.4 [NFR25] Interoperabilidade........................................................................................22

5. MODELAGEM ORGANIZACIONAL........................................................................................23

5.1 MODELAGEM DE DEPENDÊNCIA ESTRATÉGICA....................................................................23

5.2 MODELAGEM DE RAZÃO ESTRATÉGICA................................................................................24

6. MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO).................................28



7. MODELAGEM DE REQUISITOS NÃO FUNCIONAIS.........................................................30

8. CONCLUSÃO..............................................................................................................................34

GLOSSÁRIO........................................................................................................................................35

REFERÊNCIAS BIBLIOGRÁFICAS................................................................................................37

ANEXO A – TÉCNICAS UTILIZADAS............................................................................................38

ENTREVISTA........................................................................................................................................38

COLETA DE DOCUMENTOS................................................................................................................41

ANEXO B – DESCRIÇÃO DOS CASOS DE USO........................................................................42

CADASTRO DO FLUXO DE TRAMITAÇÃO AUTOMÁTICA (FTA)..........................................................42

[UC01] Inserir FTA.......................................................................................................................42[UC02] Definir nó (Órgão e tipo “Arquivamento”)...................................................................43[UC03] Definir aresta (regra)......................................................................................................44[UC04] Consultar FTA.................................................................................................................45[UC05] Alterar FTA......................................................................................................................45[UC06] Remover FTA..................................................................................................................47

INFRAESTRUTURA PARA O FLUXO DE TRAMITAÇÃO AUTOMÁTICA..................................................48

[UC07] Registrar Processos com FTA.....................................................................................48[UC08] Receber Processo com FTA........................................................................................49[UC09] Enviar Processo com FTA............................................................................................50[UC10] Interromper FTA.............................................................................................................52[UC11] Voltar FTA........................................................................................................................53[UC12] Solicitar Parecer.............................................................................................................53[UC13] Emitir Parecer.................................................................................................................55[UC14] Arquivar processo com FTA.........................................................................................56[UC15] Inserir Tipo de Despacho..............................................................................................57[UC16] Consultar Tipo de Despacho........................................................................................58[UC17] Alterar Tipo de Despacho.............................................................................................59[UC18] Remover Tipo de Despacho.........................................................................................60[UC19] Logar no (acessar o) sistema.......................................................................................60[UC20] Logar no (acessar o) sistema com login, senha e captcha.....................................61



1. Introdução

Este documento tem por objetivo descrever o problema do Órgão objeto do estudo, bem

como especificar os requisitos identificados para a solução encontrada após entrevistas com o cliente

estudo de alternativas. A solução busca fornecer o suporte necessário para possibilitar maior

automatização aos processos eletrônicos existentes na UFPE.

O objeto de estudo deste trabalho é o grupo de analistas e técnicos administrativos que

gerenciam o módulo de processos do Projeto SIG@, o SIG@Processo. Com a solução encontrada,

pretende-se aperfeiçoar o funcionamento do módulo SIG@Processo, permitindo que os processos

eletrônicos registrados tramitem automaticamente entre os órgãos aos quais estiverem associados.

As informações apresentadas em todo o trabalho foram cedidas pelo atual diretor do NTI, o

professor José Antônio Monteiro de Queiroz, pela Gerente de Desenvolvimento de Sistemas de

Informação do NTI, Shirley Jacinto, pelo Líder do módulo SIG@Processo, Lucas Albertins de Lima e

sua equipe, Jonas Cesar e Ubiracy Júnior.

1.1 MotivaçãoEste projeto surge da necessidade de permitir uma maior automatização das tramitações e

tarefas realizadas em cada fase do processo administrativo. Atualmente, embora parte do módulo

Sig@Processo esteja em funcionamento, ainda há grande dependência de ações manuais, causando

problemas como envio do processo para locais errados, demora no despacho de processos, que

causa o atraso no término de processos.

1.2 Problema IdentificadoA partir de fevereiro de 2010, com o início do módulo SIG@Processo, alguns dos processos

administrativos da UFPE passaram a ser eletrônicos. Entretanto, problemas como o envio dos

processos para órgãos errados e a negligência quanto aos prazos dos processos, acarretam longos

atrasos ao término dos mesmos.

Sabe-se ainda que uma das metas da UFPE é criar um Bureau de Processos, sendo esse o

responsável por controlar e melhor os processos administrativos da universidade.

Dessa forma, é esperado que a solução mitigue o problema do envio de processos para

órgãos errados, aumentar o controle dos prazos processuais, aumentando as chances de terminar os

processos administrativos no tempo correto.

1.3 Solução Encontrada Diante a necessidade do NTI, a solução encontrada diz respeito à criação de uma base que

permita o cadastro de Fluxos de Tramitação Automáticos (FTA). Cada tipo de processo administrativo



contará com um FTA. Assim, com esse cadastro será possível saber os órgãos responsáveis por

cada tramitação de um processo, bem como os documentos e formulários necessários para que o

mesmo prossiga. Nesse sentido, será desenvolvida a infraestrutura necessária para a automatização

das tramitações, a partir da adaptação do módulo SIG@Processo na sua forma atual.

1.4 A OrganizaçãoO Núcleo de Tecnologia da Informação (NTI) é o órgão suplementar da UFPE responsável

pela gestão de infraestrutura de software e hardware da universidade, além de planejar e executar a

sua política de informática. É responsável ainda pela elaboração e desenvolvimento de projetos em

Tecnologia de Informação e serviços de informática. O NTI busca captar recursos através de projetos,

consultoria e serviços em tecnológicos [1].

O SIG@ é um dos projetos desenvolvidos e mantidos pelo NTI. Atualmente está presente em

cinco instituições: UFPE, UFRPE, UPE, AEDA e UNIVASF e é fundamental em cada uma delas,

atendendo às necessidades de discentes, docentes e técnico-administrativos. O sistema oferece os

seguintes módulos:

• SIG@ Acadêmico, que permite a visualização de dados acadêmicos e a realização de

procedimentos acadêmicos online; e

• O SIG@ Processo, inaugurado em 08 de fevereiro de 2010, é o Sistema de

Processos Administrativos da UFPE, que objetiva a diminuição da tramitação física da documentação,

economizando tempo [6].

Estruturalmente, o sistema conta com dezesseis servidores, sendo três de banco de dados,

onze de aplicação e dois Web, além de um firewall que suportam 1.210 usuários simultaneamente.

1.5 Convenções para Identificação dos RequisitosOs requisitos serão indicados e referenciados por um indicador no formato [RFxx], para os

requisitos funcionais, e no formato [RNFxx] para os não funcionais. Nesse sentido, xx faz referência

ao número do requisito, que possuirão os nomes dos casos de uso relacionados.

1.6 Convenções para Identificação dos Casos de UsoOs casos de uso são indicados e referenciados por um indicador no formato [UCxx], em que

xx faz referência ao número do caso de uso.

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

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 principais, secundários e/ou alternativos;

Saídas: Respostas 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.6.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.6.3 Descrição dos Atores

Os atores são aqueles que interagem de alguma forma com o sistema. Neste projeto existem

dois atores:

Os servidores designados a gerenciar o Fluxo de Tramitação Automática (FTA) –

responsáveis pelo cadastro e manutenção dos FTAs e

Os servidores (docentes e técnicos), alunos e usuários externos que utilizam os

processos eletrônicos – responsáveis por registrar e dar prosseguimento aos processos

administrativos eletrônicos da UFPE.

2. Requisitos Organizacionais

Os requisitos organizacionais são derivados de políticas e procedimentos da organização do

cliente e do desenvolvedor. Devem satisfazer os objetivos da organização e definir porque o sistema

é necessário. São eles:

Automatizar as tramitações dos processos administrativos eletrônicos – tornar a

execução de tramitações e tarefas associadas à processos, mais automática;

Mitigar as chances do processo ser enviado a órgãos errados – eliminar este erro,

aumentando a probabilidade do processo terminar no tempo correto e

Reduzir o tempo total de execução de um processo administrativo - possibilitar que a

UFPE seja célere no andamento dos processos, mediante a automatização e otimização



dos fluxos dos processos.

3. Requisitos Funcionais

Neste capítulo são definidas as funcionalidades que o sistema deve fornecer. Os requisitos

estão divididos em dois grupos: Cadastro do Fluxo de Tramitação Automática e Infraestrutura do

SIG@Processo. O primeiro é relativo às ações de cadastro do FTA e o segundo se refere à

adaptação do sistema para dar suporte ao FTA.

3.1 Cadastro do Fluxo de Tramitação Automático (FTA)

3.1.1 [RF01] Inserir FTA

Identificação: [RF01] Inserir FTA

Casos de Uso relacionados: [UC01], [UC02] e [UC03].

Descrição:

Permite que o usuário insira um FTA para um assunto de processo

especifico. Para isso, ele deverá selecionar o assunto do processo e

definir cada tramitação do FTA, bem como sua regra. Cada

tramitação de FTA possui uma regra, que é o conjunto de

formulários, documentos e despachos associados à mesma. Além

disso, é preciso informar quais os possíveis órgãos que a tramitação

poderá seguir, de acordo com o despacho, documentos e

formulários

Prioridade: Essencial Importante Desejável

3.1.2 [RF02] Consultar FTA

Identificação: [RF02] Consultar FTA

Casos de Uso relacionados: [UC04]

Descrição:

O usuário poderá consultar o FTA correspondente ao assunto do

processo. O usuário deverá informar qual assunto deseja para que o

FTA correspondente seja exibido.


3.1.3 [RF03] Alterar FTA

Identificação: [RF03] Alterar FTA

Casos de Uso relacionados: [UC02], [UC03] e [UC05].

Descrição: O usuário poderá alterar o FTA correspondente ao assunto do fnmm, mbbs, sms5, ywsr Página 9 24/10/2011


processo. Para isso deverá informar qual assunto deseja para que o

FTA correspondente seja exibido e permita ser alterado. Todos os

elementos do grafo do FTA (nó e arestas) poderão ser alterados.


3.1.4 [RF04] Remover FTA

Identificação: [RF04] Remover FTA

Casos de Uso relacionados: [UC06].

Descrição:

O usuário poderá remover o FTA correspondente ao assunto do

processo. Para isso, é necessário consultar o FTA relacionado ao

assunto desejado. Os processos abertos com o assunto do FTA

removido seguirão o fluxo dirigido, em que o responsável pela

tramitação indica para qual órgão o processo deve seguir (como

ocorre atualmente).


3.2 Infraestrutura do SIG@Processo

3.2.1 [RF05] Registrar processo com FTA

Identificação: [RF05] Registrar processo com FTA


Descrição:

Permite que o usuário registre um processo. Para tal deverá

escolher o assunto do processo, preencher o(s) formulário(s) e

anexar o(s) documento(s) necessário(s).


3.2.2 [RF06] Receber processo com FTA

Identificação: [RF06] Receber processo com FTA


Descrição: Adapta a funcionalidade “Receber Processo”, existente atualmente,

para dar suporte ao FTA. Para tal, informa ao usuário o prazo de

recebimento do processo. Se o processo tiver o prazo de

recebimento ultrapassado, o mesmo recebe prioridade, sendo



sinalizado de vermelho e ocupando lugar de destaque dentre os

processos a serem recebidos. Ao expirar o prazo de recebimento, o

sistema registra as informações da perda de prazo em um

andamento do processo.


3.2.3 [RF07] Enviar processo com FTA

Identificação: [RF07] Enviar processo FTA


Descrição:

Adapta a funcionalidade “Enviar Processo”, existente atualmente,

para dar suporte ao FTA. Para isso, a partir da segunda tramitação

do processo, informa-se ao usuário as possíveis tramitações que o

processo poderá seguir, conforme a escolha do(s) documento(s),

formulário(s) e despacho.

Além disso, informa-se ao usuário o prazo de envio do processo. Se

o prazo de envio estiver ultrapassado, o processo recebe prioridade,

sendo sinalizado de vermelho e ocupando lugar de destaque dentre

os processos a serem manipulados. Ao expirar o prazo de envio, o

sistema registra as informações da perda de prazo em um

andamento do processo.

Por fim, possibilita que o usuário anexe os documentos, preencha os

formulários e exare os despachos necessários. Com essas

informações o processo será enviado para a próxima tramitação.


3.2.4 [RF08] Interromper FTA

Identificação: [RF08] Interromper FTA


Descrição:

Permite que o usuário desvie o fluxo do FTA definido para o assunto

do processo. O sistema passará a se comportar como funciona

atualmente, um fluxo direcionado pelo usuário.




3.2.5 [RF09] Voltar FTA

Identificação: [RF09] Voltar FTA


Descrição:

Permite que o processo retorne à mesma tramitação em que houve

a interrupção do FTA. O sistema volta a se comportar conforme o

FTA definido para o assunto do processo.


3.2.6 [RF10] Solicitar parecer

Identificação: [R10] Solicitar parecer


Descrição:

Permite que o usuário solicite um parecer para exarar um despacho

em determinado processo. Para isso, ele deverá informar o parecer

necessário, selecionar as pessoas que emitirão o parecer e informar

se o parecer será público (em que qualquer pessoa com acesso ao

processo terá acesso ao parecer) ou privado (em que apenas quem

solicitou o parecer terá acesso ao mesmo). Seja a solicitação

privada ou pública, os dados pessoais (nome, CPF, etc) dos

indicados não serão disponibilizados. Além disso, a ação de exarar o

despacho pode ocorrer mesmo que nenhum parecer tenha sido

emitido.


3.2.7 [RF11] Emitir parecer

Identificação: [RF11] Emitir parecer


Descrição:

Possibilita ao usuário emitir um parecer solicitado para um processo.

Para tal, deverá ter acesso ao processo (com todas as informações

relacionadas ao mesmo) para que então emita seu parecer. Assim

que o parecer for emitido, estará disponível no processo para que o

solicitante possa verificá-lo.




3.2.8 [RF12] Arquivar processo com FTA

Identificação: [RF12] Arquivar processo com FTA


Descrição:Possibilita arquivamento de um processo, para as tramitações

cadastradas como próprias para arquivamento.


3.2.9 [RF13] Inserir Tipo de Despacho

Identificação: [RF13] Inserir Tipo de Despacho


Descrição: Permite inserir um Tipo de Despacho. É necessário informar o nome e a descrição do Tipo de Despacho a ser inserido.


3.2.10 [RF14] Consultar Tipo de Despacho

Identificação: [RF14] Consultar Tipo de Despacho


Descrição: Permite consultar os Tipos de Despacho existentes. É necessário informar o nome do Tipo de Despacho.


3.2.11 [RF15] Alterar Tipo de Despacho

Identificação: [RF15] Alterar Tipo de Despacho


Descrição: Permite alterar um Tipo de Despacho. É necessário consultar o Tipo de Despacho a ser alterado.


3.2.12 [RF16] Remover Tipo de Despacho

Identificação: [RF16] Inserir Tipo de Despacho


Descrição: Permite remover um Tipo de Despacho. Para isso, é necessário consultar o Tipo de Despacho a ser removido.




4. Requisitos Não-Funcionais

Este capítulo descreve requisitos relacionados com restrições e aspectos de qualidade.

Segundo Sommervile [7], tais requisitos podem ser agrupados em três grupos, a saber: requisitos de

processo, requisitos de produto e requisitos externos.

4.1 Requisitos de Processo

4.1.1 [NFR01] Utilizar Scrum como Metodologia de Desenvolvimento

Identificação: [NFR18] Utilizar Scrum como Metodologia de Desenvolvimento

Casos de Uso relacionados: Todos.

Descrição:

A fim de que as atividades sejam desempenhadas de forma ágil e

eficiente, além de estabelecer maior contato com o usuário, Scrum

será a metodologia adotada para auxiliar o gerenciamento do

projeto.


4.1.2 [NFR02] Plataforma Web

Identificação: [NFR02] Plataforma Web


Descrição:O sistema deverá operar sobre plataforma web.

4.1.3 [NFR03] Utilizar Linguagem Java para Web (J2EE)

Identificação: [NFR03] Utilizar Linguagem Java para Web (J2EE)


Descrição:Por ser uma linguagem independente de plataforma e fornecer

suporte para a Web, o sistema será desenvolvido utilizando Java

para Web.




4.1.4 [NFR04] Utilizar Java Server Faces(JSF)

Identificação: [NFR04] Utilizar Java Server Faces (JSF)


Descrição:Para permitir maior separação entre as camadas de visualização e

de regra de negócios, JSF será adotada como a ferramenta para a

criação das interfaces Web.


4.1.5 [NFR05] Utilizar Java Database Connectivity (JDBC)

Identificação: [NFR05] Utilizar Java Database Connectivity (JDBC)


Descrição:Por ser o padrão adotado pelo projeto SIG@, JDBC será a API

utilizada para auxiliar na execução e manipulação das consultas dos

dados.


4.1.6 [NFR06] Utilizar Sistema de Gerenciamento de Banco de Dados Oracle

Identificação:[NFR06] Utilizar Sistema de Gerenciamento de Banco de Dados

Oracle


Descrição:

Por permitir grande otimização de desempenho para dados em

grande quantidade, sendo uma potente ferramenta cliente/servidor

para a gestão de base de dados, além de ser o banco de dados

utilizado pelo projeto SIG@, o Oracle será o Sistema de

Gerenciamento de Banco de Dados utilizado.


4.1.7 [NFR07] Utilizar Apache Tomcat

Identificação: [NFR07] Utilizar Apache Tomcat


Descrição: O Apache Tomcat será o servidor web adotado no projeto para a



interpretação das aplicações escritas em Java para Web.


4.2 Requisitos de Produto4.2.1 Usabilidade

4.2.1.1 - [NFR08] Mensagens de Feedback

Identificação: [NFR08] Mensagens de Feedback


Descrição:

As mensagens de erros deverão ser claras e objetivas, de forma a

orientar o usuário a solucionar o problema apresentado e não tornar

a repetir o erro. Quanto às mensagens de sucesso, será informar ao

usuário o resultado da execução de funcionalidades utilizadas pelo

mesmo, sempre que alguma ação que altere o sistema for realizada.

Em solicitações mais demoradas, como em geração de relatórios,

deverá se utilizar imagens que indiquem que o sistema está

processando a solicitação realizada.


4.2.1.2 - [NFR09] Facilidade de Utilização

Identificação: [NFR09] Facilidade de Utilização


Descrição:

O sistema deverá possuir interface gráfica de fácil utilização pelos

usuários, que devem precisar de poucos cliques de mouse para

conseguir realizar as principais operações. Além disso, deve contar

com páginas de ajuda de rápido e fácil acesso.


4.2.1.3 - [NFR10] Facilidade de aprendizado

Identificação: [NFR10] Facilidade de aprendizado


Descrição: O sistema deverá permitir que o usuário possa rapidamente fnmm, mbbs, sms5, ywsr Página 16 24/10/2011


aprender a utilizá-lo. O usuário não deve precisar investir muito

tempo ao aprender a utilizar o sistema.


4.2.1.4 - [NFR11] Numero reduzido de dados informados pelo usuário

Identificação: [NFR11] Número reduzido de dados informados pelo usuário


Descrição:

A quantidade de informações exibidas ao usuário deverá ser a

menor possível. Sempre que possível, os dados deverão ser

fornecidos pelo sistema ao invés de serem informados pelo usuário,

de forma a eliminar a necessidade de o usuário fornecer

informações repetitivamente.


4.2.1.5 - [NFR12] Consistência

Identificação: [NFR12] Consistência


Descrição:

A interface deverá se apresentar sempre da mesma forma, para

evitar frustração causada por elementos (botões, links, menus)

inesperados. Será utilizada mesma apresentação visual e de

comportamento para cada elemento, não utilizando um mesmo

ícone para ações distintas ou ícones diferentes para uma mesma

ação.


4.2.2 Confiabilidade

4.2.2.1 - [NFR13] Tolerância a falhas

Identificação: [NFR13] Tolerância a Falhas




Descrição:

O sistema deverá gerenciar as falhas inesperadas das operações,

assegurando que transações não serão feitas de forma incompleta.

Além disso, o sistema usará um serviço de registro de transações

(logs).


4.2.2.2 - [NFR14] Heterogeneidade de Conhecimento

Identificação: [NFR14] Heterogeneidade de Conhecimento


Descrição:Os usuários do sistema passarão por um período de treinamento, dada a diferença nos níveis de conhecimento, tanto em informática como do próprio módulo SIG@Processo, por parte dos mesmos.


4.2.3 Disponibilidade

4.2.3.1 - [NFR15] Disponibilidade

Identificação: [NFR15] Disponibilidade


Descrição: O sistema deverá estar no ar pelo menos 90% do tempo. Erros dos usuários não devem deixar o sistema indisponível.


4.2.4 Segurança

4.2.4.1 - [NFR16] Autenticação

Identificação: [NFR16] Autenticação


Descrição:

Apenas usuários previamente cadastrados e devidamente autenticados através de login e senha poderão fazer uso do sistema. Uma vez autenticados os usuários só poderão ter acesso às funcionalidades aos quais o seu perfil tenha acesso. Os perfis de usuário deverão ser diferenciados.




4.2.4.2 - [NFR17] Integridade

Identificação: [NFR17] Integridade


Descrição:Os dados do sistema estarão acessíveis para manipulação apenas por pessoas autorizadas, de forma a garantir que os dados armazenados e consultados estejam corretos em relação aos dados fornecidos ao sistema.


4.2.4.3 - [NFR18] Confidencialidade

Identificação: [NFR19] Confidencialidade


Descrição:O usuário terá a garantia que seus dados não serão divulgados a terceiros sem autorização prévia.


4.2.4.4 - [NFR19] Conexão Segura

Identificação: [NFR20] Conexão


Descrição:O sistema deverá dar suporte a conexões SSL entre o servidor de aplicação e o browser dos usuários.




4.2.5 Extensibilidade

4.2.5.1 - [NFR20] Extensibilidade

Identificação: [NFR22] Extensibilidade


Descrição:O sistema deverá ser extensível, para agregar novos requisitos em versões futuras.


4.2.6 Desempenho

4.2.6.1 - [NFR21] Tempo de Resposta

Identificação: [NFR23] Tempo de Resposta


Descrição:O tempo de resposta às funcionalidades não deve exceder 2 segundos em 90%, à exceção daquelas que exijam muito processamento, como geração de relatórios.


4.3 Requisitos Externos

4.3.1 [NFR22] Orçamento

Identificação: [NFR25] Orçamento


Descrição:O custo do projeto será estabelecido através da quantidade de recurso humano necessário, ou seja, quantos servidores serão responsáveis pelo desenvolvimento do projeto.


4.3.2 [NFR23] Tempo de desenvolvimento

Identificação: [NFR26] Tempo de desenvolvimento




Descrição: O tempo de desenvolvimento da primeira versão do projeto não deve ultrapassar o período de 4 meses.


4.3.3 [NFR24] Restrições Legais

Identificação: [NFR27] Restrições Legais


Descrição: Toda informação relativa ao sistema devem ser mantidos em sigilo, sob pena de punição federal.


4.3.4 [NFR25] Interoperabilidade

Identificação: [NFR23] Interoperabilidade


Descrição: O sistema será suportado, a princípio, pelos navegadores Firefox e Internet Explorer




5. Modelagem Organizacional

Este capítulo apresenta as modelagens organizacionais do sistema, realizadas com

a notação i* (i estrela). Primeiramente será apresentada a modelagem de dependência

estratégica. Em seguida a modelagem de razão estratégica.

5.1 Modelagem de Dependência Estratégica

A Figura 1 abaixo apresenta a modelagem de dependência estratégica para o

sistema. Em seguida o modelo é explicado em detalhes:

Figura 1- Modelagem de Dependência Estratégica

Este modelo apresenta as dependências entre os atores. Com o SIG@Processo com

FTA ao centro, percebe-se que todos os demais atores passam por ele. O servidor

responsável pelo Bureau de Processos depende do SIG@Processo com FTA para a

administração dos FTAs. Depende ainda de algum especialista do servidor responsável por

Gerenciar Processos para obter informações sob os fluxos que os processos seguem e

então ter base para poder otimizar o fluxo dos processos.

O servidor responsável por Gerenciar Processos depende do sistema para a



administração de processos e, através disso, entre outros, reduzir os riscos de erros de

envio de processos a órgãos errados.

Os indicados dependem do sistema para a emissão de pareceres, quando

necessário.

Por fim, o solicitante depende do sistema para o registro de processos e, para que,

ao final, após a otimização dos fluxos, controle dos prazos do processo diminuição de

chances de erros, o processo possa concluir mais rapidamente.

5.2 Modelagem de Razão Estratégica

A Figura 2 abaixo apresenta a modelagem de razão estratégica para o sistema. Em

seguida o modelo é explicado em detalhes:



Figura 2 – Modelagem de Razão Estratégica 1fnmm, mbbs, sms5, ywsr Página 24 24/10/2011


Este modelo apresenta o sistema SIG@Processo com FTA detalhado internamente.

O que podemos perceber de diferença é a existência das tarefas principais Gerenciar FTA e

Gerenciar Processos apontando para a meta Gerenciamento do SIG@Processo com FTA.

isso significa que para o gerenciamento do SIG@Processo com FTA é necessário realizar

essas atividades.

Para gerenciar os FTAs é necessário gerenciar os Tipos de Despacho (que significa

inserir, alterar, consultar ou remover Tipos de Despacho) e inserir, alterar, consultar ou

remover os FTAs.

A tarefa de gerenciar os processos compreende registrá-los no sistema, recebê-los,

enviá-los e, a partir das regras definidas, direcioná-lo ao próximo órgão, interromper ou

voltar para o fluxo pré-definido pelo FTA, para casos especiais e solicitar ou emitir

pareceres, para embasar melhor despachos e arquivá-los ao final do processo.

Figura 3 - Modelagem de Razão Estratégica 2



Este modelo apresenta o detalhamento das atividades do servidor responsável pelo

Bureau de Processos. Ele terá a responsabilidade de elaborar fluxos de processos

otimizados a partir de informações repassadas por especialistas em determinado assunto do

processo. Com isso, poderá administrar (inserir, alterar, consultar e remover) os FTAs.

6. Modelagem de Requisitos Funcionais (Casos de Uso)

A Figura 4 a seguir apresenta o modelo de caso de uso para o sistema e em seguida fnmm, mbbs, sms5, ywsr Página 26 24/10/2011


seu detalhamento:

Figura 4 – Modelo de caso de uso

Este diagrama apresenta o modelo de caso de uso do sistema, que apresenta as

funcionalidades do sistema e quem executa cada funcionalidade. O Anexo B apresenta os

detalhes de cada funcionalidade apresentada no modelo.



O solicitante poderá registrar processos e logar (acessar) no sistema, informando

login, senha e captcha ou através de certificação digital.

Os servidores responsáveis por gerenciar o processo poderão, além das

funcionalidades permitidas ao solicitante, receber processos, enviar processos, arquivar

processos e solicitar pareceres para embasar melhor algum despacho.

Os chefes de setores poderão além das funcionalidades permitidas aos servidores

responsáveis por gerenciar o processo, interromper o fluxo do FTA, tornando o sistema ao

comportamento atual e voltar ao fluxo do FTA, retornando ao comportamento de fluxos

automáticos.

O servidor indicado em uma solicitação de parecer poderá, além das funcionalidades

permitidas ao solicitante, emitir um parecer para esta solicitação.

Por fim, o servidor responsável pelo Bureau de Processos poderá, além das

funcionalidades permitidas ao solicitante, inserir, alterar, consultar e remover tipos de

despacho e inserir, definir nós e arestas, alterar, consultar e remover FTAs.



7. Modelagem de Requisitos não Funcionais

As Figuras 5, 6 e 7 abaixo apresentam a modelagem de requisitos não funcionais

para o sistema. A Figura 5 apresenta o modelo completo. Para melhor legibilidade, o modelo

foi dividido em 2 partes, apresentadas nas Figuras 6 e 7. Em seguida o modelo é explicado

em detalhes:

Figura 5- Modelagem Requisitos não Funcionais



Figura 6- Modelagem Requisitos não Funcionais parte 1



A primeira parte da modelagem de requisitos não funcionais apresenta os requisitos

Usabilidade e Confiabilidade. Para o primeiro, definiu-se que só se alcança usabilidade se

forem exibidas mensagens de feedback positivas, se o sistema for fácil de utilizar e

aprender, se possuir consistência e o usuário informar o mínimo de dados possíveis.

Atribuiu-se prioridade à facilidade de utilização e aprendizado, pois o é de

fundamental importância que o usuário consiga utilizar corretamente o sistema para que os

objetivos do projeto sejam alcançados.

Para facilitar a utilização atribuiu-se a utilização de poucos cliques para alcançar as

principais funcionalidades e páginas de ajuda. Para facilitar o aprendizado, a exibição de

ícones e as funcionalidades principais na tela inicial.

A consistência foi caracterizada como padronização dos elementos gráficos, tais

como links e botões. A redução de informações fornecidas com o sistema carregando as

informações já existentes.

Para obter confiabilidade, o sistema precisa ser tolerante a falhas e os usuários

precisam ter seus conhecimentos nivelados. Para isso, o sistema deve estar configurado

para reagir a falhas inesperadas e devem ser realizados treinamentos para nivelar o

conhecimento dos usuários.

O treinamento dos usuários facilita o aprendizado do sistema e um sistema de fácil

utilização torna o nivelamento mais eficiente e proporciona menos dúvidas ao usuário.

A seguir será apresentada a segunda parte do modelo de Requisitos não Funcionais.



Figura 7- Modelagem Requisitos não Funcionais parte 2



A segunda parte do modelo apresenta os requisitos Disponibilidade, Segurança,

Extensibilidade e Desempenho. Para o sistema possuir disponibilidade são necessários

servidores suficientes e a replicação de dados nos servidores. A necessidade de servidores

suficientes é prioritária, pois é essencial para o sistema se manter disponível .

Para possuir segurança, é necessário ter autenticação de usuários, integridade de

dados, confidencialidade e conexões seguras. Para se obter o primeiro, optou-se por

realizar a identificação do usuário por login, senha e captcha. Para a integridade, é

necessário existir níveis de acesso aos dados. Com relação à confidencialidade, identificar

com login, senha e captcha e criptografar os dados são suficientes, sendo a criptografia dos

dados de suma importância.

Para garantir extensibilidade é importante observar boas práticas de programação e

modularizar o código.

Por fim, para melhorar o desempenho é importante reduzir o tempo de resposta, que

pode ser alcançado com a indexação em banco de dados, observação de boas práticas de

programação e replicação dos dados nos servidores.

8. Conclusão

Esse documento de requisitos apresentou o problema identificado e o detalhamento

da solução encontrada. Neste sentido, utilizou-se o detalhamento dos requisitos e as

modelagens organizacionais, de caso de uso e de requisitos não funcionais. As modelagens

organizacional e de requisitos não funcionais foram elaboradas utilizando-se a notação i* e a

modelagem de caso de uso, a linguagem UML.



Glossário

Fluxo de Tramitação Automático (FTA)

Conjunto de tramitações pela qual o processo percorrerá até que seja arquivado.

Processo É o documento ou o conjunto de documentos que exige um estudo mais detalhado, bem como procedimentos expressados por despachos, pareceres técnicos, anexos ou, ainda, instruções para pagamento de despesas assim, o documento é protocolado e autuado pelos órgãos autorizados a executar tais procedimentos [3].

Assunto de Processo Tema ao qual o processo se refere.

Tramitação É a movimentação do processo de uma unidade à outra, interna ou externa, através de sistema próprio [3].

Regra Conjunto de documentos, formulários e despacho inerente a uma tramitação. Duas regras podem requerer os mesmos documentos e formulários, mas o despacho deve ser o que diferencia cada regra, à exceção das regras associadas ao registro de processos, quando não há despacho a ser exarado. Regras associadas ao registro de processos não podem requerer os mesmos documentos e formulários.

Documento É toda informação registrada em um suporte material, suscetível de consulta, estudo, prova e pesquisa, pois comprova fatos, fenômenos, formas de vida e pensamentos do homem numa determinada época ou lugar [3].

Formulário Tipo especial de documento, em que o usuário precisa responder a algumas questões.

SIG@Formulário Sistema responsável pelo suporte à criação de formulários durante a inserção dos FTAs.

Despacho Decisão proferida pela autoridade administrativa em caso que lhe é submetido à apreciação [3].

Exarar despacho Emitir um despacho.

Órgão Unidade com atribuição específica na universidade.

Solicitante Estudante, servidor ou órgão que desejar registrar um processo administrativo.

Grafo FTA Representação gráfica do FTA utilizada para a elaboração do mesmo. É composto por nós e arestas. Um nó representa os órgãos pelo qual o processo passará e uma aresta a regra necessária para enviar o processo a outro órgão. Um nó mais sua aresta de chegada (aresta que chega ao nó) representa graficamente uma tramitação.

Aresta de origem Aresta que representa graficamente a regra associada ao registro do processo. Ou seja, as primeiras arestas do grafo FTA que ligam o processo aos possíveis órgãos de recebimento quando o processo é registrado. O registro do processo é realizado pelo solicitante. Dessa forma, não há despacho a ser exarado e é necessário que nenhuma aresta de origem tenha a mesma regra.

Aresta comum Demais arestas do grafo FTA.

Aresta de chegada Aresta que chega a um determinado nó do grafo FTA.

Aresta de saída Aresta que sai de um determinado nó do grafo FTA.



Nó folha Nós que não possuem arestas de saída. Representam o último órgão ao qual o processo pode chegar. Devem ser todos do tipo arquivamento, para que o processo seja arquivado ao seu final.

Arquivar processo Finalizar o processo.

Protocolização Registrar efetivamente o processo, concedendo-lhe um número identificador.

Perfil Representação dos níveis de acesso do usuário. Cada usuário possui um perfil que dá acesso a determinadas transações.

Transação Funcionalidade do SIG@.

Bureau de Processos Órgão que será criado para a universidade, com o objetivo de administrar melhor os processos administrativos.



Referências Bibliográficas

[1] - Site do NTI. UFPE. Disponível em: http://www.ufpe.br/nti/. Acesso em 1/10/2011.

[2] - LIMA, L. A de.; QUEIROZ, J. A. M. de. “SIG@Processo, um novo paradigma para o

ambiente processual universitário”. Acesso em: 25 de agosto 2011.

[3] - Portaria Normativa Nº 5. Secretaria de Logística e Tecnologia da Informação. 19 de

dezembro de 2002. Aceso em: 22 de setembro 2011.

[4] - Regulamento do Processo administrativo no âmbito da Administração Pública. Lei nº

9784. Janeiro de 1999. Acesso em 22 de setembro 2011.

[5] - Documento de Requisitos não Funcionais do SIG@. Acesso em 29 de setembro 2011.

[6] – Sobre SIG@Processo. Disponível em: HTTP://www.dca.ufpe.br/index.php. Acesso em

25 agosto 2011.

[7] – Kotonya, G.; Sommerville, I. “Requirements Engineering: Processes and

Techniques”. John Wiley & Sons, 1998.



Anexo A – Técnicas Utilizadas

Entrevista

De forma a compreender o negócio e o conteúdo do projeto, realizaram-se duas

reuniões para elicitação de requisitos. A cada semana realizaram-se ainda reuniões de

validação, com o objetivo de confirmar se a modelagem apresentava exatamente o que

havia sido explicado anteriormente. As reuniões de elicitação ocorreram com o líder do

projeto, Lucas Abertins e sua equipe, Jonas Pontes e Ubiracy Júnior e as reuniões de

validação com Lucas Albertins e Ubiracy Júnior. A seguir serão transcritas as entrevistas.

Entrevista 1 – Cadastro dos FTAs

P: Sobre o que é o projeto?

R: O projeto tem o objetivo de adaptar o SIG@Processo para dar suporte aos FTAs. Ele tem

duas partes: uma para o cadastro dos FTAs e outra para adaptar o SIG@Processo para

receber o FTA. A primeira parte do processo será utilizada pelo responsável pelo Bureau de

Processos, que irá existir na UFPE. A segunda parte será utilizada pelos usuários os que já

utilizam o sistema atualmente: os solicitantes e servidores responsáveis pelo processo no

momento em que passa pelo órgão.

P: O que são os FTAs?

R: FTA significa Fluxo de Tramitação Automática. Um FTA possui um conjunto de regras

que definem uma tramitação. O projeto SIG@Processo, módulo do SIG@ que apoia os

processos administrativos da UFPE, foi idealizado para funcionar com os FTAs, mas não se

pode desenvolver essa parte a princípio. Agora o reitor tem interesse de criar um Bureau de

Processos, com um responsável que otimize os fluxos que os processos e fique responsável

pela manutenção geral dos processos administrativos da UFPE. Por isso queremos

desenvolver e implantar essa parte do FTA agora.

P: Como funciona o sistema atualmente?

R: Atualmente o sistema funciona com fluxos dirigidos. Ao exarar o despacho, a pessoa que

está responsável para isso informa também o próximo órgão para o qual o processo seguirá.

P: Como será com os FTAs?

R: Com os FTAs o sistema vai “entender” para qual órgão o processo deve ir sem precisar

que a pessoa que está exarando o despacho selecione o próximo órgão.fnmm, mbbs, sms5, ywsr Página 37 24/10/2011


P: O que exatamente são as regras?

R: As regras são os documentos, formulários e despacho necessários para que o processo

possa tramitar (ser enviado) de um órgão para outro.

P: O que são esses documentos e formulários?

R: Os documentos mudam de processo para processo e são informados quando

necessários. Os formulários também são informados e são como formulários comuns, com

perguntas e respostas.

P: O que são os despachos?

R: O despacho é a decisão, dada pelo responsável pelo processo no órgão em que ele se

encontra, para o processo.

P: Qual será o passo a passo para cadastrar os FTAs?

R: Logado no SIG@, o usuário vai informar o assunto do processo. Um FTA deve

corresponder a apenas um assunto de processo. Estarão disponíveis todos os assuntos

possíveis para se abrir um processo. Após escolher, o sistema vai mostrar um espaço

gráfico para o usuário montar o FTA. Será um grafo com nós e arestas. Os nós

representarão os órgãos e as arestas as regras. O usuário clicará 2 vezes o nó ou a aresta

para definir o órgão e a regra. Nenhum nó ou aresta pode ficar sem ser definido. Os nós

folhas deverão ser de arquivamento, para que o processo ao final seja arquivado. A

definição de que o nó é de arquivamento deve ser feita no nó, junto com a escolha do órgão.

Isso significa que, quando o processo chegar a esse órgão, quem exarar o processo estará

também arquivando o mesmo.

O usuário também poderá consultar alterar ou remover os FTAs depois. Ao remover um

FTA, se houver algum processo com o assunto do FTA, este passará a seguir um fluxo

dirigido, como é atualmente.

Entrevista 2 – Infraestrutura para os FTAs

P: Qual é o propósito da existência dos FTAs? O que se ganha com os FTAs?

R: Os FTAs têm o objetivo de automatizar as tramitações do SIG@Processo, fazer com que

o sistema entenda por si só para qual órgão deve seguir, evitando seguir para órgãos

errados. É útil também para dar o suporte para ter fluxos otimizados de processos,

elaborados pelo responsável do Bureau de Processos. É útil ainda para evitar que os

processos passem tempo demais nos órgãos, controlando os prazos de recebimento e envio



dos processos.

P: O que precisa ser modificado para o sistema dar suporte aos FTAs?

Várias funcionalidades:

Ao registrar um processo, o solicitante deve poder visualizar para quais

órgãos o processo irá de acordo com os documentos e formulários informados. Como para

registrar não existe despacho, a combinação entre documentos e formulários informados

deve ser diferente para cada possível órgão de destino do processo. O usuário pode anexar

ou não os documentos. Se optar por não anexar, deve apresentá-lo em alguma secretaria

para verificar que é verdadeiro. O processo só será protocolizado após os documentos

terem sido anexados.

Na tela inicial o usuário deve ter a informação de que há processos para

receber. Ao acessar a transação para receber o processo, o usuário deve visualizar o prazo

de recebimento do processo. Se não receber até o prazo estabelecido, o processo ganhará

destaque e serão guardadas informações de perda de prazo no sistema.

Ao enviar o processo, o usuário deve visualizar informações sobre os

caminhos que o processo pode seguir. Ou seja, para qual órgão o processo seguirá de

acordo com a regra (os formulários, documentos e despacho) informada. Um processo pode

ir para diferentes órgãos dependendo da regra que escolher seguir.

Um responsável pelo processo poderá interromper o fluxo pré-estabelecido

para aquele assunto de processo e seguir outro, se necessário. Para isso, é necessário ter

cargo de chefia de setor. Interrompendo o FTA o sistema se comportará como atualmente,

com fluxo dirigido. Devem ser salvas as informações da última tramitação pela qual o

processo passou, para que possa voltar ao mesmo ponto mais tarde e concluir o processo.

Um processo que saiu do fluxo do FTA pré-definido pode voltar ao mesmo.

Para isso ele deve voltar o chefe de departamento que o interrompeu.

Um responsável pelo processo poderá ainda solicitar um parecer para

embasar melhor o despacho que precisa exarar para um processo. Para isso ele deverá os

indicados a emitir um parecer e informar a razão da solicitação. O parecer pode ser público

ou privado. Se for público, qualquer pessoa com acesso ao processo poderá visualizar os

pareceres emitidos. Caso seja privado, apenas quem solicitou o parecer poderá visualizá-lo.

Seja público ou privado, os nomes dos indicados a emitir um parecer não poderão ser

conhecidos, à exceção de quem o solicitou. Os indicados devem ser informados que

precisam emitir algum parecer. Para emitir o parecer, o indicado precisa ter acesso a todos fnmm, mbbs, sms5, ywsr Página 39 24/10/2011


os documentos associados ao processo e um campo para escrever seu parecer. Quando o

parecer for emitido, deverá ser automaticamente informado ao solicitante e disponibilizado

no processo para visualização.

O parecer está associado a um despacho, mas o solicitante pode exarar um

despacho mesmo que não tenha algum parecer emitido.

Nos nós que foram sinalizados como do tipo arquivamento, deverá ser

disponibilizado o tipo de despacho “Arquivamento”, para que o usuário possa arquivar o

processo quando for exarar o despacho.

É preciso também um cadastro de tipos de despacho, que ainda não existe

no sistema. O responsável pelo Bureau de Processos terá acesso a esse cadastro.

P: Qualquer secretária(o) pode verificar o documento?

R: Sim, por ser funcionário público, tem poder para confirmar que o documento é válido.

As reuniões para validar o projeto foram muito importantes para confirmar o que

estávamos desenvolvendo e retirar mais algumas dúvidas restantes.

Coleta de Documentos

Documentos referentes ao projeto foram coletados, de forma a compreender melhor o sistema atualmente e o que espera ser desenvolvido. Os documentos foram liberados apenas para consulta, não sendo permitido repassá-los a terceiros. Foram eles:

O artigo “SIG@Processo, um novo paradigma para o ambiente processual universitário”, que explica a motivação para o SIG@Processo e seus obvjetivos;

A especificação de Requisitos do SIG@Processo, que detalha os requisitos funcionais do SIG@Processo;

Documentos de caso de uso do SIG@Processo, que detalha os casos de uso do SIG@Processo;

O Manual do usuário do SIG@Processo; O Regulamento do Processo administrativo no âmbito da Administração

Pública (Lei nº 9784, de janeiro de 1999); A Portaria Normativa Nº 5, de 19 de dezembro de 2002, da Secretaria de

Logística e Tecnologia da Informação e O Documento de Requisitos não Funcionais do SIG@;

Os documentos foram de grande ajuda para entendimento do projeto.



Anexo B – Descrição dos Casos de Uso

Cadastro do Fluxo de Tramitação Automática (FTA)

[UC01] Inserir FTA

Identificador: [UC01] Inserir FTA

Descrição: Insere um FTA no sistema.

Atores: Servidor responsável pelo Bureau de Processos.

Prioridade: Essencial

Pré-condições: O ator deve estar logado no SIG@ com o perfil adequado.

Pós-condições: O FTA deve estar cadastrado no sistema.

Fluxo de Eventos Principal

1. O sistema exibe um conjunto de nome “Assunto”, com os possíveis assuntos de processo para seleção e o botão “Criar FTA”;

2. O ator seleciona um assunto de processo e clica o botão “Criar FTA”; [FS1]

3. O sistema exibe uma tela com espaço e disponibiliza os componentes “aresta” (representando uma regra) e “nó” (representando um órgão) para a montagem do FTA;

4. O ator adiciona/conecta/remove as arestas e os nós do FTA;

5. Para cada nó adicionado, include [UC02];

6. Para cada aresta adicionada, include [UC03];

7. O ator clica o botão “Inserir FTA”; [FE1][FE2][FE3][FE4][FE5];

8. O sistema exibe uma tela com a mensagem “Fluxo de Tramitação Automática inserido com sucesso!” e todas as informações do FTA inserido.

9. O caso de uso é encerrado.

Fluxo Secundário 1 [FE1]

1. Extends [UC04];

2. O caso de uso continua do passo 2.

Fluxo de Erro 1 [FE1]

3. O ator não define algum dos nós do grafo do FTA;

4. O sistema indica de vermelho o(s) nó(s) não definido(s) e exibe a mensagem “O(s) nó(s) indicado(s) do FTA não foi(foram) definido(s). Todos os nós devem ser definidos.”;



1. O ator não definiu nenhum nó como tipo ”Arquivamento”;

2. O sistema exibe a mensagem “Nenhum nó foi definido como tipo “Arquivamento”. É necessário definir ao menos um para que o processo seja arquivado.”;





1. O ator não definiu alguma aresta comum do grafo do FTA;

2. O sistema indica de vermelho as arestas não definidas e exibe a mensagem “A(s) aresta(s) indicada(s) não foi(foram) definida(s). É necessário definir todas as arestas do FTA.”;



1. O ator não conectou um ou mais nó(s) a alguma aresta do FTA;

2. O sistema indica de vermelho os nós não conectados e exibe a mensagem: “O(s) nó(s) indicado(s) não estão conectados a alguma aresta do FTA. É necessário que todos os nós do FTA estejam conectados a alguma aresta.”



1. O ator não definiu algum nó folha como do tipo “Arquivamento”;

2. O sistema indica de vermelho os nós não definidos e exibe a mensagem: “O(s) nó(s) - folha indicado(s) não foram definidos como tipo “Arquivamento”. Todos os nós - folha devem ser definidos como tipo “Arquivamento”.”


[UC02] Definir nó (Órgão e tipo “Arquivamento”)

Identificador: [UC02] Definir Órgão e nós do tipo “Arquivamento”

Descrição: Define o nó do grafo do FTA, informando o órgão de destino para o qual o processo será enviado e se, para o órgão definido, o processo será arquivado ou não.



Pré-condições: O ator deve ter adicionado ao menos um “nó” na montagem do FTA.

Pós-condições: Órgão e opção por arquivamento definidos.


1. O sistema exibe uma tela com um conjunto de órgãos para seleção e uma opção nomeada “É de arquivamento”, para confirmar que o mesmo deve arquivar o processo; [FS1]

2. O ator seleciona o órgão que o nó representa a opção “É de arquivamento”, se apropriado, e clica o botão “Ok”; [FS1][FE1]

3. O sistema exibe a tela principal, que exibe todo o FTA construído, exibindo no nó o órgão definido.


Fluxo Secundário 1 [FS1]



1. O ator clica o botão “Cancelar”;

2. O sistema aborta a operação;

3. O sistema exibe a tela principal, que exibe todo o FTA construído, sem alterar a informação exibida anteriormente pelo nó;

4. O caso de uso continua no passo 2.


1. O ator não selecionou o órgão;

2. O sistema exibe a mensagem “Não foi definido órgão para o nó. É necessário informá-lo.”;


[UC03] Definir aresta (regra)

Identificador: [UC03] Definir aresta (regra)

Descrição: Define a aresta (regra) da tramitação em questão.



Pré-condições: O ator deve ter adicionado ao menos uma “aresta” na montagem do FTA.

Pós-condições: Aresta (regra) definida.


1. O sistema exibe uma tela com os campos “Documento(s)”, “Formulário(s)” e “Despacho”; [FS1]

2. O ator seleciona o(s) tipo(s) de documento(s) associados à tramitação; [FS1]

3. O ator cria o(s) formulário(s) associados à tramitação; [FS1]

4. O ator seleciona o tipo de despacho associado à tramitação; [FS1]

5. O ator clica o botão “Ok”; [FS1]; [FE1]



1. O ator clica o botão “Cancelar”;

2. O sistema aborta a operação;

3. Continua no passo 1.


1. O ator não seleciona o tipo de despacho associado à tramitação (relacionado apenas a arestas comuns);

2. O sistema exibe a mensagem “O tipo de despacho associado à tramitação não foi selecionado. Este item é obrigatório em arestas comuns.”;




[UC04] Consultar FTA

Identificador: [UC04] Consultar FTA

Descrição: Consultar um FTA no sistema.




O(s) FTA(s) deve(m) estar cadastrado(s) no sistema.

Pós-condições: O(s) FTA(s) do(s) assunto(s) selecionado(s) deve(m) ser exibido(s).


1. O sistema exibe uma tela com o campo “Assunto”, com um conjunto de assuntos de

processo possíveis e o botão “Consultar”;

2. O ator seleciona o(s) assunto(s) desejado(s);

3. O ator clica o botão “Consultar”; [FE1]

4. O sistema exibe o(s) FTA(s) correspondente(s);


Fluxo de Erro 1

1. O ator não seleciona o(s) assunto(s) desejado(s);

2. O sistema exibe a mensagem “Nenhum assunto foi selecionado. Este campo é

obrigatório.”;


[UC05] Alterar FTA

Identificador: [UC05] Alterar FTA

Descrição: Altera um FTA cadastrado no sistema.





Pós-condições: O FTA deve estar alterado no sistema.




1. O ator executa o [UC04];

2. O ator altera (adiciona/conecta/remove) as arestas e os nós do FTA; [FS1] [FE7]

3. Para os nós desejados, include [UC02];

4. Para as arestas desejadas, include [UC03];

5. O ator clica o botão “Alterar FTA”; [FE1][FE2][FE3][FE4][FE5][FE6];

6. O sistema exibe uma tela com a mensagem “O FTA foi alterado com sucesso!” e todas

as informações do FTA alterado;



1. O ator exclui um nó do FTA; [FE

2. O sistema exibe a mensagem “Ao excluir este nó, todas as arestas conectadas ao mesmo serão excluídas. Deseja excluir o nó?” e os botões “Sim” e “Não”;

3. O ator clica o botão “Sim”; [FS3]

4. O sistema exclui o nó e todas as arestas conectadas a ele;



1. O ator clica o botão “Não”;

2. O sistema retorna à tela principal, que exibe o FTA para ser alterado;

3. O caso de uso continua do passo 2 do fluxo principal.


1. O ator não define algum dos nós do grafo do FTA;

2. O sistema indica de vermelho o(s) nó(s) não definido(s) e exibe a mensagem “O(s) nó(s) indicado(s) do FTA não foi(foram) definido(s). Todos os nós devem ser definidos.”;



1. O ator não definiu nenhum nó como tipo “Arquivamento”;

2. O sistema exibe a mensagem “Nenhum nó foi definido como tipo “Arquivamento”. É necessário definir ao menos um, para que o processo seja arquivado.”;



1. O ator não definiu alguma aresta comum do grafo do FTA;

2. O sistema indica de vermelho as arestas não definidas e exibe a mensagem “A(s) aresta(s) indicada(s) não foi(foram) definida(s). Favor defini-las.”;





1. O ator não conectou o um ou mais nó(s) a alguma aresta do FTA;

2. O sistema indica de vermelho os nós não conectados e exibe a mensagem: “O(s) nó(s) indicado(s) não estão conectados a alguma aresta do FTA. É necessário que todos os nós do FTA estejam conectados a alguma aresta do FTA.”



1. O ator não definiu algum nó folha como do tipo “Arquivamento”;

2. O sistema indica de vermelho os nós não definidos e exibe a mensagem: “O(s) nó(s)-folha indicado(s) não foram definidos como do tipo “Arquivamento”. Todos os nós-folha devem ser definidos como do tipo “Arquivamento”.”



1. O ator exclui um nó que representa um órgão em que existe(m) processo(s) aberto(s);

2. O sistema exibe a mensagem “Existe(m) processo(s) aberto(s) sob responsabilidade do órgão representado por este nó. Um nó só pode ser excluído se não houver processos associado ao órgão representado por ele.”


[UC06] Remover FTA

Identificador: [UC06] Remover FTA

Descrição: Remove um FTA do sistema.



Pré-condições: O ator deve estar logado no SIG@ com o perfil adequado;


Pós-condições: O(s) FTA(s) não deve(m) permanecer no sistema.




1. Include [UC04];

2. O sistema exibe o(s) FTA(s) com caixas de seleção à esquerda;

3. O ator seleciona qual(quais) FTA(s) será(serão) removido(s);

4. O ator clica o botão “Remover FTA”;

5. O sistema exibe a mensagem “Tem certeza que deseja remover o(s) FTA(s)

selecionado(s)?” e os botões “Sim” e “Não”;

6. O ator clica o botão “Sim”;[FS1]

7. O sistema remove o(s) FTA(s) selecionado(s);

8. O sistema exibe a mensagem “Fluxo(s) de Tramitação Automático removido(s) com

sucesso!”;


Fluxo Secundário 1

1. O ator clica o botão “Não”;


Infraestrutura para o Fluxo de Tramitação Automática

[UC07] Registrar Processos com FTA

Identificador: [UC07] Registrar Processos com FTA

Descrição: Registrar um processo com FTA no sistema.

Atores: Solicitantes (servidores, estudantes e usuários externos com permissão para tal) e secretárias de órgãos, responsáveis por certificar a originalidade de documentos, quando necessário.


Pré-condições: Os atores devem estar logados no SIG@ com o perfil adequado.

Pós-condições: O processo deve ser registrado no sistema.




1. O sistema exibe um conjunto, de nome “Assunto”, com os possíveis assuntos de

processo para seleção e o botão “Continuar”;

2. O ator seleciona o assunto do processo desejado e clica o botão “Continuar”;

3. O sistema exibe as possíveis combinações de documentos e formulários necessários

para o registro do processo, os formulários, os campos para anexar documentos e o

botão “Registrar Processo”;

4. O ator anexa os documentos necessários; e responde ao(s) formulário(s)

necessário(s);

5. O ator clica o botão “Registrar Processo”; [FE1]

6. O sistema exibe a mensagem: “O processo foi registrado com sucesso, porém ainda

não foi protocolizado. Assim que os documentos solicitados estiverem certificados, o

processo será protocolizado. Caso os documentos não tenham sido anexados, é

necessário certificar sua originalidade junto à secretaria”.



1. O ator não responde ao(s) formulário(s) necessário(s);

2. O sistema exibe a mensagem “O(s) formulário(s) requisitado(s) para o despacho

selecionado não foi(foram) anexado(s) ao processo.”



1. O ator não anexa o(s) documento(s) necessário(s);

2. O sistema exibe a mensagem “O(s) documento(s) requisitado(s) para o despacho



[UC08] Receber Processo com FTA

Identificador: [UC08] Receber Processo com FTA

Descrição: Recebimento de processos adaptado para o FTA.

Atores: Servidores responsáveis por gerenciar os processos.



O processo deve estar registrado no sistema.

Pós-condições: Deve-se ter conhecimento do prazo de recebimento do processo.

Se o prazo for ultrapassado, os dados de perda de prazo devem estar registrados no sistema.

O processo deve estar protocolizado.




1. O sistema informa, na tela inicial, que existem processos a serem recebidos;

2. O ator acessa a transação “Receber Processo”, existente atualmente;

3. O sistema exibe, além das informações existentes, o prazo de recebimento do

processo na tabela de processos a receber;

4. O ator seleciona o(s) processo(s) que deseja receber e clica o botão “Receber

Processos”; [FS1]



1. O ator não recebe o(s) processo(s) em tempo e seu(s) prazo(s) é(são) expirado(s);

2. O sistema exibe, no topo da tabela de processo(s) a receber e sinalizado(s) de

vermelho, o(s) processo(s) com prazo(s) de recebimento expirado(s) e registra as

informações da perda de prazo do recebimento do processo;


[UC09] Enviar Processo com FTA

Identificador: [UC09] Enviar Processo com FTA

Descrição: Enviar processo para próximo órgão, adaptado para suportar o FTA.

Atores: Servidores responsáveis por gerenciar os processos e solicitante, quando necessário.



O processo deve estar registrado e protocolizado no sistema.

Pós-condições: Deve-se ter conhecimento do prazo de envio do processo.

Se o prazo for ultrapassado, os dados de perda de prazo devem estar registrados no sistema.

Processo enviado ao próximo órgão.




1. O sistema informa, na tela inicial, que existem processos a serem enviados;

2. O ator acessa a transação “Processos Recebidos”, existente atualmente, e seleciona o

processo a ser manipulado;

3. O sistema exibe, além das informações existentes atualmente, e apenas a partir da

segunda tramitação do processo, uma tabela informativa com as possíveis

combinações entre documentos, formulários e despacho (essa tabela não pode ser

exibida aos solicitantes). Informa ainda para qual órgão será enviado o processo, a

partir das combinações entre documentos, formulários e despacho possíveis.

Finalizando, o sistema informa, na tabela de processos a serem enviados, o prazo de

envio dos mesmos; [FS1]

4. O ator anexa os documentos, responde os formulários necessários e seleciona o

despacho apropriado;

5. O ator clica o botão “Exarar Despacho”; [FE1][FE2][FE3]

6. O sistema exibe a mensagem “Despacho exarado e processo enviado com sucesso!” e

envia o processo para o próximo órgão de acordo com o FTA pré-definido;



1. O ator não envia o(s) processo(s) em tempo e seu(s) prazo(s) é(são) expirado(s);

2. O sistema exibe, no topo da tabela de processo(s) a enviar e sinalizado(s) de

vermelho, o(s) processo(s) com prazo(s) de envio expirado(s) e registra as

informações de perda de prazo do envio do processo;



1. O ator não anexa os documentos necessários;

2. O sistema exibe a mensagem “O(s) documento(s) requisitado(s) para o despacho




1. O ator não responde a um ou mais formulário(s) necessário(s);

2. O sistema exibe a mensagem “O(s) formulário(s) requisitado(s) para o despacho

selecionado não foi(foram) anexado(s) ao processo.”;





1. O ator seleciona o despacho errado para o conjunto de documentos e formulários

informados;

2. O sistema exibe a mensagem “O despacho selecionado não corresponde aos

documentos anexados e formulários respondidos. Favor verificar a tabela informativa

ao início da tela.”;


[UC10] Interromper FTA

Identificador: [UC10] Interromper FTA

Descrição: Interrompe o fluxo pré-definido do FTA. Ao interromper o FTA o processo volta a ter o comportamento de um fluxo de tramitação dirigido, existente atualmente.

Atores: Servidores responsáveis por gerenciar os processos e com cargo de chefia.




Pós-condições: O processo volta a seguir um fluxo dirigido, como ocorre atualmente.


1. O ator acessa a transação “Manipular processo”, existente atualmente;

2. O sistema exibe, além dos itens já existentes, o botão “Interromper FTA”;

3. O ator seleciona o processo que será interrompido e clica o botão “Interromper FTA”;

4. O sistema exibe a mensagem “Fluxo de Tramitação Automático interrompido com

sucesso!”, registra as informações da última tramitação do FTA, registra que o

processo como interrompido e exibe o campo “Órgão”, para escolha do órgão que será

enviado o processo;

5. O ator seleciona o órgão desejado e clica o botão “Enviar Processo”; [FE1]



1. O ator não seleciona o órgão para envio do processo;

2. O sistema exibe a mensagem “É necessário selecionar um órgão para enviar o

processo”;


[UC11] Voltar FTA

Identificador: [UC11] Voltar FTA

Descrição: Volta ao fluxo pré-definido do FTA.



Atores: Servidores responsáveis por gerenciar os processos e com cargo de chefia.




O processo deve ter sido interrompido anteriormente.

Pós-condições: O processo volta a seguir o FTA pré-definido.


1. O ator acessa a transação “Manipular Processo”;

2. O sistema exibe, além dos componentes da tela já existente, a informação que aquele

processo foi interrompido e o botão “Voltar FTA”;

3. O ator clica o botão “Voltar FTA”;

4. O sistema recupera as informações da última tramitação realizada com FTA, em que o

processo foi interrompido, e retoma o FTA;


[UC12] Solicitar Parecer

Identificador: [UC12] Solicitar Parecer

Descrição: Solicita o parecer de alguns indicados para alguma determinada situação do processo, de forma a orientar a decidir o despacho apropriado.

Atores: Servidores responsáveis por gerenciar os processos




Pós-condições: A solicitação do parecer é registrado no sistema e enviado para os indicados.




1. O ator acessa a transação “Processos Recebidos”, existente atualmente;

2. O sistema exibe, além dos itens já existentes, o botão “Manipular Processo”;

3. O ator seleciona um processo e acessa a transação “Manipular Processo”; [FE1]

4. O sistema exibe o processo com todas as suas informações. Na área em que estão

agrupados os itens para efetuar os despachos, exibe o botão “Solicitar Parecer”;

5. O ator clica o botão “Solicitar Parecer”; [FE1]

6. O sistema exibe um campo “Descrição”, para descrever o assunto que necessita do

parecer. Área, de nome “Indicados”, para consultar os servidores indicados a emitirem

o parecer. Bem como, a opção de nome “Privado”, para informar se o parecer deve

ser privado e o botão “Solicitar Parecer”;

7. O ator preenche o campo “Descrição”, consulta os servidores desejados, os adiciona à

tabela “Indicados”, seleciona a opção “Privado”, se desejar, e clica o botão “Solicitar

Parecer”;[FE2][FE3]

8. O sistema exibe a mensagem “Parecer solicitado com sucesso!” e envia emails para os

indicados, informando da solicitação de parecer, além de disponibilizar em suas

respectivas telas iniciais a informação de que há parecer a ser emitido; [FS1]


Fluxo Secundário 1 [FE1]

1. O sistema não possui a informação do email de algum indicado;

2. O sistema exibe a mensagem “O sistema não possui o registro do(s) email(s) do(s)

indicado(s) ______________. O aviso não pode ser enviado por email.”;



1. O ator não seleciona o processo que deseja solicitar o parecer;

2. O sistema exibe a mensagem “É necessário selecionar um processo para solicitar um

parecer.”;



1. O ator não preenche o campo “Descrição”;

2. O sistema exibe a mensagem “É necessário preencher o campo “Descrição” para

solicitar um parecer.”;





1. O ator não adiciona os indicados a solicitar o parecer;2. O sistema exibe a mensagem “É necessário selecionar ao menos um indicado para

solicitar um parecer.”;3. O caso de uso continua do passo 7.

[UC13] Emitir Parecer

Identificador: [UC13] Emitir Parecer

Descrição: Emite um parecer para um processo.





Houve uma solicitação de parecer para o usuário em questão.

Pós-condições: O sistema registra o parecer emitido no processo ao qual está associado.


1. O sistema exibe na tela inicial a transação “Emitir Parecer” e a mensagem de que há

parecer a ser emitido;[FS1]

2. O ator acessa a transação;

3. O sistema exibe toda a informação existente acerca do processo a ser emitido o

parecer, o campo “Parecer” e o botão “Emitir Parecer”;

4. O ator analisa o processo, preenche o campo “Parecer” e clica o botão “Emitir

Parecer”; [FE1]

5. O sistema atualiza o processo com o parecer emitido, o remove da lista de processos

com solicitações para emitir parecer, exibe a mensagem “Parecer emitido com

sucesso!” e envia email para o solicitante do parecer, informando que o parecer foi

emitido;



1. O solicitante do parecer despacha o processo antes da emissão do parecer pelo

indicado;

2. O sistema retira a solicitação de emissão do parecer e a informação de que há parecer

a ser emitido da tela inicial;





1. O ator não preenche o campo “Parecer”;

2. O sistema exibe a mensagem “É necessário preencher o campo “Parecer” para emitir

um parecer.”;


[UC14] Arquivar processo com FTA

Identificador: [UC14] Arquivar processo com FTA

Descrição: Arquiva o processo.





A tramitação deve ter sido sinalizada como tipo “Arquivamento” no momento da criação do FTA.

Pós-condições: O processo é arquivado.


1. O processo alcança uma tramitação do tipo “Arquivamento”;

2. O sistema, na transação “Manipular Processo”, no conjunto de tipos de Despachos,

exibe a opção “Arquivar Processo”;

3. O ator executa as atividades finais no processo, exara o despacho apropriado,

seleciona a opção “Arquivar Processo” e o botão “Exarar Despacho”;

4. O sistema exibe a mensagem “Despacho exarado e processo arquivado com sucesso!”

e arquiva o processo;


[UC15] Inserir Tipo de Despacho

Identificador: [UC15] Inserir Tipo de Despacho

Descrição: Insere um tipo de despacho no sistema.




Pós-condições: O tipo de despacho deve estar inserido no sistema.




1. O sistema exibe os campos “Nome”, “Descrição” e o botão “Adicionar”, que acrescenta

os tipos de despacho ao conjunto de nome “Tipos de Despacho”, uma área para

consultar os tipos de despacho existentes e o botão ”Inserir Tipos de Despacho”, para

inserir todos os despachos adicionados ao conjunto “Tipos de Despacho”;

2. Extends [UC16]; [FS1]

3. O ator preenche os campos “Nome” e “Descrição” e clica o botão “Adicionar”, que

adiciona o tipo de despacho ao campo “Tipos de Despacho”; [FS2]

4. O ator clica o botão “Inserir Tipos de Despacho” [FE1]

5. O sistema exibe a mensagem “Tipo(s) de despacho inserido(s) com sucesso!” e insere

os Tipos de Despacho;



1. O ator não consulta para verificar a existência do tipo de despacho que deseja inserir;



1. O ator preenche os campos “Nome” e “Descrição”, mas não adiciona o tipo de

despacho ao campo “Tipos de Despacho”;



1. O ator não preenche o(s) campo(s) “Nome” e/ou “Descrição” e não há nenhum tipo de

despacho no campo “Tipos de Despacho”;

2. O sistema exibe a mensagem “Não há Tipo de Despacho definido para inserir no

sistema.”


[UC16] Consultar Tipo de Despacho

Identificador: [UC16] Consultar Tipo de Despacho

Descrição: Consulta um tipo de despacho existente no sistema.




O tipo de despacho deve estar registrado no sistema.

Pós-condições: O tipo de despacho deve estar exibido ao ator.




1. O sistema exibe um campo em branco, 2 opções, “Nome” e “Descrição”, para consulta

por nome ou descrição do tipo de despacho (a opção “Nome” já selecionada) e o botão

“Consultar”;

2. O ator preenche o campo, seleciona a opção de consulta e clica o botão “Consultar”;

[FE1] [FE2]

3. O sistema exibe o resultado da consulta;



1. O ator não preenche o campo de consulta;

2. O sistema exibe a mensagem: “O campo de consulta está em branco. É necessário

preenchê-lo para realizar a consulta.”;



1. O sistema não retorna resultados para a consulta;

2. O sistema exibe a mensagem: “Não foi encontrado Tipo de Despacho para a

informação fornecida”;


[UC17] Alterar Tipo de Despacho

Identificador: [UC17] Alterar Tipo de Despacho

Descrição: Altera um tipo de despacho existente no sistema.





Pós-condições: O tipo de despacho deve estar alterado no sistema.




1. Include [UC16];

2. O ator seleciona o(s) Tipo(s) de Despacho que deseja alterar e clica o botão

“Continuar”; [FS1][FE1]

3. O sistema exibe os campos “Nome” e “Descrição” preenchidos;

4. O ator modifica “Nome” e/ou “Descrição” do(s) tipo(s) de despacho(s) selecionado(s) e

clica o botão “Alterar Tipo de Despacho”; [FE2][FE3]

5. O sistema exibe a mensagem “Tipo(s) de despacho alterado(s) com sucesso!” e realiza

as alterações necessárias no sistema;



4. O sistema não retorna o resultado esperado pelo ator;



1. O ator não seleciona o(s) tipo(s) de despacho(s) para alterar;

2. O sistema exibe a mensagem “Nenhum tipo de despacho foi selecionado. É necessário

selecionar ao menos um para prosseguir”;

3. O caso continua do passo 2.


1. O ator não modifica nenhum campo do(s) tipo(s) de despacho(s) selecionado(s);

2. O sistema exibe a mensagem “Não houve modificações em nenhum campo.”



1. O ator deixa algum campo em branco;

2. O sistema indica com um “*” o campo em branco e exibe a mensagem “O(s) campo(s)

indicado(s) está(estão) em branco. É necessário que todos os campos estejam

preenchido.”


[UC18] Remover Tipo de Despacho

Identificador: [UC18] Remover Tipo de Despacho

Descrição: Remove um tipo de despacho existente no sistema.







Pós-condições: O tipo de despacho está removido do sistema.


1. Include [UC16];

2. O ator seleciona o(s) tipo(s) de despacho que deseja remover e clica o botão

“Remover Tipos de Despachos”; [FE1]

3. O sistema exibe a mensagem “Tipo(s) de despacho removido(s) com sucesso!” e

remove o(s) Tipo(s) de Despacho(s) do sistema;



1. O ator não seleciona o(s) tipo(s) de despacho(s) para remover;

2. O sistema exibe a mensagem “Nenhum tipo de despacho foi selecionado. É necessário

selecionar ao menos um para ser removido”;


[UC19] Logar no (acessar o) sistema

Identificador: [UC19] Logar no (acessar o) sistema

Descrição: Loga no (acessa o) sistema.

Atores: Todos os usuários.


Pré-condições: Os atores devem estar cadastrados no sistema.

Pós-condições: Ator deverá acessar o sistema.


1. O ator acessa a tela para acessar o sistema;

2. O sistema exibe as formas de acesso;

3. O ator fornece as informações necessárias

4. O ator acessa o sistema;[FE1]



1. O ator fornece alguma das informações errada;

2. O sistema exibe a mensagem “Alguma das informações fornecidas está errada. Favor

alterar e tentar acessar novamente”;




[UC20] Logar no (acessar o) sistema com login, senha e captcha

Identificador: [UC20] Logar no (acessar o) sistema com login, senha e captcha

Descrição: Loga no (acessa o) sistema.

Atores: Todos os usuários.


Pré-condições: Os atores devem estar cadastrados no sistema.

Pós-condições: Ator deverá acessar o sistema.


1. Especialização do [UC19];

2. No passo 2 do [UC19], o sistema exibe campos para login, senha e captcha;

3. No passo 3 do [UC19], o ator informa login, senha e captcha e acessa o sistema;

4. O caso de uso continua do passo 4 do [UC19].


UFPE · Web view4.1.4[NFR04] Utilizar Java Server Faces(JSF)16 4.1.5[NFR05] Utilizar Java Database...

Documents

Transcript of UFPE · Web view4.1.4[NFR04] Utilizar Java Server Faces(JSF)16 4.1.5[NFR05] Utilizar Java Database...