ANEXO I - TERMO DE REFERÊNCIA

1. OBJETO:

Contratação de empresa especializada para prestação de serviços técnicos em tecnologia da informação, visando a Modernização Institucional da Prefeitura Municipal de Xxxxxx Xxxxxxx, através da implantação de uma solução web, mediante a execução das atividades e demais características e especificações técnicas contidas no presente Termo de Referência.

2. JUSTIFICATIVA:

O presente Termo de Referência contempla uma solução, composta por um conjunto de ferramentas e serviços em tecnologia da informação, que permitirão a modernização da gestão administrativa da Prefeitura Municipal de Xxxxxx Xxxxxxx.

Esta solução permitirá que os processos administrativos sejam criados e tramitem de forma eletrônica e sejam assinados com certificados digitais em formato A1 e A3 (token ou cartão), nos termos da ICP-Brasil e da legislação vigente, o sistema poderá ser instalado em servidores locais ou em nuvem conforme estratégia adotada pela administração municipal. (**Despesas referente a contratos com Armazenamento em Nuvem devem estar inseridos no valor do Item Licença de Uso, Suporte e Hospedagem, não podendo ser alterado posteriormente ou repassados em forma de novo contrato. Para o armazenamento em nuvem deverá ser apresentado o Contrato com Nuvem de Armazenamento e acesso aos backup dos dados pela administração. Todos esses procedimentos visão tornar os serviços públicos prestados pelo Município de Xxxxxx Xxxxxxx sejam mais eficientes, céleres e acessíveis ao cidadão).

A implantação do software trará grande avanço na modernização administrativa do Município, com foco em resultados e melhorias nas práticas de administração. Em geral os benefícios esperados são:

• Celeridade na tramitação de documentos e processos;

• Redução de custos operacionais relacionados à entrega, ao armazenamento e arquivamento de documentos e processos;

• Redução de custos financeiros e ambientais associados à impressão (impressoras, toner, papel, contratos de impressão e cópias de documentos);

• Facilidade e rapidez na localização de documentos e processos;

• Controle e acompanhamento do trâmite processual e documental;

• Aumento na produtividade dos colaboradores;

• Retenção de conhecimento, através da padronização de procedimentos e documentos, permitindo o uso e reuso das informações;

• Facilidade na busca e localização de informações;

• Segurança e transparência nas ações de execução das atividades processuais necessárias;

• Prevenção de acesso não autorizado a documentos e processos;

• Aumento de controle dos processos, eliminando os riscos de perda, roubo e extravio;

• Ganhos sociais com a melhoria dos serviços prestados;

• Resgate e controle de realizações passadas;

• Controle da proliferação e da duplicação de arquivos;

• Conformidade com normas e regulamentos.

Também está contemplado no objeto do presente Termo de Referência, a modelagem de processos de negócio, tendo como objetivo a simplificação e desburocratização dos serviços públicos prestados pelo Município de Xxxxxx Xxxxxxx aos cidadãos. Em atendimento a LEI 13.709/2018 deverá ser apresentado pela contratada plano de tratamento de segurança de dados.

3. FORMA DE AQUISIÇÃO/CONTRATAÇÃO:

O serviço a ser contratado enquadra-se na classificação de bens ou serviços comuns, podendo ser especificadas de forma objetiva, encontrando amparo nos termos da Lei Federal n° 10.520/2002 e da Lei n° 8.666/93, consolidada. A presente contratação deverá ser realizada por meio de processo licitatório, na modalidade Pregão presencial, considerando o MENOR PREÇO GLOBAL, proposto entre as licitantes interessadas, segundo as especificações

e normas adotadas pela Administração, atendendo a Lei de Licitações 10.520/2002 subsidiada pela Lei 8.666/93, consolidada.

4. DESCRIÇÃO E ESPECIFICAÇÃO DOS SERVIÇOS

4.1 - O objeto deste Termo de Referência está distribuído conforme a tabela e detalhamento a seguir:

ITEM	DESCRIÇÃO	UN.	QTDE
LOTE 01
1.1	Implantação: Implantação do software de acordo com os requisitos estabelecidos neste Termo de Referência.	Un.	01
1.2	Modelagem de Processos: Modelagem de processos de negócio da área administrativa, de acordo com a notação BPMN 2.0.	Un.	10
1.3	Treinamento na Operação do Software: Treinamento na operação do software, com turmas de até 10 (dez) servidores.	Turma	02
1.4	Licença de Uso, Suporte e Hospedagem: Locação de licença de uso, suporte e hospedagem mensal do software.	Mês	12
1.5	Operação Assistida: Operação assistida na utilização do software.	Mês	6

4.1.1 IMPLANTAÇÃO DO SOFTWARE PARA GERENCIAMENTO ELETRÔNICO DE PROCESSOS ADMINISTRATIVOS:

O Software para Gerenciamento Eletrônico de Processos Administrativos deve atender o controle das funções da área administrativa da Prefeitura Municipal de Xxxxxx Xxxxxxx, contemplando as fases de abertura de processos e documentos, tramitação eletrônica e arquivamento, todos podendo ser assinados digitalmente, através de certificados digitais, de acordo com os requisitos previstos na MP nº 2.200-2, que instituiu a Infraestrutura de Chaves Públicas Brasileiras - ICP-Brasil e nos termos da Lei 14.063/2020, que dispõe acerca das assinaturas eletrônicas.

Os Requisitos Técnicos do Software para Gerenciamento Eletrônico de Processos Administrativos estão descritos no Anexo I-A deste Termo de Referência.

A etapa de implantação do software corresponde a todos os serviços necessários ao pleno funcionamento e utilização do Software para Gerenciamento Eletrônico de Processos Administrativos, devendo ser acompanhada pelo fiscal do contrato, que se responsabilizará por todo relacionamento administrativo da Contratada com a Contratante.

4.1.1.1 Serviços de Migração de Dados:

A Migração de Dados é o processo de transferência dos dados do sistema existente da Contratante para a base de dados do Software para Gerenciamento Eletrônico de Processos Administrativos, que compreende 03 (três) etapas distintas:

• Extração de dados: processo de captura de todos os dados dos bancos de dados e outras fontes do sistema existente;

• Validação dos dados: processo de limpeza dos dados (detecção e correção de dados incorretos, incompletos, corrompidos ou duplicados), enriquecimento dos dados (compreende a atualização dos dados com novos atributos, complementares aos existentes até então), validação lógica e física dos dados e a adequação dos mesmos ao formato de dados utilizado pelo Software para Gerenciamento Eletrônico de Processos Administrativos;

• Carga de Dados: os dados extraídos e validados são inseridos nas bases de dados do Software para Gerenciamento Eletrônico de Processos Administrativos.

4.1.1.2 Serviços de Customização:

Durante a implantação poderá ocorrer à necessidade de customização de algumas tabelas, cadastros, consultas, ou relatórios do Software para Gerenciamento Eletrônico de Processos Administrativos, visando atender à Legislação vigente.

O prazo para a realização do serviço de Implantação do Software será de até 03(três) meses, a contar da data de recebimento da Autorização de Serviços.

4.1.2 MODELAGEM DE PROCESSOS DE NEGÓCIO:

Esta etapa consiste na modelagem de processos de negócio da área administrativa, de acordo com a notação BPMN

2.0. Para cada Tipo de Processo deverá ser fornecida documentação da visão funcional, permitindo aos usuários descrever por completo o processo incluindo também a documentação referente aos tipos documentais e fluxos de trabalho, devendo o mesmo ser mapeado e configurado no Software para Gerenciamento Eletrônico de Processos Administrativos.

A Modelagem de Processos deverá objetivar a sua otimização trazendo ganhos para a Contratante na execução dos mesmos, eliminando gargalos, redundâncias, retrabalho e falta de padrões.

Será estabelecido para cada Tipo de Processo todas as rotas possíveis, contemplando no mínimo: Atividade atual, parecer da tramitação, próxima atividade e os setores responsáveis de cada etapa estabelecida, bem como prazo para conclusão de cada atividade.

Ao final da Modelagem de Processos, a Contratada deverá fornecer documentação detalhada e consistente o suficiente para:

a) Permitir a discussão e compreensão do fluxo do processo de negócio, podendo ser usado para ensinar e treinar novos usuários;

b) Auxiliar na definição de atividades, tendo em vista atingirem aos objetivos da Contratante;

c) Servir como base para melhoria contínua (análise eficiência e de eficácia).

d) Simular alternativas ou novos modelos;

e) Atuar como elemento fundamental na especificação dos fluxos do processo que deverão suportar o negócio;

f) Facilitar, no futuro, a implementação de Programas da Qualidade de Gestão Governamental, ISO 9000, etc.

Serão modelados 30 (trinta) tipos de processos.

A Contratante definirá e informará à Contratada quais serão os tipos de processos a serem modelados durante a execução do contrato.

O prazo para a realização do serviço de Modelagem de Processos de Negócio será de até 03 (três) meses, a contar da data de recebimento da Autorização de Serviços.

4.1.3 TREINAMENTO NA OPERAÇÃO DO SOFTWARE:

A implantação do software exige que sejam realizados treinamentos essenciais à compreensão do usuário para a tecnologia que está sendo implantada e facilitar a Gestão da Mudança.

O treinamento ocorrerá em horário comercial, na sede da Contratante, com carga horária de 04 (quatro) horas, para até 30 (trinta) servidores com no máximo 10 (dez) alunos por turma, sendo de responsabilidade da Contratante a disponibilização do espaço, com mesas e cadeiras e equipamentos com acesso à internet.

A Contratada deverá apresentar um cronograma de treinamento de usuários indicados pela Contratante para ser executado no período de implantação do software.

O prazo para a realização do serviço de Treinamento na Operação do Software será de até 03(três) meses, a contar da data de recebimento da Autorização de Serviços.

4.1.4 DA LICENÇA DE USO, SUPORTE E HOSPEDAGEM DO SOFTWARE:

A Licença de uso do software, nos termos da Lei Nº 9.609/1998, será na modalidade de locação e terá validade durante a vigência do Contrato. Por se tratar de software para ambiente Web, o número de acessos simultâneo por usuário é ilimitado.

Todas as licenças do Software para Gerenciamento Eletrônico de Processos Administrativos possuirão garantia de atualizações de versão, pelo período de vigência do contrato.

O Software para Gerenciamento Eletrônico de Processos Administrativos poderá ser instalado no servidor da

Contratada, no formato de Cloud Computing (Computação em Nuvem), sendo de sua responsabilidade disponibilizar todos os recursos de hardware e software necessários para o perfeito funcionamento da solução, bem como backup do software e da base de dados produzida, tendo seus custos já incluídos no valor da licença de uso.

O Suporte oferecido pela Contratada deverá possuir os seguintes níveis de atendimento:

• Helpdesk:

Atendimento remoto através de comunicação telefônica, serviços de mensagens instantâneas, software de comunicação falada e escrita via Internet, página da internet para atualização de versões, serviço de publicação de dúvidas mais frequentes, serviço de FTP (transmissão remota de arquivos), comunicação remota, inclusive com acesso aos bancos de dados.

• Serviço de Suporte Técnico:

Nos casos não solucionados via Helpdesk deverá ser acionado o Setor de Suporte, que efetuará uma análise mais técnica, como checagem e auditoria no Banco de Dados, processamentos de Scripts (comandos específicos), correção de programas e envio de atualizações, se for o caso.

• Atendimento “in loco”:

Se ainda assim não for solucionado o problema, será gerada uma Ordem de Serviço para atendimento local. O Suporte deverá, ainda, deverá obedecer ao seguinte:

a) Possuir um sistema de gerenciamento do atendimento no qual todas as solicitações de suporte em cada nível do atendimento técnico serão registradas em sistema próprio permitindo acompanhamento on-line (internet);

b) Horário disponível para registro das solicitações, não podendo ser inferior ao horário comercial, de 8h às 18h, ininterruptamente;

c) Informar e realizar as atualizações imediatamente, sempre que ocorrerem atualizações das versões dos módulos que compõem o objeto deste contrato.

A transferência de arquivos da Contratada para a Contratante deverá ser feita utilizando o protocolo FTP ou HTTP e de acordo com as normas de segurança praticadas na Contratante.

O atendimento obedecerá aos prazos abaixo:

Severidade ALTA: Esse nível de severidade é aplicado quando há a indisponibilidade no uso do Software para Gerenciamento Eletrônico de Processos Administrativos:

Prazo de Solução Definitiva

No máximo de até 24 (vinte e quatro) horas

Severidade MÉDIA: Esse nível de severidade é aplicado quando há falha, simultânea ou não, no uso do sistema, estando ainda disponíveis, porém apresentando problemas nível de severidade é aplicado quando há a indisponibilidade no uso do Software para Gerenciamento Eletrônico de Processos Administrativos:

Prazo de Solução Definitiva

No máximo de até 48 (quarenta e oito) horas

Severidade BAIXA: Esse nível de severidade é aplicado para problemas que não afetem o desempenho e disponibilidade do Software para Gerenciamento Eletrônico de Processos Administrativos, bem como para atualizações de sistema, esclarecimentos técnicos relativos ao uso e aprimoramento do Software para Gerenciamento Eletrônico de Processos Administrativos:

Prazo de Solução Definitiva

No máximo de até 72 (setenta e duas) horas.

Será considerado para efeitos do nível de serviço exigido, prazo de solução definitiva, como o tempo decorrido entre a abertura da ordem de serviço efetuado pelo Setor Solicitante da Contratante à Contratada e a efetiva recolocação do Software para Gerenciamento Eletrônico de Processos Administrativos em seu pleno estado de funcionamento.

A contagem do prazo de solução definitiva de cada chamado será a partir da abertura da ordem de serviço na Central de Atendimento disponibilizada pela Contratada, até o momento da comunicação da solução definitiva do problema e aceite pelo Setor solicitante da Contratante.

Concluída a ordem de serviço, a Contratada comunicará o fato ao Setor Solicitante da Contratante e solicitará autorização para o fechamento do mesmo. Caso o Xxxxx solicitante da Contratante não confirme a solução definitiva do problema, o chamado permanecerá aberto até que seja efetivamente solucionado pela Contratada. Neste caso, a Contratante fornecerá as pendências relativas ao chamado aberto.

A Contratada realizará os serviços de Licença de Uso, Suporte e Hospedagem do Software, pelo período de 12 (doze) meses, contados a partir da data de emissão da Autorização de Serviços, o que ocorrerá após o aceite do serviço de Implantação.

4.1.5 OPERAÇÃO ASSISTIDA AO SOFTWARE:

O serviço de Operação Assistida consiste no acompanhamento presencial, com a alocação de 01 (um) técnico da Contratada durante o uso do software pelos usuários da Contratante, com a função de:

• Sanar dúvidas de utilização e efetuar as correções ou ajustes necessários;

• Resolver problemas de inconsistências identificadas ou não conformidades com as exigências do Contrato.

Durante o período da operação assistida, a Contratada deverá prover aos usuários do software suporte funcional e técnico na sua operação, compreendendo as seguintes atividades:

• Apoio à Contratante na operação do software;

• Correção de todo e qualquer erro que seja detectado no software pela Contratante;

• Re-treinamento complementar de capacitação de usuário (s), nos casos em que a Contratante identificar a necessidade.

Com o intuito de realizar os ajustes necessários para assegurar a disponibilidade e performance do software, a Contratada deverá realizar o monitoramento de:

• Nível de uso do software;

• Nível de desempenho;

• Quantidade de chamados por módulo;

• Disponibilidade do software.

Os locais de execução desse serviço restringem-se à sede da Prefeitura Municipal de Xxxxxx Xxxxxxx, no horário comercial, das 8h às 18h.

A Contratada realizará os serviços de Operação Assistida ao Software, pelo período de 6 (seis) meses, contados a partir da data de emissão da Autorização de Serviços, o que ocorrerá após o aceite do serviço de Implantação.

5. PRAZOS DE INÍCIO E TÉRMINO DOS SERVIÇOS:

Assinado o contrato, a Contratada deverá iniciar os trabalhos a partir do envio da ordem de serviço pela Contrante, nos termos a seguir:

a) Implantação do Software para Gerenciamento Eletrônico de Processos Administrativos, que consiste na: Instalação do sistema e disponibilização via web, modelagem de processos de negócio e treinamento para operação do software, que deverá ser executada no prazo de 03 (três) meses.

b) A licença de uso, suporte e hospedagem do software deverão ser executados, após o término da etapa de implantação do software, pelo período de 12 (doze) meses.

c) A operação assistida ao software deverá ser executada, após o término da etapa de implantação do software, pelo período de 6 (seis) meses.

Enquanto não for concluída a etapa de Modelagem de Processos, os processos que não tiverem sido modelados terão sua tramitação eletrônica ad hoc.

6. LOCAL DE EXECUÇÃO DOS SERVIÇOS:

Os serviços de Operação Assistida ao Software serão executados na sede da Contratante. Os demais serviços serão executados em local a ser definido pela Contratada e as suas próprias expensas.

7. CONDIÇÕES E PRAZOS DE PAGAMENTO:

Os pagamentos serão efetuados da seguinte forma:

a) Implantação do Software para Gerenciamento Eletrônico de Processos Administrativos: 03 (três) parcelas mensais, mediante a apresentação de nota fiscal à Contratante, acompanhada do Relatório de Implantação Mensal, no prazo de até 15 (quinze) dias úteis após a análise e certificação dos serviços pelo fiscal do contrato;

b) Modelagem de processos: 03 (três) parcelas mensais, mediante a apresentação de nota fiscal à Contratante, acompanhada do Relatório da Modelagem de Processos e Diagrama dos Processos Modelados, no prazo de até 15 (quinze) dias úteis após a análise e certificação dos serviços pelo fiscal do contrato;

c) Treinamento na operação do software: parcela única, mediante a apresentação de nota fiscal à Contratante, acompanhada do Relatório do Treinamento, Certificados de Participação e Listas de Presença, no prazo de até 15 (quinze) dias úteis após a análise e certificação dos serviços pelo fiscal do contrato;

d) Licença de uso, suporte e hospedagem do software: 12 (doze) parcelas mensais, iguais e consecutivas, mediante a apresentação de nota fiscal à Contratante, acompanhada do Relatório Mensal, no prazo de até 15 (quinze) dias úteis após a análise e certificação dos serviços pelo fiscal do contrato;

e) Operação assistida ao software: 6 (seis) parcelas mensais, iguais e consecutivas, mediante a apresentação de nota fiscal à Contratante, acompanhada do Relatório Mensal, no prazo de até 15 (quinze) dias úteis após a análise e certificação dos serviços pelo fiscal do contrato;

As notas fiscais dos serviços deverão ser emitidas com data, razão social da empresa, discriminação e descrição dos serviços, seu valor unitário e global, indicação do período correspondente de sua realização, bem como conter o nome da Prefeitura Municipal de Xxxxxx Xxxxxxx e CNPJ.

8. PROPOSTA E CRITÉRIO DE JULGAMENTO:

O regime de execução será por empreitada preço global e critério de julgamento será menor preço por lote.

Não serão aceitas propostas com valores unitários e/ou global, superiores aos estimados pela Prefeitura Municipal de Xxxxxx Xxxxxxx.

Nos preços propostos deverão estar inclusas todas as despesas com salários, leis sociais, trabalhistas, seguros, impostos, taxas e contribuições, transporte, alimentação, despesas administrativas e lucros e demais insumos necessários à sua composição.

A Contratada deverá arcar com o ônus decorrente de eventual equívoco no dimensionamento dos quantitativos de sua proposta, devendo complementá-los, caso o previsto inicialmente em sua proposta não seja satisfatório para o atendimento ao objeto da licitação, exceto quando ocorrer algum dos eventos arrolados nos incisos do § 1º do art. 57 da Lei nº 8.666, de 1993.

Para critério de julgamento será considerada vencedora a proposta que apresentar menor preço global.

9. VALIDADE DA PROPOSTA:

A proposta deverá ser elaborada com validade de no mínimo 60 (sessenta) dias.

10. OBRIGAÇÕES DA CONTRATADA:

São obrigações da Contratada:

a) Responsabilizar-se integralmente pela execução e entrega dos serviços contratados, em conformidade com os prazos, padrões e normas aplicadas à espécie, responsabilizando-se integralmente pela qualidade deles;

b) Executar o objeto deste contrato sob sua total e inteira responsabilidade, sendo-lhe vedado ceder, transferir ou terceirizar, no todo ou em parte, os direitos e obrigações assumidos neste instrumento, ou que dele resultem, sem prévia e formal anuência da contratante;

c) Coordenar e supervisionar os serviços, cumprindo rigorosamente os termos, serviços e prazos estabelecidos neste Termo de Referência;

d) Comunicar, formal e imediatamente, a contratante sobre eventuais ocorrências anormais verificadas na execução do contrato, no menor espaço de tempo possível, incluindo toda e qualquer irregularidade constatada;

e) Fornecer um canal de comunicação direta com os usuários da Contratante, visando o atendimento com a maior diligência possível, as determinações da contratante, adotando todas as providências necessárias à regularização de faltas e irregularidades verificadas e sugestões permitindo o acompanhamento;

• A regularização que afete o andamento do sistema deverá ser solucionada imediatamente, as demais, no prazo máximo de 5 (cinco) dias;

f) Xxxxxx, durante toda a execução do contrato, em compatibilidade com as obrigações assumidas, as mesmas condições de habilitação e qualificação exigidas na licitação;

g) Responsabilizar-se pelos encargos fiscais, trabalhistas e da seguridade social resultante da execução do contrato;

h) Responsabilizar-se pelo pagamento de todas as despesas, diretas ou indiretas, de quaisquer tributos, contribuições, multas ou ônus oriundos da contratação, pelos quais seja responsável, principalmente os de natureza fiscal, trabalhista, previdenciária e comercial.

i) Apresentar, sempre que solicitado pela contratante, comprovante expedido pelo órgão oficial competente, do cumprimento das obrigações trabalhistas e programas sociais tais como: vale transporte, cesta básica, vale refeição, vale transporte e demais benefícios, previstos em acordo coletivo ou convenção da categoria, e apresentar sempre que solicitado, os comprovantes de pagamentos de benefícios e encargos.

j) Responsabilizar-se por quaisquer danos ou prejuízos que causar a contratante ou a terceiros, decorrentes de culpa ou dolo, em decorrência do não cumprimento ou cumprimento irregular das obrigações assumidas;

k) Indicar representante para manter contato com a CONTRATANTE para o esclarecimento de dúvidas, fornecendo nome, telefone e endereço eletrônico para contato, informando formalmente caso haja mudança de representante ou de dados;

l) Responsabilizar-se pela observância das leis, decretos, regulamentos, portarias e normas federais, estaduais e municipais direta e indiretamente aplicáveis ao objeto do contrato;

m) Acompanhar as publicações das normas no Diário Oficial do Município para as efetivas inserções e atualizações.

n) Apresentar os Relatórios referente a execução dos serviços, na forma estipulada no presente Termo de Referência;

o) Emitir nota fiscal datada com a razão social da empresa, discriminando e descrevendo os serviços, seu valor unitário e global, com período correspondente de sua realização, contendo nome da Prefeitura Municipal de Xxxxxx Xxxxxxx e CNPJ.

11. OBRIGAÇÕES DA CONTRATANTE:

São obrigações da Contratante:

a) Manter um arquivo completo e atualizado de toda a documentação pertinente aos trabalhos contidos neste Termo de Referência;

b) Acompanhar e Fiscalizar a execução dos trabalhos por meio de um usuário da Contratante;

c) Promover a avaliação e fiscalização deste instrumento;

d) Atestar as notas fiscais, nos termos contratados, para efeito de pagamento;

e) Após o recebimento da nota fiscal e do Relatório, os usuários da Contratante designados para fiscalização do contrato, atestarão a execução do contrato, certificando o cumprimento dos serviços, à vista das cláusulas contratuais;

f) Solicitar a substituição de qualquer funcionário da Contratada que embarace a ação da fiscalização;

g) Esclarecer ou solucionar incoerências, falhas e omissões eventualmente constatadas, bem como nas demais informações e instruções complementares deste Termo de Referência, necessárias ao desenvolvimento dos trabalhos;

h) Exercer rigoroso controle sobre a execução dos serviços aprovando os eventuais ajustes que ocorrerem durante o desenvolvimento dos trabalhos;

i) Verificar e atestar os serviços, bem como conferir, visitar e encaminhar para pagamento as faturas emitidas pela Contratada;

j) Encaminhar à Contratada os comentários efetuados para que sejam providenciados os respectivos atendimentos.

12. PRAZO DO CONTRATO:

O prazo de vigência do contrato de prestação de serviços será: Implantação, treinamento e Modelagem 3 (Três) meses; Licença de Uso, Suporte e Hospedagem 12 (doze) meses; Operação Assistida 6 (seis) meses.

Sempre a partir da data de sua assinatura, sendo facultado, a contratante prorrogá-lo, nos termos da legislação vigente.

13. GARANTIA:

A garantia dos serviços deverá ser de no mínimo 01 (um) ano, incluindo a manutenção corretiva e o perfeito funcionamento do software.

14. QUALIFICAÇÃO TÉCNICA:

Os atestados de capacidade técnica deverão conter, no mínimo, as seguintes informações: nome das empresas declarantes, a identificação do nome e a assinatura do responsável, número do contrato, o número de telefone para contato, bem como a descrição do escopo dos serviços prestados pela Licitante, de forma a comprovar as experiências nas atividades descritas. Esta descrição deverá conter dados que permitam o amplo entendimento dos trabalhos realizados para comparação com o escopo a ser licitado e exigido nos respectivos atestados.

Documentos em língua estrangeira deverão estar acompanhados da tradução para a língua portuguesa.

Admitir-se-á o somatório dos quantitativos consignados em atestados que comprovem a simultaneidade de fornecimento do objeto desde que seja, no mesmo período de prestação dos serviços.

14.1 Da Empresa:

Os atestados de capacidade técnica exigidos têm por objetivo garantir a capacidade da empresa Licitante de executar o contrato e entregar os objetos licitados de forma satisfatória, dentro de parâmetros mínimos de qualidade e prazo, recaindo as exigências de atestação somente em atividades comuns, genéricas e frequentes de contratos de mesma natureza.

Para demonstrar a prova de qualificação técnica da empresa, os licitantes deverão apresentar em conjunto:

a) Comprovação de aptidão da LICITANTE em prestação de Serviços de Implantação e Suporte do Software ofertado com as características e quantidades do objeto deste Termo de Referência através da apresentação de, pelo menos, 01 (um) atestado de desempenho atual ou anterior, fornecido por organização pública ou privada, comprobatório da capacidade técnica, devendo ainda constar no documento:

• Endereço eletrônico do software publicado na Web;

• Fazer menção que o software implantado contemplou os módulos de: Gerenciamento de Processos Eletrônicos, com utilização de Certificação Digital, nos mesmos termos do objeto descrito neste Termo de Referência.

b) Comprovação de aptidão da LICITANTE em prestação de Serviços de Modelagem de Processos de Negócios com as características e quantidades do objeto deste Termo de Referência através da apresentação de, pelo menos, 01 (um) atestado de desempenho atual ou anterior, fornecido por organização pública ou privada:

14.2 Da Equipe Técnica:

Considerando a aderência do software a ser implantado em todas as áreas da Prefeitura Municipal de Xxxxxx Xxxxxxx e a complexidade e a criticidade das informações nele existentes, não é razoável permitir que o projeto seja realizado por profissional sem as competências e habilidades adequadas.

A equipe deverá apresentar os perfis e experiências detalhados a seguir, além das qualificações mínimas exigidas para cada função. Estas características deverão ser comprovadas mediante apresentação pela Contratada da descrição dos perfis, segundo modelo exigido pela Contratante, acrescidos das comprovações de experiência (curriculum vitae e declarações de capacidade técnica) e vida acadêmica (certificados e diplomas).

Importa frisar que a descrição do pessoal exigido neste Termo de Referência está circunscrita à equipe mínima necessária para garantir a excelência na prestação do serviço pretendido e que as comprovações de habilitação dos profissionais que a empresa irá dispor para compor tal equipe são importantes instrumentos de aferição da capacidade técnica da equipe e profissionais que irão executar as atividades do contrato e referem-se apenas às atividades e capacidades imprescindíveis à prestação do objeto licitado.

A Prefeitura Municipal de Xxxxxx Xxxxxxx só aceitará a prestação de serviço de profissionais da Contratada que atendam às exigências de qualificação profissional, incluindo as certificações e experiências, que estão descritas neste Termo de Referência.

Sempre que um novo profissional for incluído ou substituído na equipe da Contratada, a Contratada deverá comunicar a Prefeitura Municipal de Xxxxxx Xxxxxxx e apresentar os documentos requisitados.

Se, porventura, um profissional que estiver prestando serviços perder quaisquer das certificações exigidas, a Contratada deverá comunicar à Prefeitura Municipal de Xxxxxx Xxxxxxx e providenciar um substituto, apresentando os documentos requisitados deste novo profissional.

Para as exigências dos profissionais, a comprovação de experiência poderá ser feita também por apresentação de currículo, como alternativa ao documento emitido pela empresa onde foi adquirida a experiência.

Assim, na assinatura do contrato, para fins de execução do objeto deste contrato, a Contratante exigirá da Contratada a alocação de uma equipe técnica, formada pelos seguintes profissionais:

a) Profissional com formação em TECNOLOGIA DA INFORMAÇÃO:

Este profissional será responsável pela Implantação do Software para Gerenciamento Eletrônico de Processos Administrativos, e deverá apresentar para fins de comprovação os seguintes documentos:

1. Diploma de conclusão de curso de graduação ou pós-graduação na área de Tecnologia da Informação;

2. Curriculum vitae os quais deverão constar nas descrições das experiências, além das informações técnicas exigidas, outras informações necessárias e suficientes para a avaliação das experiências referenciadas pela Contratante. Deverão ser informados para cada experiência:

3. Identificação da pessoa jurídica para a qual se refere a experiência;

4. Período de vigência do contrato.

b) Profissional com formação em ADMINISTRAÇÃO DE EMPRESAS:

1. Este profissional será responsável pela Modelagem de Processos e deverá apresentar para fins de comprovação os seguintes documentos:

2. Diploma de conclusão de curso de administração de empresas;

3. Atestado de capacidade técnica que comprove conhecimentos em Modelagem de Processos, preferencialmente para o setor público;

4. Curriculum vitae os quais deverão constar nas descrições das experiências, além das informações técnicas exigidas, outras informações necessárias e suficientes para a avaliação das experiências referenciadas pela Contratante. Deverão ser informados para cada experiência:

5. Identificação da pessoa jurídica para a qual se refere a experiência;

6. Período de vigência do contrato.

15. PROVA DE CONCEITO:

Será aplicada a Prova de Conceito - POC - que terá por finalidade avaliar a proficiência das empresas qualificadas e terá caráter eliminatório.

15.1 DISPOSIÇÕES GERAIS:

A ordem de avaliação da POC será a ordem de classificação das Licitante qualificadas, ou seja, a primeira colocada no certame terá seu software avaliado e, caso não seja aprovada, esta será eliminada do processo licitatório, passando a avaliação da comissão à segunda colocada. Esse processo se repetirá até que uma das licitantes seja considerada habilitada pelas equipes técnicas que julgarão a POC.

A Licitante provisoriamente classificada em primeiro lugar, denominada LICITANTE EM AVALIAÇÃO, deverá comprovar que atende a todas as simulações propostas na prova de conceito, conforme ANEXO I-A Procedimentos da POC, sob pena de desclassificação.

A Contratante apresentará a lista de requisitos a serem avaliados na POC, conforme descritos na Tabela de Requisitos Técnicos do Software - Anexo I-A deste Termo de Referência.

A Prova de Conceito consiste na apresentação do produto final em pleno funcionamento pela LICITANTE EM AVALIAÇÃO, permitindo a averiguação prática das funcionalidades e características do produto, devendo ser acompanhada por uma Equipe Técnica de Avaliação da Prefeitura Municipal de Xxxxxx Xxxxxxx.

Para a realização da Prova de Conceito, a LICITANTE EM AVALIAÇÃO deverá fornecer todos os insumos necessários à análise do piloto/amostra da solução apresentada, tais como ambiente único com a solução devidamente instalada, configurada e parametrizada, rede e equipamentos próprios, pessoal técnico necessário, etc. Todas as licenças, toda a infraestrutura e todos os equipamentos necessários (Ex.: rede, nobreak) deverão ser providenciados pela LICITANTE EM AVALIAÇÃO e ser devidamente instalados e configurados na solução proposta. Caberá a Contratante a disponibilização de acesso à Internet e equipamento para projeção.

Antes de começar a POC, a Contratante poderá verificar a conformidade dos softwares e equipamentos físicos no ambiente de instalação para não haver quaisquer dúvidas quanto à integridade, conformidade e confiabilidade do processo, podendo a LICITANTE EM AVALIAÇÃO ser reprovada, automaticamente, se verificada alguma irregularidade, até mesmo antes de iniciar a POC.

Poderão participar da Prova de Conceito até 03 (três) representantes credenciados da LICITANTE EM AVALIAÇÃO, até 01 (um) representante credenciado de cada uma das demais LICITANTES, os membros da Equipe Técnica de Avaliação e da equipe de licitação da Prefeitura Municipal de Xxxxxx Xxxxxxx.

Eventuais questionamentos prévios acerca da execução da Prova de Conceito poderão ser feitos pelas Licitantes, oportunamente, nos prazos pertinentes ao pedido de esclarecimentos e impugnações, depois de publicado o edital de licitação.

15.2 EQUIPE TÉCNICA DE AVALIAÇÃO:

A equipe responsável pela avaliação técnica será composta por membros indicados das seguintes unidades administrativas da Prefeitura Municipal de Xxxxxx Xxxxxxx:

• Secretário Municipal de Administração;

• Secretário Municipal de Finanças;

• Diretor de Tecnologia da Informação.

• Consultor ou Prestador de Serviço de Tecnologia da Informação indicado pela Prefeitura de Xxxxxx Xxxxxxx.

Caberá à Equipe Técnica de Avaliação:

a) Coordenar a execução de todas as atividades relativas à Prova de Conceito e realizar questionamentos quanto ao piloto/amostra apresentado, podendo realizar diligências;

b) Declarar, no decorrer da prova de conceito, a conclusão das atividades de Avaliação Técnica (Vale ressaltar que declarar a conclusão não consiste em confirmar o atendimento ou não do requisito. Tal resposta somente será disponibilizada no Relatório de Julgamento da Prova de Conceito);

c) Emitir ao pregoeiro o Relatório de Julgamento da prova de conceito, devidamente justificado, para continuidade do procedimento licitatório.

15.3 PROCEDIMENTOS DA POC:

Para a Prova de Conceito serão avaliados os requisitos descritos na Tabela de Requisitos Técnicos do Software – Anexo I-A deste Termo de Referência. Todos os requisitos solicitados na prova de conceito deverão ser demonstrados e validados.

A LICITANTE EM AVALIAÇÃO será reprovada se não conseguir demonstrar o percentual mínimo dos requisitos exigidos na POC.

A LICITANTE em avaliação terá um prazo de 02 (dois) dias úteis, a contar do primeiro dia útil seguinte à convocação pelo pregoeiro, para preparar um piloto/amostra do produto, deixando-o em plenas condições operacionais de avaliação.

As realizações das demonstrações da POC deverão ocorrer a partir do terceiro dia útil, a contar do primeiro dia útil seguinte à convocação pelo pregoeiro, devendo a LICITANTE em avaliação se apresentar à Equipe Técnica de Avaliação do piloto/amostra nas datas e horários da convocação.

Se a LICITANTE provisoriamente classificada em primeiro lugar não comparecer à sessão da Prova de Conceito, será desclassificada e será convocada a segunda colocada e assim sucessivamente.

Durante a Prova de Conceito, somente a Equipe Técnica de Avaliação e o Pregoeiro poderão se manifestar com questionamentos pertinentes à verificação e quanto ao cumprimento dos requisitos licitatórios, respectivamente, sendo a eles facultado realizar diligências para aferir o cumprimento dos requisitos, não sendo permitida, durante eventual diligência, qualquer alteração no produto criado para a Prova de Conceito, salvo para parametrização e alterações feitas através da interface do sistema, com o conhecimento de toda a equipe da POC.

Se, durante o período de demonstração, a Equipe Técnica de Avaliação constatar a impossibilidade de a LICITANTE atender integralmente as exigências da POC, esta será desclassificada, independentemente de restarem itens a serem demonstrados e avaliados, e a próxima colocada será convocada.

A LICITANTE em avaliação deverá apresentar profissionais especialistas no produto para apresentar o piloto/amostra, bem como exaurir eventuais questionamentos da Equipe Técnica de Avaliação.

Concluída a Prova de Conceito, a Equipe Técnica de Avaliação declarará encerrada a sessão, iniciando-se o prazo para elaboração e entrega ao pregoeiro do Relatório de julgamento da prova de conceito.

Aprovada a LICITANTE em avaliação, com consequente emissão do Relatório de julgamento da prova de conceito, o pregoeiro a declarará como vencedora, procedendo à abertura do prazo recursal e demais trâmites licitatórios legais.

Desclassificada a LICITANTE em avaliação, a próxima colocada será convocada para apresentação dos documentos de habilitação, proposta de preços e para participação da Prova de Conceito.

A LICITANTE EM AVALIAÇÃO que for reprovada na Prova de Conceito não terá direito a qualquer indenização.

15.4 PRAZOS:

A LICITANTE EM AVALIAÇÃO terá um prazo de até 02 (dois) dias úteis para preparar todo o ambiente necessário para a sua execução, em instalação própria.

Preparado o ambiente, a empresa terá até 03 (três) Dias úteis para comprovar o atendimento aos requisitos selecionados pela Prefeitura Municipal de Xxxxxx Xxxxxxx.

A Prefeitura Municipal de Xxxxxx Xxxxxxx divulgará o resultado em até 02 (dois) dias úteis após a conclusão da fase de demonstração. Este período poderá ser prorrogado mediante justificativa.

15.5 CRITÉRIOS DE AVALIAÇÃO:

Será considerada aprovada a LICITANTE EM AVALIAÇÃO que demonstrar atendimento a, no mínimo, 75% (Setenta e cinco por cento) dos requisitos descritos na Tabela de Requisitos Técnicos do Software - Anexo I-A deste Termo de Referência.

16 FISCALIZAÇÃO E GESTÃO:

A Fiscalização dos serviços será realizada pela Diretoria de Tecnologia da Informação, e a gestão do contrato será realizada pela Secretaria Municipal de Administração.

17 VISTORIA TÉCNICA:

É facultada a Licitante a realização de Vistoria Técnica.

Em caso de realização de Vistoria, a contratada deverá credenciar um funcionário para apresentar-se na sede da Prefeitura Municipal de Xxxxxx Xxxxxxx, munido de Carta de Credenciamento e documento de identificação.

Durante a vistoria, o representante credenciado pela empresa será acompanhado por um membro da Secretaria Municipal de Administração, e receberá o comprovante de sua visita técnica, fornecido pela Prefeitura Municipal de Xxxxxx Xxxxxxx.

A vistoria deverá ser previamente agendada junto à Secretaria Municipal de Administração, informando a razão social da empresa interessada, nº de inscrição no CNPJ/MF, endereço, telefone, e-mail, o nome e o nº da cédula de identidade da pessoa que fará a visita.

Não serão atendidas Licitantes que não efetuarem o agendamento.

18. REFERÊNCIA PARA ELABORAÇÃO DO TERMO DE REFERÊNCIA:

O presente Termo de Referência foi baseado nos documentos relacionados a seguir, e adaptado para as necessidades e especificidades da Prefeitura Municipal de Xxxxxx Xxxxxxx - ES:

• Edital de Pregão Eletrônico n° 45/2021, da Prefeitura Municipal de Cariacica; xxxxx://xxxxxxxxxxxxx.xxxxxxxxx.xx.xxx.xx/Xxxxxxxxx.Xxxxxxxx.xxxx?xxxxxxxxxXxx0&XxxxxxxxxXxx00000

• Edital de Pregão Eletrônico nº 000/0000, xx Xxxxxxxxxx Xxxxxxxxx xx Xxxx Xxxxxxxxx - XX; xxxxx://xxxxxxxxxx.xxx.xxx.xx/xxxxx/xxxxxxx/xxxxx/xxxxxxxxx-xx- governo/fazenda/licitacoes/licitacoes_fazenda_pe_2019004_editalV2_0.pdf

• CONARQ. e-ARQ Brasil. Modelo de Requisitos para Sistemas Informatizados de Gestão Arquivística de Documentos. 2. versão. Rio de Janeiro: Arquivo Nacional, 2020.

19 DÚVIDAS E AGENDAMENTOS:

Xxxxx Xxxxxxxx Xxxxxxx

Secretário Municipal de Administração

E-mail: xxxxxxxxxxxxx@xxxxxxxxxxxxx.xx.xxx.xx Tel.: 00 0000-0000

Aprovado por Secretaria de Administração.

ANEXO I-A

Esta seção consiste na descrição dos Requisitos Técnicos do Software a ser implementado na Contratante, organizados de acordo com os respectivos macroprocessos funcionais.

O software, objeto desta contratação, deverá atender aos requisitos transcritos no quadro abaixo, na seguinte conformidade:

CLASSIFICAÇÃO DO REQUISITO	PROVA DE CONCEITO
Requisitos Obrigatórios	75%
Requisitos Altamente Desejáveis	50%

A Contratada terá um prazo de 10 (dez) meses, contados a partir da conclusão da etapa de implantação, para atender 100% dos Requisitos Técnicos, classificados como “obrigatórios”.

Os requisitos estão organizados em tabela que é composta das seguintes informações:

a) ID: contém o código referente ao requisito técnico;

b) Categoria: contém a categoria do requisito técnico;

c) Descrição: contém a descrição do requisito que deve ser atendido pelo software;

d) Classificação: o requisito será classificado em: (O) “Obrigatório” e (AD) “Altamente Desejável”.

TABELA DE REQUISITOS TÉCNICOS DO SOFTWARE

Categoria

Requisito

Class.

Aspectos Gerais

O Software deverá ser do tipo “aplicação web”, acessado pelos

usuários através de navegadores (cliente) e executada em servidores de aplicação centralizados (servidor).

Aspectos Gerais

O Software deve ser compatível com, no mínimo, os navegadores Edge, Google Chrome e Mozilla Firefox.

Aspectos Gerais

O Software deve utilizar protocolo SMTP para integração com

serviços de correio eletrônico, com autenticação por meio de usuário e senha.

Aspectos Gerais

O Software deverá utilizar Banco de Dados Relacional para armazenamento e gerenciamento da base de dados produzida.

Aspectos Gerais

É altamente desejável que o Software permita a conexão do servidor de aplicação com o banco dedados, por meio de pool

de conexões.

Aspectos Gerais

É altamente desejável que os documentos que dependam de assinatura digital, o Software assine digitalmente, nos termos

dos requisitos definidos pela ICP-Brasil.

Funções administrativas

O Software tem que permitir que os administradores, de maneira controlada e sem esforço excessivo, recuperem, visualizem e

reconfigurem os parâmetros do sistema e os atributos dos usuários.

Funções administrativas

É altamente desejável que o Software forneça relatórios para que o administrador possa gerenciar os documentos e seu uso. Esses relatórios devem apresentar, no mínimo:

• quantidade de dossiês/processos, volumes e itens a partir de parâmetros ou atributos definidos (tempo, classe, unidade administrativa etc.);

• estatísticas de transações relativas a dossiês/processos, volumes e itens;

• atividades por usuário.

Usabilidade

É altamente desejável que toda mensagem de erro produzida pelo Software deve ser clara e significativa, de modo a permitir que o usuário se recupere do erro ou cancele a operação.

10.

Usabilidade

É altamente desejável que a interface do Software siga padrões preestabelecidos e consolidados como boas práticas de projeto

gráfico.

11.

Usabilidade

É altamente desejável que o Software empregue um conjunto simples e consistente de regras de interface, privilegiando a facilidade de aprendizado das operações pelos seus usuários.

12.

Usabilidade

O Software deve permitir que sua estrutura de classes e

dossiês/processos possa ser visualizada em diferentes formas de apresentação.

13.

Usabilidade

É altamente desejável que o Software permita a realização de transações ou tarefas mais frequentemente executadas com um

pequeno número de interações (por exemplo, cliques de mouse) e sem mudanças excessivas de contexto.

14.

Usabilidade

É altamente desejável que o Software permita a definição e utilização de referências cruzadas entre documentos arquivísticos digitais correlacionados.

15.

Usabilidade

É altamente desejável que o Software disponibilize pelo menos dois papéis de acesso diferenciados, um para usuário final e outro para administrador de sistema.

16.

Usabilidade

É altamente desejável que o Software forneça a usuários finais e administradores funções intuitivas e fáceis de usar, que requeiram poucas ações para completar uma tarefa padrão.

17.

Usabilidade

O Software tem que restringir o acesso às funcionalidades administrativas e impossibilitar sua visualização pelo usuário

final.

18.

Disponibilidade e Desempenho

É altamente desejável que o Software mantenha estatísticas dos tempos de atendimento, discriminadas por tipo de operação.

19.

Segurança da Informação

O Software não deverá permitir que exista identificadores de usuários (login) inscritos em qualquer parte do código do

programa ou arquivos auxiliares, à exceção dos logs de acesso e ações no sistema (trilha de auditoria).

20.

Segurança da Informação

O Software deverá apresentar a funcionalidade de controle de acesso por perfil de usuário com o objetivo de gerenciar e monitorar todas as operações do sistema.

21.

Segurança da Informação

É altamente desejável que o Software bloqueie o acesso a usuários não autorizados tenham qualquer acesso, formal (entrada através da página de login) ou informal (tentativa de acessar URL diretamentepelo browser).

22.

Segurança da Informação

O Software tem que garantir que as senhas de acesso não poderão estar escritas em qualquer parte do código do programa

ou arquivos auxiliares.

23.

Segurança da Informação

O Software tem que garantir que usuários que não tenham acesso a determinado conteúdo, que os mesmos não sejam mostrados em resultados de pesquisas, por exemplo, listas e índices.

24.

Segurança da Informação

O Software tem que garantir que os dados da trilha de auditoria

estarão protegidos contra falsificação e acesso não autorizado, não sendo permitida qualquer modificação nos registros.

25.

Segurança da Informação

O Software tem que assegurar a integridade e a confidencialidade das informações dos dados, monitorando por meio de registros de operações na trilha de auditoria, armazenando as seguintes informações:

• Identificação do usuário.

• Identificação da estação de trabalho (IP e agente do navegador).

• Identificação do tipo da transação (inclusão, consulta, alteração, exclusão, etc.).

• Identificação da funcionalidade do sistema que provocou a operação;

• Data, hora e detalhes de eventos-chave, como, por exemplo, horário de entrada (logon) e saída (logoff) do sistema.

26.

Configuração e administração do plano de classificação no Software

O Software tem que incluir e ser compatível com o plano de classificação da Contratante, e permitir o registro das seguintes informações:

• Identificador da classe;

• Nome da classe;

• Código da classe;

• Subordinação da classe;

• Indicação de permissão de uso;

• Indicação de classe ativa/inativa.

27.

Configuração e administração do plano de classificação no Software

O Software tem que garantir a criação de classes, subclasses, grupos e subgrupos nos níveis do plano de classificação de acordo com o método de codificação adotado. Por exemplo, quando se adotar o método decimal para codificação, cada classe pode ter no máximo dez subordinações, e assim

sucessivamente.

28.

Configuração e administração do plano de classificação no

Software

O Software tem que permitir a usuários autorizados acrescentar novas classes sempre que necessário.

29.

Configuração e administração do plano de classificação no Software

O Software tem que registrar a data de abertura de uma nova classe no respectivo metadado.

30.

Configuração e administração do plano de classificação no

Software

O Software tem que registrar a mudança de nome de uma classe já existente no respectivo metadado.

31.

Configuração e administração do plano de classificação no Software

O Software tem que permitir o deslocamento de uma classe inteira, incluídas as subclasses, grupo, subgrupos e documentos nela classificados, para outro ponto do plano de classificação.

Nesse caso, é necessário fazer o registro do deslocamento nos metadados do plano de classificação.

32.

Configuração e administração do plano

de classificação no Software

É altamente desejável que o Software permita que usuários autorizados tornem inativa uma classe em que não sejam mais classificados documentos.

33.

Configuração e administração do plano

de classificação no Software

O Software tem que permitir que um usuário autorizado apague uma classe inativa.

34.

Configuração e administração do plano de classificação no Software

O Software tem que impedir a eliminação de uma classe que tenha documentos nela classificados. Essa eliminação pode ocorrer a partir do momento em que todos os documentos ali classificados tenham sido recolhidos ou eliminados ou que esses documentos tenham sido reclassificados.

35.

Configuração e administração do plano de classificação no

Software

O Software tem que permitir a associação de metadados às classes, conforme estabelecido no padrão de metadados, e deve restringir a inclusão e alteração desses mesmos

metadados somente a usuários autorizados.

36.

Configuração e administração do plano de classificação no Software

O Software tem que disponibilizar pelo menos dois mecanismos de atribuição de identificadores a classes do plano de classificação, prevendo a possibilidade de se utilizar ambos, separadamente ou em conjunto, na mesma aplicação:

• atribuição de um código numérico ou alfanumérico;

• atribuição de um termo que identifique cada classe.

37.

Configuração e administração do plano de classificação no Software

É altamente desejável que o Software prever um atributo associado às classes para registrar a permissão de uso daquela classe para classificar um documento. Em algumas classes, não

é permitido incluir documentos. Nesse caso, os documentos devem ser classificados apenas nos níveis subordinados.

38.

Configuração e administração do plano de classificação no Software

O Software tem que utilizar o termo completo para identificar uma classe.

Entende-se por termo completo toda a hierarquia referente àquela classe.

39.

Configuração e administração do plano de classificação no

Software

O Software tem que assegurar que os termos completos, que identificam cada classe, sejam únicos no plano de classificação.

40.

Configuração e administração do plano

de classificação no Software

É altamente desejável que o Software seja capaz de importar e exportar, total ou parcialmente, um plano de classificação.

41.

Configuração e administração do plano de classificação no Software

O Software tem que prover funcionalidades para elaboração de relatórios de apoio à gestão do plano de classificação, incluindo a capacidade de:

• gerar relatório completo do plano de classificação;

• gerar relatório parcial do plano de classificação a partir de um ponto determinado na hierarquia;

• gerar relatório dos documentos ou processos/dossiês classificados em uma ou mais classes do plano de classificação;

• gerar relatório de documentos classificados por unidade administrativa.

42.

Configuração e administração do plano de classificação no

Software

É altamente desejável que o Software possibilite a consulta ao plano de classificação a partir de qualquer atributo ou combinação de atributos, e emita relatório com os resultados

obtidos.

43.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que prover funcionalidades para definição e manutenção de tabela de temporalidade e destinação de documentos, associada ao plano de classificação do órgão ou entidade.

44.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que manter tabela de temporalidade e destinação de documentos com as seguintes informações:

• identificador da classe;

• prazo de guarda na idade corrente:

• evento que determina o início de contagem do prazo de retenção na idade corrente;

• prazo de guarda na idade intermediária;

• evento que determina o início de contagem do prazo de retenção na idade intermediária;

• destinação final;

• observações.

45.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que prever, pelo menos, as seguintes situações para destinação:

• apresentação dos documentos para reavaliação em data futura;

• eliminação;

• exportação para transferência;

• exportação para recolhimento (guarda permanente).

46.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que prever a iniciação automática da contagem dos prazos de guarda referenciados na tabela de temporalidade e destinação de documentos, pelo menos, a partir dos seguintes eventos:

• abertura de processo/dossiê;

• arquivamento de processo/dossiê;

• desarquivamento de processo/dossiê;

• inclusão de documento sigiloso em um processo/dossiê, se aplicável.

Acontecimentos específicos, descritos na tabela de temporalidade e destinação como, por exemplo, “cinco anos a contar da data de aprovação das contas”, quando não puderem ser detectados automaticamente pelo sistema, deverão ser informados ao Software por usuário autorizado.

47.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que prever que a definição dos prazos de guarda seja expressa por:

• um número inteiro de meses ou

• um número inteiro de anos.

48.

Configuração da tabela de temporalidade e

destinação de documentos

O Software tem que limitar a definição e a manutenção (alteração, inclusão e exclusão) da tabela de temporalidade e destinação de documentos a usuários autorizados.

49.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que permitir que um usuário autorizado altere o prazo ou destinação prevista em um item da tabela de temporalidade e destinação de documentos e garantir que a alteração tenha efeito em todos os documentos ou processos/dossiês associados àquele item.

As alterações na tabela de temporalidade e destinação só poderão ser feitas como resultado de um processo de reavaliação realizado pela comissão de avaliação do órgão ou entidade em virtude de mudança do contexto administrativo, jurídico ou cultural.

50.

Configuração da tabela de temporalidade e destinação de documentos

É altamente desejável que o Software seja capaz de manter o histórico das alterações realizadas na tabela de temporalidade e destinação de documentos.

51.

Configuração da tabela de temporalidade e destinação de

documentos

É altamente desejável que o Software seja capaz de importar e exportar total ou parcialmente uma tabela de temporalidade e destinação de documento.

52.

Configuração da tabela de temporalidade e destinação de documentos

O Software tem que prover funcionalidades para elaboração de relatórios que apoiem a gestão da tabela de temporalidade e destinação, incluindo a capacidade de:

• gerar relatório completo da tabela de temporalidade e destinação de documentos;

• gerar relatório parcial da tabela de temporalidade e destinação de documentos a partir de um ponto determinado na hierarquia do plano de classificação;

• gerar relatório dos documentos ou processos/dossiês aos quais foi atribuído um determinado prazo de guarda;

• identificar as inconsistências existentes entre a tabela de temporalidade e destinação de documentos e o plano de classificação.

53.

Classificação e metadados das

unidades de arquivamento

O Software tem que permitir a classificação das unidades de arquivamento por Tipos de Unidade, segregadas em Tipo de Processos/Dossiês e Tipos de Documentos.

54.

Classificação e metadados das unidades de arquivamento

O Software tem que manter tabela de tipos de processo/dossiê com as seguintes informações:

• identificador do tipo de processo/dossiê;

• descrição do tipo de processo/dossiê;

• autor;

• classificação arquivística;

• status para poder atribuir numeração automática por tipo de processo/dossiês e ano;

• grupos de usuários com permissão para abertura de processos/dossiês;

• grupos de usuários com permissão para autuação de processos/dossiês;

• status para autorizar abertura de processos/dossiês por usuários externos;

• suporte do processo/dossiê: digital ou não digital;

• tipo de assinatura: Digital ou Eletrônica;

• número mínimo de assinaturas;

• grau de sigilo legal.

55.

Classificação e metadados das unidades de arquivamento

O Software tem que manter tabela de tipos de documento com as seguintes informações:

• identificador do tipo de documento;

• descrição do tipo de documento;

• autor;

• classificação arquivística;

• status de transmissão: minuta, original ou cópia;

• status para poder atribuir numeração automática por tipo de documento e ano;

• grupos de usuários com permissão para abertura de documentos;

• suporte do documento: digital ou não digital;

• tipo de assinatura: Digital ou Eletrônica;

• número mínimo de assinaturas;

• grau de sigilo legal.

56.

Classificação e metadados das unidades de

arquivamento

O Software deve efetuar o vínculo entre uma unidade de arquivamento e a classe através dos tipos de unidade de arquivamento, podendo ser pelo tipo de processo/dossiê ou pelo

tipo de documento.

57.

Classificação e metadados das unidades de arquivamento

O Software tem que permitir a classificação das unidades de arquivamento somente nas classes autorizadas.

58.

Classificação e metadados das unidades de

arquivamento

O Software tem que permitir a classificação de um número ilimitado de unidades de arquivamento dentro de uma classe, através dos tipos de unidade de arquivamento.

59.

Classificação e metadados das unidades de arquivamento

O Software tem que utilizar o termo completo da classe para identificar uma unidade de arquivamento.

60.

Classificação e metadados das unidades de arquivamento

O Software tem que permitir a associação de metadados aos tipos de unidades de arquivamento (tipos de processo/dossiê e tipos de documento) e deve restringir a inclusão e alteração desses metadados a usuários autorizados.

A alteração de metadado só deve ser realizada por correção de erro e registrado na trilha de auditoria.

61.

Classificação e metadados das unidades de

arquivamento

O Software tem que associar os metadados das unidades de arquivamento conforme estabelecido no padrão de metadados.

62.

Classificação e metadados das unidades de arquivamento

O Software tem que permitir a associação de um modelo de tipo de processo/dossiê para cada grupo de usuários.

Poderão compor um grupo de usuários: unidades administrativas, comissões, conselhos ou grupos de trabalho

estabelecidos pela Contratante.

63.

Classificação e metadados das unidades de arquivamento

O Software tem que permitir a associação de um usuário responsável para cada grupo de usuários, que também será o autor dos processos/dossiês e documentos produzidos pelo grupo.

64.

Classificação e metadados das unidades de

arquivamento

O Software tem que permitir a associação de um modelo de tipo de documento para cada grupo de usuários.

65.

Classificação e metadados das unidades de arquivamento

O Software tem que permitir que uma nova unidade de arquivamento herde, da classe em que foi classificada, através do Tipo de Unidades de Arquivamento, alguns metadados predefinidos.

Exemplos desta herança são prazos de guarda previstos na tabela de temporalidade e destinação e restrição de acesso.

66.

Classificação e metadados das unidades de arquivamento

O Software tem que relacionar os metadados herdados de forma que uma alteração no metadado de uma classe seja automaticamente incorporada à unidade de arquivamento que herdou esse metadado.

67.

Classificação e metadados das unidades de arquivamento

O Software tem que permitir que uma unidade de arquivamento e seus respectivos volumes e/ou documentos sejam reclassificados por um usuário autorizado e que todos os documentos já inseridos permaneçam nas unidades de arquivamento e nos volumes que estão sendo transferidos, mantendo a relação entre documentos, volumes e unidades de

arquivamento.

68.

Classificação e metadados das unidades de arquivamento

Quando uma unidade de arquivamento ou documento é reclassificado, é altamente desejável que o Software mantenha o registro de suas posições anteriores à reclassificação, de forma a manter um histórico, através da trilha de auditoria.

69.

Classificação e metadados das unidades de

arquivamento

Quando uma unidade de arquivamento ou documento é reclassificado, é altamente desejável que o Software permita que o administrador introduza as razões para a reclassificação.

70.

Classificação e metadados das unidades de arquivamento

É altamente desejável que o Software seja capaz de permitir que os usuários criem referências cruzadas para unidades de arquivamento afins.

71.

Classificação e metadados das

unidades de arquivamento

O Software tem que associar, automaticamente, ao processo/dossiê o prazo e a destinação previstos na classe em que o documento foi inserido.

72.

Captura

A captura tem que garantir a execução das seguintes funções:

• registrar e gerenciar todos os documentos não digitais;

• registrar e gerenciar todos os documentos digitais, independentemente do contexto tecnológico;

• classificar todos os documentos de acordo com o plano ou código de classificação;

• controlar e validar a introdução de metadados.

73.

Captura

O Software tem que ser capaz de capturar documentos digitais das formas a seguir:

• captura de documentos produzidos dentro do Software;

• captura de documento digital produzido fora do Software;

74.

Captura

É altamente desejável que administradores autorizados, possam configurar o software para só permitir a captura de documentos digitais produzidos fora do software, no formato PDF/A pesquisável.

75.

Captura

O Software tem que aceitar o conteúdo do documento, bem como as informações que definem sua aparência, mantendo as

associações entre os vários componentes digitais do documento.

76.

Captura

O Software tem que permitir a inserção de todos os metadados, obrigatórios e opcionais, definidos na sua configuração e garantir que se mantenham associados ao documento.

Os metadados obrigatórios são:

• nome do arquivo digital;

• id do documento (identificador do documento atribuído pelo Software);

• data de produção;

• data e hora de transmissão e recebimento;

• data e hora da captura;

• título;

• classe (classificação de acordo com o plano/código de classificação);

• prazos de guarda (idade corrente e idade intermediária);

• autor (pessoa física ou jurídica);

• redator (se diferente do autor);

• originador;

• destinatário;

• indicação de anotação;

• indicação de anexos;

• indicação de versão;

• níveis de acesso;

• registro das migrações e data em que ocorreram.

Os metadados opcionais se referem a informações mais

detalhadas sobre o documento, e podem criados por usuários autorizados.

77.

Captura

O Software tem que ser capaz de atribuir um número identificador a cada processo/dossiê e documento capturado, que serve para identificá-lo desde o momento da captura até sua

destinação final no Software.

78.

Captura

O Software tem que ser capaz de atribuir mais de um autor a cada processo/dossiê e documento capturado.

79.

Captura

O Software tem que ser capaz de permitir que determinados tipos de processos/dossiês, sejam autuados automaticamente, caso não haja pendência de assinatura eletrônica ou digital do autor.

80.

Captura

É altamente desejável que o Software permita ao autor, nos casos de atuação automática, definir o momento da autuação do processo/dossiê.

81.

Captura

O formato do número identificador atribuído pelo Software ao Documento deve ser definido no momento da configuração do Software.

O identificador pode ser numérico ou alfanumérico.

82.

Captura

No Software, o número identificador atribuído pelo sistema ao processo/dossiê tem que:

• ser gerado automaticamente, sendo vedada sua introdução manual e alteração posterior; ou

• ser atribuído pelo usuário e validado pelo Software antes de ser aceito.

83.

Captura

O Software tem que prever a adoção da numeração única de processos e/ou documentos oficiais de acordo com a legislação específica a fim de garantir a integridade do número atribuído ao processo no momento de sua autuação.

84.

Captura

É altamente desejável que o software utilize tesauro ou

vocabulário controlado para apoiar a atribuição do metadado assunto/descritor.

85.

Captura

O Software tem que garantir que os metadados associados a um documento sejam inseridos somente por usuários autorizados.

86.

Captura

O Software tem que garantir que os metadados associados a um documento sejam alterados somente por administradores e usuários autorizados e devidamente registrados em trilhas de auditoria.

87.

Captura

É altamente desejável que o Software seja capaz de inserir, automaticamente, os metadados previstos no Software para o maior número possível de documentos, pois isso diminui as tarefas do usuário do Software e garante maior rigor na inserção dos metadados.

Por exemplo, no caso de documentos com forma padronizada (formulários, modelos de requerimento, de memorando etc.), alguns metadados podem ser inseridos automaticamente, tais como número identificador, título, classificação, prazo de

guarda.

88.

Captura

O Software tem que garantir a visualização do registro de entrada do documento no sistema com todos os metadados inseridos automaticamente e os demais a serem atribuídos pelo usuário.

Por exemplo, o Software pode atribuir, automaticamente, o número identificador, a data de captura, o título, o originador, e requerer que o usuário preencha os demais metadados.

89.

Captura

O Software tem que garantir a inserção de outros metadados após a captura.

Por exemplo, data e hora de alteração e mudança de suporte.

90.

Captura

Sempre que um documento tiver mais de uma versão, o Software tem que permitir que os usuários selecionem pelo menos uma das seguintes ações:

• registrar todas as versões do documento como um só documento arquivístico; ou

• registrar uma única versão do documento como um documento arquivístico; ou

• registrar cada uma das versões do documento, separadamente, como um documento arquivístico.

91.

Captura

É altamente desejável que o Software preste assistência aos usuários no que diz respeito à classificação dos documentos, por meio de algumas ou de todas as ações a seguir:

• tornar acessível ao usuário somente o subconjunto do plano de classificação que diz respeito à sua atividade;/

• indicar as últimas classificações feitas pelo usuário;

• indicar dossiês que contenham documentos de arquivo relacionados;

• indicar classificações possíveis a partir dos metadados já inseridos, como, por exemplo, o título;

• indicar classificações possíveis a partir do conteúdo do documento.

92.

Captura

É altamente desejável que o Software permita a administradores autorizados, configurar o tamanho máximo dos arquivos que

serão capturados pelo software.

93.

Captura

No caso de documentos constituídos por mais de um componente digital, é altamente desejável que o Software efetue as seguintes ações:

• tratar o documento como uma unidade indivisível, assegurando a relação entre os componentes digitais;

• preservar a integridade do documento, mantendo a relação entre os componentes digitais;

• garantir a integridade do documento quando de sua recuperação, visualização e gestão posteriores;

• gerenciar a destinação de todos os componentes digitais que compõem o documento como uma unidade indivisível.

94.

Captura em lote

É altamente desejável que o Software proporcione a captura em lote de documentos gerados por outros sistemas.

Esse procedimento tem que:

• permitir a importação de transações predefinidas de arquivos em lote;

• registrar automaticamente cada um dos documentos importados contidos no lote;

• permitir e controlar a edição do registro dos documentos importados;

• validar a integridade dos metadados.

Exemplos de lotes de documento: mensagens de correio eletrônico, correspondência digitalizada por meio de escâner, documentos provenientes de um departamento, grupo ou indivíduo, transações de aplicações de um computador ou, ainda, documentos oriundos de um sistema de gestão de

documentos ou sistema de negócio.

95.

Captura de documentos não digitais ou híbridos

O Software tem que ser capaz de capturar também os documentos não digitais e/ou híbridos.

96.

Captura de documentos não digitais ou híbridos

O Software tem que acrescentar aos metadados dos documentos não digitais informações sobre sua localização.

Essa informação só será acessada por usuários autorizados.

97.

Formato de arquivo e estrutura dos documentos a serem capturados

O Software tem que possuir a capacidade de capturar documentos com diferentes formatos de arquivo e estruturas.

98.

Formato de arquivo e estrutura dos documentos a serem capturados

É altamente desejável que o Software possa capturar, entre outros, os documentos a seguir:

• calendários eletrônicos;

• informações de outros aplicativos – contabilidade, folha de pagamento, desenho assistido por computador (CAD);

• documentos em papel digitalizados por meio de escâner;

• documentos sonoros;

• videoclipes;

• diagramas e mapas digitais;

• dados estruturados (EDI);

• bases de dados;

• documentos multimídia.

99.

Formato de arquivo e estrutura dos documentos a serem

capturados

O Software tem que ser capaz de incluir novos formatos de arquivos à medida que forem sendo adotados pela Contratante.

100.

Formato de arquivo e estrutura dos

documentos a serem capturados

O Software tem que ser capaz de registrar em metadados as informações relativas à dependência de software, quando

capturar documentos em formatos diferentes dos previstos pelo programa de gestão de documentos do órgão ou entidade.

101.

Estrutura dos procedimentos de gestão

O Software tem que ser capaz de reconhecer três domínios para o controle dos procedimentos de trâmite de processos/dossiês: espaço individual, espaço do grupo e espaço do responsável pelo grupo.

102.

Estrutura dos procedimentos de

gestão

O Software tem que ser capaz de operacionalizar as regras estabelecidas pelo Software nos três espaços, ao efetuar o

trâmite de processos/dossiês.

103.

Estrutura dos procedimentos de gestão

O Software tem que impedir que o conteúdo de um documento seja alterado por usuários e administradores, exceto se a alteração fizer parte do processo documental, tais como: corrigir erros de usuário (p. ex., declarar documentos de arquivo no

processo/dossiê errado) ou para cumprir requisitos jurídicos no âmbito da legislação sobre proteção de dados.

104.

Estrutura dos procedimentos de gestão

É altamente desejável que o Software possa emitir um aviso caso se tente capturar um documento incompleto ou inconsistente a ponto de comprometer sua futura autenticidade.

Por exemplo, uma correspondência sem assinatura digital válida ou uma fatura de fornecedor não identificado.

105.

Estrutura dos procedimentos de

gestão

É altamente desejável que o Software possa emitir um aviso caso se tente capturar um documento cuja autenticidade não

possa ser verificada no futuro.

106.

Aplicação da tabela de temporalidade e destinação de documentos

O Software tem que fornecer recursos integrados à tabela de temporalidade e destinação de documentos para implementar as ações de destinação.

O Software tem que prever a iniciação automática da contagem dos prazos de guarda referenciados na tabela de temporalidade e destinação de documentos, pelo menos, a partir dos seguintes eventos:

107.

Aplicação da tabela de temporalidade e

destinação de documentos

Para cada processo/dossiê, o Software tem que acompanhar automaticamente os prazos de guarda determinados para a

classe à qual pertence, nos casos de contagem de prazos automáticos.

108.

Aplicação da tabela de temporalidade e destinação de documentos

Para cada processo/dossiê, que não possua contagem de prazo automática, o Software tem que permitir a usuários autorizados, informar manualmente os prazos de guarda.

109.

Aplicação da tabela de temporalidade e destinação de

documentos

O Software tem que prover consulta para informar ao usuário autorizado sobre os documentos ou processos/dossiês que já cumpriram ou estão para cumprir o prazo de guarda previsto.

110.

Aplicação da tabela de temporalidade e destinação de documentos

O Software tem de prover funcionalidades para gerenciar o processo de destinação, que tem de ser iniciado por usuário autorizado e cumprir os seguintes passos:

• identificar, através de consulta, os documentos ou processos/dossiês que atingiram os prazos de guarda previstos;

• informar o usuário autorizado sobre todos os documentos ou processos/dossiês que foram identificados no passo anterior, através de um memorando eletrônico;

• possibilitar a alteração do prazo ou destinação previstos para aqueles documentos ou processos/dossiês, caso necessário;

• proceder à ação de destinação quando confirmada pelo usuário autorizado.

111.

Aplicação da tabela de temporalidade e destinação de documentos

O Software tem sempre que pedir confirmação antes de realizar as ações de destinação.

112.

Aplicação da tabela de temporalidade e destinação de documentos

É altamente desejável que o Software preveja, em determinados casos, dispositivo de aviso antes do início de uma ação de destinação.

Por exemplo, emitir aviso ao administrador, caso um documento arquivístico possua restrição de acesso.

113.

Aplicação da tabela de temporalidade e

destinação de documentos

O Software tem que restringir as funções de destinação a usuários autorizados.

114.

Aplicação da tabela de temporalidade e destinação de documentos

Quando um administrador transfere documentos ou processos/dossiês de uma classe para outra, em virtude de uma reclassificação, o Software tem que adotar automaticamente a temporalidade e a destinação vigentes na nova classe.

115.

Exportação de documentos

O Software tem que ser capaz de exportar documentos e

processos/dossiês digitais e seus metadados para outro sistema dentro ou fora do órgão ou entidade.

116.

Exportação de documentos

Quando o Software exportar os documentos e processos/dossiês de uma classe para executar uma ação de transferência ou recolhimento, tem que ser capaz de exportar todos os documentos

e processos/dossiês da classe incluídos na ação de destinação, com seus respectivos volumes, documentos e

metadados associados.

117.

Exportação de documentos

É altamente desejável que o Software seja capaz de exportar um documento e processo/dossiê ou grupo de documentos e processos/dossiês numa sequência de operações, de modo que:

• o conteúdo, o contexto e a estrutura dos documentos não se degradem;

• todos os componentes de um documento digital sejam exportados como uma unidade. Por exemplo, uma mensagem de correio eletrônico e seus respectivos anexos;

• todos os metadados do documento sejam relacionados a ele de forma que as ligações possam ser mantidas no novo sistema;

• todas as ligações entre documentos, volumes e processos/dossiês sejam mantidas.

118.

Exportação de documentos

É altamente desejável que o Software seja capaz de exportar processos/dossiês:

• em seu formato nativo (ou no formato para o qual foi migrado);

• de acordo com os formatos definidos em padrões de interoperabilidade;

• de acordo com o formato definido pela instituição arquivística que irá receber a documentação, no caso de transferência ou

recolhimento.

119.

Exportação de documentos

O Software tem que ser capaz de exportar todos os tipos de documentos que está apto a capturar.

120.

Exportação de documentos

O Software tem que produzir um relatório detalhado sobre qualquer falha que ocorra durante uma exportação. O relatório tem que identificar os documentos e processos/dossiês que originaram erros de processamento ou cuja exportação não

tenha sido bem-sucedida.

121.

Exportação de documentos

O Software tem que conservar todos os documentos e processos/dossiês digitais que foram exportados, pelo menos

até que tenham sido importados no sistema destinatário com êxito.

122.

Exportação de documentos

O Software tem que manter metadados relativos a documentos e processos/dossiês que foram exportados.

O Administrador deve indicar o subconjunto de metadados que deverá ser mantido.

123.

Exportação de documentos

O Software tem que gerar listagem para descrever documentos e processos/dossiês digitais que estão sendo exportados.

Este requisito se aplica principalmente nos casos em que é feita exportação para transferência ou recolhimento a uma instituição arquivística pública. Nesse caso, a listagem deverá ser produzida

na forma documental estabelecida pela instituição arquivística recebedora.

124.

Exportação de documentos

É altamente desejável que o Software possibilite a inclusão de metadados necessários à gestão do arquivo permanente nos documentos e processos/dossiês que serão exportados para recolhimento.

125.

Exportação de documentos

Quando se exportar documentos e processos/dossiês híbridos, é altamente desejável que o Software exija do usuário autorizado a confirmação de que a parte na forma não digital dos mesmos documentos e processos/dossiês tenha passado pelo procedimento de destinação adequado antes de confirmar a

exportação da parte na forma digital.

126.

Exportação de documentos

É altamente desejável que o Software permita que documentos sejam exportados mais de uma vez.

127.

Eliminação

O Software tem que restringir a função de eliminação de

documentos ou processos/dossiês somente a usuários autorizados.

128.

Eliminação

O Software tem que pedir confirmação da eliminação a um usuário autorizado antes que qualquer ação seja tomada com relação ao documento e processo/dossiê e cancelar o processo de eliminação se a confirmação não for dada.

129.

Eliminação

O Software tem que impedir sempre a eliminação de uma unidade de arquivamento digital ou de qualquer parte de seu conteúdo, a não ser quando estiver de acordo com a tabela de temporalidade e destinação de documentos.

A eliminação será devidamente registrada em trilha de auditoria.

130.

Eliminação

O Software tem que avisar o usuário autorizado quando um documento ou processo/dossiê que estiver sendo eliminado se encontrar relacionado a outro; os sistemas também têm de suspender o processo até que seja tomada uma das medidas abaixo:

• confirmação pelo usuário autorizado para prosseguir ou cancelar o processo;

• produção de um relatório especificando os documentos ou processos/dossiês envolvidos e todas as ligações com outros

documentos ou processos/dossiês.

131.

Eliminação

É altamente desejável que o Software permita a eliminação de documentos ou processos/dossiês de forma irreversível a fim de que não possam ser restaurados por meio da utilização normal do

Software nem por meio de rotinas auxiliares do sistema operacional nem por aplicações especiais de recuperação de dados.

132.

Eliminação

Quando um documento tem várias referências armazenada, o Software tem que garantir que todas essas referências sejam verificadas antes de eliminar o arquivo digital.

Esse requisito deve ser considerado quando o Software relacionar um documento digital a mais de um dossiê ou processo, sem a duplicação física do arquivo digital.

Por exemplo, uma lista de alunos aprovados em um concurso de doutorado de determinada universidade estará associada ao dossiê “Concurso doutorado 2005” e aos dossiês de cada aluno aprovado.

Quando um documento digital estiver associado a mais de um dossiê, o Software deve criar um registro para cada referência

desse documento. Cada registro estará vinculado ao mesmo arquivo digital.

133.

Eliminação

O Software tem que produzir um relatório detalhando qualquer falha que ocorra durante uma eliminação. O relatório tem que

identificar os documentos cuja eliminação não tenha sido bem- sucedida.

134.

Eliminação

Quando eliminar documentos ou processos/dossiês híbridos, é altamente desejável que o Software exija do usuário autorizado a confirmação de que a parte na forma não digital dos mesmos seja eliminada também antes de confirmar a eliminação da parte

digital.

135.

Eliminação

O Software tem que gerar relatório com os documentos e processos/dossiês que serão eliminados.

Essa listagem deve seguir o formato da Listagem de eliminação conforme o estabelecido na norma vigente.

136.

Eliminação

O Software tem que manter metadados relativos a documentos e processos/dossiês eliminados. O Administrador deve indicar o subconjunto de metadados que

deverá ser mantido.

137.

Avaliação e destinação de documentos arquivísticos não digitais e híbridos

O Software tem que aplicar a mesma tabela de temporalidade e destinação de documentos para os documentos não digitais, digitais ou híbridos.

138.

Avaliação e destinação de documentos arquivísticos não

digitais e híbridos

O Software tem que acompanhar os prazos de guarda dos documentos não digitais e deve dar início aos procedimentos de eliminação ou transferência desses documentos, tomando em

consideração suas especificidades.

139.

Avaliação e destinação de documentos arquivísticos não digitais e híbridos

O Software tem que alertar o administrador sobre a existência e a localização de uma parte não digital associada a um documento híbrido que esteja destinado a ser exportado, transferido ou

eliminado.

140.

Avaliação e destinação de documentos arquivísticos não digitais e híbridos

É altamente desejável que o Software exporte metadados de documentos e processos/dossiês não digitais.

141.

Pesquisa, localização,

visualização e impressão

O Software tem que fornecer facilidades para pesquisa, localização e apresentação dos documentos.

142.

Pesquisa, localização, visualização e

impressão

O Software tem que disponibilizar interface de pesquisa, localização e apresentação em ambiente web.

143.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software preveja a navegação gráfica no plano de classificação, a navegação direta de uma classe para os documentos arquivísticos produzidos nesta classe e a seleção, recuperação e apresentação direta dos documentos arquivísticos e de seus conteúdos por meio desse

mecanismo.

144.

Pesquisa, localização, visualização e impressão

O Software tem que fornecer uma série flexível de funções que atuem sobre os metadados relacionados com os diversos níveis de agregação (documento, unidade de arquivamento e classe) e sobre os conteúdos dos documentos arquivísticos por meio de parâmetros definidos pelo usuário, com o objetivo de localizar e

acessar os documentos e/ou metadados, seja individualmente ou reunidos em grupo.

145.

Pesquisa, localização, visualização e impressão

O Software tem que executar pesquisa de forma integrada, isto é, apresentar todos os documentos e processos/dossiês, sejam eles digitais, híbridos ou não digitais, que satisfaçam aos

parâmetros da pesquisa.

146.

Pesquisa, localização, visualização e

impressão

O Software em que permitir que todos os metadados de gestão de um documento ou processo/dossiê possam ser pesquisados.

147.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita que o conteúdo dos documentos possa ser pesquisado.

148.

Pesquisa, localização, visualização e impressão

O Software tem que permitir que um documento ou processo/dossiê possa ser recuperado por meio de um número identificador.

149.

Pesquisa, localização, visualização e impressão

O Software tem que permitir que um documento ou processo/dossiê possa ser recuperado por meio de todas as formas de identificação implementadas, incluindo, no mínimo:

• identificador;

• título;

• assunto;

• datas;

• interessado;

• autor/redator /originador;

• classificação de acordo com plano ou código de classificação.

150.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software forneça uma interface que possibilite a pesquisa combinada de metadados e de conteúdo

do documento por meio dos operadores booleanos “e”, “ou” e “não”.

151.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita que os termos utilizados na pesquisa possam ser qualificados, especificando-

se um metadado ou o conteúdo do documento como fonte de busca.

152.

Pesquisa, localização, visualização e impressão

O Software tem que permitir a consulta de processos/dossiês com prazo da atividade “vencido” ou “a vencer”.

153.

Pesquisa, localização,

visualização e impressão

É altamente desejável que o Software permita o uso de períodos

típicos de pedidos de pesquisa nos campos de data, como, por exemplo, “semana anterior”, “mês corrente”.

154.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita a utilização de caracteres curinga e de truncamento à direita para pesquisa de metadados.

155.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita que os usuários refinem pesquisas já realizadas.

156.

Pesquisa, localização,

visualização e impressão

É altamente desejável que o Software permita que o usuário

marque um processo/dossiê, resultado de uma consulta, como “favoritos”, para pesquisas futuras.

157.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software utilize tesauros ou vocabulário controlado, e seja capaz de realizar pesquisa dos documentos e processos/dossiês por meio da navegação nesses instrumentos.

158.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita a pesquisa de termos já em desuso, fazendo relação com os termos atualizados, com o apoio de um tesauro ou vocabulário controlado, caso

existam.

159.

Pesquisa, localização, visualização e impressão

O Software tem que permitir a pesquisa e recuperação de uma unidade de arquivamento completa e exibir a lista de todos os

documentos que a compõem, como uma unidade e num único processo de recuperação.

160.

Pesquisa, localização, visualização e impressão

O Software deve ser capaz de mostrar o conteúdo de um processo/dossiê no formato de uma estrutura de árvore, permitindo que o usuário selecione o documento que será

visualizado.

161.

Pesquisa, localização, visualização e impressão

O Software tem que limitar o acesso a qualquer informação (metadado ou conteúdo de um documento arquivístico) se restrições de acesso e questões de segurança assim determinarem.

162.

Pesquisa, localização, visualização e impressão

O Software tem que apresentar o resultado da pesquisa como uma lista de documentos e processos/dossiês digitais, não digitais ou híbridos que cumpram os parâmetros da consulta e

deve notificar o usuário se o resultado for nulo.

163.

Pesquisa, localização, visualização e impressão

Após apresentar o resultado da pesquisa, o Software tem que oferecer ao usuário as opções:

• visualizar os documentos e processos/dossiês resultantes da pesquisa;

• redefinir os parâmetros de pesquisa e fazer nova consulta.

164.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita que os documentos e processos/dossiês apresentados em uma lista de

resultados sejam selecionados e, em seguida, abertos por meio de um clique ou toque de tela ou acionamento de tecla.

165.

Pesquisa, localização, visualização e impressão

No resultado da consulta de processos/dossiês, é altamente desejável que o Software permita que o usuário, por meio de um clique ou toque de tela ou acionamento de tecla, possa visualizar apenas a relação dos documentos que estejam entranhados ao

processo/dossiê selecionado.

166.

Pesquisa, localização, visualização e impressão

No resultado da consulta de documentos, é altamente desejável que o Software permita que o usuário, por meio de um clique ou toque de tela ou acionamento de tecla, visualize apenas a

relação dos processos/dossiês que o documento selecionado esteja entranhado.

167.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita a visualização do trâmite de um processo/dossiê, nos seguintes formatos:

• no formato de “lista”, contendo a atividade, ação, data e quem realizou a operação;

• no formato de “linha do tempo”, contendo a atividade, data e quem realizou a operação e o tempo gasto para a realização do trâmite;

Nos dois formatos é altamente desejável visualizar o despacho proferido pelo usuário que efetuou o trâmite.

168.

Pesquisa, localização,

visualização e impressão

É altamente desejável que o Software permita a visualização do

diagrama BPMN em cada registro do trâmite de um processo/dossiê.

169.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software forneça recursos que permitam ao usuário “navegar” para o nível de agregação imediatamente superior ou inferior, como, por exemplo:

• de um documento para a unidade de arquivamento em que está incluído;

• de uma unidade de arquivamento para os documentos nela incluídos;

• de uma unidade de arquivamento para a respectiva classe;

• de uma classe para as unidades de arquivamento a ela relacionadas.

170.

Pesquisa, localização, visualização e impressão

O Software tem que ser capaz de apresentar o conteúdo de todos os documentos arquivísticos digitais definidos pelo programa de gestão de documentos, de forma que:

• preserve as características de exibição visual e de formato apresentados pela aplicação geradora;

• exiba todos os componentes do documento digital em conjunto, como uma unidade.

No caso de necessidade de captura de documentos em formatos de arquivo não previstos no programa de gestão de documentos, o Software tem que permitir o download do documento para que

possa ser visualizado em outro ambiente.

171.

Pesquisa, localização, visualização e impressão

O Software tem que ser capaz de exibir em tela todos os documentos definidos pelo programa de gestão de documentos.

No caso de necessidade de captura de documentos em formatos de arquivo não previstos no programa de gestão de documentos,

o Software tem que permitir o download do documento para que possa ser visualizado em outro ambiente.

172.

Pesquisa, localização, visualização e impressão

O Software tem que ser capaz de imprimir os documentos definidos pelo programa de gestão de documentos, preservando o formato produzido pelas aplicações geradoras.

No caso de necessidade de captura de documentos em formatos de arquivo não previstos no programa de gestão de documentos, o Software tem que permitir o download do documento para que possa ser visualizado em outro ambiente.

173.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software seja capaz de exibir/reproduzir o conteúdo de documentos que incluam imagem fixa, imagem em movimento e som.

174.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software proporcione ao usuário formas flexíveis de impressão de documentos com seus metadados e possibilitar a definição dos metadados a serem

impressos.

175.

Pesquisa, localização, visualização e impressão

O Software tem que ser capaz de exibir em tela e imprimir todos os metadados associados aos documentos e processos/dossiês resultantes de uma pesquisa.

176.

Pesquisa, localização, visualização e impressão

O Software tem que ser capaz de permitir que o usuário informe a quantidade de registros pré-definidos que serão mostrados no

resultado das consultas de processos/dossiês e documentos por tela.

177.

Pesquisa, localização, visualização e impressão

O Software tem que permitir a impressão de uma lista dos documentos e processos/dossiês resultantes de uma pesquisa.

178.

Pesquisa, localização,

visualização e impressão

O Software tem que permitir a impressão dos trâmites que compõem um processo/dossiê selecionado em uma consulta.

179.

Pesquisa, localização, visualização e impressão

O Software tem que permitir a impressão de etiqueta para identificação de processos/dossiês que estejam no suporte não digital.

180.

Pesquisa, localização, visualização e impressão

O Software tem que permitir que todos os documentos de um processo/dossiês sejam impressos em uma ou mais operações.

181.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software inclua recursos destinados a transferir para suportes adequados documentos que não possam ser impressos, tais como documentos sonoros, vídeos e páginas web.

182.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software seja capaz de exportar o resultado das consultas de processos/dossiês e documentos para, no mínimo, os seguintes formatos:

• formato .XLS;

• formato .CSV;

• formato .RTF.

183.

Pesquisa, localização,

visualização e impressão

O Software tem que ser capaz de realizar pesquisa e exibição

de documentos e processos/dossiês, simultaneamente, para diversos usuários.

184.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software permita ao administrador determinar que todas as cópias em papel de documentos e

processos/dossiês sejam impressas junto com metadados pré- selecionados.

185.

Pesquisa, localização, visualização e impressão

É altamente desejável que o Software seja capaz de permitir que um usuário envie o link para acesso de um processo/dossiê por e-mail.

186.

Pesquisa, localização, visualização e

impressão

O Software tem que permitir automatização da produção automática de documentos, para os tipos de processo e tipos de

documento, mesclando o modelo com os metadados.

187.

Gerenciamento dos documentos

O Software tem que prever a produção de documentos do tipo “circular eletrônica” controlando no mínimo as seguintes informações:

• identificador;

• referência;

• data;

• autor;

• destinatários internos;

• atribuir marcação de urgência.

188.

Gerenciamento dos documentos

O Software tem que impedir o envio de documentos do tipo “circular eletrônica” aos destinatários, caso haja pendência de

assinatura eletrônica ou digital do autor.

189.

Gerenciamento dos documentos

O Software tem que garantir a notificação por e-mail a todos os destinatários que receberam documentos do tipo “circular eletrônica”.

190.

Gerenciamento dos documentos

O Software tem que mudar o status de visualização como “lida” quando o destinatário acessar o documento, do tipo “circular

eletrônica”, armazenando ainda a data, hora e o usuário que visualizou.

191.

Gerenciamento dos documentos

O Software tem que disponibilizar consulta ao autor, contendo o status de visualização dos documentos do tipo “circular interna”, enviados ao destinatário.

192.

Gerenciamento dos documentos

O Software tem que prever a produção de documentos do tipo “memorando eletrônico” controlando no mínimo as seguintes informações:

• identificador;

• referência;

• data;

• autor;

• destinatário interno;

• atribuir marcação de urgência.

193.

Gerenciamento dos documentos

O Software tem que impedir o envio de documentos do tipo “memorando eletrônico” aos destinatários, caso haja pendência de assinatura eletrônica ou digital do autor.

194.

Gerenciamento dos documentos

O Software tem que garantir a notificação por e-mail ao destinatário que recebeu documento do tipo “memorando eletrônico”.

195.

Gerenciamento dos documentos

O Software tem que mudar o status de visualização como “lida” quando o destinatário acessar o documento, do tipo “memorando eletrônico”, armazenando ainda a data, hora e o

usuário que visualizou.

196.

Gerenciamento dos documentos

O Software tem que disponibilizar consulta ao autor, contendo o status de visualização dos documentos do tipo “memorando eletrônico”, enviados ao destinatário.

197.

Gerenciamento dos documentos

O Software tem que prever a produção de documentos do tipo “ofício externo eletrônico” controlando no mínimo as seguintes informações:

• identificador;

• referência;

• data;

• autor;

• destinatário externo;

• atribuir marcação de urgência.

198.

Gerenciamento dos documentos

O Software tem que impedir o envio de documentos do tipo “ofício externo eletrônico” aos destinatários, caso haja pendência de assinatura eletrônica ou digital do autor.

199.

Gerenciamento dos documentos

O Software tem que garantir a notificação por e-mail ao

destinatário que recebeu documento do tipo “ofício externo eletrônico”.

200.

Gerenciamento dos documentos

O Software tem que mudar o status de visualização como “lida” quando o destinatário acessar o documento, do tipo “ofício

externo eletrônico”, armazenando ainda a data, hora e o usuário que visualizou.

201.

Gerenciamento dos documentos

O Software tem que disponibilizar consulta ao autor, contendo o status de visualização dos documentos do tipo “ofício externo eletrônico”, enviados ao destinatário.

202.

Gerenciamento dos documentos

O Software tem que prever a produção de documentos do tipo “ato normativo compilado” controlando no mínimo as seguintes informações:

• identificador;

• espécie normativa;

• ementa;

• data do ato normativo;

• situação da vigência;

• autor;

203.

Gerenciamento dos documentos

O Software tem que permitir a associação de assuntos a um determinado documento classificado como ato normativo.

204.

Gerenciamento dos documentos

É altamente desejável que o Software utilize tesauro ou

vocabulário controlado para apoiar a atribuição do metadado ementa do ato normativo.

205.

Gerenciamento dos documentos

O Software tem que permitir a associação de remissões a um determinado documento classificado como ato normativo.

206.

Gerenciamento dos documentos

O Software tem que garantir a anexação de um arquivo em formato PDF/A, editável, a um ato normativo.

207.

Gerenciamento dos documentos

O Software tem que garantir a anexação de um arquivo em formato HTML, editável, contendo todas as marcações de remissão a um ato normativo.

208.

Gerenciamento dos documentos

O Software tem que permitir que um ato normativo possa ser recuperado por meio de todas as formas de identificação implementadas, incluindo, no mínimo:

• identificador;

• espécie normativa;

• ementa;

• ano;

• situação da vigência;

• autor;

• tema;

• tesauro;

209.

Gerenciamento dos documentos

É altamente desejável que o Software seja capaz de exportar o resultado das consultas de atos normativos para, no mínimo, os seguintes formatos:

• formato .XLS;

• formato .CSV;

• formato .RTF.

210.

Gerenciamento dos documentos

O Software tem que ser capaz de realizar pesquisa e exibição de atos normativos, simultaneamente, para diversos usuários.

211.

Gerenciamento dos documentos

O Software tem que ser capaz de permitir que o usuário informe

a quantidade de registros pré-definidos que serão mostrados no resultado das consultas de atos normativos.

212.

Gerenciamento dos documentos

O Software tem que ser capaz de permitir que o usuário informe a quantidade de registros pré-definidos que serão mostrados no resultado das consultas de atos normativos.

213.

Gerenciamento dos documentos

É altamente desejável que o Software permita que os atos normativos apresentados em uma lista de resultados sejam

selecionados e, em seguida, abertos por meio de um clique ou toque de tela ou acionamento de tecla.

214.

Gerenciamento dos documentos

Após apresentar o resultado da pesquisa, o Software tem que oferecer ao usuário as opções:

• visualizar os atos normativos resultantes da pesquisa;

• redefinir os parâmetros de pesquisa e fazer nova consulta.

215.

Gerenciamento dos documentos

É altamente desejável que o Software permita que os arquivos anexados ao ato normativo, sejam selecionados e, em seguida,

abertos por meio de um clique ou toque de tela ou acionamento de tecla.

216.

Gerenciamento dos processos/dossiês

O Software tem que registrar nos metadados as datas de abertura e de encerramento do processo/dossiê.

Essa data pode servir de parâmetro para aplicação dos prazos de guarda e destinação do processo/dossiê.

217.

Gerenciamento dos processos/dossiês

O Software tem que emitir um aviso caso o usuário tente registrar um documento que já tenha sido registrado no mesmo

processo/dossiê.

218.

Gerenciamento dos processos/dossiês

O Software tem que permitir que um processo/dossiê seja encerrado por meio de procedimentos regulamentares e somente por usuários autorizados.

219.

Gerenciamento dos processos/dossiês

O Software tem que permitir a consulta aos processos/dossiês já encerrados por usuários autorizados.

220.

Gerenciamento dos processos/dossiês

O Software tem que impedir o acréscimo de novos documentos a processos/dossiês já encerrados.

Processos/dossiês encerrados devem ser reabertos para receber novos documentos.

221.

Gerenciamento dos processos/dossiês

O Software tem que garantir sempre a integridade da relação hierárquica entre classe, processo/dossiê, volume e documento, independentemente de atividades de manutenção, ações do usuário ou falha de componentes do Software.

Em hipótese alguma pode o Software permitir que uma ação do

usuário ou uma falha do Software dê origem a inconsistência em sua base de dados.

222.

Gerenciamento dos processos/dossiês

O Software tem que prever a formação/autuação de processos/dossiês, por usuário autorizado conforme

estabelecido em legislação específica.

223.

Gerenciamento dos processos/dossiês

O Software tem que prever a formação/autuação de processo/dossiê, do tipo acessório, vinculado a um processo/dossiê, do tipo principal, para garantir a inter-relação e rastreabilidade entre eles.

224.

Gerenciamento dos processos/dossiês

É altamente desejável que o Software preveja funcionalidades para apoiar a pesquisa sobre a existência de processo relativo à

mesma ação ou interessado.

225.

Gerenciamento dos processos/dossiês

O Software tem que prever que os documentos integrantes do processo digital recebam numeração sequencial sem falhas por ordem de entranhamento, não se admitindo que documentos diferentes recebam a mesma numeração.

226.

Gerenciamento dos processos/dossiês

O Software tem que impedir a renumeração dos documentos integrantes de um processo digital.

Este requisito tem por objetivo impedir a exclusão não autorizada de documentos de um processo. Casos especiais que autorizem a renumeração, como no caso dos documentos do processo

acessório na juntada por anexação, devem obedecer à legislação específica na devida esfera e âmbito de competência.

227.

Gerenciamento dos processos/dossiês

O Software tem que prever procedimentos para juntada de processos segundo a legislação específica na devida esfera e âmbito de competência. A juntada pode ser por anexação ou apensação.

Este procedimento deve ser registrado nos metadados do processo.

228.

Gerenciamento dos processos/dossiês

O Software tem que prever procedimentos para desapensação de processos segundo a legislação específica na devida esfera e âmbito de competência.

Esse procedimento deve ser registrado nos metadados do processo.

229.

Gerenciamento dos processos/dossiês

O Software tem que prever procedimentos para desentranhamento de documentos integrantes de um processo, segundo norma específica na devida esfera e âmbito de competência.

Esse procedimento deve ser registrado nos metadados do processo.

230.

Gerenciamento dos processos/dossiês

O Software tem que prever procedimentos para desmembramento de documentos integrantes de um processo,

segundo norma específica na devida esfera e âmbito de competência.

Esse procedimento deve ser registrado nos metadados do processo.

231.

Gerenciamento dos processos/dossiês

O Software tem que prever o encerramento dos processos incluídos seus volumes e metadados.

232.

Gerenciamento dos processos/dossiês

O Software tem que prever o desarquivamento para reativação dos processos, por usuário autorizado e obedecendo a procedimentos legais e administrativos.

Para manter a integridade do processo, somente o último volume receberá novos documentos ou peças.

233.

Volumes: abertura, encerramento e

metadados

É altamente desejável que o Software seja capaz de gerenciar volumes para subdividir processos/dossiês, fazendo a distinção

entre processos/dossiês e volumes.

234.

Volumes: abertura, encerramento e metadados

É altamente desejável que o Software permita a associação de metadados aos volumes e restringir a inclusão e alteração desses metadados a usuários autorizados.

235.

Volumes: abertura, encerramento e metadados

O Software tem que permitir que um volume herde, automaticamente, do processo/dossiê ao qual pertence, alguns

metadados predefinidos, como, por exemplo, classes e temporalidade.

236.

Volumes: abertura, encerramento e metadados

O Software tem que permitir a abertura de volumes para qualquer processo/dossiê que não esteja encerrado.

237.

Volumes: abertura, encerramento e metadados

É altamente desejável que o Software permita o registro de metadados correspondentes às datas de abertura e encerramento de volumes.

238.

Volumes: abertura, encerramento e

metadados

O Software tem que assegurar que um volume conterá somente documentos. Não é permitido que um volume contenha outro

volume ou outro processo/dossiê.

239.

Volumes: abertura, encerramento e metadados

O Software tem que permitir que um volume seja encerrado por meio de procedimentos regulamentares e apenas por usuários autorizados.

240.

Volumes: abertura, encerramento e metadados

O Software tem que assegurar que, ao ser aberto um novo volume, o precedente seja automaticamente encerrado.

Apenas o volume produzido mais recentemente pode estar aberto; os demais volumes existentes no processo/dossiê têm que estar encerrados.

241.

Volumes: abertura, encerramento e metadados

O Software tem que impedir a reabertura, para acréscimo de documentos, de um volume já encerrado.

242.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

O Software tem que capturar documentos ou processos/dossiês não digitais e gerenciá-los da mesma forma que os digitais.

243.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

O Software tem que ser capaz de gerenciar a parte não digital e a parte digital integrantes de processos/dossiês híbridos, associando-as com o mesmo número identificador atribuído pelo sistema e o mesmo título, além de indicar que se trata de um

documento arquivístico híbrido.

244.

Gerenciamento de documentos e

O Software tem que permitir que um conjunto específico de metadados seja configurado para os documentos ou

processos/dossiês arquivísticos

não digitais e híbridos

processos/dossiês não digitais e incluir informações sobre o local de arquivamento.

245.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

O Software tem que dispor de mecanismos para acompanhar a movimentação do documento arquivístico não digital, de forma que fique evidente para o usuário a localização atual do documento.

246.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

O Software tem que ser capaz de oferecer ao usuário funcionalidades para solicitar ou reservar a consulta a um documento arquivístico não digital, enviando uma mensagem para o detentor atual do documento ou para o administrador.

247.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

O Software tem que assegurar que a recuperação de um documento ou processo/dossiê híbrido permita, igualmente, a recuperação dos metadados da parte digital e da não digital.

248.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

Sempre que os documentos ou processos/dossiês híbridos estiverem classificados quanto ao grau de sigilo, o Software tem que garantir que a parte não digital e a parte digital correspondente recebam a mesma classificação de sigilo.

249.

Gerenciamento de documentos e processos/dossiês arquivísticos

não digitais e híbridos

O Software tem que registrar na trilha de auditoria todas as alterações efetuadas nos metadados dos documentos ou processos/dossiês não digitais e híbridos.

250.

Tramitação e fluxo de trabalho

Um recurso de fluxo de trabalho do Software tem que fornecer os passos necessários para o cumprimento de trâmites preestabelecidos ou aleatórios. Nesse caso, cada passo significa o

deslocamento de um documento ou processo/dossiê de um participante para outro, a fim de serem objeto de ações.

251.

Tramitação e fluxo de trabalho

Para controlar o fluxo de trabalho de um tipo de processo/dossiê, o Software deve gerenciar as seguintes tabelas:

• áreas de processos/dossiês;

• atividades de processos/dossiês;

• grupos de usuários responsáveis por determinada atividade;

• ações realizadas em processos/dossiês;;

252.

Tramitação e fluxo de trabalho

O Software tem que garantir para cada tipo de processo/dossiê que possua trâmites preestabelecidos, no mínimo as seguintes informações:

• atividade atual;

• ação efetuada na atividade atual;

• complemento da ação efetuada;

• próxima atividade;

• identificação da necessidade de entranhar um tipo de documento na atividade atual;

• prazo para execução da atividade;

• participantes da atividade atual: indivíduo, grupo ou responsável pelo grupo.

253.

Tramitação e fluxo de trabalho

Somente administradores autorizados têm que ser capazes de criar trâmites preestabelecidos para os tipos de processos/dossiês, no mínimo, através das seguintes ações:

• modelando um diagrama BPMN no próprio Software;

• importando um digrama BPMN criado numa plataforma externa ao Software;

• cadastrando manualmente os registros no tipo de processo/dossiê.

254.

Tramitação e fluxo de trabalho

Somente administradores autorizados têm que ser capazes de modelar diagramas BPMN para representar o fluxo de trabalho de um tipo de processo/dossiê.

255.

Tramitação e fluxo de trabalho

Administradores autorizados do Software podem tornar obrigatório o entranhamento de um tipo documento em fluxo de

trabalho do trâmite de um tipo de processo/dossiê.

256.

Tramitação e fluxo de trabalho

O Software tem que ter capacidade, sem limitações, de estabelecer o número necessário de trâmites nos fluxos de trabalho.

257.

Tramitação e fluxo de trabalho

É altamente desejável que o Software permita que o usuário efetue trâmites de processos/dossiês em lote, nos casos em que o destinatário e a próxima atividade serão os mesmos.

258.

Tramitação e fluxo de trabalho

O Software tem que gerar a cada trâmite efetuado o despacho eletrônico, no formato PDF/A editável.

259.

Tramitação e fluxo de trabalho

O Software tem que impedir o trâmite dos processos/dossiês que estejam no suporte digital e tenham pendência de assinatura

eletrônica ou digital no despacho eletrônico ou no documento entranhado, caso tenha sido inserido.

260.

Tramitação e fluxo de trabalho

O Software tem que enviar ao autor do processo/dossiê notificação por e-mail de cada novo trâmite.

261.

Tramitação e fluxo de trabalho

O Software tem que ter capacidade de gerar a guia de trâmite para comprovação de movimentação de processos não digitais.

262.

Tramitação e fluxo de trabalho

É altamente desejável que o Software assegure que qualquer usuário tenha acesso a visualização dos diagramas BPMN.

263.

Tramitação e fluxo de trabalho

É altamente desejável que o Software mantenha versões dos fluxos alterados e estabelecer vínculos entre os documentos já

processados ou em processamento nos fluxos alterados.

264.

Tramitação e fluxo de trabalho

O Software deve assegurar que qualquer modificação nos atributos dos fluxos, como extinção ou ampliação do número de pessoas ou extinção de autorização, leve em conta os documentos

vinculados.

265.

Tramitação e fluxo de trabalho

O fluxo de trabalho do Software tem que disponibilizar uma função para avisar um participante do fluxo de que um processo/dossiê lhe foi enviado, especificando a ação

necessária.

266.

Tramitação e fluxo de trabalho

É altamente desejável que o fluxo de trabalho do Software permita o uso do correio eletrônico, para que um usuário possa informar a outros usuários sobre documentos que requeiram sua atenção.

Esse requisito requer a integração com um sistema de correio eletrônico existente.

267.

Tramitação e fluxo de trabalho

O recurso de fluxo de trabalho do Software tem que permitir que fluxos de trabalho pré-programados sejam definidos, alterados e mantidos exclusivamente por usuário autorizado.

268.

Tramitação e fluxo de trabalho

Um recurso de fluxo de trabalho do Software tem que registrar na trilha de auditoria todas as alterações ocorridas neste fluxo.

269.

Tramitação e fluxo de trabalho

Um recurso de fluxo de trabalho do Software tem que registrar o

trâmite de um processo/dossiê a fim de que os usuários possam conhecer a situação de cada um no processo.

270.

Tramitação e fluxo de trabalho

É altamente desejável que o Software organize os processos/dossiês que estejam com determinado usuário, através de caixas virtuais, organizadas no seguinte formato:

• caixa de entrada: conterá os processos/dossiês ainda não recebidos pelo usuário;

• caixa mesa de trabalho: conterá os processos/dossiês recebidos pelo usuário;

• caixa de saída: conterá os processos/dossiês enviados pelo usuário e ainda não recebidos pelo destinatário.

271.

Tramitação e fluxo de trabalho

O Software tem que garantir que os processos/dossiês enviados diretamente para um indivíduo do grupo, não possam ser visualizados por outro indivíduo, mesmo sendo do mesmo grupo.

272.

Tramitação e fluxo de trabalho

É altamente desejável que o Software permita que o responsável pelo grupo de usuários consiga redistribuir um processo/dossiê a outro individuo participante do mesmo grupo.

273.

Tramitação e fluxo de trabalho

O Software tem que permitir que o usuário ao efetuar um determinado trâmite, escolha as seguintes opções de envio:

• enviar para o responsável pelo grupo de usuários;

• enviar para todos do grupo de usuários;

• enviar para um indivíduo do grupo de usuários.

274.

Tramitação e fluxo de trabalho

Um recurso de fluxo de trabalho do Software tem que fornecer um histórico de trâmite dos processos/dossiês.

O histórico de trâmite corresponde a um conjunto de metadados de datas de entrada e saída, nomes de responsáveis, título do documento, providências etc.

275.

Tramitação e fluxo de trabalho

É altamente desejável que um recurso de fluxo de trabalho do Software possa incluir processamento condicional, isto é, permitir que um fluxo de trabalho seja suspenso para aguardar a chegada de um documento e prossiga automaticamente

quando este for recebido.

276.

Tramitação e fluxo de trabalho

É altamente desejável que o Software identifique de forma visual os processos/dossiês que estejam com o prazo de determinada atividade vencido.

277.

Tramitação e fluxo de trabalho

Um recurso de fluxo de trabalho do Software tem que fornecer meios de elaboração de relatórios completos para permitir que gestores monitorem o trâmite dos processos/dossiês e o desempenho dos participantes.

278.

Tramitação e fluxo de trabalho

Um recurso de fluxo de trabalho do Software tem que registrar o trâmite de um processo/dossiê em seus metadados. Os metadados referentes ao trâmite devem registrar data e hora de

envio e recebimento, e a identificação do usuário.

279.

Controle de versões e do status do documento

Um recurso de fluxo de trabalho do Software tem que ser capaz de registrar o status de transmissão do documento, ou seja, se é minuta, original ou cópia.

280.

Controle de versões e do status do documento

O Software tem que manter o identificador único do documento, e controlar as diversas versões deste documento.

281.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que implementar a classificação de grau de sigilo e demais caracterizações de restrição de acesso de documentos e processos/dossiês.

282.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que implementar a identificação de restrições legais de acesso baseando-se nos seguintes atributos de segurança:

• Tipo de restrição legal de acesso;

• credencial de segurança do usuário.

Os tipos de restrição legal podem ser documentos preparatórios,

dados pessoais, sigilo comercial, bancário, industrial, telefônico, segredo de justiça etc.

283.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que tratar a classificação de grau de sigilo baseando-se nos seguintes atributos de segurança:

• grau de sigilo do documento;

• credencial de segurança do usuário;

• identificação da autoridade classificadora.

O grau de sigilo tem que estar associado à credencial de segurança.

Incluem-se também os documentos recebidos com classificação de grau de sigilo.

284.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software deve permitir a formalização da decisão de classificação da informação em qualquer grau de sigilo, conforme legislação vigente.

A título de exemplo, o Poder Executivo Federal utiliza o Termo de Classificação de Informação - TCI, conforme estabelecido no decreto nº 7.724, de 16 de maio de 2012, que registra as seguintes informações:

• código de indexação de documento;

• grau de sigilo;

• categoria na qual se enquadra a informação;

• tipo de documento;

• data da produção do documento;

• indicação de dispositivo legal que fundamenta a classificação;

• razões da classificação;

• indicação do prazo de sigilo, contado em anos, meses ou dias, ou do evento que defina o seu termo final;

• data da classificação; e

• identificação da autoridade que classificou a informação.

285.

Classificação da informação quanto ao grau de sigilo e restrição de

O Software tem que recusar o acesso de usuários a documentos que possuam grau de sigilo superior à sua credencial de segurança.

acesso à informação sensível

286.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que garantir que documentos sem atribuição de grau de sigilo ou identificação de outras restrições de acesso, provenientes de fontes externas ao Software, estejam sujeitos às

políticas de controle de acesso e de sigilo.

287.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que ser capaz de manter a marcação de restrição de acesso original durante a importação de documentos a partir de fontes externas ao Software.

288.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

É altamente desejável que o Software garanta que não haja ambiguidade na associação entre as marcações de grau de sigilo e outros atributos de segurança (permissões) do documento

importado.

289.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que permitir que um dos itens abaixo seja selecionado durante a configuração:

• graus de sigilo e restrições de acesso a serem atribuídos a tipos de unidade de arquivamento, podendo ser para tipos de documentos e tipos de processos/dossiês;

• tipos de unidade de arquivamento, podendo ser para tipos de documentos e tipos de processos/dossiês sem grau de sigilo ou outras restrições de acesso.

290.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

Em caso de erro ou reavaliação, o administrador autorizado tem que ser capaz de alterar o grau de sigilo ou outra restrição de acesso de todos os documentos arquivísticos de um processo/dossiê ou de uma classe, numa única operação.

A informação quanto à desclassificação, reclassificação, redução do prazo de sigilo ou alteração de restrição de acesso deverá ser registrada conforme legislação em vigor.

291.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que permitir que somente administradores autorizados sejam capazes de realizar as seguintes ações:

• remover ou revogar os atributos de segurança dos documentos;

• criar, alterar, remover ou revogar as credenciais de segurança dos usuários.

292.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

O Software tem que permitir somente ao usuário autorizado, mediante confirmação, a desclassificação, redução do grau de sigilo ou alteração de restrição de acesso de um documento.

A informação quanto à desclassificação, reclassificação, redução do prazo de sigilo ou alteração de restrição de acesso deverá ser registrada conforme legislação em vigor.

293.

Classificação da informação quanto ao grau de sigilo e restrição de

acesso à informação sensível

É altamente desejável que o Software permita o armazenamento dos documentos sigilosos em meios físicos ou lógicos distintos dos documentos não sigilosos.

294.	Classificação da informação quanto ao grau de sigilo e restrição de acesso à informação sensível	O Software tem que impedir que um documento com classificação de sigilo seja eliminado. Os documentos com classificação de sigilo têm que se tornar ostensivos antes de receberem a destinação prevista.	O
295.	Classificação da informação quanto ao grau de sigilo e restrição de acesso à informação sensível	O Software tem que implementar metadados nos níveis de processo/dossiê ou documento para controlar o acesso à informação com restrição de acesso.	O
296.	Assinatura Digital e Eletrônica	O Software tem que estar em conformidade com as normas do ICP-Brasil e seja capaz de garantir a origem e a integridade dos documentos com assinatura digital.	AD
297.	Assinatura Digital e Eletrônica	É altamente desejável que o software possua componente para execução de assinaturas digitais através do browser.	O
298.	Assinatura Digital e Eletrônica	O Software tem que ser capaz de verificar a validade da assinatura digital no momento da captura do documento.	O
299.	Assinatura Digital e Eletrônica	O Software deve possuir suporte a dispositivos criptográficos (tokens e smartcards).	O
300.	Assinatura Digital e Eletrônica	O Software tem que ser capaz de assinar digitalmente documentos individualmente ou em lote.	AD
301.	Assinatura Digital e Eletrônica	O Software tem que permitir a assinatura digital por mais de um autor.	AD
302.	Assinatura Digital e Eletrônica	É altamente desejável que o Software seja capaz de receber atualizações tecnológicas quanto à plataforma criptográfica de assinatura digital.	AD
303.	Assinatura Digital e Eletrônica	É altamente desejável que o Software seja capaz de permitir que o usuário rejeite pedido de assinatura digital de um documento.	AD
304.	Assinatura Digital e Eletrônica	É altamente desejável que o Software tenha a capacidade de gerar uma “hash” nos documentos assinados digitalmente contendo no mínimo: CPF e identificação do autor, data e hora da assinatura, QR Code e endereço eletrônico para validação da assinatura digital.	AD
305.	Assinatura Digital e Eletrônica	O Software deve possibilitar a geração de assinatura eletrônica, sem a necessidade de instalação de nenhum pluggin, applet ou aplicativo no computador do usuário.	AD
306.	Assinatura Digital e Eletrônica	O Software tem que ser capaz de assinar eletronicamente documentos individualmente ou em lote.	AD
307.	Assinatura Digital e Eletrônica	É altamente desejável que o Software seja capaz de permitir que o usuário rejeite pedido de assinatura eletrônica de um documento.	AD
308.	Assinatura Digital e Eletrônica	O Software tem que ser capaz de garantir a autoria de um documento que tenha sido autenticado por meio da identificação do autor após confirmação de senha, nos documentos produzidos e mantidos dentro do Software.	O
309.	Assinatura Digital e Eletrônica	O Software tem que registrar a identificação do autor como metadado de autenticação do documento após verificação da senha do usuário.	O
310.	Assinatura Digital e Eletrônica	É altamente desejável que o Software faça uso de checksum para apoiar a verificação da integridade do documento que foi autenticado após confirmação de senha.	AD
311.	Carimbo digital do tempo	O Software tem que ter acesso a relógios e carimbador de tempo confiáveis para seu próprio uso.	O

312.

Carimbo digital do tempo

O Software tem que ser capaz de verificar a validade do carimbo digital do tempo no momento da captura do documento.

313.

Carimbo digital do tempo

O Software, no processo de verificação do carimbo digital do tempo, tem que ser capaz de registrar, nos metadados do documento, o seguinte:

• validade do carimbo digital do tempo;

• registro da verificação do carimbo digital do tempo;

• data e hora em que ocorreu a verificação.

314.

Segurança e controle de acesso

O Software tem que exigir que o usuário esteja devidamente identificado e autenticado antes de iniciar qualquer operação.

315.

Segurança e controle de acesso

O Software tem que permitir o cadastro de Pessoas Físicas e Jurídicas por administradores autorizados, que poderão assumir os papéis de usuários, responsáveis, autores e etc no Software.

316.

Segurança e controle de acesso

O Software tem que exigir que o usuário esteja vinculado a uma Pessoa (física ou jurídica) na base de dados;

317.

Segurança e controle de acesso

O Software tem que garantir que os valores dos atributos de segurança e controle de acesso, associados ao usuário, estejam dentro de conjuntos de valores válidos.

318.

Segurança e controle de acesso

É altamente desejável o Software só permita que as credenciais de autenticação só devem ser alteradas pelo usuário proprietário ou pelo administrador, em conformidade com a política de segurança da Contratante.

319.

Segurança e controle de acesso

Permitir acesso as funções do software somente a usuários autorizados e sob controle rigoroso da administração do sistema, a fim de proteger a autenticidade dos documentos arquivísticos digitais.

320.

Segurança e controle de acesso

O Software não pode permitir que o usuário acesse o sistema com as mesmas credenciais simultaneamente, em dois locais de acesso.

321.

Segurança e controle de acesso

O Software deve bloquear acesso ao sistema após 03 (três) tentativas com autenticação malsucedida.

322.

Segurança e controle de acesso

Se o usuário solicitar o acesso ou pesquisa de um documento arquivístico, volume ou processo/dossiê específico a que não tenha direito de acesso, é altamente desejável que o Software forneça uma das seguintes respostas (estabelecidas durante a configuração):

• mostrar o título e os metadados do documento; ou

• demonstrar a existência do processo/dossiê ou documento, mas não o respectivo título nem outro metadado; ou

• não mostrar qualquer informação do documento, nem indicar a sua existência.

323.

Segurança e controle de acesso

Somente administradores autorizados têm que ser capazes de criar, alterar, remover ou revogar permissões associadas a

papéis de usuários, grupos de usuários ou usuários individuais.

324.

Segurança e controle de acesso

É altamente desejável que o Software aplique a partir do

próximo acesso do usuário, alterações ou revogações dos atributos de segurança de usuários e de documentos digitais.

325.

Segurança e controle de acesso

É altamente desejável que o Software ofereça ferramentas de aumento de produtividade ao administrador, tais como a realização de operações sobre papéis e grupos de usuários, atribuindo as permissões de acesso em lote, para todos os

usuários.

326.

Segurança e controle de acesso

Quando o Software controlar o acesso por grupos de usuários, papéis de usuários e usuários individuais, deve obedecer a uma hierarquia de permissões preestabelecida na política de segurança.

Poderão compor um grupo de usuários: unidades administrativas, comissões, conselhos ou grupos de trabalho estabelecidos pela Contratante.

327.

Segurança e controle de acesso

O Software tem que aplicar a política de controle de acesso a documentos por grupos de usuários considerando:

• a identidade do usuário e sua participação em grupos: responsável ou membro;

• os atributos de segurança, associados ao documento arquivístico digital, às classes e/ou aos processos/dossiês.

328.

Segurança e controle de acesso

O acesso a documentos, a processos/dossiês ou classes, tem que ser concedido se a permissão requerida para a operação estiver associada a pelo menos um dos grupos aos quais pertença o

usuário.

329.

Segurança e controle de acesso

O Software tem que permitir que um usuário pertença a mais de um grupo de usuários.

330.

Segurança e controle de acesso

O Software tem que usar os seguintes atributos do usuário ao implementar a política de controle de acesso aos documentos digitais por papéis de usuários:

• identificação do usuário;

• papéis associados ao usuário;

• grupos associados ao usuário.

331.

Segurança e controle de acesso

O Software tem que usar os seguintes atributos dos documentos digitais ao implementar a política de controle de acesso por papéis:

• identificação do documento digital;

• operações permitidas aos vários papéis de usuários, sobre as classes ou unidades de arquivamento a que o documento pertence.

332.

Segurança e controle de acesso

O acesso a documentos, processos/dossiês ou classes tem que ser concedido somente se a permissão requerida para a

operação estiver presente em pelo menos um dos papéis e grupos associados ao usuário.

333.

Segurança e controle de acesso

O usuário pode possuir mais de um papel do usuário;

334.

Segurança e controle de acesso

Os administradores autorizados têm que ser capazes de definir os dias e horários para acesso ao software, por papel de usuário.

335.

Segurança e controle de acesso

Os administradores autorizados têm que ser capazes de definir períodos de bloqueio de acesso ao software de um determinado

usuário.

336.

Segurança e controle de acesso

É altamente desejável que o Software possua funcionalidade para validar a solicitação de cadastro, por usuário externo.

337.

Segurança e controle de acesso

O Software deve atribuir ao usuário todas as permissões dos papeis aos quais está vinculado.

338.

Segurança e controle de acesso

O Software tem que usar criptografia no armazenamento, na transmissão e na apresentação de documentos arquivísticos digitais ao implementar a política de sigilo.

339.

Trilhas de auditoria

O Software tem que ser capaz de registrar, na trilha de auditoria, informações acerca das ações a seguir:

• todas as ações efetuadas em processos/dossiês;

• todas as ações efetuadas em documentos;

• todos os acessos e tentativas de acesso malsucedidas;

• todas as ações administrativas sobre os atributos de segurança;

• todas as ações administrativas sobre dados de usuários (cadastro, ativação, bloqueio, atualização de dados e permissões, troca de senha etc.);

• todos as ações efetuadas de parametrizações e configurações do Software;

340.

Trilhas de auditoria

O Software tem que registrar, em cada evento auditado, informações sobre a identidade do usuário, desde que essa identificação esteja de acordo com a política de privacidade da

Contratante e a legislação vigente.

341.

Trilhas de auditoria

É altamente desejável que o Software permita apenas ao administrador e ao auditor a leitura das trilhas de auditoria.

342.

Trilhas de auditoria

O Software tem que assegurar que as informações da trilha de auditoria estejam disponíveis para inspeção, a fim de que uma ocorrência específica possa ser identificada e todas as

informações correspondentes sejam claras e compreensíveis.

343.

Trilhas de auditoria

É altamente desejável que o Software possua mecanismos para realização de buscas nos eventos das trilhas de auditoria.

Para facilitar a visualização do relatório, os resultados podem ser apresentados de modo ordenado, mas essa ordenação não pode alterar os dados incluídos na trilha.

344.

Trilhas de auditoria

O Software tem que ser capaz de impedir qualquer modificação na trilha de auditoria.

345.

Trilhas de auditoria

Somente administradores autorizados têm que ser capazes de exportar as trilhas de auditoria sem afetar a trilha armazenada,

ou transferir as trilhas de auditoria de um suporte de armazenamento para outro.

346.

Trilhas de auditoria

É altamente desejável que o Software seja capaz de aplicar um conjunto de regras na monitoração de eventos auditados e, com base nelas, indicar a possível violação da segurança.

347.

Trilhas de auditoria

É altamente desejável que o Software garanta pelo menos as seguintes regras para monitoração dos eventos auditados:

• acumulação de um número predeterminado de tentativas consecutivas de log in com erro (autenticação malsucedida), conforme especificado pela política de segurança;

• ocorrência de vários log in simultâneos do mesmo usuário em locais (computadores) diferentes;

• log in do usuário fora do horário autorizado, após logoff no período normal.

348.

Trilhas de auditoria

O Software tem que fornecer relatórios sobre as ações que afetam classes, unidades de arquivamento e documentos, em ordem cronológica e organizados por:

• documento arquivístico, unidade de arquivamento ou classe;

• usuário;

• tipo de ação ou operação.

349.

Trilhas de auditoria

Somente administradores autorizados têm que ser capazes de configurar o conjunto de eventos auditáveis e seus atributos.

350.

Trilhas de auditoria

O Software tem que ser capaz de arquivar periodicamente a trilha de auditoria como documento arquivístico.

Os Requisitos Técnicos do Software estão organizados em tabela que é composta das seguintes informações:

a) ID: contém o código referente ao requisito;

b) Categoria: contém a categoria do Requisito;

c) Descrição: contém a descrição do requisito que deve ser atendido pelo software;

d) Classificação: o requisito será classificado em: (O) “Obrigatório” e (AD) “Altamente Desejável”.

Document Metadata

Table of Contents

Free Standard Templates

ANEXO I - TERMO DE REFERÊNCIA

Document Metadata