1. Processos
1. Documentos recebidos
1. Documentos emitidos
1. Trâmites (para cada um dos objetos acima)
1. Operadores do sistema
1. Pessoas físicas
1. Entidades

Cada um desses objetos é descrito mais detalhadamente adiante através da lista de seus atributos tais como vistos pelos usuários.

1. Processos/Documentos recebidos/Documentos emitidos

Este objeto mantém os dados cadastrais dos documentos, códigos de controle que digam respeito ao seu comportamento durante a tramitação, além de informações relativas aos encaminhamentos dados ao documento (se houver; por exemplo, há encaminhamentos para processos, talvez não para Documentos Emitidos). Os atributos deste objeto são:

1. Tipo do documento. Este campo é necessário para que o GT possa formatar outros campos com a máscara correta, validar esses outros campos. Além do mais, regras de encaminhamento ou outros comportamentos do GoldenTrack poderão depender do tipo de documento.
1. Código do documento no cliente. Sua formatação, validação, etc., podem depender do tipo de documento.
1. Status atual do documento.
1. Confidencialidade do documento. Este campo significa que algum grau de confidencialidade existe para o documento. As regras exatas de confidencialidade estão definidas adiante.
1. Nome e Organização do remetente do documento. Este campo indica a identidade da pessoa que introduziu o documento na área de atuação do sistema.
1. Nome e organização do emitente do documento (quem assinou o documento).
1. Nome e organização do interessado. Campo multivalorado. Poderá ser um grupo e ter outras informações adicionadas ao grupo (campos definidos para a AGT particular).
1. Data do documento. Indica a data de emissão impressa no documento.
1. Data e hora de recebimento. Data e hora do recebimento do documento.
1. Data e hora de cadastramento. Data e hora do cadastramento do documento.
1. Assunto. Curta descrição (uma linha) do documento.
1. Descrição. Campo documento descrevendo o documento.
1. Grupo de cadastro. Pessoa que se identificou junto ao sistema e cadastrou o documento ou alterou este cadastro, além da data e hora do cadastro/alteração.
1. Outras informações de natureza particular ao sistema final gerado mas que não precisam ser de conhecimento do GT. Tais informações podem ser usadas pelo usuário para fins de pesquisa, emissão de relatórios, etc. O módulo básico do GT não utiliza tais informações para o controle da aplicação. Essas informações poderão pertencer a um grupo formados por outros campos.

Qualquer um dos campos acima poderá não ser incluído numa AGT final particular. Os objetos Processos, Documentos recebidos e Documentos emitidos deverão ser armazenados separadamente.

1. Trâmites

Este objeto mantém o histórico da tramitação dos documentos entre entidades cadastradas. A palavra trâmite refere-se a toda atividade desde a recepção de um documento numa entidade até sua saída para outra entidade. A palavra despacho refere-se ao preenchimento do campo de descrição. A palavra encaminhamento refere-se ao ato pontual de repassar o documento para outra entidade. Os atributos deste objeto são:

1. Origem. Entidade e pessoa que encaminhou o documento para a entidade atual.
1. Responsável pelo despacho do documento na entidade atual.
1. Destino. Entidade e pessoa para a qual o documento foi encaminhado após o despacho objeto deste trâmite.
1. Data e hora de entrada na entidade atual.
1. Data e hora de saída da entidade atual.
1. Descrição. Descrição do despacho recebido na entidade atual.
1. Grupo multivalorado de acompanhamento. Novos status/data/descrição do documento durante trâmite. Isto permite acompanhar mudanças de status enquanto o processo estiver numa determinada entidade. Exemplo: Aguardando Senado, Aguardando BACEN, ...
1. Operador que efetuou o encaminhamento.
1. Operador que efetuou o despacho.
1. Outras informações de natureza particular ao sistema final gerado mas que não precisam ser de conhecimento do GT.

1. Operadores do sistema

Este objeto mantém informações sobre os usuários habilitados a utilizarem o sistema GT. Os atributos deste objetos são:

1. Nome de login
1. Senha de acesso
1. Identificação deste operador no cadastro de usuários
1. Informação de segurança indicando para que entidades este operador pode responder e que ações ele pode realizar.
1. Informação de perfil de usuário detalhando as preferências deste operador em termos de interface visual, etc.
1. Outras informações de natureza particular ao sistema final gerado mas que não precisam ser de conhecimento do GT.

1. Pessoas físicas

Este objeto mantém dados cadastrais de responsáveis por entidades e operadores do sistema. Os atributos deste objetos são:

1. Nome completo
1. Telefone
1. Email
1. Número de identificação (CPF, matrícula, ...)
1. Outras informações de natureza particular ao sistema final gerado mas que não precisam ser de conhecimento do GT.

1. Entidades

Este objeto mantém a descrição do modelo da organização, em termos de entidades que podem receber documentos. Os atributos deste objetos são:

1. Nome da entidade
1. Identificação da pessoa que está associada à entidade. Pode ser vazio.
1. Códigos de controle de acesso para a entidade. O controle de acesso da entidade é colocado aqui, porque na maioria das vezes as permissões de acesso de uma pessoa estão associadas diretamente ao seu cargo ou função dentro da organização.
1. Identificação do posicionamento da entidade dentro do modelo hierárquico que descreve a organização.
1. Outras informações de natureza particular ao sistema final gerado mas que não precisam ser de conhecimento do GT.

É requisito deste objeto possuir facilidade para tratar o "mundo de fora", isto é, entidades que não estão diretamente sob controle da AGT.

1. As ações sobre os objetos

1. Processos/Documentos recebidos/Documentos emitidos

1. Cadastrar

O cadastramento deve permitir o preenchimento de todos os campos do objeto. Este preenchimento é manual em alguns casos, automático em outros (de acordo com uma fórmula de preenchimento). Máscaras devem ser aplicáveis a qualquer campo (menos imagem, documento, som). Valores iniciais devem ser possíveis para qualquer campo. Uma fórmula de validação pode se aplicar a qualquer campo (menos imagens, documento, som). Todas essas fórmulas poderão ser função do tipo de documento. Tabelas poderão ser aplicáveis a qualquer campo onde isso fizer sentido.

O Grupo de Cadastro deverá ser preenchido no cadastramento inicial e após qualquer modificação ao cadastro. Considera-se como única alteração qualquer modificação feita numa única sessão de uso da AGT, mesmo que o registro seja gravado várias vezes durante a sessão.

2. Editar

A ação de editar poderá alterar qualquer campo, com exceção do Grupo de Cadastro, o qual será preenchido automaticamente a cada alteração feita, e da data/hora de cadastramento que não pode ser alterado.

Como opção do sistema, poderá ser possível a inibição da edição dos campos após o encaminhamento inicial de um documento.

3. Encaminhar

Esta ação afeta apenas o campo de status do documento. A ação diz mais respeito ao objeto Trâmites e será descrita adiante. O novo status do documento será aquele escolhido durante o trâmite, conforme descrito adiante. Várias restrições podem ser aplicadas ao encaminhamento.

4. Anexar

Esta ação faz com que o documento atual seja anexado a outro documento. O outro documento deve ser informado. Um documento poderá ser anexado a apenas um (1) outro documento, mas vários documentos poderão ser anexados a um determinado documento. Vários tipos de anexos deverão ser possíveis. Cada tipo possui um nome particular e restrições. Por exemplo, deve ser possível definir a ação de "anexar" um processo a outro, "apensar" um processo a outro (permitindo a "desapensação"), juntar um documento recebido a um processo. Em outras palavras, cada sub-tipo de anexação possui um atributo de irreversibilidade (ligado/desligado), um nome particular (anexar, apensar, juntar, ...) e restrições sobre os tipos de documentos envolvidos. Enquanto um documento for anexado a outro, o documento original deixa de ter seus dados modificados, com a possível exceção de alterações de cadastro. Quando a operação de desapensação for possível, deverá estar disponível na interface do usuário. Neste caso, o documento original passa a ser de responsabilidade da entidade atual (que faz a desapensação). Um registro de trâmite deverá ser criado para o documento original indicando a anexação, desapensação, etc.

5. Migrar

Um documento poderá migrar de uma base de dados para outra. Por exemplo, um documento recebido poderá "formar um processo". Neste caso, o documento original permanece na base original com indicação de que migrou para outra base, e indicando que novo documento foi criado. Na nova base de dados (recipiente), um cadastro de documento é simulado, transferindo (copiando) a informação de cadastro da base original para a nova. Restrições podem se aplicar sobre quais documentos poderão assim migrar e para onde.

6. Navegar

Deverá ser possível navegar entre os documentos, visualizando as informações cadastrais. Certos campos poderão não ser vistos por determinadas pessoas, ou em determinados status (ou outro campo) do documento (confidencialidade). A navegação entre processos anexados/apensados/juntados/migrados deverá ser possível nos dois sentidos.

7. Pesquisar

A pesquisa de documentos deverá ser possível por qualquer campo visível para o operador. Restrições de visibilidade podem existir conforme descrito na ação "Navegar". Pesquisas QBF e por sentença deve ser possíveis.

8. Remover

A remoção de um documento só será possível para usuários com permissão para tal, caso houver. A remoção deverá eliminar não somente o cadastro do documento bem como os trâmites a ele associados. A integridade referencial deverá ser mantida de forma que não seja possível remover documentos para os quais outros documentos (anexados, ...) fazem referência. A remoção deverá ser inibida neste caso ou todos os documentos associados deverão ser removidos.

9. Administrar

Deverá ter recursos para as tarefas de administração tais como: reprocessar base, reindexar base, indexar base parcialmente, ligar/desligar indexação online. Deverá ser possível chamar um script de backup através da interface gráfica de administração. O script de backup poderá ser qualquer arquivo executável. Deverá ser possível repassar uma seleção de documentos para arquivo morto. Neste caso, o arquivo morto pode ser escolhido e criado caso não exista. A integridade referencial deve ser mantida (documentos que se referencia devem ser levados para o arquivo morto também) se possível. Se a lista de documentos selecionados não mantiver a integridade referencial, o operador deve ser informado do fato e indagado sobre a forma de prosseguimento.

Estas operações poderão aplicar-se a qualquer base de dados mantida pelo GT e este item não será mais mencionado abaixo.

2. Trâmites

O trâmite envolve dois lados. Quem está com o documento e faz o despacho e quem recebe o documento. A descrição que segue tem como ponto de vista o primeiro lado: aquele que "possui" o documento e deve fazer um despacho e encaminhar o documento para o destinatário.

1. Cadastro do primeiro responsável

Quando um documento é cadastrado, a entidade/pessoa responsável em primeira instância é automaticamente preenchida na base de dados de documentos. Este responsável poderia ser o "Protocolo" da empresa, por exemplo. Neste momento, nenhum registro de trâmite ainda foi gerado.

2. Acompanhar

Enquanto um documento estiver num determinada entidade, esta poderá preencher o grupo multi-valorado de acompanhamento indicando mudanças de status e descrições associadas a essas mudanças de status do documento. As datas associadas serão preenchidas automaticamente. Qualquer repetição das descrições poderá ser editada a qualquer momento até que o documento seja encaminhado. O novo status poderá ser escolhido manualmente através de uma tabela ou de forma automática ao clicar em botões previamente definidos para este fim. Cada botão embute um novo status predefinido.

3. Despachar

O despacho poderá ser preenchido por qualquer operador que tiver permissão para tal. O despacho poderá ser editado e salvo várias vezes até o documento ser encaminhado. Despachos não poderão ser editados após o encaminhamento do documento para outra entidade. O operador que efetuou o despacho deve ser gravado automaticamente.

4. Encaminhar

As datas/horas de entrada e saída na entidade atual deverão ser mantidos automaticamente. A data/hora de entrada na próxima entidade é igual à data/hora de saída da entidade atual. O responsável pelo documento na entidade receptora é automático já que é um atributo da entidade. Cada entidade possui um único responsável (mesmo que vários operadores tenham poderes para tratar dos documentos desta entidade).

Caso o despacho esteja vazio, a AGT poderá ser configurada de forma a avisar o operador antes de efetuar o encaminhamento ou poderá também proibir tal encaminhamento.

O encaminhamento do documento implica em uma possível mudança de status. Este status poderá ser escolhido através de botões predefinidos ou manualmente através de uma tabela de status. O status final deve ser armazenado de forma a permitir a obtenção de um histórico completo das mudanças de status sofridas pelo documento.

Finalmente, a entidade destinatária deve ser escolhida pelo operador. Poderá haver restrições de destinatários possíveis dependendo do status do documento, da entidade atual, do tipo de documento, etc.

O operador que efetuou o encaminhamento deve ser gravado automaticamente.

5. Navegar

Ao estar focado em um determinado documento, poderá ser apresentada a lista de todos os trâmites do documento de uma forma a facilitar a navegação entre trâmites e de forma a fornecer uma representação visual simples do histórico do documento. Deverá haver uma forma de "explodir" um trâmite particular e verificar todos os seus campos detalhadamente. A informação que poderá assim ser visualizada pode ter restrições devido a perfis de usuários, confidencialidade de documentos, etc. tal como no caso do cadastro de documentos descrito acima.

6. Pesquisar

Deverá ser possível localizar documentos através da informação de seus trâmites, bem como posicionar-se em um determinado trâmite de uma lista através de operações de pesquisa em qualquer campo do documento ou dos trâmites.

7. Anexar, Migrar

Para facilidade de uso, as operações de anexação (dos vários tipos) e de migração de bases deverão gerar um registro de trâmite (quando o documento original estiver sob controle de tramitação).

8. Remoção

A remoção de um trâmite não deve ser possível.

3. Operadores do sistema

1. Cadastrar

Operação normal de cadastro de informação. O nome de login não pode ser duplicado. A senha é obrigatória, deve ser mantida de forma criptografada, deve ter um mínimo de 6 caracteres, e um máximo de 32. Pode aceitar qualquer caractere não inibido pela representação interna da informação. A identificação do usuário pode permitir que um mesmo usuário tenha vários nomes de login para ter perfis de segurança diferentes. A informação de segurança e de perfil de usuário é detalhada em outra seção. Apenas um operador com poderes de cadastramento pode cadastrar algum operador e ele só poderá fornecer um perfil de segurança "menor ou igual" ao seu. Ao alocar o perfil de segurança, o operador poderá escolher entre tipos de usuários com permissões pré-definidas, ou poderá ligar/desligar cada bit da máscara de segurança individualmente (sempre respeitando o fato de que não se pode atribuir poderes a um novo usuário que o operador não tenha).

2. Editar

Permite alterar o cadastro de usuários. As mesmas restrições de segurança mencionadas na ação de "Cadastrar" se aplicam. O operador em si poderá consultar o seu próprio cadastro, mudar sua senha e seu perfil de usuário (preferências). Alguma identificação única atribuída ao operador nunca poderá ser modificada, no sentido de manter a identificação de operadores usada em outras bases de dados constante com o tempo.

3. Remover

A remoção de um operador só deverá ser possível caso a integridade referêncial dos dados da AGT possam ser mantidos. Caso seja inviável por uma questão de desempenho, a remoção não deverá ser possível.

4. Login

A operação de login serve como ponto de identificação e autenticação (via senha) do operador. O perfil de preferências e de segurança do operador devem ser obedecidas. As permissões finais alocadas ao operador são um AND bit-a-bit das permissões do operador e da entidade que ele representa no momento.

5. Relogin

Uma operação de relogin deve ser possível enquanto o operador estiver usando a AGT de forma a poder ganhar permissão para uma determinada operação. O contexto inteiro é mantido (levando em conta as restrições de segurança do novo operador).

4. Pessoas físicas

Cadastro normal de usuários com operações de cadastro, edição. A remoção só deve ser possível caso a integridade referencial dos dados da AGT possa ser mantida.

5. Entidades

1. Cadastrar

Operação normal de cadastro de informação. O nome da entidade não pode ser duplicado. A informação de segurança e de perfil de usuário é detalhada em outra seção. Apenas um operador com poderes de cadastramento pode cadastrar alguma entidade e ele só poderá fornecer um perfil de segurança "menor ou igual" ao seu. Ao alocar o perfil de segurança, o operador poderá escolher entre tipos de entidades com permissões pré-definidas, ou poderá ligar/desligar cada bit da máscara de segurança individualmente (sempre respeitando o fato de que não se pode atribuir poderes a um novo usuário que o operador não tenha).

A informação de hierarquia deverá possuir uma forma de especificação simples e abrangente (sem limite de hierarquia horizontal ou verticalmente).

2. Editar

Permite alterar o cadastro de entidades. As mesmas restrições de segurança mencionadas na ação de "Cadastrar" se aplicam. Alguma identificação única atribuída à entidade nunca poderá ser modificada, no sentido de manter a identificação de entidades usada em outras bases de dados constante com o tempo.

3. Remover

A remoção de uma entidade só deverá ser possível caso a integridade referêncial dos dados da AGT possam ser mantidos. Caso seja inviável por uma questão de desempenho, a remoção não deverá ser possível. Apenas folhas da hierarquia podem ser removidas.

4. Escolha da entidade para despacho

Deve haver uma forma visualmente simples de escolher uma entidade da hierarquia no momento do encaminhamento.

5. Mudança de entidade representada

A qualquer momento após o login, o operador poderá escolher representar qualquer entidade para a qual tenha este direito.

2. As restrições de comportamento da AGT

A AGT final permite desempenhar as ações especificadas acima. Entretanto, determinadas restrições (ou direcionamento) de comportamento devem ser possíveis de forma a permitir configurar a AGT para as necessidades do cliente. Esta seção lista os requisitos de restrições de comportamento que devem ser possíveis na AGT. Nenhuma consideração de segurança é feita aqui (vide outra seção adiante).

1. Máscaras, valores iniciais e fórmulas de validação de campos devem ser variáveis e podem depender do valor de outros campos.
1. Confidencialidade. Vários tipos de confidencialidade podem ser definidos. Um tipo de confidencialidade consiste de uma sequência de restrições de visualização de campo. Um item desta sequência é formado por um nome de campo e de uma fórmula booleana que indica se o campo é visível ou não. A fórmula pode fazer deferência a valores de campos deste documento e pode também utilizar a identificação do operador ou de quem o operador representa. Por exemplo, para esconder o "relator" de um processo até o processo estar "CONCLUIDO", exceto para o próprio relator (ou seu operador representante), bastaria uma regra de confidencialidade com um único item dizendo: relator, se Status eq "CONCLUIDO" or Entity eq "PROCURADORIA" then TRUE else FALSE. Neste caso, "Entity" é o nome (ou outra identificação) da entidade que o operador representa e é a entidade do relator.
1. Opção para inibir a edição do cadastro de um documento após seu encaminhamento inicial.
1. Anexação de documentos. Deve ser possível definir vários tipos de anexações e, para cada um, dizer se é reversível ou não e indicar de que bases de dados e que tipos de documentos podem estar envolvidos em cada lado da transação. Isto pode ser feito através de uma fórmula booleana, desde que se possa acessar os campos de cada documento envolvido, além dos nomes das bases em que estão.
1. Migração de documentos. Deve haver uma fórmula booleana indicando se esta migração é possível em função dos campos do documento sendo migrado e da base onde está indo. Também deve-se informar usando alguma sintaxe como os campos são copiados do documento para formar o outro.
1. O destino de um trâmite deve ser passível de restrição. A escolha do destino é feito a partir de uma lista que é um sub-conjunto de todas as entidades possíveis. Deve ser possível definir que sub-conjunto é este através de uma ou mais fórmulas ou outra técnica que permita referenciar os valores dos campos do documento. Caso haja um único destino na lista gerada, o destino pode ser preenchido automaticamente.
1. A lista de novo status possível para um documento durante o acompanhamento ou o encaminhamento deve ser passível de restrição através de fórmula ou outra técnica que permita referenciar os campos do documento. Caso haja um único status na lista gerada, o novo status pode ser preenchido automaticamente.
1. Opção de proibição de encaminhamento com despacho vazio.

1. Cadastrar processo (também permite a criação de um processo através da migração de um documento de uma outra base).
1. Editar cadastro de um processo
1. Anexar/desanexar processo
1. Navegar/pesquisar processos e/ou trâmites
1. Remoção de documentos
1. Administrar o sistema (para todas as bases), dando direito apenas às operações descritas acima na ação "Administrar".
1. Acompanhar um documento
1. Despachar um documento
1. Encaminhar um documento
1. Cadastrar/editar/remover o cadastro de um operador
1. Cadastrar/editar/remover o cadastro de um usuário
1. Cadastrar/editar/remover o cadastro de uma entidade

1. A atribuição de permissões

Máscaras de permissões são associadas a entidades e a operadores. A entidades já que é normal que todos os que representem uma entidade tenham os poderes desta e a operadores porque casos especiais devem ser tratados. As permissões finais alocadas ao operador são um AND bit-a-bit das permissões do operador e da entidade que ele representa no momento.

Não há noção de "dono" de um documento de forma que as permissões de acesso dão (ou não) permissão para todos os documentos.

Perfis de permissão já prontos podem ser criados a a atribuição de permissões a uma entidade ou operador pode referenciar tais perfis já elaborados.

A AGT possui um conjunto inicial de operadores já cadastrados com nomes e permissões informadas pelo cliente. Não há nocção de super-usuário com permissões completas, a não ser que o cliente assim o queira.

2. A identificação de um usuário

Ao entrar na AGT, uma pessoa deve fazer login, identificando-se como operador e fornecendo a senha correta. Este operador jé estará representando uma entidade inicial (configurável pelo operador) e receberá as permissões apropriadas à combinação operador/entidade. A interface deverá permitir que o operador faça um novo login ou mude a entidade representada sem sair da aplicação.

3. Outros requisitos de segurança

As bases de dados poderão ser criptografadas a pedido do cliente. As senhas deverão ser mantidas de forma criptografada, mesmo que as bases de dados não sejam criptografadas.

Para cada operador/entidade, a navegação ou pesquisa será sujeita a duas sentenças de pesquisa cadastradas para o operador e para a entidade. Isto permite limitar o tipo de documento acessível pelo operador. Esta sentença de pesquisa de filtragem poderá ser modificada por qualquer operador que tenha poderes de cadastro de operadores e/ou entidades.

O uso do LBW "por fora" não poderá permitir furar as regras de segurança aqui definidas. Este requisito poderá não ser cumprido na primeira versão do produto, até que o uso "por fora" do LBW seja completamente eliminado. Quando isso for atingido, apenas a LISA poderá acessar as bases "por fora", a pedido do cliente. Este estágio será possível apenas quando a robustez do GT ficar comprovado.

Enquanto o LBW for usado por fora, a combinação usuário/senha para o LBW deverá ser diferente (único) para cada cliente.

Qualquer alteração de dados poderá ser auditada utilizando o log de transações mantido pela AGT (ver requisitos de robustez, abaixo).

Marcus: Importante: reexaminar os requisitos da PGFN, UnB, PGE/SP e Infraero para verificar se nossos requisitos aqui vão atender todos os requisitos desses clientes.