SmartDocs – Inovação em Gestão Documental

Ricardo João Correia Vieira

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Júri
Presidente: Prof. Alberto Cunha (IST)

Orientador: Prof. José Borbinha (IST)

Co-Orientador: Eng.ª Irene Oliveira (Fujitsu)

Arguente: Prof. André Vasconcelos (IST)

Outubro 2010
 Agradecimentos
Gostaria de agradecer ao professor José Borbinha pelo tempo dispensado, conselhos e
ajuda dada durante todo este processo de tese de mestrado. À Engª Irene Oliveira e ao Engº
Nuno Semedo que me acompanharam durante todo o percurso da tese mostrando-se sempre
disponíveis para me ajudar. Às pessoas com quem trabalhei na Fujistu pelo excelente
ambiente de trabalho que me proporcionaram fazendo-me sempre sentir bem recebido e
apoiado.
Agradeço no mundo académico a todos os meus colegas e professores que me ajudaram
durante todo o meu percurso universitário e que dessa forma contribuíram para os meus
sucessos e conquistas como aluno e irão sempre ser parte do meu eventual sucesso como
profissional.
A todos os meus amigos que fazem parte da minha vida pelas manhãs, tardes e noites de
divertimento e por estarem presentes sempre que precisei. Sem eles nada disto seria possível.
Por último mas não menos importante aos meus pais, irmão e avós pelo apoio constante
durante todo o meu percurso académico (e durante toda a minha vida), pela motivação para
procurar sempre o melhor para mim e pelo exemplo de pessoas que representam para mim.

1
 Resumo
Um sistema de gestão documental (SGD) é hoje essencial para o aumento da produtividade
de uma empresa, razão pela qual poucas são as que não têm um implementado e muitas são
as soluções disponíveis no mercado. Com um leque de soluções variado disponível no
mercado verificou-se a necessidade de definição de boas práticas de SGD, com o objectivo
não só de auxiliar quem procura comprar, como quem pretende desenvolver este tipo de
sistemas. Por essa razão em 2001 foi disponibilizado online a primeira versão do MoReq, uma
especificação de requisitos para sistemas de gestão de documentos de arquivo. Com a
introdução e propagação do MoReq pela Europa este passou a ser considerado uma exigência
por parte dos consumidores de SGD deixando um problema para os fornecedores com
produtos já desenvolvidos: como avaliar os seus softwares com base no MoReq e quais os
desenvolvimentos necessários para cumprir os seus requisitos.
Esta dissertação analisa esse problema e propõe um processo de avaliação de SGC, classe
de sistemas onde os SGD se incluem, de acordo com uma especificação de requisitos como o
MoReq. Para obter o resultado final foram estudadas e aplicadas técnicas de avaliação de
software a um SGD já desenvolvido (SmartDocs) que pretende evoluir para um sistema em
total cumprimento com os requisitos do MoReq2, segunda versão do MoReq. A solução
proposta é o resultado das ilações retiradas na utilização dos métodos estudados no caso de
referência referido.

Palavras-chave: sistema de gestão documental; sistema de gestão de conteúdos;

sistema de gestão de documentos de arquivo; MoReq; avaliação de software; evolução de
software;

2
 Abstract
A document management system (DMS) is now essential to increase the productivity of a
company, which is why there are few who do not have one implemented and there are many
solutions available in the market. With a varied range of solutions available on the market there
was a need to define DMS’s best practices with the aim of, not only assist those looking to buy
but also those who want to develop similar systems. For this reason in 2001 the first version of
MoReq, a requirements specification for records management system, was made available
online. With the introduction and spread of MoReq in Europe the DMS’s consumers started to
consider its compliance a demand, leaving a problem for suppliers with products already
developed: how to evaluate their software based on MoReq and what developments are
necessary to meet its requirements.
In this dissertation we analyze this problem and propose a process for evaluating content
management systems, class of systems where the DMSs fall, according to a requirements
specification as MoReq. To achieve the final results we studied and applied techniques for
evaluating software in an already developed DMS (SmartDocs) who wants to evolve to a
system in full compliance with the requirements of MoReq2, the second version of MoReq. The
proposed solution is the result of the lessons taken from the use of the methods studied in the
reference case above.

Keywords: document management system; content management system; record

management system; MoReq; software evaluation; software evolution;

3
Índice
Agradecimentos ......................................................................................................................1

Resumo ...................................................................................................................................2

Abstract ...................................................................................................................................3

Lista de Tabelas .......................................................................................................................6

Lista de Figuras ........................................................................................................................7

Lista de Acrónimos ..................................................................................................................8

1. Introdução ....................................................................................................................9

1.1. Problema e Motivação........................................................................................10

1.2. Objectivo ............................................................................................................10

1.3. Resultados ..........................................................................................................11

1.4. Estrutura da Dissertação.....................................................................................12

2. Estado da Arte ............................................................................................................13

2.1. Conceitos Fundamentais ........................................................................................13

2.1.1. Tipos de Conteúdo ..........................................................................................13

2.1.2. Tipos de Sistemas de Gestão de Conteúdos ...................................................14

2.2. Evolução de Software .............................................................................................14

2.3. Avaliação de Software ............................................................................................17

2.3.1. Listas de Verificação .......................................................................................19

2.3.2. Listas Ponderadas ...........................................................................................21

2.3.3. Análise de Intervalos.......................................................................................21

2.4. Sistemas de Gestão Documental ............................................................................22

2.4.1. Alfresco ...........................................................................................................23

2.4.2. Spring CM .......................................................................................................25

2.4.3. Open Text ECM Suite ......................................................................................26

2.4.4. FileNet P8 .......................................................................................................27

2.4.5. Comparação entre Sistemas ...........................................................................28

4
 3. SmartDocs ..................................................................................................................30

3.1. Enquadramento com os outros sistemas ...............................................................33

4. MoReq ........................................................................................................................35

4.1. Análise e Resumo do MoReq2 ................................................................................36

5. Análise do SmartDocs segundo o MoReq ...................................................................43

5.1. Lista de Verificação .................................................................................................43

5.2. Lista Ponderada ......................................................................................................46

5.3. Análise de Intervalos ..............................................................................................51

6. Validação dos Resultados ...........................................................................................54

6.1. Avaliação de um Sistema de Gestão de Conteúdos de acordo com uma

especificação de Requisitos ....................................................................................................54

6.2. Portal de Gestão de Requisitos de Sistemas de Gestão de Documentos de Arquivo

56

7. Conclusões e Trabalho Futuro ....................................................................................59

Bibliografia ............................................................................................................................61

ANEXO I – DIAGRAMAS DE MODELAÇÃO DOS REQUISITOS DO MOREQ2 ............................64

ANEXO II – RESULTADOS QUANTITATIVOS COMPLETOS DA AVALIAÇÃO POR LISTA DE

VERIFICAÇÃO. .............................................................................................................................79

ANEXO III – REESTRUTURAÇÃO DO MOREQ2 SEGUNDO OS DIAGRAMAS DE ANÁLISE DO

ANEXO I ......................................................................................................................................80

ANEXO IV – RESULTADOS QUANTITATIVOS COMPLETOS DA AVALIAÇÃO POR LISTA

PONDERADA...............................................................................................................................94

5
 Lista de Tabelas
TABELA 1. EXEMPLO DE RESPOSTA QUANTITATIVA EM LISTA DE VERIFICAÇÃO. ............................................................ 20
TABELA 2. DESCRIÇÃO DAS FUNCIONALIDADES BASE DE UM SGDA .........................................................................29
TABELA 3. FUNÇÕES DO SMARTDOCS ENQUADRADAS COM AS ÁREAS DE FUNCIONALIDADE DE UM SGDA........................33
TABELA 4. PRINCIPAIS DIFERENÇAS ENTRE UM SGD E UM SGDA (EDMS: ELECTRONIC DOCUMENT MANAGEMENT SYSTEM ;
ERMS: ELECTRONIC RECORD MANAGEMENT SYSTEM)................................................................................34
TABELA 5 TABELA DE AVALIAÇÃO DO SUBCAPÍTULO 9.1 (“GENERAL ADMINISTRATION”) DO MOREQ2 UTILIZANDO O MÉTODO
DE LISTA DE VERIFICAÇÃO. ..................................................................................................................... 44

TABELA 6 TABELA DE RESULTADOS QUANTITATIVA DA AVALIAÇÃO POR LISTA DE VERIFICAÇÃO NO QUE DIZ RESPEITO A
REQUISITOS OBRIGATÓRIOS. LEGENDA: PRETO = 0-24%; VERMELHO = 25-49%; AMARELO = 50-74%; VERDE = 75-
100%; .............................................................................................................................................45
TABELA 7. PESOS DOS REQUISITOS APÓS REESTRUTURAÇÃO DO MOREQ2 ................................................................48
TABELA 8 SIGNIFICADO DAS RESPOSTAS QUANTITATIVAS DA AVALIAÇÃO POR LISTA PONDERADA ....................................48
TABELA 9. TABELA DE RESULTADOS QUANTITATIVA DA AVALIAÇÃO POR LISTA PONDERADA NO QUE DIZ RESPEITO A
REQUISITOS OBRIGATÓRIOS DISCRIMINADOS PELO NÍVEL DE IMPORTÂNCIA DOS REQUISITOS. LEGENDA: PRETO = 0-24%;
VERMELHO = 25-49%; AMARELO = 50-74%; VERDE = 75-100%; ..............................................................49
TABELA 10. TABELA DE RESULTADOS QUANTITATIVA LISTA PONDERADA NO QUE DIZ RESPEITO A
DA AVALIAÇÃO POR
REQUISITOS OBRIGATÓRIOS DESCRIMINADOS PELA RESPOSTA QUANTITATIVA DADA. LEGENDA: PRETO = 0-24%;
VERMELHO = 25-49%; AMARELO = 50-74%; VERDE = 75-100%; ..............................................................50
TABELA 11. LISTA DE PROPOSTAS DE DESENVOLVIMENTO PARA O SMARTDOCS OBTIDA ATRAVÉS DA ANÁLISE DE INTERVALOS.
......................................................................................................................................................52

6
 Lista de Figuras
FIGURA 1. DIAGRAMA QUE DEFINE O PROCESSO DE AVALIAÇÃO DE UM SGC DE ACORDO COM UMA ESPECIFICAÇÃO DE
REQUISITOS, E AS SUAS DIVERSAS FASES. ................................................................................................... 11

FIGURA 2. TIPOS DE EVOLUÇÃO E MANUTENÇÃO DE SOFTWARE ............................................................................16

FIGURA 3 SIGNIFICADO DA CLASSIFICAÇÃO NO QUADRANTE GARTNER.....................................................................22
FIGURA 4 GARTNER ECM MAGIC QUADRANTE DE OUTUBRO DE 2009 ...................................................................23
FIGURA 5. FUNCIONALIDADES DO MÓDULO DE GESTÃO DOCUMENTAL ALFRESCO (SHARIFF, 2007) ................................24
FIGURA 6. FUNCIONALIDADES DO MÓDULO DE GESTÃO DE DOCUMENTOS DE ARQUIVO ALFRESCO .................................25
FIGURA 7. FUNCIONALIDADES DO SISTEMA DE GESTÃO DOCUMENTAL SPRINGCM ......................................................26
FIGURA 8 PLANEAMENTO DAS NOVAS VERSÕES DO MOREQ ..................................................................................36
FIGURA 9. ELEMENTOS E CONECTORES UTILIZADOS NOS DIAGRAMAS DE RESUMO DOS CAPÍTULOS DO MOREQ2................37
FIGURA 10 EXEMPLO DE UM PLANO DE CLASSIFICAÇÃO. ......................................................................................38
FIGURA 11 MODELO ENTIDADE-RELAÇÃO QUE REPRESENTA A BASE DE UM SGDA SEGUNDO O MOREQ2. ......................39
FIGURA 12. ESTRUTURA FIXA DA LISTAGEM DE REQUISITOS NO MOREQ2 .................................................................39
FIGURA 13. DIAGRAMA DE MODELAÇÃO DOS REQUISITOS DO CAPITULO 3.1 (“CONFIGURING THE CLASSIFICATION SCHEME”)
DO MOREQ2 ..................................................................................................................................... 47

FIGURA 14. DIAGRAMA QUE DEFINE O PROCESSO DE AVALIAÇÃO DE UM SGC DE ACORDO COM UMA ESPECIFICAÇÃO DE
REQUISITOS, E AS SUAS DIVERSAS FASES. ................................................................................................... 55

7
Lista de Acrónimos
SGD Sistema de Gestão Documental

SGDA Sistema de Gestão de Documentos de Arquivo

SGC Sistema de Gestão de Conteúdos

SGCE Sistema de Gestão de Conteúdos Empresariais

8
 1. Introdução
Em termos gerais, um Sistema de Gestão Documental (SGD) é um sistema de informação
concebido para gerir as fases do ciclo de vida de um documento. Essas tipicamente são: a
captura ou criação do documento, o armazenamento, a gestão de versões, o acesso e
eventualmente também a eliminação.
Na sua versão tradicional, um SGD é assim composto pelos espaços físicos de
armazenamento dos documentos (eles também objectos físicos) e pelos processos materiais
de gestão da informação de registo, pesquisa e acesso aos mesmos. A introdução de sistemas
de informação nesta área deu-se inicialmente com o suporte a essa informação de gestão,
vulgarmente chamada de “metadados”. Neste cenário continuamos a ter os documentos a
existir em suporte físico, mas os processos de registo, pesquisa e acesso já a ser suportados
digitalmente. Entretanto, com a desmaterialização total dos processos nas organizações,
também os documentos têm passado a existir em formatos digitais (nalguns casos
exclusivamente mesmo nessa forma), o que levou o âmbito dos SGD digitais a ser estendidos
à gestão dos metadados e dos próprios documentos.
Um SGD é assim hoje essencial para o aumento da produtividade de uma empresa.
Actualmente são poucas as grandes empresas que não têm um SGD implementado, havendo
um leque alargado de soluções disponíveis no mercado.
Na verdade, actualmente, um SGD não é mais que uma parte das soluções de sistemas de
gestão de conteúdos (SGC) que existem actualmente. Um perfil desse tipo de sistema é o
Sistema de Gestão de Documentos de Arquivo (SGDA), um sistema de informação capaz de
gerir os documentos de arquivo de uma organização considerando os seus requisitos de
arquivo. Nesta perspectiva temos o conceito de documentos de arquivo que em última análise
refere não apenas documentos textuais como geralmente os entendemos, mas qualquer
objecto físico ou digital que tenha valor para a organização. Em concreto, um documento de
arquivo é qualquer documento produzido com o objectivo de fornecer prova e/ou informar um
procedimento administrativo ou legal.
Podemos assim dizer que um SGDA é um sistema da classe dos SGD que para além de
suportar os requisitos gerais de um sistema dessa classe (gestão de conteúdos, em termos
gerais), suporta também um conjunto de requisitos específicos impostos pelos objectivos de
um arquivo.
Em 2001 foi publicado o MoReq (Model of Requirements), um modelo de requisitos para
SGDA, desenvolvido pelo DLM Forum (uma iniciativa fortemente apoiada pela Comissão
Europeia) e recomendado em Portugal pela Direcção Geral de Arquivos. Apesar de não ser
uma norma formal, mas sim um conjunto de recomendações, começa cada vez mais a ser
exigido pelos utilizadores dos SGC que os requisitos definidos pelo MoReq sejam cumpridos. A
razão por detrás da exigência é que o cumprimento desses requisitos é visto actualmente como
uma definição de qualidade dos sistemas avaliados.

9
 1.1. Problema e Motivação
O SmartDocs é um produto da classe dos SGD, criado pela empresa Fujitsu Portugal,
contando com cerca de 170 instalações e mais de 20.000 utilizadores estimados. Consolidado
o produto no mercado, com forte penetração na Administração Pública, a Fujitsu procura novas
formas de melhorar o SmartDocs com o objectivo de melhorar a experiência dos seus clientes
e a qualidade do produto. Um dos pedidos dos clientes da Fujitsu e que começa a ser uma
exigência geral no mercado é que o SmartDocs esteja de acordo com os vários requisitos
formais estabelecidos pelo MoReq. Isto corresponde a uma tendência das organizações em
tentarem ter os seus processos gerais de gestão de conteúdos alinhados com os requisitos
específicos de gestão de arquivo. Historicamente tem havido a percepção de que numa
organização devem existir por um lado SGC tendo como objectivo suportar os processos
produtivos nucleares da organização1, e depois separado um serviço de arquivo que
eventualmente fará parte das actividades de suporte mas sem impacto relevante esperado nas
actividades nucleares. Esta concepção teria até a sua lógica num paradigma de objectos de
informação materiais, mas com a total desmaterialização dos processos e conteúdos tem
emergido uma percepção de que em última análise as soluções de SGC deveriam ser ao
mesmo tempo, sempre que exigido, sistemas com propriedades de gestão de arquivo.
O objectivo deste projecto, surgiu assim da constatação da emergência deste tipo de
cenário em que cada vez mais se começam a pedir a um SGD já desenvolvido que também
responda aos requisitos específicos de um SGDA, o que implica analisar o SGD à luz do
MoReq, compreender os vários requisitos e funcionalidades implicadas, e confrontá-los. Este
foi assim o problema abordado neste projecto, tendo o caso do SmartDocs sido utilizado como
motivação e contexto para avaliação das propostas.

1.2. Objectivo
O objectivo deste projecto de mestrado passa então por estudar os métodos de avaliação
de software existentes que são aplicáveis contra uma especificação de requisitos, quais as
suas vantagens e desvantagens e as conclusões que se podem retirar de cada um deles.
Como o SmartDocs é utilizado como caso de referência a correcção e análise dos métodos é
validada nos resultados que estes apresentam sobre o produto da Fujitsu.
O objectivo final é depois de analisado o MoReq2 e o SmartDocs perceber de acordo com
as ilações e resultados retirados de cada método qual o procedimento geral a aplicar para uma
avaliação correcta e objectiva de um SGC de acordo com uma especificação de requisitos,
quais as informações a retirar dessa mesma avaliação e quais os desenvolvimentos a efectuar
de acordo com a avaliação. Resumindo o objectivo deste projecto de mestrado passa por
identificar as actividades nucleares de um processo de avaliação essencial para o
desenvolvimento e evolução de um SGC de acordo com um conjunto de requisitos
especificados.

1
Ou actividades primárias, segundo o modelo de cadeia da valor de Porter
(http://en.wikipedia.org/wiki/Value_chain)

10
 1.3. Resultados
Depois de aplicados os métodos de avaliação estudados nomeadamente, a avaliação por
lista de verificação, avaliação por lista ponderada e a análise de intervalos concluiu-se que
apenas os dois últimos apresentam resultados fiáveis e com informação útil para um produtor
de software.
Para cada um dos métodos foram identificados factores-chave para a sua aplicação como a
análise e estruturação dos objectos que utilizam, as pessoas envolvidas na aplicação dos
métodos e os resultados a retirar de cada técnica aplicada. O resultado final, ilustrado na Figura

1, identifica as actividades necessárias para uma correcta avaliação de um SGC de acordo

com uma especificação de requisitos tendo em conta esses mesmos factores.

Figura 1. Diagrama que define o processo de avaliação de um SGC de acordo com uma especificação de
requisitos, e as suas diversas fases.

Esse processo identifica três fases principais que são a:

 Análise de dados, tanto do SGC como da especificação de requisitos que são
essenciais, respectivamente, para a correcta aplicação da avaliação do sistema e
priorização dos requisitos a analisar.
 Avaliação, fase da qual se irá retirar os resultados da avaliação que servirão de
base para todo o processo descrito.
 Planeamento, onde se procede ao estudo dos resultados da fase anterior com o
objectivo de planear o desenvolvimento do software em estudo.

11
 1.4. Estrutura da Dissertação
Esta dissertação de mestrado encontra-se organizada da seguinte forma: no capítulo 2 são
apresentados os conceitos fundamentais para a correcta compreensão da dissertação, os
estudos relacionados com as áreas de evolução e avaliação de software e no último
subcapítulo é feita uma análise e comparação entre os principais SGCEs do mercado.
No capítulo 3 é feita uma a análise e descrição do SmartDocs e o seu enquadramento junto
dos SGCE analisados no capítulo anterior enquanto no capítulo 4 é feita uma análise e
descrição do MoReq2. No capítulo 5 os métodos de avaliação estudados no capítulo 2 são
aplicados utilizando como referência o SmartDocs e o MoReq2 e são tiradas as primeiras
conclusões sobre os mesmos.
No capítulo 6 são retiradas as conclusões finais dos resultados do capítulo anterior e
segundo estas é generalizado um processo de avaliação de SGC de acordo com uma
especificação de requisitos. É também feita uma descrição de um projecto de mestrado feito
em colaboração com um colega, que aplica os resultados obtidos nesta dissertação de
mestrado.
Por fim o capítulo 7 apresenta as conclusões finais e propostas para trabalho futuro.

12
 2. Estado da Arte
2.1. Conceitos Fundamentais
Para uma correcta compreensão deste projecto de dissertação é fundamental perceber os
termos definidos nesta área da gestão de informação. De maneira a ser rigoroso nos termos,
1
as definições aqui identificadas foram obtidas da norma ISO 15489, do site da AIIM e o site da
ARMS2. A norma ISO 15489 é uma das principais normas relevantes para a análise, desenho e
concretização de SGDA (sistemas onde incidem as recomendações do MoReq). A AIIM é uma
organização reconhecida internacionalmente na área, que tem como objectivo auxiliar os
utilizadores a perceber os desafios por detrás da gestão documental, conteúdos, documentos
de arquivo e processos de negócio. A ARMS é a secção de arquivo das Nações Unidas.

2.1.1. Tipos de Conteúdo

Um objecto de informação produzido numa organização, que genericamente podemos
designar de “conteúdo” pode ser físico ou digital, pode ser simples tratando-se apenas de um
ficheiro ou complexo no caso de vários, pode ser texto, imagem, vídeo, etc. Resumidamente
um conteúdo pode ser tudo o que contenha informação.
Um documento é definido como um objecto ou informação armazenada que pode ser
tratada como uma unidade. Com base no conceito de conteúdo, um documento é um
agrupamento lógico de conteúdos de maneira a poder ser tratado como uma unidade.
O conceito documento de arquivo é definido pela norma ISO 15489 como:
 Informação criada, recebida e gerida como evidência por uma organização ou
pessoa por obrigação legal, ou num processo de negócio.
Por sua vez o comité sobre documentos de arquivo electrónicos do International Council on
Archives (ICA) definiu o mesmo termo como:
 Informação guardada produzida ou recebida no início, durante ou fim de uma
actividade individual ou institucional e que contem conteúdo, contexto e
estrutura suficiente para servir como evidência de uma actividade.
Se olharmos para as duas definições reparamos que apesar de diferentes ambas
concordam que um documento de arquivo é informação que é utilizada como prova e como tal
tem requisitos de gestão específicos tais como a sua preservação a longo prazo. Esta definição
explica assim as afirmações da AIIM, que escreve que qualquer conteúdo pode ser designado
como um documento de arquivo e da ARMS que afirma que um documento de arquivo é um
documento com atributos específicos.
É importante ainda referir que a palavra documento de arquivo é adaptada da palavra
inglesa record que tem como tradução directa para português a palavra registo. A razão para
várias organizações portuguesas da área da informação, como a Direcção-Geral de Arquivos,

1
http://www.aiim.org/
2
http://archives.un.org/unarms/

13
não usarem a tradução registo é para que esta não seja confundida com outro termo, definido
pela norma ISO 15489, pela AIIM e outras organizações internacionais, que é o registration
(acto de atribuir um identificador único no sistema a um documento de arquivo) que tem
também como tradução directa para português a palavra registo. Esta ressalva é apenas
importante porque ainda existe alguma confusão em publicações da área e a palavra registo é
usada para referir um documento de arquivo.

2.1.2. Tipos de Sistemas de Gestão de Conteúdos

Como já referido existem vários tipos de SGC que diferem entre si pelo tipo de conteúdo
que objectivam gerir. Os termos mais utilizados para definir estes sistemas são:
 Sistema de Gestão Documental, responsável por gerir a criação, revisão, aprovação e
consumo do documento, ou seja, as várias etapas do seu ciclo de vida.
 Sistema de Gestão de Documentos de Arquivo, responsável pela eficiente e
sistemática gestão do documento de arquivo em todo o seu ciclo de vida, incluindo os
processos de captura e preservação como evidência de uma actividade.
 Sistema de Gestão de Conteúdos Web, responsável pela gestão de conteúdo Web em
todo o seu ciclo de vida, incluindo os processos de publicação na rede.
 Sistemas de Gestão de Processos de Negócio, que permitem a criação, execução,
monitorização e optimização de múltiplos processos de negócio automáticos,
envolvendo pessoas ou sistemas.
 Sistemas de Gestão de Conteúdos Empresariais. Segundo um modelo criado pela AIIM
é um sistema que tem integrado os sistemas referidos acima e um sistema de
colaboração que oferece funcionalidades para auxiliar e optimizar a comunicação e
partilha de informação entre os utilizadores do sistema.

2.2. Evolução de Software

Com a crescente utilização de software na sociedade tornou-se uma necessidade que os
sistemas informáticos respondam com rapidez e eficácia à mudança de requisitos e ambiente
da área de negócio em que o produto se insere. A intenção de qualquer empresa fornecedora
de produtos de software de evoluir o seu produto com o MoReq está integrada numa área da
engenharia de software em claro crescimento: a evolução de software.
A evolução de software, ou manutenção de software como também é chamada, é definida
na norma IEEE 1219 como a modificação de um produto de software acabado para corrigir
falhas, aumentar o desempenho ou outros atributos, ou adaptar o produto a um ambiente
modificado. Uma definição semelhante é dada pela norma ISO 12207, que define o termo
como a actividade de modificar o código e documentação de um produto de software para
responder a uma necessidade de correcção ou melhoria, preservando a integridade do
software (ISO95 Int. Standards Organisation 1995).
Tanto o termo evolução de software, como manutenção de software são amplamente
utilizados e fazem parte desta área. Historicamente o termo de manutenção foi o primeiro a ser

14
largamente reconhecido, grande parte devido ao conhecido artigo de Canning: “That
Maintenance Iceberg” de 1972 (Canning 1972) e também à categorização das actividades de
manutenção introduzida em 1976 por Swanson (Swanson 1976). O termo evolução surgiu
devido à pouca abrangência da palavra manutenção que, como Parnas e outros apontaram,
está mais relacionada com assegurar o funcionamento de um sistema sem alterar o seu
desenho. A palavra evolução dá assim a ideia de uma necessidade de mudança envolvendo
novos desenhos de sistema que evoluem de antigos (Parnas 1994) (Lehman, Perry e Ramil,
Implications of evolution metrics on software maintenance 1998).
Um dos pioneiros da área e dos primeiros a usar o termo evolução de sistema foi Lehman
que no seu estudo da evolução do sistema operativo OS360 da IBM, definiu as intituladas Leis
da Evolução (Lehman, Programs, Life Cycles, and Laws of Software Evolution 1980, Lehman,
Perry e Ramil, Implications of evolution metrics on software maintenance 1998):
1. Mudança contínua – um sistema torna-se progressivamente menos satisfatório ao
longo do tempo a menos que se adapte constantemente a novas necessidades.
2. Aumento de Complexidade – um sistema torna-se progressivamente mais complexo
a menos que sejam feitas mudanças para reduzir a complexidade.
3. Auto-Regulação - O processo de evolução de software é auto regulado em relação à
distribuição de produtos e processos que são produzidos.
4. Conservação da Estabilidade da Organização – Não existe crescimento de
actividade de evolução do sistema ao longo do tempo, ou seja, a quantidade de trabalho em
cada release do sistema é constante.
5. Conservação da Familiaridade – A quantidade de novo conteúdo em cada
lançamento do sistema tem tendência para ser constante ou decrescer ao longo do tempo.
6. Crescimento Contínuo – A quantidade de funcionalidades num sistema vai aumentar
ao longo do tempo de maneira a satisfazer os utilizadores.
7. Qualidade Decrescente – A qualidade de um sistema é vista como decrescente ao
longo do tempo a menos que o desenho do sistema tenha sido cuidadosamente mantido e
adaptado a novas restrições operacionais.
8. Feedback do Sistema – O sucesso de evolução de um sistema exige o
reconhecimento de que o processo de desenvolvimento é um ciclo envolvendo vários
agentes e os seus feedbacks.
É no seguimento e estudo das leis de Lehman que as actividades de evolução de software
se baseiam e objectivam.
Outro trabalho muito relevante na área foi a categorização das actividades de manutenção,
introduzidas por Swanson que definiu 4 classes principais de actividades de manutenção:
Adaptação, Perfeição, Correcção e Prevenção (Swanson 1976). Na prática, esta classificação
ainda é usada hoje em dia, mas actualizada pela norma ISO/IEC 1476 com novas definições e
novos termos (ISO/IEC-14764 2006):
1. Manutenção Correctiva, que inclui mudanças para reparar falha no código.

15
 2. Manutenção Adaptativa, onde se incluem alterações de infra-estrutura técnica.
3. Manutenção Perfectiva, inclui todas as alterações com o objectivo de melhorar o
sistema como adicionar novas funcionalidades, aumentar a performance, ou melhorar a
documentação.
4. Manutenção Preventiva, mudanças feitas para facilitar a futura manutenção e evolução
do sistema, como reorganizar dependências internas para melhorar coesão e introdução de
módulos.
No entanto muitos investigadores da área defendem que as categorias de Swanson são
insuficientes para classificar correctamente todas as actividades e processos da evolução de
software e procuram hoje novas taxionomias. Um dos trabalhos mais relevantes nesse sentido
foi feito por Ned Chapin (Chapin, et al. 2000).
Chapin criou a sua própria classificação refinando a classificação de Swanson (Swanson
1976) tendo em conta que as alterações a um software podem ocorrer a três níveis diferentes:
software, código e funcionalidade do utilizador, em que cada nível dá origem a tipos de
actividades diferentes que foram agrupadas em quatro grupos: Interface de Suporte,
Documentação, Propriedades de Software e Regras de Negócio. A Figura 2, retirada de
(Chapin, et al. 2000) resume o esquema base utilizado, onde se pode também verificar que
dentro de cada grupo existe mais uma refinação da actividade.

Figura 2. Tipos de Evolução e Manutenção de Software

O grupo A (Interface de Suporte) diz respeito à condição antes e depois do software. Se

esta se manteve, então o software foi usado como referência e as actividades fazem parte do
sub-grupo A1, A2 ou A3. O primeiro sub-grupo diz respeito a actividades de treino dos
stakeholders, como por exemplo aulas de formação aos utilizadores, o segundo envolve

16
actividades de consulta, como estudar alterações ao sistema ou questionar consumidores
sobre a eficácia do sistema, e o terceiro concentra-se nas actividades de avaliação do sistema
que permitem ter uma visão completa do mesmo e assim agir correctamente na sua evolução.
O segundo grupo engloba as actividades de mudança de documentação, que se divide em
dois tipos de actividades:
 Reformativa, que consiste em actividades de reformulação da documentação para que
esta esteja de acordo com as necessidades dos stakeholders.
 Actualizadora, onde o objectivo das actividades é o de garantir que o conteúdo é
actualizado de maneira a que este seja o mais correcto possivel.
Se o código do software foi alterado mas não resultou em mudanças nas funcionalidades do
sistema, então as actividades de evolução estão enquadradas no grupo C. As actividades em
C1 dizem respeito a actividades de melhoramento, como substituir componentes e algoritmos
por outros mais simples ou elegantes, C2 diz respeito às mudanças de manutenção
preventivas que Swanson identificou. As mudanças para melhorar o desempenho do sistema
fazem parte de C3 e por último C4 inclui as mudanças adaptativas, como alterações para
garantir a conformidade com outra plataforma técnica, ou sistema operativo.
Por último temos o grupo das regras de negócio em que classificamos as actividades
como:
 Reductivas, se as mudanças implementadas/alteradas reduzirem, ou restringirem, as
funcionalidades do utilizador, já existentes no sistema.
 Correctiva, quando a mudança é para corrigir ou refinar alguma funcionalidade
existente.
 Melhorativa, quando as alterações implicam a adição, substituição, ou expansão das
funcionalidades do software.
A classificação de Chapin (Chapin, et al. 2000) permite não só perceber os tipos de
actuações que estão associados à evolução de software mas também que esta é uma área
enorme em que cada actividade apresenta os seus desafios e problemas. A necessidade e o
porquê de se investir, e estudar, as actividades apresentadas são bem evidentes pelas Leis da
Evolução de Lehman (Lehman, Programs, Life Cycles, and Laws of Software Evolution 1980).

2.3. Avaliação de Software

Um dos tipos de actividades de evolução de software, como foi visto no subcapítulo
anterior, diz respeito à avaliação de software (grupo A3). Dentro dessas actividades temos
processos de auditoria, pesquisa, examinação, testes de regressão, estudos de sistemas,
testes de diagnóstico, cálculo de métricas para avaliar o sistema, entre outras que partilham o
mesmo objectivo: criar um entendimento do sistema necessário para o poder evoluir. Na
classificação de Chaplin a actividade de avaliação do sistema é inclusive estabelecida como
defeito no grupo de interface de suporte porque, segundo o autor, é a actividade que utiliza
mais de metade do tempo dispensado na evolução/manutenção de software (Chapin, et al.
2000).

17
 O objectivo da Fujistu em alinhar o seu produto com o MoReq necessita então da fase
essencial que é a avaliação de um sistema, em que neste caso particular, o instrumento de
avaliação utilizado é uma especificação de requisitos (MoReq). É neste tipo específico de
avaliação que esta dissertação se centra.
A avaliação de software é, como se pode verificar no subcapítulo anterior, uma actividade
antiga no mundo da evolução de software, mas a avaliação de SGD é bastante recente. Por
este tipo de sistemas terem características, funcionalidades e objectivos específicos, a sua
avaliação também tem que ser específica e ponderada.
Uma das primeiras abordagens à avaliação de SGD foi feita numa conferência organizada
pela AIIM em 2002 com o tema “A Informação Empresarial e a Gestão de Conteúdo” (The
Enterprise Information & Content Management Forum), por Len Asprey e Michael Middleton,
que apresentaram um artigo intitulado: especificar requisitos e seleccionar o fornecedor da
aplicação para gestão de documentos simples e de arquivo ("Specifying your requirements and
selecting your supplier for records and document management applications") (Asprey e
Middleton 2002).
No artigo de Asprey e Middleton estes suportam a ideia que o mercado de SGD está em
grande crescimento com a crescente criação de produtos e requisitos para os mesmos. Por
essa razão é importante que existam orientações para seleccionar os requisitos necessários e
escolher o produto de software que mais se adequa às necessidades dos consumidores.
Em relação ao primeiro problema, seleccionar os requisitos necessários, existem vários
desafios como determinar a função dos documentos no contexto do negócio, determinar
requisitos relevantes para a gestão dos documentos, especificar as funcionalidades
necessárias e definir requisitos de arquitectura, desempenho e administração, entre outros.
Para resolver estes problemas os autores do artigo sugerem a criação de uma especificação
de requisitos que detalhe as necessidades dos utilizadores e do sistema, incluindo requisitos
funcionais, não funcionais e de domínio. Na criação da especificação é aconselhável seguir os
passos do processo de análise definidos por Shelly, Chasman e Rosenblatt em 2001 (Shelly,
Chasman e Rosenblatt 2001) que são:
1. Determinar os requisitos, que consiste principalmente em perceber os processos de
negócio da organização.
2. Analisar os requisitos, que se focam em várias tecnologias e processos de negócio
de maneira a poder optimizá-los ou melhorá-los.
3. Especificar os requisitos, de integração ou adaptação com outros sistemas na
organização.
4. Validar os requisitos, que consiste em confirmar o documento por todas as partes
interessadas e com responsabilidade no sistema e negócio.
Para a conclusão de todo o processo de definição e análise de requisitos existem as
seguintes técnicas que podem ser usadas: entrevistas, recolher dados e analisá-los,
amostragem e/ou utilização de ferramentas analíticas para análise de funções, modelação de

18
processos, diagramas de fluxos de dados, modelos de dados e descrições detalhadas de
processos (Asprey e Middleton 2002).
No artigo os autores não esqueçam também de relembrar que foi lançado em 2001 a
primeira versão do MoReq que pode, e deve, ser usado como fundação para a análise e
definição dos requisitos.
Em relação à escolha de um SGD esta necessita de vários passos que identificados são
também os desafios do problema:
1. Desenvolver uma estratégia para procura e selecção dos produtos que satisfazem as
necessidades do negócio.
2. Desenvolver uma estratégia de avaliação dos produtos.
3. Seleccionar informação dos produtos que vão de encontro aos requisitos específicos.
4. Escolher o fornecedor que tem o produto adequado e a experiência do domínio,
combinado com os recursos necessários para a manutenção e actualização do produto.
5. Negociar o contrato com o fornecedor para aceitação de todas as partes.
O principal desafio no entanto, segundo o autor, é claramente a avaliação do produto. Com
uma estratégia bem definida que dá origem a uma avaliação sucinta e qualitativa do produto o
processo de decisão torna-se muito mais fácil (Asprey e Middleton 2002). As técnicas
recomendadas pelos autores para avaliação do produto são:
 Utilização de listas de verificação, que são desenhadas para ajudar organizações a
confirmar as capacidades do produto.
 Listas ponderadas, que ajudam a diferenciar a relevância entre requisitos e
funcionalidades do produto.
 Análise de Intervalos, técnica utilizada para identificar falhas, ou novas funcionalidade
do produto.
Os objectivos, os desafios e as partes interessadas desta dissertação não são os mesmos
que os identificados no artigo de Asprey e Middleton (Asprey e Middleton 2002). O objectivo
passa não por escolher um fornecedor de SGD, mas sim avaliar um e centrar a análise na
perspectiva do fornecedor em vez do consumidor. O processo de avaliação é no entanto
semelhante em muitos aspectos, visto que a avaliação é feita através de uma lista de
requisitos, o que resulta em semelhantes técnicas de avaliação, mas com diferente análise de
resultados. O objectivo deste subcapítulo é perceber como funcionam as técnicas
mencionadas, vantagens e desvantagens. No capítulo 5 (Análise do SmartDocs segundo o
MoReq2) essa análise será feita na perspectiva do objectivo que se pretende depois de
utilizados os métodos para avaliar o SmartDocs.

2.3.1. Listas de Verificação

Uma lista de verificação para avaliação de software consiste numa lista de itens que são
estruturados segundo categorias relevantes do produto. Os itens podem ser perguntas,
requisitos e/ou conceitos do sistema. Dependendo da cobertura da lista, quantidade de

19
categorias e nível de detalhe, esta pode conter centenas de itens para avaliação (Tergan
1998). Tipicamente o tipo de resposta a uma lista de verificação é sim, ou não, indicando se o
item é cumprido, ou não, pelo produto, mas podem ser usados tipos de resposta quantitativos
que indicam estados de conformidade intermédios como ilustra a tabela 1. Com o uso de
respostas quantitativas é possível depois calcular a soma das respostas e atribuir uma
pontuação ao produto podendo ser feita uma análise do resultado por categorias ou conjunto
de itens (Prichard, Micceri e Barret 1989).

Valor Significado

0 Não - O produto não cumpre o item.

1 Baixo – O produto cumpre o requisito apenas parcialmente e necessita de melhoria

significativa.

2 Abaixo da Média – O produto praticamente cumpre o requisito sendo apenas

necessária ligeira melhoria.

3 Sim – O produto cumpre o item da lista em toda a sua extensão e não necessita de
melhoria.

4 Acima da Média – O produto cumpre o item e apresenta melhorias em relação ao

mesmo.

5 Alto – O produto excede todas as expectativas em relação ao item e distingue-se

pela qualidade que o diferencia.

NA Não se Aplica – O produto não foi avaliado.

Tabela 1. Exemplo de resposta quantitativa em lista de verificação.

A popularidade e vantagens das listas de verificação estão relacionadas principalmente com

os seguintes factores (Tergan 1998):
 As listas de verificação permitem que o avaliador não tenha de se preocupar em criar
um método de avaliação próprio, podendo inclusive poupar muito dinheiro e tempo à
organização, que normalmente necessita de contratar especialistas de software para avaliação.

 As listas de verificação são fáceis de manusear. O processo de avaliação é simples,

visto que basta percorrer a lista e marcar o quanto o produto cumpre, ou não, o item da lista.
 As listas de verificação dão a impressão de uma avaliação completa, objectiva e
confiável através de um método simples e barato de avaliação.
No entanto existem também vários problemas associados às listas de verificação como
McDougall e Squires e outros identificaram (McDougall e Squires 1995) (Komoski 1987):
 A verificação utilizando uma lista concentra-se na semelhança e esquece a diferença e
qualidade do produto, em contraste com a lista.

 A avaliação é bastante subjectiva da opinião do avaliador, principalmente quando se

usa respostas quantitativas.

20
  A correcção e completude da lista são fundamentais para a qualidade da avaliação. Má
formulação dos itens, ou itens em falta na lista, podem levar a uma má avaliação.
 O mesmo critério de avaliação pode não fazer sentido para todos os itens, por
exemplo, se o item for determinista não faz sentido ter o critério de resposta quantitativo.

2.3.2. Listas Ponderadas

A avaliação por Listas Ponderadas é uma das mais utilizadas para avaliação de software e
baseia-se em listas de verificação. O método de avaliação passa pelos seguintes passos
(Jadhav e Sonar 2009):
1. Atribuir pesos aos itens da lista que reflectem a sua importância na mesma.
2. Determinar o intervalo de respostas quantitativas possíveis em relação a cada item.
Diferentes itens podem ter diferentes intervalos de resposta.
3. Atribuir resposta a cada um dos itens.
4. Calcular a pontuação do produto utilizando a seguinte fórmula:

( ) ∑

Onde W j é o peso do item j e Sij é a resposta quantitativa i ao item j.

As vantagens desta avaliação são as mesmas que as listas de verificação, acrescentando
no entanto que este método permite uma análise mais objectiva e correcta do produto.
Em relação às desvantagens comparando com o método anterior, as três primeiras
mantêm-se enquanto a quarta é descartada, visto que este método permite diferentes critérios
de avaliação para diferentes itens.

2.3.3. Análise de Intervalos

A análise de intervalos é, na sua prática habitual, uma técnica para analisar as diferenças
entre o estado actual de software e aquele que se pretende atingir. A definição de intervalo na
análise é o espaço entre o estado onde o software se encontra e onde este quer estar. Este
tipo de análise ajuda a perceber a quantidade de trabalho que necessita ser feito para evoluir o
software e clarificar quais as principais diferenças entre os dois estados (Levine, A Sample Gap
Analysis Explained 2010) (Levine, Learn About Gap Analysis Methods: Wich is the Best? 2010).
Para estabelecer correctamente a ponte entre os dois espaços é preciso perceber não só o
estado que se quer atingir, mas também o estado onde nos encontramos, ou seja, neste caso
particular é preciso conhecer o sistema correctamente e perceber quais os seus pontos fortes
que podem ser usados para atingir o estado que se pretende.
Um dos métodos conhecidos na análise de intervalos é o método SWOT (Strengths,
Weakness, Opportunies and Threats), que como o próprio nome indica consiste em identificar
no produto, ou projecto de evolução, os pontos fortes e fracos, as oportunidades de evoluir e os
riscos associados (Levine, Learn About Gap Analysis Methods: Wich is the Best? 2010)
(Sharma 2010).

21
 2.4. Sistemas de Gestão Documental
Para o desenvolvimento da solução desta tese de mestrado foi utilizado o SmartDocs como
produto de teste e validação. De maneira a garantir que a resposta ao problema não é válida
apenas para um SGD foi feita uma análise a diversos produtos no mercado. O objectivo é
assegurar que o produto da Fujitsu nas suas funcionalidades nucleares se assemelha aos
produtos analisados e como consequência pode ser usado como caso de estudo e teste.
No directório de produtos do Google1 são identificados 244 produtos que oferecem uma
solução de gestão documental. Tendo esse número em consideração foi necessário fazer uma
selecção de produtos a analisar, feita com base nos estudos de mercado realizados pela
Gartner.
A Gartner2 é uma empresa de investigação de tecnologia informática responsável por, todos
os anos, divulgar um estudo do mercado de SGCE (ECM – Enterprise Content Management)
intitulado “Gartner ECM Magic Quadrant”. No estudo, os sistemas são classificados em relação
à sua:

 Habilidade de execução, medida que engloba vários factores como a viabilidade

financeira do vendedor, resposta do mercado, desenvolvimento do produto, estatísticas de
vendas e apreciação do consumidor. (J. Lehman 2008)

 Completude da Visão, que reflecte a inovação do fornecedor, se o sistema segue ou

não o mercado e se inova no sentido do desenvolvimento do mercado, segundo a visão da
Gartner. (J. Lehman 2008)

Figura 3 Significado da Classificação no Quadrante Gartner

1
http://www.google.com/Top/Computers/Software/Document_Management/
2
http://www.gartner.com/technology/home.jsp

22
 Depois de classificados em relação às medidas descritas, os produtos são introduzidos num
quadrante que reflecte as suas classificações tal como explicado na Figura 3, retirada de (J.
Lehman 2008).
Os produtos analisados nesta dissertação são então dos quadrantes à direita do quadrante
de 2009, último divulgado até à data pela Gartner (ver Figura 4), visto que são os que melhor
representam o mercado e o seu desenvolvimento futuro. Dentro dessa selecção e porque é
desnecessário analisar todos os sistemas, foram escolhidos para análise aqueles que mais
informação pública têm disponível. De realçar ainda que os produtos escolhidos são SGCEs,
mas que apenas foram analisadas as funcionalidades de SGD e SGDA.

Figura 4 Gartner ECM Magic Quadrante de Outubro de 2009

2.4.1. Alfresco
Alfresco é a plataforma líder de mercado Open Source para gestão de conteúdos
empresariais tendo já cerca de um milhão de downloads, 39.000 membros de comunidade,
21.000 instalações activas e mais de 300 clientes em diversos sectores desde o sector
bancário, comunicação social e educação até governamentais. (Alfresco Software, Inc)
Apesar de o produto inicial Alfresco ser uma solução de gestão documental, em Maio de
2006 foi anunciada a intenção de expansão para a gestão de conteúdo Web através da
contratação da equipa técnica e gestores da Interwoven (Business Wire, 2006). A partir dessa
contratação o sistema foi expandido e actualmente o Alfresco Enterprise Edition é uma
plataforma que oferece cinco sistemas integrados: gestão documental, gestão de documentos
de arquivo, serviços de colaboração, gestão de documentos Web e serviços de conteúdo
integrados (Alfresco Software, Inc).

23
 Serviços de Modelação de Conteúdo
• Sistema de Ficheiros Virtuais.
• Sincronização por CIFS.
• Acesso por Portal utilizando JSR-168.
• Extracção automática de metadados.
• Conversão de Ficheiros.

Serviços de Biblioteca
• Controlo de Versões.
• Ferramentas de Auditoria.
• Relações entre Documentos.

Serviços de Pesquisa
• Pesquisa simples e avançada.
• Pesquisa através do Internet Explorer ou Firefox.

Serviços de Colaboração
• Suporte à criação de espaços partilhados.
• Suporte através de fóruns.
• Criação de Fluxos de Trabalho simples através de correio electrónico.
• Criação de Fluxos de Trabalho complexos através de uma integração jBPM.
• Suporte à gestão de tarefas.
• Notificações por correio electrónico e RSS.
• Criação de Fluxos de Trabalho para gestão do ciclo de vida dos documentos.

Serviços de Segurança
• Gestão de permissões de utilizadores, grupos de utilizadores e/ou papéis de
utilizadores.
• Segurança ao nível do documento.
• Autenticação por NTLM ou DLAP.

Figura 5. Funcionalidades do módulo de gestão documental Alfresco (Shariff, 2007)

O módulo de gestão documental do Alfresco tem uma gama de funcionalidades (Broadbent,

2009) (Anderson, 2008), listadas na Figura 5, que se dividem nos seguintes temas:

 Serviços de modelação do conteúdo, que permitem classificar e identificar o

documento no sistema de ficheiros virtuais da plataforma.
 Serviços de biblioteca, para controlo de alterações e acções do documento, assim
como facilitar o acesso à informação por parte do utilizador.
 Serviços de pesquisa, para recuperação de qualquer documento armazenado num
repositório Alfresco.
 Serviços de Colaboração, que fornecem ao utilizador o suporte necessário para a
utilização do sistema com outros utilizadores.
 Serviços de Segurança, que asseguram a confidencialidade e autenticidade dos
documentos e utilizadores do sistema.
O módulo de gestão documental de arquivo Alfresco, certificado pelo Departamento da
Defesa dos EUA como cumpridor da norma 5015.02. adiciona às funcionalidades (Powell,
2008) (Broadbent, 2009) listadas acima, os seguintes serviços:

24
  Serviços de Gestão do Ciclo de Vida do Documento, através de um plano de
classificação pré-estruturado que permite classificar o documento e consequentemente
determinar o seu ciclo de vida.
 Serviços de Suporte ao Destino do Documento, assegurando que todos os
documentos são tratados convenientemente no fim do seu período útil de vida segundo as
politicas da organização.
As funcionalidades dos serviços descritos são listadas na figura 6.

Serviços de Gestão e Controlo do Ciclo de Vida do Documento

• Criação de um Plano de Classificação.
• Numeração automática dos documentos de arquivo.
• Categorização do Documento, determinando o seu ciclo de vida e
classificação.
• Gestão Automática do Ciclo de Vida.
• Relatórios configuráveis sobre os documentos de arquivo.
• Pesquisa rápida.

Serviços de Suporte ao Destino do Documento

• Criação de políticas de retenção.
• Conversão automática de ficheiros para preservação.
• Exportação para "repositorio arquivo".
• Suporte ao destino do Documento de Arquivo.

Figura 6. Funcionalidades do módulo de gestão de Documentos de Arquivo Alfresco

2.4.2. Spring CM
SpringCM é um SGCE, que oferece gestão documental e soluções de fluxo de trabalho para
negócios e organizações. A companhia do mesmo nome tem sede em Chicago e tem o apoio
da Fundation Capital uma empresa que fez um grande investimento na companhia em Janeiro
de 2006, tornando-a uma das empresas de renome na área da gestão de conteúdos
empresariais.
A SpringCM divide as funcionalidades do seu produto (SpringCM) nas seguintes áreas:
 Captura e Armazenamento de Documentos, de variadas maneiras podendo o
utilizador utilizar aquela que for mais conveniente para o processo de negócio.
 Gestão Documental, onde se incluem as funcionalidades de pesquisa, manutenção,
revisão e controlo dos documentos.
 Fluxo de Trabalho e Colaboração, onde se encontram as funcionalidades para
optimizar operações de negócio.
 Entrega de Documentos, onde é dado foco aos vários métodos de envio de
documentos que o sistema permite.
 Gestão de Documentos de Arquivo, onde se incluem as funcionalidades para um
eficaz controlo e gestão da retenção e destino dos documentos.
 Gestão de Relatórios, que fornecem a informação necessária para o controlo das
actividades do sistema e suas optimizações.

25
 As funcionalidades presentes em cada uma das áreas seguintes encontram-se listadas na
figura 7.

Captura e Armazenamento de Documentos

• Captura de Documento através de Aplicações Office, Windows Explorer, Web

Browsers e FTP.
• Armazenamento automático de Documentos.
• Captura de Correio Electrónico.
• Captura através de digitalização.
• Captura através de Serviços Web.
• Captura de Documentos em Bloco.
• Captura de Metadados e Indexação
• Reconhecimento de texto e OCR

Gestão de Documentos

• Check-in/Check-out de Documentos.
• Anotação de Documentos.
• Controlo de Versões.
• Pesquisa simples e avançada.
• Plano de Classificação.
• Gestão de permissões de acesso.
• Rotinas de Auditoria.

Fluxo de Trabalho e Colaboração

• Criação de Fluxos de Trababalho Simples e Complexos.

Entrega de Documentos

• Envio de Documentos por Correio Electronico, Fax ou Correio.

• Assinatura electrónica para aprovação do documento.
• Criação de Pastas Publicas acessiveis pela Internet.
• Conversão de ficheiros para PDF.

Gestão de Documentos de Arquivo

• Criação de períodos de retenção para documentos.

• Atribuição automática de períodos de retenção consoante a classificação do
documento.
• Suporte a pausas legais.

Gestão de Relatórios

• Criação de Relatórios Simples e Avançados configuráveis.

• Criação de Templates de Relatórios.

Figura 7. Funcionalidades do sistema de gestão documental SpringCM

2.4.3. Open Text ECM Suite

A Open Text é uma companhia líder em software de gestão de conteúdos empresariais que
tem como objectivo ajudar as organizações a gerir e aproveitar o valor do seu conteúdo

26
empresarial. A Open Text foi fundada em 1991 e suporta hoje mais de 50 milhões de
utilizadores em 114 países. O produto principal e do qual advêm muito do sucesso e reputação
da companhia é o Open Text ECM Suite (OpenText s.d.).
A Open Text na informação divulgada sobre o seu produto prefere, ao contrário dos outros
produtos já analisados, centrar-se no âmbito das funcionalidades do seu sistema, não referindo
tecnologia e não sendo específica. Assim o módulo de gestão documental do Open Text ECM
Suite tem as seguintes áreas de funcionalidade (OpenText, 2009):
 Serviços de Repositório e Biblioteca, que permitem capturar, armazenar e organizar
informação em pastas, espaços de trabalho, e documentos compostos personalizados.
 Classificações de Conhecimento, consiste em dar identidade ao documento
atribuindo-lhe classificações pré-existentes, categorias ou atributos aos seus metadados.
 Recuperação de Informação, com funcionalidades de pesquisa através de texto livre,
metadados, XML e linguagem natural. O resultado das pesquisas pode depois ser ordenado,
resumido, agrupado ou destacado, entre outros.
 Suporte de todos os tipos de ficheiros, com acesso a todas as operações do
sistema.
 Controlo de Versões.
 Fluxo de Trabalho Integrado, com operações de sistema flexíveis para a criação de
processos de revisão e aprovação de documentos.
 Rotinas de Auditoria, que garantem o total controlo do sistema.

 Controlo de Acesso, através de um sistema de gestão de permissões.

 Integração com o Ambiente de Trabalho, assim como aplicações Office.
O módulo de gestão de documentos de arquivo para além da simples gestão dos prazos de
retenção e suporte ao destino dos documentos inclui funcionalidades de (OpenText, 2009):
 Preservação de Documentos de Arquivo Essenciais, ou seja, permite a
identificação de documentos como sendo vitais ou oficiais para que o sistema coloque em
prática medidas de salvaguarda e recuperação extras, e impeça a alteração desses
documentos.
 Pausa legal, que consiste em suspender as acções de destino dos documentos para
que estes possam ser auditados.
 Gestão de Documentos físicos, através de códigos de barras que permitem a gestão
dos locais onde os documentos físicos estão guardados assim como controlar a sua circulação
entre espaços físicos.

2.4.4. FileNet P8
A plataforma FileNet P8 é o produto mais conhecida da empresa FileNet, companhia
adquirida pela IBM em 2006, que desenvolve software de suporte à gestão de conteúdos e
processos de negócio de uma empresa. A plataforma reúne num único produto módulos de
gestão de, conteúdos, processos de negócio e documentos de arquivo (Zhu, et al., 2009).

27
 O gestor de documentos de arquivo centra as suas funcionalidades na manutenção de um
plano de classificação sobre o qual os documentos são identificados e categorizados o que irá
determinar o prazo de retenção do documento. Ao longo do prazo de retenção o sistema
permite controlar os acessos e permissões sobre os documentos ao nível do plano de
classificação, utilizadores e seus grupos. No fim do prazo o sistema suporta vários destinos do
documento como a destruição do objecto, armazenamento em arquivo, revisão, etc. O sistema
tem também a possibilidade de efectuar uma pausa legal nos documentos impedindo que estes
sejam destruídos para que seja efectuada uma auditoria (Zhu, et al., 2009) (Zhu, Chan, Flaig,
Wang, Wheeler, & Hogg, 2007).
O gestor de conteúdos acrescenta funções essenciais à gestão documental como a captura
através de várias aplicações (Ex: Outlook, Microsoft Office, ente outros), controlo de versões,
criação de fluxos de trabalho, rotinas de auditoria e relatórios, pesquisa simples e avançada,
ligação entre documentos, entre outros (Zhu, et al., 2009) (FileNet).

2.4.5. Comparação entre Sistemas

Analisados os sistemas é então possível criar uma visão geral das funcionalidades base que
um SGD contém. De realçar que isso não significa que todos os produtos analisados
funcionam da mesma maneira: as tecnologias utilizadas nas funcionalidades, a interface
utilizada, a velocidade da operação, a eficácia, entre outros factores, são características de
cada funcionalidade que fazem a diferença no produto final. Nesta análise apenas se levou em
conta o objectivo principal da funcionalidade.
As funcionalidades nucleares encontradas em todos os sistemas estão descritas na
tabela 2.

Área da
Âmbito da Área
Funcionalidade

Plano de Funções para criação e manutenção de uma estrutura ou base para o

Classificação armazenamento e identificação dos documentos.

Identificação e Inclui todas as funções que permitem uma melhor identificação do documento
Categorização como suporte de metadados, anotações, atribuir categorias, etc.

Diversos métodos de captura como aplicações de gestão de correio

Captura de
electrónico, aplicações Office, entre outras aplicações geradoras de
Documentos
conteúdo.

Categoria que inclui funcionalidades para uma melhor gestão dos

Serviços de Biblioteca documentos, como a conversão de ficheiros, criação de relações entre os
documentos, controlo de versões, rotina de auditoria, etc.

Pesquisa Pesquisa simples ou avançada das entidades do sistema.

Funções para criação e gestão de fluxos de trabalho que optimizem a

Fluxo de Trabalho deslocação de documentos entre utilizadores para aprovação, revisão, entre
outros.

28
 Gestão de Permissões de acesso, e outras acções, sobre os documentos,
Segurança utilizadores, grupos de utilizadores e papéis de utilizadores. Autenticação de
utilizadores.

Funcionalidades relacionadas com a criação, alteração e suspensão de

Prazo de Retenção
prazos de retenção e à associação dos mesmos aos documentos.

O sistema tem que ter funcionalidades que suportem os varios destinos do

Suporte ao Destino
documento após a sua vida útil como a sua eliminação, exportação para um
dos Documentos
repositório, posterior avaliação, entre outros.

Tabela 2. Descrição das funcionalidades base de um SGDA

29
 3. SmartDocs
O SmartDocs é um SGD desenvolvido pela Fujitsu Portugal contando com cerca de 170
instalações e mais de 20.000 utilizadores estimados principalmente no sector da Administração
Pública. O objectivo do programa é a gerir a documentação de forma rápida, fácil e eficiente
para um melhor controlo e utilização de toda a informação da organização.
O SmartDocs assenta sobre um repositório de dados, ao qual dá o nome de Arquivo, que
contém uma estrutura hierárquica de pastas e subpastas, onde se encontra a estrutura da
organização. À unidade básica de informação no sistema dá-se o nome de registo. O processo
de captura de um documento para o sistema é então realizado com a criação de um registo.
Na criação do registo o utilizador é solicitado a preencher a componente propriedade que
irá definir o tipo de registo criado. Para além dos campos óbvios obrigatórios como o autor, o
assunto, entidade responsável, entre outros, destaca-se os campos tipo, perfil e nível de
acesso.
O registo pode ser do tipo documento ou do tipo pasta. A diferença entre ambos é que o
tipo pasta cria um novo nível no Arquivo ao qual podem ser adicionados novos registos. O
campo perfil dependendo do tipo de registo escolhido será indicativo de que documento
estamos a tentar capturar, por exemplo, se escolhermos um registo do tipo documento
podemos ter então um perfil “factura” que indica o tipo de documento a capturar. O campo nível
de acesso permite identificar a confidencialidade do registo consoante diferentes categorias de
segurança.
Preenchendo a componente propriedade o registo disponibiliza então as seguintes
componentes:
 Capa. Componente onde são preenchidos os metadados do registo consoante o perfil
escolhido.
 Anexos. Nesta componente o utilizador pode acrescentar ao registo os ficheiros
digitais associados.
 Anotações. Descrições em texto livre que podem ser associados por vários
utilizadores com acesso ao registo.
 Processos Decisórios. Onde o utilizador pode requerer pareceres ou decisões sobre
o registo.
 Relações. Onde se permite criar uma relação com outros registos definindo o motivo
da relação.
 Localização. Pasta(s) onde o registo se encontra.
Dentro de cada componente é possível então aceder a várias funcionalidades do
sistema:
Na componente anexos existe a possibilidade de inserir um ficheiro através de várias
fontes: ficheiro local, digitalização e correio electrónico, e estes podem ser, editados,
apagados, copiados, exportados e convertidos para pdf. A cada alteração de um anexo o

30
sistema automaticamente cria diferentes versões do mesmo para evitar qualquer perca de
informação, permitindo ao utilizador repor versões antigas sem nunca perder as actuais. O
utilizador tem também a possibilidade de assinar o anexo caso este se trate de um formato de
ficheiro que permita assinaturas digitais. Um anexo depois de assinado pode ser finalizado não
permitindo que este seja alterado ou eliminado. Por fim na componente anexos é ainda
possível utilizar a tecnologia OCR para reconhecimento de caracteres em imagens ou a
tecnologia de leitura de códigos de barras para o preenchimento automático de metadados na
capa.
Nas anotações para além das simples funções de edição de texto livre existe tal como nos
anexos a possibilidade de criar uma assinatura digital. A uma anotação pode ainda ser
associado um alerta para notificar o utilizador de alguma acção a tomar sobre o registo.
Na componente Processos Decisórios o utilizador ao criar um processo decisório tem que
definir os utilizadores para os quais se destina o processo. Os utilizadores em questão são
então notificados que devem emitir uma decisão ou parecer, iniciar novo processo decisório ou
concluir o actual.
Na componente Relações para além do já referido existe ainda a função de “criar um
registo consequente” onde é possível criar uma cópia do registo com uma relação já criada
entre o original e a cópia.
Para além das funcionalidades presentes nas componentes de um registo o SmartDocs
possui ainda outras funcionalidades globais.
 Impressão de registos, permitindo seleccionar quais as componentes a imprimir.

 Certificar documentos. Consiste em imprimir a identificação do registo no documento

original através de uma certificadora.
 Duplicação de Registos, permitindo indicar quais as componentes a duplicar.
 Notificação de Registos, principal meio de circulação de registos no sistema, que consiste
em avisar um utilizador ou vários que é necessária actuar sobre o registo. Os utilizadores
avisados podem então ao receber a notificação, responder, reenviar ou concluir a
notificação.
 Históricos. O Sistema permite consultar o histórico de acções sobre um registo, um anexo
e ainda sobre o reencaminhamento de registos por notificações.
 Permissões. O SmartDocs possui um sistema de permissões baseado em matrizes de
acesso sobre utilizadores, ou seja, uma matriz que indica as funções permitidas para cada
utilizador ou grupo de utilizadores. As permissões podem ser definidas sobre um perfil, um
registo, um anexo, uma anotação e um processo decisório, possibilitando assim restringir o
acesso apenas a partes do registo.
 Descritores. A cada registo é possível atribuir palavras-chave (denominadas descritores)
que permitem uma melhor identificação do registo.
 Enviar Registo via e-mail, através da integração do SmartDocs com o Microsoft Outlook.

31
 Exportação e Importação de registos. A exportação cria um ficheiro com o formato sdr
(formato criado pelo Fujitsu Portugal) que contém toda a informação do registo de modo
compactado. A importação de registos é feita também através do formato sdr.
 Subscrição de registos. O utilizador ao subscrever um registo recebe notificações pelo
SmartDocs ou por e-mail de alterações ao registo, podendo personalizar o tipo de acções
que deseja ser notificado.
 Fluxo de Trabalho. O utilizador pode iniciar através de um registo um circuito de acções
pré-definidas pelo administrador. O sistema gere então o registo dentro do circuito
garantindo que quando todas as acções de uma etapa forem concluídas o sistema avança
para a próxima etapa.
 Relatórios. O sistema permite criar 3 tipos de relatórios sobre um registo:
o Relatório Simples, contendo apenas os campos base do registo (ex: tipo, referência,
perfil, titulo, etc.).
o Relatório de Perfil, contendo informação mais detalhada sobre o perfil e os seus
metadados.
o Relatórios Configuráveis, criados pelo administrador seleccionando qual a
informação a incluir no relatório.
 Delegação. Esta funcionalidade permite ao utilizador sempre que se ausentar delegar as
suas funções a um ou mais utilizadores permitindo que estes efectuem acções em seu
nome. O utilizador delegado pode assim utilizar a opção “trabalhar em nome de…” para
aceder à área do utilizador que o delegou e trabalhar por este. A informação de que se
trata de um delegado fica no entanto sempre presente no sistema e o utilizador que
delegou pode inclusive, ao regressar, consultar as acções que o delegado tomou por ele.
 Pesquisa. A funcionalidade de pesquisa está sempre disponível no sistema e é totalmente
configurável permitindo pesquisa por texto livre ou utilizando conectores lógicos. É possível
também uma pesquisa mais avançada onde podemos seleccionar se queremos pesquisar
nos campos (e quais) do perfil, das propriedades, da capa, dos anexos, dos processos
decisórios, da localização, dos descritores ou das notificações.
O produto SmartDocs inclui também uma ferramenta de administração que é instalada
aos administradores do sistema e através da qual podem aceder às funcionalidades
administrativas do sistema.
A ferramenta permite gerir todo o sistema incluindo utilizadores, perfis, níveis de acesso,
descritores, formas de notificação, processos decisórios, assinaturas digitais, entre outros. Das
funcionalidades disponíveis destacam-se as seguintes:
 Interoperabilidade. Necessita de um módulo adicional instalado mas permite
configurar a comunicação entre o SmartDocs e outros sistemas.
 Gestão de Repositório de Anexos. Permite modificar a localização dos anexos,
move-los, copiá-los ou criar outros repositórios.

32
  Auditoria. Através deste ponto de gestão o administrador pode efectuar consultas
sobre o histórico do sistema, o log e estatísticas. As consultas podem ser feitas sobre
um registo, e/ou um utilizador, e/ou uma acção especifica.
É através da ferramenta de administração que o utilizador pode também criar todos os
relatórios e modelos configuráveis do sistema.

3.1. Enquadramento com os outros sistemas

Tal como no subcapítulo 2.4.5 se fez uma comparação entre os varios SGC estudados no
que diz respeito às suas funcionalidades de SGDA é necessário fazer também o
enquadramento do SmartDocs com esses sistemas. A tabela 3 ilustra esse enquadramento
categorizando as funcionalidades descritas neste capítulo com as áreas de funcionalidade
identificadas no subcapítulo 2.4.5.

Área de
Funções Presentes no SmartDocs
Funcionalidade

Plano de Classificação Arquivo e as funções sobre este; Exportação e Importação de Registos.

Identificação e
Capa, Anotações e Localização do Registo; Descritores;
Categorização

Captura de Perfil do Registo; Anexos; Captura de Correio Electrónico através de

Documentos integração com o Outlook

Impressão de Registo; Certificar Documentos; Duplicação de Registos;

Serviços de Biblioteca Históricos de um Registo; Subscrição de Registos; Relatórios simples, de
perfil e configuráveis; Delegação;

Pesquisa Pesquisa e funções associadas.

Fluxo de Trabalho Fluxo de Trabalho e as funções associadas.

Segurança Sistema de Permissões; Assinaturas Digitais;

Não possui funcionalidades para gerir os prazos de retenção de um

Prazo de Retenção
documento.

Suporte ao Destino
Não possui funcionalidades para gerir o suporte ao destino dos documentos.
dos Documentos

Tabela 3. Funções do SmartDocs enquadradas com as áreas de funcionalidade de um SGDA.

Como se pode verificar pela tabela, o SmartDocs tem funcionalidades que se enquadram
em praticamente todas as áreas de funcionalidade de um SGDA excepto as áreas que incluem
as funcionalidades para gestão do prazo de retenção e suporte ao destino dos documentos. A
causa para essa ausência de funcionalidades é o facto de o produto da Fujistu ser um SGD
enquanto as funcionalidades dos sistemas analisadas são de SGDA. Como já referido no
subcapítulo 2.1.2 estes dois sistemas gerem tipos de conteúdo diferentes mas, tal como o seu
nome indica e o enquadramento regista, são sistemas com bastantes similaridades.
Pelo enquadramento feito podemos reparar que um SGD não possui funcionalidades para
gerir a preservação dos documentos a longo prazo. Esse facto é derivado do facto de um

33
documento não necessitar necessariamente de constituir informação ou prova de um processo
de negócio a longo prazo podendo ser apenas necessário num curto espaço de tempo após a
sua criação. Já um documento de arquivo é por definição, como apresentada no subcapítulo
2.1.1, um documento que é gerido como evidência de um processo de negócio ou uma
actividade da organização o que implica uma obrigatoriedade de preservação a médio/longo
prazo.
Na perspectiva de que um documento é apenas uma unidade de informação esta pode
inclusivamente não estar completa sendo necessária a sua finalização para ser considerada útil
a longo prazo tornando-se assim um documento de arquivo. Resumindo a principal diferença
entre os dois objectos é o objectivo com que são geridos implicando diferentes
comportamentos dos sistemas que o gerem mas funcionalidades semelhantes visto que ambos
se tratam de documentos. O MoReq2 na subsecção 10.3 intitulada “Gestão Documental e
Trabalho Colaborativo” apresenta a tabela 4 aqui reproduzida que identifica as principais
diferenças de comportamento entre um SGD e um SGDA.

An EDMS… An ERMS…

 allows documents to be modified;  prevents records from being

modified;

 allows documents to exist in several  allows a single final version of a

versions; record to exist;

 may allow documents to be deleted by  prevents records from being deleted

their owners; except in certain strictly controlled
circumstances;

 may include some retention controls;  must include rigorous retention

controls;

 may include a document storage  must include a rigorous record

structure, which may be under the arrangement structure (the
control of users; classification scheme) which is
maintained by an administrative role;

 is intended primarily to support day-to-  may support day-to-day working, but

day use of documents for ongoing is primarily intended to provide a
business. secure repository for business
records.

Tabela 4. Principais diferenças entre um SGD e um SGDA (EDMS: Electronic Document Management System ;
ERMS: Electronic Record Management System)

34
 4. MoReq
O DLM-Forum1 foi criado e oficializado por iniciativa da comissão europeia em 1997 para
servir como suporte à coordenação, cooperação, gestão e armazenamento adequado dos
arquivos públicos dos países membros. No entanto, o primeiro encontro do DLM-Forum foi
realizado em 1996 em Bruxelas e foi nele que se identificou a necessidade de criar uma
especificação compreensiva de requisitos para a gestão de documentos de arquivo
electrónicos. A comissão europeia tomou então a iniciativa de iniciar e gerir o desenvolvimento
dessa especificação, que mais tarde ficou conhecida como MoReq, modelo de requisitos para
a gestão de documentos de arquivo electrónicos.
A equipa que desenvolveu a especificação foi acompanhada durante todo o processo por
especialistas na área de gestão de documentos de arquivo de vários países tanto de
organizações públicas como privadas. O MoReq ficou disponível electronicamente pela
primeira vez em 2001 e foi publicado oficialmente pela comissão europeia em 2002.
Actualmente está disponível online no site Europa2 e encontra-se traduzido em 7 línguas,
incluindo o português. A versão portuguesa é uma tradução do original, adaptada à realidade
portuguesa. A especificação foi desenvolvida para ser aplicável, tanto por sectores públicos ou
privados, que pretendem adquirir ou avaliar um sistema de gestão de arquivos electrónicos.
Desde a disponibilização do MoReq que este provou ser uma especificação bastante útil e
começou a ser usado em diversos países na Europa. No entanto, com o rápido crescimento e
desenvolvimento das tecnologias de informação começou-se a reconhecer a falta de
actualização ao seu conteúdo de maneira a manter o seu valor como um modelo de referência.
Representantes do DLM-Forum iniciaram então discussões com a comissão europeia para a
possível fundação do MoReq2 e os resultados dessas discussões foram apresentados no
DLM-Forum 2005, onde se concordou em lançar uma versão actualizada do MoReq em 2007
que acabou apenas por ser lançada em 2008 intitulada MoReq2.
O MoReq2 contou imediatamente com a reputação do seu antecessor e rapidamente
começou a ser utilizado sendo que actualmente já se encontra traduzido em 5 línguas
diferentes (onde não se inclui o português). Um dado que permite perceber melhor essa
reputação é o facto de que desde o lançamento da primeira versão do MoReq terem sido já
criadas 23 novas especificações de requisitos baseadas no MoReq/MoReq2.
Na mesma reunião de 2005 foi também discutido o futuro do MoReq ficando definido que
este terá uma nova actualização em 2010 e no futuro terá versões específicas para diferentes
negócios tal como exemplifica a figura 8.

1
http://www.dlmforum.eu
2
http://ec.europa.eu/transparency/archival_policy/moreq/doc/moreq_en.pdf

35
 1
Figura 8 Planeamento das novas versões do MoReq

4.1. Análise e Resumo do MoReq2

Nesta dissertação a versão utilizada do MoReq será a intitulada MoReq2. As principais
diferenças em relação à versão anterior são:
 Framework de teste. Foi criada um conjunto de simples testes práticos que caso
consigam ser realizadas num software conclui-se que este cumpre os requisitos do MoReq2.
Cada capítulo da especificação tem um conjunto de testes e é indicado para cada um qual o
requisito que valida.
 Monitorização e Certificação. Foi criado um grupo independente que tem como
missão controlar e monitorizar traduções, extensões e alterações ao MoReq2, bem como
ajudar na compreensão e utilização da especificação.
 Estrutura da Especificação. Foram criados 13 novos subcapítulos de módulos
opcionais, um novo esquema de metadados maior, mais completo e simples e foi introduzido o
conceito do capítulo zero que deve ser especifico para cada país e deve fornecer informações
sobre:
o Traduções para as terminologias e conceitos importantes da especificação.
o Requisitos Legislativos do país.
o Requisitos provenientes de normas ou guias do país.
o Outros requisitos que possam ser considerados importantes nacionalmente.
o Sites, documentos e outros recursos que possam acrescentar valor ao capitulo.
 Conteúdo. Foram adicionados e alterados vários requisitos de maneira a garantir que
o MoReq2 se mantenha actualizado e correcto.
O MoReq2 tem actualmente 792 requisitos divididos em 13 capítulos e 9 anexos, com mais
de 70 subsecções. A versão em formato Word contém 377 paginas e mais de 91 000 palavras.
Resumindo é uma especificação bastante extensa, com alguma complexidade e que precisa de
ser analisada para total compreensão dos seus requisitos. Assim para cada um dos capítulos

1
Imagem retirada do site do DLM Forum :
http://www.dlmforum.eu/index.php?option=com_content&view=article&id=21&Itemid=25

36
principais do MoReq2 foi feito um diagrama onde se agrupam os requisitos de acordo com
funcionalidade/assunto a que se referem e se identificam dependências entre estes. O
objectivo é que através dos diagramas se consiga perceber rapidamente e resumidamente o
que cada capítulo cobre. Os diagramas foram criados utilizando a ferramenta “Enterprise
Architect, versão 7.5.844” utilizando os elementos e conectores ilustrados na figura 9. Os
diagramas de todos os capítulos encontram-se no anexo I.
req Requirements Model [Legendas]...

<Assunto, Funcionalidade ou
Referência Categoria dos Requisitos>
<Resumo do Requisito>

Requisito Obrigatório Requisito X Requisito Y

Agrupamento de Requisitos. Todos os

Referência O cumprimento do Requisito Y depende
requisitos dentro da caixa pertencem ao
<Resumo do Requisito> do cumprimento do Requisito X
assunto, funcionalidade ou categoria
indicada.
Requisito Opcional

Figura 9. Elementos e Conectores utilizados nos diagramas de resumo dos capítulos do MoReq2

O MoReq2 é estruturado, como referido atrás, em 13 capítulos. O primeiro capítulo é

introdutório e fala um pouco sobre a história, objectivo e organização da especificação que já
foram aqui descritos. O segundo capítulo introduz uma visão geral de um SGDA e alguns
conceitos para além dos já falados no subcapítulo 2.1. desta dissertação, nomeadamente:
 Dossiê. Conjunto de documentos de arquivo que pode ser tratado como uma unidade.
Os documentos de arquivo são agrupados num dossiê por uma relação entre eles, tal como, o
assunto a que se referem, serem tipologicamente idênticos, entre outros.
 Sub-Dossiê. Subdivisão intelectual de um dossiê com o objectivo de distinguir
documentos de arquivo no dossiê.
 Volume. Subdivisão mecânica, tipicamente automática, de um dossiê com o objectivo
de melhorar o controlo e gestão de dossiês. Como por exemplo, dividir um dossiê por ano.
 Classificação. Identificação e categorização de um documento de arquivo de acordo
com convenções, métodos e procedimentos de maneira a que estes possam ser representados
logicamente num plano de classificação.
 Plano de Classificação. Um plano de classificação é uma hierarquia de documentos
de arquivos de acordo com a classificação dos mesmos. É a estrutura hierárquica sobre a qual
assenta todo o sistema. A figura 10 dá um exemplo de um plano de classificação.
 Classe. O termo classe é usado pelo MoReq2 para se referir a uma parte da hierarquia
representada no plano de classificação por uma linha traçada de qualquer ponto da hierarquia
até ao nível mais baixo a partir desse ponto. No exemplo da figura 10, por exemplo, ao
referirmo-nos à classe “Recrutamento e Progressão” referimo-nos a todos os dossiês, sub-
dossies, volumes e documentos de arquivo abaixo desta. Serve também para dar uma
estrutura ao plano de classificação e ao dossiê inserido na classe.

37
  Tabela de Selecção. Tabela associada a um documento de arquivo, volume, sub-
dossiê, dossiê ou classe, que define o período de retenção e o destino da entidade
associada.

Figura 10 Exemplo de um Plano de Classificação.

Com base nos conceitos apresentados o MoReq2 define então a base para um SGDA com
base num modelo entidade-relação apresentado na figura 11.
Introduzidos os conceitos e a base de um SGDA o MoReq2 lista os requisitos principais nos
capítulos seguintes. Todos os requisitos são apresentados numa tabela de estrutura fixa
(apresentada na figura 12 e retirada do MoReq2) com os seguintes campos: referência
(identificador) do requisito, descrição do requisito, onde aparece sempre a palavra “must” ou
“should” indicando se o requisito é, respectivamente, obrigatório ou opcional e o campo de
teste que indica se o requisito pode ser testado através da framework de teste do MoReq2.
O primeiro capítulo de requisitos (capitulo 3 do MoReq2) intitulado: “Plano de Classificação
e organização de dossiês” descreve nos seus requisitos o seguinte:
 Um Plano de Classificação deve ser sempre compatível com a organização e não o
inverso e deve ser gerido e mantido por um Administrador de sistema.
 O Administrador deve poder importar, exportar ou copiar todo, ou parte, do plano.
 As classes e dossiês devem ter metadados associados que devem ser herdados
segundo a hierarquia, metadados identificadores como um título e metadados
automáticos como a data de criação.
 Deve ser possível dividir dossiês em sub-dossies e volumes, ou apenas um deles, e só
deve haver um volume aberto em cada momento que tipicamente é o mais
recentemente criado. Uma entidade do plano de classificação fechada é uma entidade
que não pode receber documentos de arquivo nem ser subdividida.

38
 O plano de classificação tem de ser estável devendo este manter relações, estados e
referências em todas as operações sobre o mesmo (ex: movimentação de dossiês).
 As classes do plano de classificação devem poder ser divididas ou combinadas entre si.

Classification Scheme
1

 CONTAINS

1-
*
Class
1-
0-
* *
11 1


IS MADE UP OF

Retention &
1-
 MAY
APPLIES
* Disposition
CONTAIN
TO Schedule


0-
* 1-
0-1
File *
111

 MAY BE  MAY BE
DIVIDED DIVIDED
INTO INTO

0- 
* 1- APPLIES
Sub-file * TO
1 1

MAY BE
DIVIDED
INTO

0- 0-
Document * * 1-
Type Volume *
1
1
 
HAS
IS STORED IN
1-
0-
* *
1-
* 1-
Document
1-
* 1-
* Record * 1 Record
1- HAS Type
IS FORMED *


1 OF 1


IS MADE IS MADE

UP OF UP OF

1-
1-
*
* Component
Key:

1 Exactly one 0 – 1 Zero or one 0 - * Zero or more 1 - * One or more Exclusive OR

Figura 11 Modelo Entidade-Relação que representa a base de um SGDA segundo o MoReq2.

Ref Requirement Test

13.1.1 The ERMS must provide … Y

NUMBER REQUIREMENT TESTABILITY

Figura 12. Estrutura fixa da listagem de requisitos no MoReq2

Os requisitos do capítulo seguinte (“Controlos e Segurança”) descrevem que:

 Apenas um utilizador autenticado no sistema deve poder efectuar acções sobre o
mesmo e que é responsabilidade do Administrador definir acessos e permissões a
utilizadores, grupos de utilizadores ou papéis de utilizadores.

39
 O sistema deve possuir uma rotina de auditoria inalterável que regista todos os eventos
do sistema e pode ser alvo de pesquisa ou auditoria por utilizadores autorizados.
 A preservação dos dados deve ser assegurada por mecanismos de salvaguarda e
recuperação que devem ser geridos pelo Administrador.
 Um utilizador deve poder marcar um documento de arquivo como essencial garantindo
que o sistema irá assegurar medidas de salvaguarda extra no mesmo.
No capítulo 5 (“Retenção e Destino”) a especificação define que:
 Uma tabela de retenção e destino deve ter um identificador, um título, um período de
retenção e um destino. Os destinos possíveis são: preservar indefinidamente, reavaliar,
eliminar automaticamente, eliminar após autorização do Administrador, ou transferir
para um repositório externo.
 O Administrador deve ser responsável por criar, gerir, alterar ou remover as tabelas de
selecção, mas o sistema deve garantir que todas as entidades do plano de classificação
têm pelo menos uma tabela associada.
 As entidades do plano de classificação devem poder ser alvo de uma pausa legal,
operação que impede as mesmas de serem apagadas ou afectadas por acções das
tabelas de selecção.
 O sistema deve ter mecanismos de suporte à transferência e exportação de
documentos de arquivo como destino. Após um desses destinos o Administrador pode
optar por manter no sistema metadados de rasto que indiquem que um documento de
arquivo foi transferido ou exportado.
O capítulo seguinte (“Captura de Documentos de Arquivo”) descreve que:
 O sistema deve ser capaz de capturar documentos de arquivo independentemente do
seu formato atribuindo-lhes uma localização válida no plano de classificação. Se o
documento tiver várias componentes, estas devem ser juntamente capturadas, mas o
documento deve sempre ser tratado como uma unidade.
 Na captura de documentos deve ser responsabilidade do utilizador a introdução dos
seus metadados e responsabilidade do sistema a validação dos mesmos devendo
alguns metadados serem preenchidos automaticamente como por exemplo a data de
criação do documento.
 O sistema deve permitir a introdução de palavras-chave ao documento para uma melhor
identificação do mesmo.
 O sistema deve permitir a captura em bloco de vários documentos de arquivo.
 O sistema deve possibilitar a captura de correio electrónico juntamente com os seus
anexos de forma manual ou automática.
 O sistema deve assegurar que todos os documentos têm um tipo associado e o
conjunto de tipos de documentos que podem existir deve ser gerido pelo Administrador.
 O sistema deve permitir a integração com pelo menos uma solução de digitalização de
maneira a assegurar a captura de documentos digitalizados.

40
 O capítulo 7 intitulado “Referenciação” descreve que todas entidades do plano de
classificação devem ter sempre um identificador único no nível do plano de classificação em
que se encontram e um identificador completo único em toda a hierarquia. O sistema para
gestão e manutenção interna deve associar sempre um identificador de sistema às entidades
do plano de classificação.
O capítulo seguinte (“Pesquisa, Recuperação e Apresentação”) identifica como requisito:
 O sistema dever ter um sistema de pesquisa que permite pesquisar todas as entidades
do plano de classificação utilizando vários termos de pesquisa como metadados,
conteúdo de texto, palavras-chave, localização, entre outros.
 Os campos apresentados na lista de resultados de uma pesquisa devem poder ser
configurados pelo Administrador.
 O sistema deve permitir a impressão de diversos elementos do sistema como os
documentos de arquivo, os resultados de uma pesquisa, parâmetros administrativos,
lista de dossiês, lista de palavras-chave, entre outros.
O último capítulo principal (“Administração Geral”) identifica as seguintes funcionalidades
que o sistema deve ter disponíveis aos Administradores do sistema:
 Verificação de espaço livre de armazenamento.
 Criação de relatórios específicos sobre vários elementos do sistema como actividades
das tabelas de selecção, acções da rotina de auditoria, tentativas de acesso não
autorizado, erros existentes nos processos de transferência, exportação, eliminação e
importação, entre outros.
 Dois modos de funcionamento do sistema:
o Modo por defeito, onde uma eliminação/relocação é apenas simulada e os
dados permanecem no sistema.
o Modo de eliminação, onde uma eliminação/relocação é definitiva.
 Possibilidade de truncar um documento, que consiste em copiá-lo, eliminando ou
escondendo informação sensível e criando assim um extracto do documento.
O capítulo 10 do MoReq2 é um capítulo onde são listados requisitos para o
desenvolvimento dos seguintes módulos opcionais de sistema:
 Gestão de Documentos de Arquivo Físicos.

 Destino de Documentos de Arquivo Físicos.

 Gestão Documental e Trabalho Colaborativo. Módulo que permite gerir os

documentos antes de se tornam documentos de arquivo.
 Fluxo de Trabalho. Módulo que permite criar vários fluxos de trabalho para optimizar e
automatizar os processos de negócio.
 Dossiês de Projecto. Módulo que permite criar uma nova entidade no plano de
classificação denominada “Dossiês de Projecto”, que simula a criação de uma pasta de
trabalho de um projecto partilhada pela equipa do mesmo.

41
  Integração com Sistemas de Conteúdo.

 Assinaturas Electrónicas.
 Encriptação.

 Gestão de Direitos de Autor.

 Sistemas Distribuídos.
 Trabalho offline e remoto.

 Integração com Fax.

 Categorias de Segurança. Módulo que permite criar e associar categorias de

segurança aos documentos de arquivo para uma melhor gestão das suas permissões.
O capítulo 11 lista os requisitos não funcionais do sistema, o capitulo 12 lista requisitos
de metadados e o capítulo final apresenta um glossário dos termos utilizados na especificação
e uma explicação detalhada do modelo entidade-relação, apresentado anteriormente na figura
11.
É importante realçar, que a descrição dos requisitos de cada capitulo é centrada nos
requisitos obrigatórios e que esta não passa de um resumo muito sucinto dos mesmos. O
objectivo é que ao ler a descrição se fique com uma ideia geral dos requisitos do MoReq2, não
substituindo nunca a leitura e análise completa da especificação para uma noção total dos
requisitos.

42
 5. Análise do SmartDocs segundo o MoReq
Depois de analisados os dois artefactos que vamos utilizar: SmartDocs e MoReq2 e após
obter um melhor conhecimento sobre ambos torna-se então possível efectuar uma avaliação
do produto em relação à especificação de requisitos. O objectivo pretendido não é apenas
perceber quais os requisitos não cumpridos pelo SmartDocs, mas sim fazer uma análise
objectiva do produto utilizando como material de avaliação o MoReq2.
Para essa análise foram utilizados os seguintes métodos de avaliação: avaliação por lista de
verificação, lista ponderada e análise de intervalos. Neste capitulo irá ser descrito como cada
método foi utilizado e quais as conclusões retiradas com os resultados.
Importante ainda realçar que as avaliações centram-se nos capítulos principais do MoReq2
(Capitulo 3 a 9), não abrangendo portanto os módulos opcionais da especificação e os seus
requisitos não-funcionais. As razões para esta decisão foram:
Da análise e leitura dos módulos opcionais do MoReq2 fica a ideia que vários exigem
um investimento, tanto a nível de trabalho de desenvolvimento, como de tecnologia no produto
que não compensa se realmente não for um módulo pretendido. Módulos demasiado
específicos como o módulo de “pastas de trabalho” apenas fazem sentido serem avaliados se
realmente for um objectivo do fornecedor, ou um desejo do consumidor. De qualquer das
formas é possível utilizar a mesma metodologia usada nesta dissertação para avaliar os
módulos opcionais se assim for desejado.
Os requisitos não-funcionais têm métodos de avaliação completamente distintos dos
explorados nesta dissertação e não devem ser avaliados apenas por uma pessoa, devido à sua
grande subjectividade, mas sim por um grupo de utilizadores. Para esta dissertação isso
simplesmente não era possível visto que o acesso aos utilizadores do produto era escasso e a
complexidade da tese aumentava exponencialmente.

5.1. Lista de Verificação

Relembrando muito sucintamente, esta técnica de avaliação consiste em comparar o
produto com uma lista de verificação, indicando se o produto cumpre os itens da lista. Neste
caso em particular a lista utilizada para a avaliação é os requisitos do MoReq2. Assim para
cada subcapítulo da especificação de requisitos foi criada uma tabela com os seguintes
campos:
 Referência. Que corresponde ao identificador do requisito no MoReq2.
 Essencial. Que, se assinalado com uma cruz, indica que o requisito é dado como
obrigatório pelo MoReq2.
 Justificação. Este campo indica a razão da decisão tomada em cada requisito e é
importante para que se possa perceber as razões da avaliação, não só para qualquer pessoa
que consulte a lista, mas até para memória futura do avaliador
 Cumprimento. Se assinalado indica que o requisito é cumprido.

 Total de Requisitos Obrigatórios.

43
  Total de Requisitos Cumpridos e a percentagem de requisitos obrigatórios
cumpridos em relação ao total de requisitos obrigatórios.
A tabela 5 exemplifica um dos subcapítulos avaliados do MoReq2. No exemplo, podemos
constatar que o requisito obrigatório 9.1.1. (“O sistema tem que permitir que Administradores
consigam visualizar e reconfigurar parâmetros e configurações de sistema feitas no período de
configuração”) é cumprido, visto que o SmartDocs permite que o Administrador aceda e altere
parâmetros de configuração do sistema. O requisito opcional 9.1.4 (“Quando existe verificação
de taxas de erro nos dispositivos de armazenamento, o sistema deve monitorizar as mesmas e
reportar aos Administradores a existência de um dispositivo no qual a frequência de erros
exceda um parâmetro definido em período de configuração ou mais tarde”) não é cumprido,
porque não existe uma integração do SmartDocs com dispositivos de armazenamento que
permita a monitorização de erros. Podemos ainda verificar através da mesma tabela que
existem 3 requisitos obrigatórios no subcapítulo 9.1 num total de 5 requisitos, 3 requisitos são
cumpridos e 67% dos requisitos obrigatórios são cumpridos.

Ref. Essencial Justificação Cumprimento

9.1.1 x O Administrador de sistema é o único com possibilidade X
de visualizar e reconfigurar as definições de sistema.
9.1.2 x O Administrador pode atribuir funções a utilizadores X
assim como atribuir papéis de utilizadores.
9.1.3 x Não existe aviso de falta de espaço.
9.1.4 Não existe integração com suportes de armazenamento
de maneira a registar erros no suporte e notifica-los ao
administrador.
9.1.5 O Administrador consegue facilmente mover utilizadores X
entre grupos e papéis.
Total 3 3 (67%)
Tabela 5 Tabela de avaliação do subcapítulo 9.1 (“General Administration”) do MoReq2 utilizando o método
de lista de verificação.

Os resultados quantitativos completos encontram-se no anexo II. Nestes resultados a

primeira impressão da tabela é que o produto da Fujitsu não cumpre a maioria dos requisitos
do MoReq2.
Analisando os resultados em relação aos requisitos obrigatórios (resultados reproduzidos na
tabela 6), cujo cumprimento deve ser prioritário, podemos verificar que no capítulo de retenção
e destino não existe nenhum requisito cumprido, devido ao facto de o SmartDocs não ter
mecanismos de retenção e destino dos seus documentos. Esse facto não é surpreendente
pois, tal como mencionado atrás, o produto é um SGD e não um SGDA. Esta circunstância faz
com que a avaliação seja negativa no capítulo 5 do MoReq2, mas também afecta outros
capítulos, como por exemplo o capitulo 9.2, que tem 11 capítulos (4 obrigatórios) relacionados
com a criação de relatórios sobre tabelas de selecção.
No capítulo do Plano de Classificação e Organização de Pastas, a justificação para a baixa
percentagem de requisitos cumpridos deve-se ao facto do produto não ter um processo de
importação/exportação de todas as entidades do plano de classificação, mas apenas de
algumas, e também devido a não ter o conceito de entidade fechada e aberta.

44
 Requisitos Obrigatórios

Cumpridos (%)
Cumpridos
Requisitos

Requisitos

Requisitos
Número de
Plano de Classificação e Organização de Pastas 72 21 29%
Configuração do Plano de Classificação 19 5 26%
Classes e Pastas 12 6 50%
Volumes e Sub-Pastas 18 5 28%
Gestão do Plano de Classificação 22 5 23%
Segurança e Controlo 45 22 49%
Acesso 21 13 62%
Rotina de Auditoria 15 8 53%
Salvaguarda e Recuperação 5 1 20%
Documentos de Arquivo Vitais 4 0 0%
Retenção e Destino 61 0 0%
Tabelas de Selecção 34 0 0%
Revisão do Destino 7 0 0%
Transferência, Exportação e Eliminação 20 0 0%
Captura e Declaração de Documentos de Arquivo 63 29 46%
Captura 26 13 50%
Importação em Bloco 8 0 0%
Gestão de Correio Electronico 15 5 33%
Tipos de Documentos de Arquivo 5 5 100%
Imagens e Digitalização 9 6 67%
Referenciação 12 9 75%
Codigos de Classificação 8 5 63%
Identificadores de Sistema 4 4 100%
Pesquisa, Recuperação e Visualização 34 17 50%
Pesquisa e Recuperação 19 11 58%
Apresentação: Visualização de Documentos de Arquivo 1 1 100%
Apresentação: Impressão 13 5 38%
Apresentação: Outros 1 0 0%
Funções Administrativas 36 13 36%
Administração Geral 3 2 67%
Relatorios 17 4 24%
Alterar, Eliminar e Truncar Documentos de Arquivo 16 7 44%

Tabela 6 Tabela de Resultados Quantitativa da avaliação por lista de verificação no que diz respeito a
requisitos obrigatórios. Legenda: Preto = 0-24%; Vermelho = 25-49%; Amarelo = 50-74%; Verde = 75-100%;

No capítulo da segurança as principais falhas são o sistema não ter um mecanismo de

gestão e manutenção de recuperação e salvaguarda de dados, apesar de fazer
recomendações e apresentar maneiras de criar tais rotinas, conjugado com o facto de não
reconhecer o conceito de documento de arquivo essencial.
As principais lacunas identificadas no capítulo de captura e declaração de documentos de
arquivo são: a falta de integração da gestão de correio electrónico com as suas aplicações, a
ausência de importações em bloco e opções limitadas no processo de captura e digitalização.
O capítulo de referenciação é o mais completo pecando apenas por uma melhor
configuração dos identificadores que podem ser atribuídos às entidades do sistema.
No que diz respeito às funcionalidades de pesquisa, recuperação e visualização existe
pouca possibilidade de configuração dos elementos e campos a imprimir, e alguma falta de

45
flexibilidade na pesquisa, o que faz com que apenas metade dos requisitos obrigatórios sejam
cumpridos.
No último capítulo registam-se limitações na criação e configuração de relatórios e
inexistência de um processo para truncar documentos de arquivo, que sendo dois dos seus
subcapítulos resultam numa avaliação negativa.
Em conclusão fica a ideia de que o SmartDocs tem muito a melhorar mas também que os
resultados são demasiado negativos para aquilo que o sistema possui. Na opinião de avaliador
existem vários requisitos que não são cumpridos, apenas por pequenos detalhes, o que não é
visível nos resultados mas na análise da lista. Existem ainda funcionalidades não existentes
que dão origem ao não cumprimento de vários requisitos em diferentes capítulos, ou seja a
técnica de avaliação pesa demasiado negativamente uma única falha do sistema.

5.2. Lista Ponderada

Uma das características do MoReq2 identificadas na análise feita no capítulo 4.1. é que
existem vários requisitos que estão relacionados, ou mesmo dependentes uns dos outros. Esse
factor tal como referido na avaliação anterior penaliza exageradamente, por exemplo, um
produto que possui todas as funcionalidades identificadas na especificação de requisitos, mas
que falha em pequenos atributos dessas funcionalidades. Por essa razão torna-se necessário
fazer uma distinção desses requisitos e atribuir-lhes diferentes pesos nesta avaliação para que
não aconteça o mesmo problema.
Nesse sentido foi feita uma reestruturação do MoReq2 introduzindo os conceitos de
requisitos principais e sub-requisitos e novos requisitos principais. O objectivo é que um
requisito principal identifique uma funcionalidade, ou um processo, que o sistema tem que
possuir, enquanto os sub-requisitos são apenas características ou atributos desse requisito
principal. Essa reestruturação foi feita com base na análise por diagramas realizada no capítulo
4.1.
Para se perceber melhor o trabalho desenvolvido reproduz-se na figura 13 o diagrama do
capítulo 3.1 do MoReq2 (“Configuring the Classification Scheme”) onde podemos identificar
uma dependência entre os requisitos 3.1.12-15. Essa dependência existe porque o requisito
3.1.12 identifica a necessidade de o sistema suportar a importação do plano de classificação,
ou parte dele, enquanto os requisitos seguintes 3.1.13, 3.1.14 e 3.1.15 identificam
características que o processo de importação deve cumprir, como rejeitar classes que não
contenham título, importar juntamente com as entidades do plano de classificação as tabelas
de selecção associadas e validar os metadados importados. Assim, de acordo com o objectivo
da reestruturação o requisito 3.1.12 é considerado um requisito principal e os restantes seus
sub-requisitos.
No mesmo diagrama podemos ver também um agrupamento dos requisitos 3.1.23 e 3.1.24
visto que o primeiro afirma que ao copiar um plano de classificação, ou parte dele, os
metadados associados devem ser copiados, enquanto o segundo afirma que ao copiar um
plano de classificação, ou parte dele, as tabelas de selecção associadas devem ser incluídas

46
na cópia. Mais uma vez, estes requisitos são característicos de um processo que é o de copiar
um plano de classificação, no entanto neste caso não existe nenhum requisito que identifique
especificamente esse processo, portanto na reestruturação efectuada esse requisito é
adicionado como requisito principal dos requisitos 3.1.23 e 3.1.24.
A reestruturação completa do MoReq2 é apresentada no anexo III.
Nota: Nem todos os agrupamentos/dependências dão origem a requisitos principais visto
que em alguns raros casos os agrupamentos são demasiado abrangentes o que tem como
consequência a desvalorização de todos os requisitos englobados, mesmo quando estes são
realmente parte importante de um processo.
custom Configuring the Classification Scheme

3.1.1 Organization
Compatible Import All or Part of the
Classification Scheme
3.1.2 Internal Integrity
3.1.12 Import ::
Classification Scheme
3.1.4 Hierarchy of Classes.

3.1.5 Administration 3.1.13 Import :: Retention 3.1.14 Import :: Exception

Management Schedules & Audit Trails Report

3.1.8 Classification Scheme 3.1.15 Import :: Hierarchical 3.1.16 Import :: Validation

Creation Code Rules

3.1.9 Titling Mechanism

3.1.25 Add Classes Export All or Part of the Classification

Scheme

3.1.11 Import/Export :: 3.1.17 Export ::

MoReq2 XML Schema Classification Scheme

3.1.18 Export :: Select 3.1.19 Export :: Select

3.1.3 Identifier, Title and Metadata Retention Schedules
Description

3.1.20 Export :: Select Audit 3.1.21 Export ::

3.1.6 User Management
Trail Documentation

3.1.7 Number of Levels

3.1.22 Export :: XML

3.1.10 Textual Scope Notes

3.1.26 Multiple Classification Copying All or Part of the

Schemes Classification Scheme

3.1.23 Copy :: Classification 3.1.24 Copy :: Retention

Scheme Schedules

Figura 13. Diagrama de modelação dos requisitos do capitulo 3.1 (“Configuring the Classification Scheme”) do
MoReq2

Com a reestruturação do MoReq2 podemos então dar relevância aos requisitos principais
na avaliação, visto que estes não só indicam um processo que o sistema deve ter
(independentemente de cumprir todas as suas características ou atributos) como do ponto de
vista da implementação o custo de acrescentar características a um processo, ou

47
funcionalidade, é tipicamente menor do que criar uma nova funcionalidade. Resumindo, um
sistema que cumpra um requisito principal está mais próximo de cumprir os seus sub-requisitos
e isso deve ser valorizado.
Dessa forma passamos a ter duas medidas a ter em conta no MoReq2: o nível do requisito
criado com a reestruturação e a sua obrigatoriedade já existente na especificação que podem
ser combinados para atribuir os pesos dos requisitos como se ilustra na tabela 7.
A multiplicação das duas medidas foi usada para dar maior foco na medida já existente no
MoReq2, visto que resulta numa prioridade muito maior (dobro), quando os requisitos são
obrigatórios.

O resultado do cruzamento entre as duas Requisito Requisito

medidas é a multiplicação das mesmas. Opcional (Peso 1) Obrigatório (Peso 2)

Requisito Principal (Peso 4) 4 8

Requisito Normal (Peso 3) 3 6

Sub-Requisito de um Requisito Principal 2 4

Obrigatório (Peso 2)

Sub-Requisito de um Requisito Principal 1 2

Opcional (Peso 1)

Tabela 7. Pesos dos Requisitos após reestruturação do MoReq2

De maneira a obter então uma pontuação como o método exige é também necessário
atribuir respostas quantitativas na avaliação. Assim, utilizaram-se as medidas de resposta
apresentadas na tabela 8.

Medida Significado

0 “Não Cumpre” – O Sistema não cumpre o requisito.

1 “Cumpre Parcialmente” – O Sistema cumpre parte do requisito mas necessita

ainda de algum desenvolvimento para o cumprir na totalidade.

2 “Cumpre Praticamente” – O Sistema praticamente cumpre o requisito falhando

apenas em algum detalhe.

3 “Cumpre Totalmente” – O Sistema cumpre totalmente o requisito.

Tabela 8 Significado das respostas quantitativas da avaliação por Lista Ponderada

Relembrando a técnica aplicada, para cada requisito existe um peso pré-definido ao qual
será dado uma resposta quantitativa. A multiplicação do peso com a resposta dá origem à
pontuação do requisito enquanto a soma das pontuações dá a pontuação do sistema.
No anexo IV apresentam-se então os resultados completos. Como se pode rapidamente
reparar, as percentagens de cumprimento dos requisitos subiram significativamente sendo que
em alguns casos são inclusive o dobro da avaliação anterior. Como é obvio o sistema não foi

48
alterado entre as duas avaliações e a única razão para esta subida de percentagem é por esta
técnica de avaliação ser mais especifica do que a anterior.
A primeira razão para a melhoria registada está relacionada com a reestruturação do
MoReq2. Se analisarmos a tabela 9, que apresenta um resumo das percentagens obtidas nos
requisitos obrigatórios, podemos reparar que as maiores percentagens encontram-se nos
níveis superiores. Estes resultados são a validação daquilo que na qualidade de avaliador foi
observado anteriormente, mas que não ficou registado nos resultados anteriores: as
funcionalidades principais identificadas na especificação estão presentes no SmartDocs
falhando principalmente em detalhes, características ou atributos dessas mesmas
funcionalidades.
Requisitos Obrigatórios

Requisitos (%)
Principais (%)

Normais (%)
Requisitos

Requisitos

Total (%)
Sub-
Plano de Classificação e Organização de Pastas 61% 61% 39% 51%
Configuração do Plano de Classificação 83% 78% 40% 64%
Classes e Pastas 67% 75% 67% 69%
Volumes e Sub-Pastas 44% 0% 33% 34%
Gestão do Plano de Classificação 56% 48% 32% 43%
Segurança e Controlo 70% 75% 52% 63%
Acesso 80% 80% 74% 77%
Rotina de Auditoria 67% 67% 52% 60%
Salvaguarda e Recuperação 100% - 17% 44%
Documentos de Arquivo Vitais 0% - 0% 0%
Retenção e Destino 0% 0% 0% 0%
Tabelas de Selecção 0% 0% 0% 0%
Revisão do Destino 0% 0% 0% 0%
Transferência, Exportação e Eliminação 0% 0% 0% 0%
Captura e Declaração de Documentos de Arquivo 70% 59% 53% 60%
Captura 87% 69% 63% 72%
Importação em Bloco 0% 0% 0% 0%
Gestão de Correio Electronico 33% 50% 33% 45%
Tipos de Documentos de Arquivo 100% - 100% 100%
Imagens e Digitalização 100% 67% 75% 76%
Referenciação 92% - 83% 88%
Codigos de Classificação 89% - 73% 82%
Identificadores de Sistema 100% - 100% 100%
Pesquisa, Recuperação e Visualização 38% 63% 53% 54%
Pesquisa e Recuperação 67% 67% 50% 65%
Apresentação: Visualização de Documentos de Arquivo - 100% - 100%
Apresentação: Impressão 20% 60% 56% 40%
Apresentação: Outros - 0% - 0%
Funções Administrativas 42% 58% 17% 42%
Administração Geral - 67% - 67%
Relatorios 11% 52% 0% 35%
Alterar, Eliminar e Truncar Documentos de Arquivo 60% 100% 23% 46%

Tabela 9. Tabela de Resultados Quantitativa da avaliação por Lista Ponderada no que diz respeito a requisitos
obrigatórios discriminados pelo nível de importância dos requisitos. Legenda: Preto = 0-24%; Vermelho = 25-49%;
Amarelo = 50-74%; Verde = 75-100%;

Olhando para a tabela podemos também rapidamente identificar quais as principais

funcionalidades em falta no produto através da coluna dos requisitos principais. Os valores
mais baixos encontram-se no:

49
  Subcapítulo “Volumes e pastas” devido ao facto de o SmartDocs não reconhecer o
conceito de entidades, do plano de classificação, abertas e fechadas.
 Subcapítulo “Gestão do Plano de Classificação” devido ao facto de não possuir
duas das funcionalidades identificadas nessa secção da especificação: combinação e
divisão de classes.
 Capitulo “Retenção e Destino” devido a ausência de mecanismos de controlo e
retenção de documentos.
 Subcapítulo “Importação em Bloco” por o SmartDocs não possuir essa
funcionalidade.
 Subcapítulo “Gestão de Correio Electrónico” principalmente por o sistema não
permitir captura automática de correio electrónico.
 Subcapítulos “Apresentação: Impressão” e “Relatórios” pela quantidade limitada
de opções e elementos que podem ser impressos ou sobre os quais podem ser
pedidos relatórios.
Requisitos Obrigatórios

Praticamente (%)

Parcialmente (%)

Não Cumpre (%)

Totalmente(%)

Cumpre

Cumpre
Cumpre

Plano de Classificação e Organização de Pastas 35% 11% 14% 38%

Configuração do Plano de Classificação 35% 20% 10% 25%
Classes e Pastas 62% 8% 8% 23%
Volumes e Sub-Pastas 32% 0% 5% 63%
Gestão do Plano de Classificação 23% 14% 27% 36%
Segurança e Controlo 47% 16% 6% 31%
Acesso 58% 25% 4% 13%
Rotina de Auditoria 50% 13% 0% 38%
Salvaguarda e Recuperação 20% 0% 40% 40%
Documentos de Arquivo Vitais 0% 0% 0% 100%
Retenção e Destino 0% 0% 0% 100%
Tabelas de Selecção 0% 0% 0% 100%
Revisão do Destino 0% 0% 0% 100%
Transferência, Exportação e Eliminação 0% 0% 0% 100%
Captura e Declaração de Documentos de Arquivo 48% 11% 5% 36%
Captura 56% 19% 7% 19%
Importação em Bloco 0% 0% 0% 100%
Gestão de Correio Electronico 33% 13% 7% 47%
Tipos de Documentos de Arquivo 100% 0% 0% 0%
Imagens e Digitalização 67% 0% 0% 33%
Referenciação 75% 17% 0% 8%
Codigos de Classificação 63% 25% 0% 13%
Identificadores de Sistema 100% 0% 0% 0%
Pesquisa, Recuperação e Visualização 50% 6% 0% 44%
Pesquisa e Recuperação 58% 5% 0% 37%
Apresentação: Visualização de Documentos de Arquivo 100% 0% 0% 0%
Apresentação: Impressão 38% 8% 0% 54%
Apresentação: Outros 0% 0% 0% 100%
Funções Administrativas 32% 5% 8% 54%
Administração Geral 67% 0% 0% 33%
Relatorios 22% 11% 11% 56%
Alterar, Eliminar e Truncar Documentos de Arquivo 38% 0% 6% 56%

Tabela 10. Tabela de Resultados Quantitativa da avaliação por Lista Ponderada no que diz respeito a
requisitos obrigatórios descriminados pela resposta quantitativa dada. Legenda: Preto = 0-24%; Vermelho = 25-
49%; Amarelo = 50-74%; Verde = 75-100%;

50
 A segunda razão para a melhoria de resultados do sistema tem a ver com a utilização de
resposta quantitativa. Como a tabela 10 mostra, em vários capítulos existe uma amostra
significativa de requisitos (média de 14%) que são praticamente ou parcialmente cumpridos.
Isso para além de ser uma das causas da melhoria, apresenta também novos dados para a
avaliação do produto mostrando que existem requisitos que teoricamente podem, com relativa
facilidade em comparação com os outros, ser cumpridos contribuindo assim para um melhor
sistema.

5.3. Análise de Intervalos

Das técnicas estudadas para avaliação de um produto, a análise de intervalos é a menos
rigorosa e formal. Existem vários templates online que exemplificam e ajudam a fazer este tipo
de avaliação mas todos têm algo em comum: são construídos especificamente para cada
projecto. O objectivo da avaliação é claro: perceber onde o software se encontra e onde este
quer estar. Com os resultados das avaliações anteriores não há necessidade de explorar
novamente onde o software se encontra ainda mais quando não existe novo método formal
para o fazer, restando portanto perceber o desenvolvimento que é necessário fazer para atingir
o objectivo final: alinhar o SmartDocs com o MoReq2.
Nesse sentido foi feita uma avaliação focada nos requisitos não cumpridos do MoReq2 de
maneira a apresentar uma lista de propostas de desenvolvimento para o SmartDocs. A
estrutura fixa utilizada para apresentar uma proposta foi a seguinte:
Titulo da Proposta, indicativo da funcionalidade ou desenvolvimento que se pretende
propor.
Requisitos Relacionados, do MoReq2 utilizando as referências da especificação.
Propostas Relacionadas, da lista de propostas indicando uma dependência entre elas
ou que, por questões lógicas, devem ser desenvolvidas conjuntamente.
Peso da Proposta, somatório dos pesos dos requisitos, relacionados com a proposta,
utilizados na avaliação anterior.
Cumprimento da Proposta, somatório das respostas quantitativas dos requisitos,
relacionados com a proposta, utilizadas na avaliação anterior.
Classificação da Proposta, de acordo com a classificação de Swanson (Swanson
1976) estudada no subcapitulo 2.2.
Descrição da Proposta, em linguagem natural apresentando na prática um resumo
dos requisitos da proposta.
A tabela 11 apresenta o resumo da lista final ordenada pelo peso da proposta e com
propostas relacionadas já agrupadas. A barra verde divide a lista de acordo com a classificação
de Swanson (Swanson 1976).

51
 Peso da Cumprimento
Ranking Título da Proposta Requisitos Relacionados
Proposta da Proposta
Propostas de Adaptação
Manutenção de Permissões 4.1.2-5; 4.1.19 40 13
1
Papeís de Utilizadores 4.1.2-4; 4.1.8; 4.1.10; 4.1.20 42 9
3.3.13; 6.1.1; 6.1.4-7; 6.1.12;
2 Captura e Classificação de Documentos 6.1.14-15; 6.1.17-19; 6.1.30; 81 14
6.1.33-35; 6.1.37-41
8.1.6-7; 8.1.21-22; 8.1.25-31;
3 Opções de Pesquisa 54 8
8.1.33
4 Funções de Digitalização 6.5.9; 6.5.12-13; 6.5.15-22 33 3
5 Manutenção de Palavras-chave no documento 6.1.23-28 23 6
6 Eventos Registados na Rotina de Auditoria 4.2.8; 4.2.11; 4.2.16 20 4
7 Configuração de Identificadores 7.1.5; 7.1.8-10 18 6
8 Captura, Manutenção e Apresentação de de Metadados 3.2.2; 3.2.6-7; 6.1.12 13 6
9 Apresentação e Visualização de Documentos 8.2.2; 8.4.1 9 1
Propostas de Perfeição
3.4.13; 5.1.1-8; 5.1.10-13;
Conceito de Tabelas de Selecção 133 0
5.1.15-27; 5.1.29-30;
1 5.1.3; 5.1.9; 5.1.14; 5.1.28;
Funções da Tabela de Selecção 36 0
5.1.31-33
Suporte ao Destino dos Documentos 5.2.1-8; 5.3.1-18; 5.3.24 114 0

3.1.25; 3.3.16-17; 3.4.2-3; 3.4.5;

Funções de Manutenção do Plano de Classificação 90 17
3.4.7-16; 3.4.24; 3.4.28-29

3.3.4-12; 3.3.18-19; 3.4.10-11;

Conceito de Entidades Fechadas/Abertas 77 3
2 3.4.20-22; 6.1.41
Importação de Dados 3.1.11-16; 6.2.1-8; 6.5.21 71 7
Copia de Dados 3.1.23-24 16 6
3.2.8;3.2.10; 3.4.12; 6.1.17-18;
Metadados Automáticos 56 1
6.3.10; 6.3.13; 6.5.19-20
5.3.24; 9.2.1; 9.2.4-7; 9.2.10-14;
Criação e Manutenção de Relatorios 122 12
3 9.2.16-17; 9.2.19; 9.2.37-52
Impressão de Dados 8.3.2; 8.3.3-6; 8.3.8-17 65 2
4 Gestão de Correio Electronico 6.3.1-18 69 5
5 Conceito de Pausa Legal 5.1.34-43 34 0
6 Truncar Documento 9.3.10-15; 9.3.17-19 34 0
7 Metadados de Rasto 5.3.19-23 24 0
8 Conceito de Registos Vitais 4.4.1-5 23 0
9 Funções da Rotina de Auditoria 4.2.2; 4.2.5; 4.2.13; 4.2.15 22 0
10 Exportação de Dados 3.1.17-22; 3.2.16 16 6
11 Mecanismo de Salvaguarda e Recuperação 4.3.2-5 16 2
12 Utilização de Vocabulario Controlado 3.2.13-3.2.14; 8.1.16-19 15 0
13 Acesso através de outras aplicações 4.1.21; 6.3.2; 6.3.6 10 0
14 Marcar para Eliminação 9.3.6-7 8 1
15 Conceito de Identificadores Globais 7.2.4-5 4 0
Propostas de Correcção
1 Prevenções do Sistema 3.4.19; 8.1.20; 9.3.1; 9.3.3 12 2

Tabela 11. Lista de propostas de desenvolvimento para o SmartDocs obtida através da análise de intervalos.

A nível de propostas de adaptação, ou sejam que implicam modificações em

funcionalidades actuais, a captura e classificação de documentos e manutenção de permissões
são aquelas que mais modificações impõem o que obviamente resulta num maior peso de
proposta. A proposta de papéis de utilizadores é na verdade uma proposta de perfeição mas é
englobada com a manutenção de permissões, porque para além dos requisitos relacionados
não faz sentido desenvolvê-la sem modificar o actual sistema de manutenção de permissões
do SmartDocs.

52
 Nas propostas de Perfeição, que consistem na adição de novas funcionalidades ou
conceitos, a proposta mais relevante está relacionada com o capítulo de Retenção e Destino
do MoReq2, que como avaliado anteriormente não tem nenhum requisito cumprido pelo
SmartDocs. Esse facto é determinante na colocação da proposta em primeiro lugar da lista
apesar do aglomerado de propostas em segundo lugar ter um peso maior no seu conjunto.
A única proposta de correcção diz respeito a requisitos que descrevem eventos ou acções
que o sistema deve evitar que aconteçam, como a eliminação de uma pasta por um utilizador
que não é Administrador, e que o SmartDocs não cumpre.

53
 6. Validação dos Resultados
Depois de utilizadas as técnicas estudadas para a avaliação de um produto impõem-se
agora retirar ilações e algumas conclusões sobre o trabalho desenvolvido.

6.1. Avaliação de um Sistema de Gestão de Conteúdos de acordo

com uma especificação de Requisitos
Considerando os três métodos de avaliação e o quadro geral da avaliação feita ao
SmartDocs podemos retirar as seguintes ilações:
1. Todas as avaliações requerem um conhecimento elevado tanto da especificação como
do sistema em avaliação. Quanto maior for o conhecimento de ambos mais rápido e
correcto se torna o processo de decisão nos métodos de avaliação.
2. Tanto a avaliação por lista de verificação e lista ponderada são métodos que demoram
bastante tempo (média de 80 horas para cada) para uma especificação tão extensa
como o MoReq2, no entanto a segunda permite-nos obter um bom volume de dados
conclusivos que a primeira não permite.
3. A análise e compreensão do MoReq2 são vitais para qualquer das avaliações. A
correcção dos resultados na avaliação por lista ponderada é directamente proporcional
à correcção dos pesos dos requisitos, ou seja, depende particularmente da análise da
especificação.
4. O documento produzido na análise de intervalos (lista de propostas) é o que tem mais
valor para uma equipa de desenvolvimento de software, no entanto, seria um processo
muito mais complexo e demorado se não tivesse partido das avaliações anteriores.
Tendo em consideração as ilações tiradas define-se na figura 14 um método de avaliação
para SGC de acordo com uma especificação de requisitos, com as seguintes fases:
 Análise de Dados.
o Objectivo: Fase de análise e compreensão do sistema em avaliação e da
especificação de requisitos.
o Objectos de Entrada: Especificação de Requisitos e Sistema.
o Pessoas a Envolver:
 Avaliador(es) do processo, de preferência dois ou mais para evitar
subjectividades na avaliação.
 Consumidor do sistema e/ou autor da especificação, para ajudar na
compreensão, análise e atribuição de prioridades dos requisitos da
especificação.
 Fornecedor do sistema, para ajudar na compreensão e análise do
sistema.
o Técnicas a utilizar: Técnicas de análise e modelação de requisitos e sistemas.

54
 o Objectos de Saída: Lista de verificação baseada na especificação de
requisitos com prioridades já atribuídas.

Figura 14. Diagrama que define o processo de avaliação de um SGC de acordo com uma especificação de
requisitos, e as suas diversas fases.

 Avaliação
o Objectivo: Avaliar o sistema de acordo com a especificação de requisitos.
o Objectos de Entrada: Objecto de Saída da fase anterior, ou seja, lista de
verificação baseada na especificação de requisitos com prioridades já
atribuídas.
o Pessoas a envolver: Avaliador(es).
o Técnicas a utilizar: Avaliação por lista ponderada.
o Objectos de saída: Resultados da Avaliação que inclui a lista de verificação
avaliada, dados estatísticos e conclusão dos dados.
 Planeamento
o Objectivo: Analisar os requisitos não cumpridos pelo sistema na perspectiva
do seu desenvolvimento.
o Objectos de Entrada: Objecto de Saída da fase anterior, ou seja, resultados
da Avaliação que inclui a lista de verificação avaliada, dados estatísticos e
conclusão dos dados.
o Pessoas a envolver:
 Avaliador(es), que irão elaborar a lista de propostas e atribuir
prioridades.

55
  Equipa de Desenvolvimento do Fornecedor, que irão refinar o detalhe
da lista de propostas e poderão fazer uma análise custo/risco da
proposta juntamente com o(s) avaliador(es).
o Técnicas a utilizar: Análise de Intervalos, Análise custo/risco, Análise de
viabilidade das propostas.
o Objectos de saída: Lista de propostas para o cumprimento dos requisitos da
especificação.

6.2. Portal de Gestão de Requisitos de Sistemas de Gestão de

Documentos de Arquivo
Como foi referido no subcapítulo 6.1. a avaliação de um SGDA só tem benefícios na
aproximação das partes interessadas nesta área de negócio. No caso particular desta
dissertação a avaliação foi feita com a colaboração da equipa de desenvolvimento da Fujitsu
que ajudou em muito a análise e compreensão do sistema antes da sua avaliação. No entanto
a Fujitsu é apenas parte interessada no negócio e existem outras que podem contribuir em
muito para o sucesso de todas as partes.
É com esse objectivo em mente, e como consequência da colaboração entretanto
desenvolvida com outro projecto de mestrado de um colega (Veiga 2010), surgiu a
oportunidade de criar um portal para automatizar e auxiliar a gestão de requisitos de SGDA.
Em (Veiga 2010) foi feita uma análise das partes interessadas nos SGDA identificando-se,
nomeadamente as seguintes:
 Gestores de especificações. Entidade responsável pelo desenvolvimento de
especificações de SGD como o MoReq, MoReq2, Pro 2002, DoD 5015.2, entre outros.
 Fornecedores de software e serviços de gestão de documentos de arquivo, onde
se incluem as empresas responsáveis por produzir este tipo de sistemas, as suas
equipas de desenvolvimento, os gestores de software, analistas de sistemas, entre
outros.
 Consumidores de software e serviços de gestão de documentos de arquivo, que
engloba os utilizadores dos sistemas e serviços, as organizações consumidoras e os
seus gestores tecnológicos, consultores/operadores, entre outros.
 Legislação e Conformidade. Onde se incluem os legisladores e auditores deste tipo
de sistemas que asseguram que estes cumprem as leis e normas da área de gestão de
documentos de arquivo.
Identificadas as partes interessadas no negócio o portal pretende apresentar uma vista de
negócio para cada uma delas assegurando as funcionalidades necessários para a gestão de
todas. Assim os:
 Gestores de especificações e entidades ligadas à legislação e conformidade têm que
ter ao seu dispor funcionalidades para gerir os requisitos do negócio como:
o Criação, alteração e eliminação de requisitos.

56
 o Identificação dos requisitos por categorias e/ou referências internas e externas.
o Ferramenta de estruturação de requisitos que permite a manutenção dos
vários requisitos do portal.
 Consumidores de sistemas e serviços de gestão de documentos de arquivo têm de ter
ao dispor duas actividades principais:
o Criação de caderno de encargos, que detalhe o tipo de serviços/sistemas que
procuram através dos requisitos no portal.
o Avaliação de Propostas/Respostas ao caderno de encargos.

 Fornecedores de sistemas e serviços de gestão de documentos de arquivo têm de ter

ao dispor também duas actividades principais:
o Representação do sistema/serviço que representam através dos requisitos no
portal.
o Criação de Propostas/Respostas aos cadernos de encargos dos
consumidores.
Com as funcionalidades referidas o sistema permite auxiliar duas actividades principais
recorrentes: a selecção de produtos por parte dos consumidores e a resposta às exigências
dos consumidores por parte dos fornecedores.
Assim foi definido em conjunto com o André que um requisito seria descrito no sistema por
um identificador interno, uma prioridade por defeito, um autor/criador do requisito, descrição e
categoria do mesmo. Todos os campos referidos são obrigatórios na criação de um requisito e
existe ainda o campo opcional notas que permite adicionar qualquer informação que se
considere relevante sobre o mesmo.
O requisito depois de criado deve poder ser apagado, alterado, relacionado com outro
(indicando o motivo e tipo de relação) e/ou dividido, que consiste em criar dois sub-requisitos
que representam uma refinação (ou simplificação) do requisito principal. Dois requisitos podem
ainda ser unidos tornando-se sub-requisitos de um novo requisito principal.
As funcionalidades referidas permitem assim estruturar os requisitos da mesma maneira
que, por exemplo, foi feito para o MoReq2 nesta dissertação.
Tanto os cadernos de encargos como os produtos dos fornecedores são então
representados indicando os requisitos do portal que cumprem, podendo também criar novos
requisitos não existentes na base de dados do portal, e introduzir notas sobre os mesmos.
Essa representação é feita através de uma lista de verificação onde se apresentam os
requisitos disponíveis e são indicados quais os requisitos pretendidos, no caso do caderno de
encargos, e os requisitos cumpridos, no caso do produto do fornecedor. Na criação de um
caderno de encargos é possível ainda definir prioridades (pesos) para cada um dos requisitos
pretendidos.
A avaliação/selecção de produtos foi determinada que ocorreria da seguinte forma:
1. Quando criado um caderno de encargos, o criador ou responsável pelo mesmo tem as
seguinte opções à sua disposição:

57
 a. Tornar o caderno de encargos público no portal permitindo resposta a todos os
fornecedores.
b. Seleccionar quais os fornecedores registados no portal a que pretende divulgar
o caderno de encargos.
c. Converter o caderno de encargos em documento (formato PDF, Word,
OpenOffice, etc) e divulgá-lo pelos meios que considerar adequados.
2. Tirando a hipótese 1.c. todas as outras podem dar origem a uma resposta de um
fornecedor. O responsável, ou responsáveis, pelo produto do fornecedor tem as
seguintes hipóteses de resposta:
a. Responder directamente ao caderno de encargos, que implica seleccionar quais
os requisitos que o seu produto cumpre, podendo adicionar notas sobre cada
um dos requisitos.
b. Se tiver um produto representado no portal, pode optar por fazer uma avaliação
automática e responder com base nela. A avaliação automática é feita
comparando os dois conjuntos de requisitos (caderno de encargos e produto) e
seleccionando automaticamente os que são cumpridos. Depois da avaliação o
responsável pelo produto tem ainda a opção de adicionar mais requisitos
cumpridos não identificados no processo e acrescentar detalhes à sua
representação do produto.
c. Converter o caderno de encargos em documento e responder da maneira e
pelos meios que considerar adequados.
3. As respostas dos fornecedores são enviadas ao consumidor, responsável pelo caderno
de encargos, que pode então tomar uma decisão sobre o produto a contratar com base
nos dados fornecidos.
Para além das funcionalidades já referidas todos os utilizadores do portal têm que se
autenticar para o poder utilizar e possuem um sistema de pesquisa de requisitos para auxiliar
na gestão e selecção dos mesmos.
Com as funcionalidades do portal os fornecedores têm não só uma oportunidade de
divulgação dos seus produtos e um meio central para responder às exigências dos seus
consumidores, como têm uma base de dados de requisitos que pode ser usada como base
para a evolução do seu software.
Infelizmente à data de conclusão deste relatório de dissertação o portal não tem ainda todas
as funcionalidades implementadas faltando principalmente o processo de resposta aos
cadernos de encargos. As funcionalidades de gestão de requisitos e representação de um
caderno de encargos e produtos estão feitas mas encontram-se ainda em fase de testes pelo
que seria prematuro dá-las como concluídas. O portal encontra-se temporariamente disponível
em http://web.ist.utl.pt/~ist155406/RMPortal/index.php.

58
 7. Conclusões e Trabalho Futuro
Esta dissertação teve como objectivo final compreender o estado da arte da avaliação de
software de maneira a poder propor um processo de avaliação especifico para SGC de acordo
com especificações de requisitos. O objectivo foi atingido e considera-se que o trabalho
realizado para atingir esse propósito é útil e cria novos temas de desenvolvimento e
investigação. As conclusões retiradas dos métodos de avaliação permitem que o sistema em
análise (SmartDocs) principie um processo de desenvolvimento com visto uma evolução e um
alinhamento com os requisitos do MoReq2. A reestruturação do MoReq2 permite obter uma
nova vista dos requisitos da especificação, o que pode facilitar não só a sua utilização como
também o seu processo de análise. O resultado final permite estruturar um processo que se
prevê recorrente nas organizações que pretendem que os seus SGC estejam alinhados com
especificações de requisitos.
A área de avaliação de software, tal como referido no capítulo 2, é bastante extensa e
antiga e existe um conjunto grande (mais de 15000) de artigos, trabalhos e projectos
publicados sobre a mesma. No entanto a maior parte dos artigos centram-se no
enquadramento e importância da avaliação de software como fase crucial do processo de
desenvolvimento e evolução de um software, e no que diz respeito a técnicas de avaliação a
utilizar estas baseiam-se principalmente em técnicas de decisão pouco formais e definidas
utilizando varios produtos de software. Os artigos encontrados poucas vezes referem a análise
de requisitos como meio de avaliação dando muitas vezes a entender que a gestão de
requisitos e a aplicação destes é única e exclusivamente utilizada no desenvolvimento do
software e não na sua evolução. Inclusive tal como referido no subcapítulo 2.3 as técnicas de
avaliação utilizadas nesta dissertação são normalmente utilizadas com objectivos diferentes da
avaliação de um sistema de acordo com uma especificação de requisitos. As listas de
verificação e listas ponderadas são tipicamente utilizadas para ajudar no processo de decisão e
selecção de um produto de acordo com um conjunto de produtos a analisar, visto que
apresentam resultados que mesmo sem posterior análise podem ser usados para comparar
produtos de acordo com uma pontuação ou resultado quantitativo.
Esses factos foram o maior problema no desenvolvimento deste projecto de mestrado mas
são também os que dão mais valor científico aos resultados obtidos. Tendo conhecimento que
existe pouca investigação para este problema específico e que existe áreas de negócio em que
esse conhecimento pode ser aplicado, a solução encontrada tem valor, pelo menos, em última
instância como ponto de partida. O projecto de mestrado de (André Veiga, 2010) no qual
colaborei é um exemplo claro de varias áreas de negocio com varias perspectivas (evolução de
software, gestão de especificação de requisitos e selecção de software) em que a solução aqui
apresentada pode ser utilizada.
Existem no entanto aspectos que podem ser melhorados nas fases identificadas da solução
proposta (análise, avaliação e planeamento):

59
  A análise tanto do sistema como da especificação usada não foi baseada em nenhuma
técnica formal. O conhecimento das funcionalidades do SmartDocs foi obtido por
experimentação, leitura dos manuais do produto e acções de formação para utilizadores
contando sempre com a ajuda e disponibilidade da equipa de desenvolvimento do produto
para o esclarecimento de qualquer dúvida. Para a análise do MoReq2 foram utilizados
diagramas que categorizam os requisitos da especificação (referidos no capítulo 4 e
apresentados no anexo I), e a leitura tanto da especificação como de artigos de análise à
mesma. Apesar de nenhum dos métodos poder ser considerado errado visto que cumpre o
objectivo de dar a conhecer os elementos a utilizar ao avaliador, a não existência de
actividades definidas para essa análise e obtenção de conhecimento, acentua o problema
da subjectividade da avaliação. Um trabalho a desenvolver seria a criação de um processo
de análise bem definido que garantisse que o avaliador compreendeu totalmente todos os
aspectos da especificação e do produto em estudo.
 Tal como referido no capítulo anterior a correcção dos resultados na avaliação por lista
ponderada é directamente proporcional à correcção dos pesos dos requisitos, ou seja,
depende particularmente da análise da especificação. No caso específico deste projecto de
mestrado a atribuição de pesos foi feita com base numa reestruturação da especificação de
requisitos tendo em conta as dependências entre eles e uma categorização dos mesmos.
Um trabalho a realizar principalmente nas futuras versões do MoReq e outras
especificações de requisitos seria a criação de diversas perspectivas dos requisitos que
permitisse não só facilitar a priorização destes, as suas dependências e as áreas que estes
abrangem.
Reconhecendo também o valor e utilidade do portal para a gestão de requisitos de SGDA
seria importante terminar o projecto e disponibiliza-lo online visto que, apesar do valor do
conceito, este só terá significado com a utilização e aderência das partes interessadas dos
processos de negócio visados.

60
 Bibliografia
Alfresco Software, Inc. AlfrescoWiki. http://wiki.alfresco.com/wiki/Main_Page (acedido em
22 de Setembro de 2010).

Anderson, D. G. Comparing Open Source and Proprietary Enterprise Content Mangement

Systems. Göteborg: Chalmers University of Technology and University of Göteborg, 2008.

Asprey, Len, e Michael Middleton. “Specifying your requirements and selecting your
supplier for records and document management applications.” AIIM Info@2002: The
Enterprise Information & Content Management Forum. Hammersmith, London, 2002.

Bell, Toby, Karen M. Shegda, Mark R. Gilbert, Kenneth Chin, e Mick MacComascaigh. Magic
Quadrant for Enterprise Content Management. Gartner, 2009.

Broadbent, R. E. A Functional Framework For Content Management. Utah: Brigham Young

University, 2009.

Business Wire. “Top Web Content Management Team Joins Alfresco Software.” Business
Wire, 2006.

Canning, R. “That maintenance 'iceberg'.” EDP Analyzer, 10 de October de 1972: 1-14.

Chapin, Ned, Joanne E. Hale, Khaled Md. Khan, Juan F. Ramil, e Wui-Gee Tan. “Types of
software evolution and software maintenance.” Journal of Software Maintenance and
Evolution: Research and Practice, 2000.

Cornwell Affiliates . MoReq: Model Requirements for the management of electronic records.
Requirement Specification, DLM Forum, 2001.

FileNet. “FileNet Document Management Overview.”

IEEE. std 1219: Standard for Software Maintenance. Los Alamitos, CA, USA: IEEE Computer
Society Press, 1998.

ISO. ISO 15489-1:2001 - Information and Documentation - Records Management - Part 1:

General. ISO, 2001.

ISO/IEC-14764. Std 14764-2006, Software Engineering—Software Life Cycle Processes—

Maintenance. IEEE, 2006.

ISO95 Int. Standards Organisation. “ISO 12207 Information Technology: Software Life Cycle
Processes.” Geneva, Switzerland, 1995.

Jadhav, Anil, e Rajendra Sonar. “Analytic Hierarchy Process (AHP), Weighted Scoring
Method (WSM), and Hybrid Knowledge Based System (HKBS) for Software Selection: A
Comparative Study.” Second International Conference on Emerging Trends in Engineering and
Technology. IEEE, 2009.

Komoski, P. K. Educational microcomputer evaluation. Oxford: Pergamon Press, 1987.

61
 Lehman, Jenni. Magic Quadrants and MarketScopes: How Gartner Evaluates Vendors
Within a Market. Gartner, 2008.

Lehman, M. M. “Programs, Life Cycles, and Laws of Software Evolution.” IEEE, 1980: 1060-
1076.

Lehman, M. M., D. E. Perry, e J. F. Ramil. “Implications of evolution metrics on software

maintenance.” 1998 IEEE Internacional Conference on Software Maintenance. Bethesda,
Maryland, 1998.

Levine, Ronda. “A Sample Gap Analysis Explained.” 30 de Junho de 2010.

http://www.brighthub.com/office/project-management/articles/76008.aspx (acedido em 22
de Setembro de 2010).

—. “Learn About Gap Analysis Methods: Wich is the Best?” 20 de Julho de 2010.
http://www.brighthub.com/office/project-management/articles/75624.aspx (acedido em 22
de Setembro de 2010).

McDougall, A., e D. Squires. “A critical examination of the checklist approach in software

selection.” Journal of Educational Computing Research, 1995: 74-263.

OpenText. Enterprise Content Management (ECM) - Open Text Corporation.

http://www.opentext.com/2/global/company (acedido em 22 de Setembro de 2010).

—. “Open Text Document Management Product Overview.” Enterprise Content

Management (ECM) - Open Text Corporation. 2009. (acedido em 22 de Setembro de 2010).

—. “Open Text Records Management Product Overview.” Enterprise Content Management

(ECM) - Open Text Corporation. 2009. (acedido em 22 de Setembro de 2010).

Parnas, D. L. “Software aging.” 16th Internacional Conference on Software Engineering.

Sorrento, Italy, 1994.

Powell, J. “Alfresco: Software for Information Governance.” Islington Council. 14 de

Fevereiro de 2008.
http://www.islington.gov.uk/DownloadableDocuments/CouncilandDemocracy/Pdf/edrm_in_t
he_public_sector/Alfresco_Software_for_Information_Governance_presentation.pdf (acedido
em 22 de Setembro de 2010).

Prichard, W. H., Th. Micceri, e A. J. Barret. “A review of computer-based training materials:

Current state of the art (instruction and interaction).” Educational, 1989: 16-22.

Shariff, M. Alfresco Enterprise Content Management Implementation. Packt Publishing,

2007.

Sharma, Ruben. “What is SWOT Analysis? How to do a SWOT Analysis in Project

Management using a SWOT Analysis Template.” 17 de Maio de 2010.
http://www.brighthub.com/office/project-management/articles/45156.aspx (acedido em 22
de Setembro de 2010).

62
 Shelly, G. B., T. J. Chasman, e H. J. Rosenblatt. Systems analysis and design. Boston, MA:
Thomson. Course Technology, 2001.

SpringCM. Cloud ECM, enterprise content management, web document management,

workflow. http://www.springcm.com/products (acedido em 22 de Setembro de 2010).

Swanson, E. B. “The dimensions of maintenance.” 2nd Internacional Conference on

Software Engineering. San Francisco, CA, 1976.

Tergan, Sigmar-Olaf. “Checklists for the Evaluation of Educational Software: Critical Review
and.” Innovations in Education and Teaching International, 1998: 9-20.

Veiga, André. “Arquitectura de Sistemas de Informação de Referência para Gestão

Documental na Administração Pública.” *A submeter no IST em Outubro de 2010+.

Zhu, Wei-Dong, et al. IBM FileNet P8 Platform and Architecture. IBM RedBooks, 2009.

Zhu, Wei-Dong, Serena S Chan, Gunther Flaig, Yi Wang, Keith Wheeler, e R Hogg. Working
with IBM Records Manager. IBM RedBooks, 2007.

63
 ANEXO I – DIAGRAMAS DE MODELAÇÃO DOS REQUISITOS DO MOREQ2
Cada diagrama representa um subcapítulo do MoReq2 cujo nome se encontra no canto superior esquerdo de
cada diagrama.
3. CLASSIFICATION SCHEME AND FILE ORGANISATION
custom Configuring the Classification Scheme
3.1.1 Organi zati on
Compati bl e
3.1.2 Internal Integri ty
3.1.4 Hi erarchy of Cl asses.
3.1.5 Admi ni strati on
Management
3.1.8 Cl assi fi cati on Scheme
Creati on
3.1.9 T i tl i ng Mechani sm
3.1.25 Add Cl asses
3.1.11 Import/Export ::
MoReq2 XML Schema
3.1.3 Identi fi er, T i tl e and
Descri pti on
3.1.6 User Management
3.1.7 Number of Level s
3.1.10 T extual Scope Notes
3.1.26 Mul ti pl e Cl assi fi cati on
Schemes
Import Al l or Part of the
Cl assi fi cati on Scheme
3.1.12 Import ::
Cl assi fi cati on Scheme
3.1.13 Import :: Retenti on 3.1.14 Import :: Excepti on
Schedul es & Audi t T rai l s Report
3.1.15 Import :: Hi erarchi cal 3.1.16 Import :: Val i dati on
Code Rul es
Export Al l or Part of the Cl assi fi cati on
Scheme
3.1.17 Export ::
Cl assi fi cati on Scheme
3.1.18 Export :: Sel ect 3.1.19 Export :: Sel ect
Metadata Retenti on Schedul es
3.1.20 Export :: Sel ect Audi t 3.1.21 Export ::
T rai l Documentati on
3.1.22 Export :: XML
Copyi ng Al l or Part of the
Cl assi fi cati on Scheme
3.1.23 Copy :: Cl assi fi cati on 3.1.24 Copy :: Retenti on
Scheme Schedul es
req Classes and Files

3.2.8 Date of 3.2.15 No Number Limit Title and Classification Code

Opening/Closing Class or of Classes or Files
File 3.2.3 Hierarchical 3.2.4 Title
Classification Code

3.2.17 Configura a Class 3.2.9 Date of Creation of

to store Records a Class, File, Sub-File or
Volume
3.2.5 Use of Classification
Code and Textual File Title

3.2.16 Export a list of all

Files

3.2.6 Configure 3.2.7 Configuration of

Classification Code Classification Code

Inherited Metadata
Use of Controlled Vocabulary Terms Classes and Files Metadata

3.2.13 Controlled 3.2.1 Capture, Mantain and 3.2.10 Inherited Metadata

Vocabulary Terms Present Metadata
compliant to ISO 2788

3.2.14 Controlled 3.2.2 Restrict the ability to

vocabulary terms add Metadata
compliant to ISO 5694 3.2.11 Modify inherited 3.2.12 All child inherit
Metadata Metadata

custom Volumes and Sub-Files

Create Volumes and/or Sub-Files within Files Delete Volume

3.3.15 Delete an Empty

3.3.1 Ability to create Volume
Sub-Files and/or Volumes

exclusive exclusive 3.3.16 Delete and re-open

Volumes

3.3.2 Allow only Sub-Files 3.3.3 Allow only Volumes 3.3.13 Most recently created
within Files volume
within Files

exclusive 3.3.17 T emplate of

Sub-Files

Open/Close Volumes

3.3.5 Prevent adding 3.3.6 Add Volume to

3.3.7 Add Sub-Files to File
Records to closed Volumes Sub-File not closed
not closed

3.3.9 Date of Volume or 3.3.8 Close Sub-File

Sub-File Opening

3.3.4 Open/Close Volumes

3.3.11 Identifier of Volume

3.3.10 Common parent file's

3.3.14 Creation of Multiple metadata
open Sub-Files

3.3.19 Allow Users to close 3.3.18 Automatically close 3.3.12 Volume Close Date
Volumes sub-files
req Maintaining the Classification Scheme [Maintaining the Classification Scheme] ...

Rellocate Rules Rellocate & Copy Rules Copy Rules

3.4.8 Rellocate Records with 3.4.5 Classes reclassified 3.4.9 Copy Records with
Classes and/or Files Classes and/or Files

3.4.10 Mantain Close Status 3.4.7 Relocato or copy

while Relocating according to the rules

3.4.11 Close or reference 3.4.12 Inheritance in

open Files
relocation

3.4.16 Log values of their

metadata pior to the 3.4.13 Apply inheritable
Retention and Disposition
relocation
Schedules during relocation or
copy

3.4.14 Reason for relocation

or copying

3.4.15 Log status prior to the

relocation or copying

Maintaining Classification Scheme Operations

Other Maintance Operations

3.4.1 Relocate a Class 3.4.4 Copy a Class

3.4.17 Mark as inactive 3.4.23 Cross-references
between Files

3.4.2 Combine two Classes 3.4.3 Divide a Class 3.4.18 Delete an empty class 3.4.24 Multiple entries of
Records without duplication

3.4.19 Prevent deletion of File 3.4.25 Reporting tools

and contents

3.4.20 Allow File to be Closed 3.4.26 Ad hoc reports of

activity
3.4.6 Relocate, divide,
combine and copy without
3.4.21 Close Volume 3.4.27 Navigate throught
import and/or export context and parents
automattically

3.4.22 Equal visualization of 3.4.28 Reason for changing

Open and Close entities keyword

3.4.29 Clear trace of

Keywords
4.Controls and Security
req Acess [Acess]

4.1.1. Only authorised users Administrator Acess Rights

4.1.10 Define same access 4.1.11 Selecions of access

4.1.8 Administration rights rights to user roles as for across roles
over Classification Scheme users

4.1.9 Mark user as inactive

4.1.2 Administrator allocate
acess

4.1.15 Systems functions only

to Administrator

4.1.4 Administrator maintain 4.1.5 Administrator can

permissions restric/denie acess
4.1.17 User with ownership
can set acess

Administrator Groups, Roles and Lists Rights Profile Acess Rights

4.1.12 Administrator set up 4.1.3 No limit to number of 4.1.16 Administrator set up

and mantain groups of users roles or groups users profiles

4.1.7 Administrator 4.1.14 Administrator can set

add/remove users from ad hoc lists of users
4.1.18 Only Administrator
roles/groups make changes to groups,
roles or users profiles

4.1.13 User can be member

of zero or more groups
Acess Denied

4.1.23 ERMS must have 4.1.22 Only show records with

different responses to access acess in a search result
denied

Administrator can create rules and roles

4.1.24 Acess denied

4.1.19 Administrator can set 4.1.20 Administrator can response is set on classes
up and manage rules of create roles
acess

Administrator Remote Acess

4.1.6 Acess throught 4.1.21 Administrator can

integrated network log-on provide acess throught
another application system
req Audit Trails [Rotinas de Auditoria]

Audit Trail Parameters

Audit Trail Data

4.2.4 The audit trail
parameters configurable
4.2.3 Audit Trail must log 4.2.10 Annotation and
any acess amendment to a record
must be logged

4.2.5 All changes to audit 4.2.6 Track actions 4.2.8 All actions performed
trail parameters must be automatically after audit in entities of the 4.2.11 Changes to
logged trail set of parameters classification scheme must Administrative parameters
be logged must be logged

4.2.9 Changes to 4.2.16 ERMS must

metadata must be logged capture and store acess
4.2.7 Preserve Audit Trail Unalterable Audit Trail violation

4.2.1 The ERMS must

keep and unalterable
4.2.12 Audit Trail always
audit trail
available for inspection
Audit Trail Search

4.2.15 Export specified

4.2.2 Audit trail data can
parts of the audit trail
be transfer out of the 4.2.14 Search of Audit
4.2.13 Allow authorised
ERMS maintaining integrity Trail must include specified
users to search for
and structure events, objects, users,
information in audit trail
groups, etc

req Backup and Recov ery [Backup and Recov ery] ...

Backup and Recovery

4.3.5 Only administratores can

set checkpoints and database
roll-forwards

4.3.2 Administrator schedule 4.3.1 ERMS must provide

backup routines automated backup and
recovery procedures

4.3.3 Administrator can

restore backups

4.3.4 After a restore system

must have full integrity of the
data

req Vital Records [Vital Records]

Vital Records Backup and Recover

4.4.4 ERMS must have two
methods of restoring

4.4.1 ERMS must have the

concept of "vital records"

4.4.2 ERMS must have extra 4.4.5 Records can be

marked as no longer vital
backup to vital records

4.4.3 After recover of "vital

backup" system must be fully
operational
5.Retention and Disposition
 req Reav aliação [Reav aliação] ...

Review Process
5.2.1 Administrator must be notified
of retention and dispositions 5.2.2 ERMS must support the
schedules wich will come into force review process presenting all the
information to be reviewed

5.2.3 ERMS apply disposition

actions simultaneously in all
different renditions of a record
5.2.4 A reviewer can mark for 5.2.5 Date of review must be
destruction, transfer, further review logged
5.2.8 If an entitie refered by
another one is about to be or infinite retention
destroyed the administrador should
be notified

5.2.6 Reviewers can enter reasons

of review decisions

5.2.7 ERMS must keep an

unalterable history of review
decisions including reasons

req Transferência, Exportação e Eliminação [Transferência, Exportação e Eliminação]

Transfer Process Export Process

5.3.14 ERMS must retain 5.3.4 Export Records in

all data being transferred 5.3.1 Export Records form of a submission
until confirmation of a compliant with MoReq2 information package as
successful transfer XML Schema defined by OAIS standard
5.3.3 ERMS must have a
transfer process

5.3.16 ERMS exported

5.3.15 ERMS must delete 5.3.23 Information can be classes preserve relative
all data transfered after exported more than once location and can rebuild
confirmation except the whole parent class
metada retained as stub branch

5.3.17 ERMS can add

user-defined metadata 5.3.18 ERMS must ensure
elements for achival complete destruction of a
management purposes record
Data Transferred or Exported

5.3.24 ERMS must

provide a report after 5.3.6 All implicit metada 5.3.2 In a transfer or
information transfer or must be explicit in a export export all components
export or transfer process must go with the record
and preserve their
relantionships
5.3.5 When
transfering/exporting all
content "below" in 5.3.7 The retention and
Metada Stub
classification scheme must disposition schedules
go along must be exported or
5.3.19 ERMS must have transfered along or printed
the ability to retain a explicited
metadata stub for entities 5.3.8 The access rights
wich have been destroyed 5.3.22 Metadata stubs must be exported or
or transferred can also be exported transfered along or printed 5.3.9 In a transfer or
along with records. explicited export the content,
structure, components
and links are preserved

5.3.21 Administrator can 5.3.10 If one of the record

5.3.20 Metada Stub exported or transfered has
specify more metada as
includes date, a pointer then the content 5.3.11 In a transfer or
stub
classification code, title, pointed must also go export the format of a
description, user along record must be preserved
responsible, reason and
references
5.3.13 ERMS can migrate
5.3.12 In a transfer or
transfered or exported
export the format of
records to another format
renditions must be
preserved
6.Capturing and Declaring Records
req Bulk Importing [Bulk Importing]

6.2.2 ERMS must Bulk Import

be ablte to
capture
transactional 6.2.1 ERMS must
records be able to bulk 6.2.7 ERMS must
generated by 6.2.8 import records manage input
other systems Administrator can consistent with queues
choose to close MoReq2 XML
the enitities schema
imported

6.2.5 Audit Trails

can be imported
along with
imported records

6.2.4 ERMS
needs to validade 6.2.3
metadata in a Automatically 6.2.6 The audit
bulk import just capture metadata trails imported in
like manual in a bulk import 6.2.5 dont go to
capture the audit trail of
the ERMS

req e-Mail Management [e-Mail Management]...

Methods to Capture E-mails

6.3.12 If a user captures 6.3.2 The capture of a
a delivery status e-mail can be done within
notification report the the e-mail application
ERMS should link it to the
respective e-mail record 6.3.4 The ERMS must be
totally configurable about
6.3.17 Users can save capturing received mails
proprietary format mails in
open formats 6.3.16 The ERMS should
capture automatically an
e-mail type specified by a
user
6.3.3 The ERMS must be
totally configurable about
capturing sent mails
6.3.6 User can capture
an e-mail by dragging it
from an e-mail client to
the ERMS
6.3.15 A user can
capture several e-mails in
one action

Metadata of Captured E-mails

6.3.1 A captured e-mail 6.3.5 ERMS must

must retain header
information
6.3.7 User can select if
he wants just the e-mail,
just the attachments or
both
6.3.9 When capturing a
attachment only the user
needs to enter metadata
for it
6.3.10 The title of an
e-mail record must be by
default the subject of the
e-mail
automatically support the
extraction of metada in
outgoing and incoming
mails
6.3.11 A user capturing
an e-mail can edit the
record title

6.3.8 Records and

attachments captured 6.3.13 Metadata of 6.3.14 User can set date
separately must be linked e-mails and attachments sent and date received of
must be captured an e-mail record
automatically
6.3.18 ERMS should
capture display names
rather than address fields
 req Record Types [Record Types]

Record T ypes

6.4.1 Records
types can be
defined and
mantain

6.4.3 Definition
6.4.2 All records and maintenance
must have exactly of record types is
one record type exclusive to
Administrators

6.4.5 6.4.4
Administrator can Administrator can
define a record restricte the
type as default creation of record
who can be used types to specified
by all users group of users

req Scanning and Imaging [Scanning and Imaging]

Scanning Solution
6.5.10 ERMS should
6.5.18 A scanning
6.5.6 Scanning feature identify single
session should be
must handle at least A4 documents in a bulk
logged
and A3 paper format scanning process
6.5.5 Scanning feature
6.5.4 Scanning feature 6.5.21 ERMS should be
should be capable of 6.5.11 Scanning feature
must be capable of capable of bulk import
saving images in colour must be able to send
saving images at scanned imagens and
or greyscale scanned images to a
different resolutions their metadata
queue after scanning

6.5.1 At least one 6.5.22 Thumbnails of

6.5.12 ERMS should
scanning solution can scanned imagens
be integred support inspection of
should be display to hel
6.5.3 Scanning result scanned images
navigation and search
must be in standard
formats 6.5.14 ERMS can have
different set-up scanning 6.5.23 Users can
parameters for different capture scanned images
6.5.2 The scanning
document types as records
solution should support
monochrome and colour
scanning 6.5.13 Administrator can
set a threshold for image
information

6.5.20 ERMS should

6.5.19 ERMS should
OCR Funcionality automatically capture
relevant metadata when
scanning
6.5.7 Scanning feature
should have OCR
have automated
classification based on
metadata that was
automatically captured

Annotation Funcionality

6.5.15 User can

annotate images
6.5.8 When OCR is
6.5.9 When OCR is
present it must be able
to treat image and text present it must allow full
text search
as a single record

6.5.16 Anotation of 6.5.17 Annotations must

images cant be changed have identity of user,
or removed time and date, attached

7.Referencing
req Classification Codes [Classification Codes]

Classification Codes
Manual/Automatic Classification Codes
7.1.1 Classes, Files, Sub-Files, 7.1.4 Classification Codes must
Volumes, Records and 7.1.8 Administrator can 7.1.9 ERMS must generate
be stored as metadata
Components must have a configure the system to accept next sequence number in
Classification Code manual or automatic Classification Code
Classification Codes

Fully-Qualified Classification Codes

7.1.2 The Fully-Qualified

Classification Code is unique 7.1.5 Administrator can 7.1.10 ERMS must validate a
7.1.6 Fully-Qualified
within a classification scheme configure the Classification Classification Code inputed by
Classification Codes must
hierarchy Codes a user
consist in several Classification
Codes separated by a
separator character

7.1.3 After a realocation the 7.1.7 Separator character can

Fully-Qualified Classification be selected from a list
Codes and Classification
Codes must be unique

req System Identifiers [System Identifiers]

System Identifiers

7.2.1 All Classification Schemes,

Classes, Files, Sub-Files,
Volumes, Records, redactions,
retention and disposition
7.2.2 The System Identifier must schedules and document hava a
be unique in the classification system identifier.
scheme and ERMS instance

7.2.6 Users never enter any

System Identifier for any ERMS
7.2.4 System Identifiers should be function
7.2.3 Metadata elements can
refer to entities by their system globally unique
identifiers

7.2.5 ERMS should use the UUID

algorithm to generate globally
unique system identifiers
8.Searching, Retrieval and Presentation
req Search and Retriev al [Search and Retriev al] ...
8.1.1 ERMS search function
only shows result who have
security clearance to the user
8.1.7 Search can be used as 8.1.2 Users can search all
part of declaration process entities of the Classification
Scheme
8.1.9 Seach should operate 8.1.3 Users can specify any
in an integrated and combination of metadata
consistent manner across elements as search terms
both record content and
metadata
8.1.4 Users can specify wich
8.1.11 Users can re-fine a type of entity they are
search without having to searching
re-enter search criteria
8.1.20 Keywords can only be 8.1.5 Search function should
changed by an Administrator appear the same to users
regardless of entity search
8.1.25 ERMS must behave in 8.1.6 Users can search text
an identical manner when content of records
searching regardless of
location of results
8.1.33 ERMS can set other
search engine other than the
default one Thesaurus Use
8.1.19 Administrator is
responsable to mantain
thesaurus
8.1.18 If thesaurus compliant
with ISO 2788 or ISO 5694 is
being used the ERMS should
use full features
req Presentation: Displaying Records [Presentation: Displaying Records]
8.2.1 ERMS must
be able to
present the
contents of
Classification
Scheme entities
by a mouse click
or keystroke
Search Terms
8.1.8 User can use any
combination of metadata
elements and/or textual
record content in a search
8.1.13 Search function can
use Boolean operator
8.1.14 Users can search
keywords
8.1.15 Keyword terms search
can be selected from
controlled vocabularies
8.1.16 ERMS should have a
thesaurus to search by
concept
8.1.17 When using thesaurus
for concept searching it
should be compliant with at
least ISO 2788 and ISO 5964
Displaying Records
8.2.2 ERMS
should be able to
present records
even if the
software
associated with
them are not
present
8.1.21 ERMS should support 8.1.28 Users can specify time
partial match of search term intervals in calendar
8.1.22 ERMS should support
word proximity searching
8.1.29 Time intervals in
search should be specified
either as dates or in natural
8.1.26 Users can save and language
re-use search terms
8.1.27 Users can share saved
search terms
8.1.23 Users can limit the
scope of any search
Result Display
8.1.10 A search must present 8.1.30 Administrator can
the number of result and how configure display of search
many are being displayed results
8.1.12 Administrator can 8.1.31 ERMS should provide
configure the elements shown implicit or explicit relevance
to diference results of a ranking of the search results
search
8.1.32 When a result is a
8.1.24 When retrieving a
entity it most show all redaction the ERMS should
contents and contextual relate the record from wich it
metadata associated has generated
8.2.3 The ERMS
should be able to
present records in
a way that
original visual
presentation is
preserved and all
component are
together
req Presentation: Printing [Presentation: Printing]
8.3.2 ERMS can print all or specified
metadata
8.3.3 ERMS must allow multiple
record printing in one operation
8.3.7 Users can print results of a
search
8.3.8 Administrator can print all or
selected administrative parameters
8.3.19 ERMS printings must preserve
the layout and include all printable
components of a record
Printable Elements
8.3.14 Authorised user can print all or 8.3.15 User can specify the content
8.3.1 ERMS must be able to print the
part of the Classification Scheme and format of the printed
content of records and metadata
Classification Scheme
8.3.4 Users can create a summary of 8.3.16 Administrator can print a list of 8.3.17 User can specify the
selected metadata for selected all files classified against a specified sequence, content and format of the
aggregations of records class printed list of files from specified class
8.3.9 Administrator can print retention 8.3.18 Administrator can print all or
and disposition schedules parts of audit trails
8.3.10 Administrator can print 8.3.11 ERMS can print a list of each
thesaurus controlled vocabulary 8.3.13 When controlled vocabulary is
a thesaurus ERMS should print all
terms and relationships
8.3.12 ERMS should be able to
export a list of each controlled
vocabulary
Printing Configuration
8.3.5 Administrator can choose 8.3.6 Users can amend the dafault
metadata default that are printed with metada elements that are appended
a record to printouts
req Presentation: Other [Presentation: Other]
8.4.1 ERMS must include features for
presenting and outputting to appropriate
media, records wich cannot be printed
9.Administrative Functions
req General Administration [General Administration]

Administration Responsabilities

9.1.1 Administrator can retrieve, 9.1.3 Administrator must be

display and re-configure system warned when available storage
parameters and settings is below a level set at
configuration time

9.1.2 Administrator can allocate 9.1.4 If ERMS supports error

functions to users and roles rate reporting then
and alocates users to roles Administrator should be warned
about excessive error rate

9.1.5 Administrator can easily

move users between user
groups and roles

req Reporting [Reporting]

9.2.1 Administrator can 9.2.10 ERMS must have
produce periodic reports reports on total number and
and specify ad hoc reports location of several
combinations of entities
9.2.2 ERMS must include
9.2.14 ERMS should have
features to print, visualize
and store reports reports on actions sorted by
user, workstation and
network address
9.2.3 User can capture a
report as a record
9.2.11 ERMS must have
9.2.9 Reports can be reports about rate of
exported for use in other capture, retrieval and
application creation
9.2.8 Reports requests can
be saved for future re-use
9.2.13 Reports can be
specified to cover only part
of the system, specified
users or/and specified dates
9.2.12 If ERMS have a
document management
then must able to provide
reports about it
Types of Reports
9.2.18 ERMS must have 9.2.24 Administrator can
reports on the audit trail produce report on
attempted acess control
and other security policy
9.2.19 Administrator can violations
produce audit trails reports
based on security
categories, user groups or
9.2.29 ERMS should
other metadata
accumulate statistics of the
imposition and lifting of
9.2.16 ERMS must have
disposal holds and provide
reports listing files, sub-files
reports about it
and volumes for all or part
of the classification scheme
9.2.31 ERMS must have
report about any failure
9.2.15 Reports described in during an importation
9.2.11 should cover
specified time interval
9.2.17 ERMS must have
9.2.32 ERMS should report about system storage
support the import process in use and available
by tracking and reporting on
its progress and status

Report Configuration Retention and Dispostion Schedules Reports

9.2.4 Reports should 9.2.23 Administrator can

covered a specified date
range or time interval
9.2.5 ERMS must allow
sorting and selecting
information included in
reports
9.2.7 ERMS should have
graphical reporting
restrict acess to selected 9.2.20 ERMS must have
reports reports on the outcome of a
disposition process
indicating any failure
9.2.6 ERMS should have
features for totalling and
summarising report 9.2.22 ERMS must have
information reports on disposition
activity indicating disposition
actions that are overdue
9.2.26 ERMS should have
reports of records about to
be reviewed
9.2.28 ERMS should
accumulate statistics of
review decisions and
provide reports about it
9.2.33 ERMS should be
able to sort files selected for
transfer into ordered lists
according to selected
metadata
9.2.21 ERMS must have
reports on the outcome of
an export process indicating
any failure
9.2.25 Administrator should
be able to specify the
frequency of retention and
disposition schedule, the
information reported and
highlighting exceptions
9.2.27 ERMS should
support reporting and
analysis tools for the
management of retention
and disposition schedules
9.2.30 ERMS must have
report about any failure
during a transfer, export,
destruction or deletion
9.2.34 ERMS should be
able to produce
user-defined reports
describing files and records
being exported or
transferred
req Changing, Deleting and Redacting Records [Changing, Deleting and Redacting Records]

Administrator Rights and Responsability

9.3.20 Any 9.3.16 ERMS
change made as should enable
result of any 9.3.6 Users can 9.3.5
amendment of
requirement in selected metdada mark Classes, Administrator can
this section must Files, Sub-Files, delete Classes,
values to users
be logged with permission Volumes and Files, Sub-Files,
Records as Volumes and
candidates for Records
deletion
System Configuration

9.3.1 ERMS must 9.3.3 If option

9.3.7 A deletion 9.3.8
have 9.3.1 is selected
implies logging, Administrator can
configuration that then ERMS
reporting, change any
prevent any simulates deletion
deleting, ensure user-entered
record from being and copies or
that ERMS stays metadata
deleted or moved moves records in
consistent, warn
even by relocation
about links to
Administrators
other files and
9.3.4 If option maintain integrity 9.3.10
9.3.2 ERMS must
of the metadata
have 9.3.2 is selected Administrator can
configuration that then ERMS really create one or
allow deleting delet and move more redactions
and moving a the record 9.3.9 All changes of a record
record to metadata must
be logged

Redaction

9.3.18 In a record
9.3.11 ERMS 9.3.14
user can see all
must allow Redactions
the redactions
removal or hiding should be
made from that
of sensitive considered
record
information within records and be
a redaction classified in the
same 9.3.15 During
aggregation redaction creation
9.3.17 Records metadata can be
and redaction copied from
should be record
9.3.13 During
cross-reference redaction creation
user must enter a 9.3.12 During
9.3.19 In a reason to be redaction creation
redaction, user stored in record date, time and
can see the and redaction creator must be
original record metadata stored in
redaction and
record metadata
ANEXO II – RESULTADOS QUANTITATIVOS COMPLETOS DA AVALIAÇÃO
POR LISTA DE VERIFICAÇÃO.
Requisitos Obrigatórios Requisitos Opcionais Total

Cumpridos (%)

Cumpridos (%)

Cumpridos (%)
Cumpridos

Cumpridos

Cumpridos
Requisitos

Requisitos

Requisitos

Requisitos

Requisitos

Requisitos

Requisitos

Requisitos

Requisitos
Número de

Número de

Número de
Plano de Classificação e Organização de Pastas 72 21 29% 19 11 58% 91 32 35%
Configuração do Plano de Classificação 19 5 26% 6 5 83% 26 10 38%
Classes e Pastas 12 6 50% 5 1 20% 17 7 41%
Volumes e Sub-Pastas 18 5 28% 1 0 0% 19 5 26%
Gestão do Plano de Classificação 22 5 23% 7 5 71% 29 10 34%
Segurança e Controlo 45 22 49% 5 1 20% 50 23 46%
Acesso 21 13 62% 3 0 0% 24 13 54%
Rotina de Auditoria 15 8 53% 1 1 100% 16 9 56%
Salvaguarda e Recuperação 5 1 20% 0 0 - 5 1 20%
Documentos de Arquivo Vitais 4 0 0% 1 0 0% 5 0 0%
Retenção e Destino 61 0 0% 14 0 0% 75 0 0%
Tabelas de Selecção 34 0 0% 9 0 0% 43 0 0%
Revisão do Destino 7 0 0% 1 0 0% 8 0 0%
Transferência, Exportação e Eliminação 20 0 0% 4 0 0% 24 0 0%
Captura e Declaração de Documentos de Arquivo 63 29 46% 32 7 22% 95 36 38%
Captura 26 13 50% 15 1 7% 41 14 34%
Importação em Bloco 8 0 0% 0 0 - 8 0 0%
Gestão de Correio Electronico 15 5 33% 3 0 0% 18 5 28%
Tipos de Documentos de Arquivo 5 5 100% 0 0 - 5 5 100%
Imagens e Digitalização 9 6 67% 14 6 43% 23 12 52%
Referenciação 12 9 75% 4 1 25% 16 10 63%
Codigos de Classificação 8 5 63% 2 1 50% 10 6 60%
Identificadores de Sistema 4 4 100% 2 0 0% 6 4 67%
Pesquisa, Recuperação e Visualização 34 17 50% 22 5 23% 56 22 39%
Pesquisa e Recuperação 19 11 58% 14 4 29% 33 15 45%
Apresentação: Visualização de Documentos de Arquivo 1 1 100% 2 1 50% 3 2 67%
Apresentação: Impressão 13 5 38% 6 0 0% 19 5 26%
Apresentação: Outros 1 0 0% 0 0 - 1 0 0%
Funções Administrativas 36 13 36% 23 4 17% 59 17 29%
Administração Geral 3 2 67% 2 1 50% 5 3 60%
Relatorios 17 4 24% 17 2 12% 34 6 18%
Alterar, Eliminar e Truncar Documentos de Arquivo 16 7 44% 4 1 25% 20 8 40%

Tabela 1. Resultados da avaliação por lista de verificação discriminados pela obrigatoriedade dos requisitos.
 ANEXO III – REESTRUTURAÇÃO DO MOREQ2 SEGUNDO OS DIAGRAMAS
DE ANÁLISE DO ANEXO I
Todas as tabelas de reestruturação apresentam a mesma estrutura fixa com os campos:
 Referência original, do MoReq2.
 Mudança, indicação da mudança no requisito que pode ser:
o Requisito Principal, o requisito passa a ser um requisito principal.
o Sub-Requisito, o requisito passa a ser um sub-requisito.
o Novo Requisito Principal, introdução de um novo requisito na especificação.
o Não, não há alteração do nível do requisito.
 Nova Referência, de acordo com a nova estruturação e identificativa das relações entre requisitos principais
e sub-requisitos.
 Descrição do Novo Requisito.
Cada tabela corresponde a um subcapítulo do MoReq2 e são apresentadas pela mesma ordem (para facilitar a
análise, usam-se nos títulos das secções os mesmos termos originais em Inglês usados do documento de referência
do MoReq2).

3. Classification Scheme and File Organisation

3.1. Configuring the Classification Scheme

Referência Original Mudança Nova Referência Descrição de Novo Requisito

3.1.1 Não -
3.1.2 Não -
3.1.3 Não -
3.1.4 Não -
3.1.5 Não -
3.1.6 Não -
3.1.7 Não -
3.1.8 Não -
3.1.9 Não -
3.1.10 Não -
3.1.11 Não -
3.1.12 Requisito Principal 3.1.12.0
3.1.13 Sub-Requisito 3.1.12.1
3.1.14 Sub-Requisito 3.1.12.2
3.1.15 Sub-Requisito 3.1.12.3
3.1.16 Sub-Requisito 3.1.12.4
3.1.17 Requisito Principal 3.1.13.0
3.1.18 Sub-Requisito 3.1.13.1
3.1.19 Sub-Requisito 3.1.13.2
3.1.20 Sub-Requisito 3.1.13.3
3.1.21 Sub-Requisito 3.1.13.4
3.1.22 Sub-Requisito 3.1.13.5

The ERMS must support the copying of

- Novo Requisito Principal 3.1.14.0
all or part of a classification scheme

3.1.23 Sub-Requisito 3.1.14.1

3.1.24 Sub-Requisito 3.1.14.2
3.1.25 Não 3.1.15
3.1.26 Não 3.1.16
3.2. Classes and Files

Referência Original Mudança Nova Referência Descrição de Novo Requisito

3.2.1 Requisito Principal 3.2.1.0
3.2.2 Sub-Requisito 3.2.1.1

The ERMS must support the creation,

maintenance and use of a classification
- Novo Requisito Principal 3.2.2.0
code and title to each class, file, sub-file
and volume in the classification scheme
3.2.3 Sub-Requisito 3.2.2.1
3.2.4 Sub-Requisito 3.2.2.2
3.2.5 Sub-Requisito 3.2.2.3
3.2.6 Sub-Requisito 3.2.2.4
3.2.7 Sub-Requisito 3.2.2.5
3.2.8 Não 3.2.3
3.2.9 Não 3.2.4
3.2.10 Requisito Principal 3.2.5.0
3.2.11 Sub-Requisito 3.2.5.1
3.2.12 Sub-Requisito 3.2.5.2

The ERMS should support the allocation

of controlled vocabulary terms as
- Novo Requisito Principal 3.2.6.0 descriptive class or file metadata subject
terms, in addition to the other
requirements in this section
3.2.13 Sub-Requisito 3.2.6.1
3.2.14 Sub-Requisito 3.2.6.2
3.2.15 Não 3.2.7
3.2.16 Não 3.2.8
3.2.17 Não 3.2.9

3.3. Volumes and Sub-Files

Referência Original Mudança Nova Referência Descrição de Novo Requisito

It must be possible for and
administrative role to configure the
ERMS at configuration time or later to
- Novo Requisito Principal 3.3.1.0 remove the ability to create sub-files
and/or volumes (or only one of them)
within files across the classification
scheme
3.3.1 Sub-Requisito 3.3.1.1
3.3.2 Sub-Requisito 3.3.1.2
3.3.3 Sub-Requisito 3.3.1.3
3.3.4 Requisito Principal 3.3.2.0
3.3.5 Sub-Requisito 3.3.2.1
3.3.6 Sub-Requisito 3.3.2.2
3.3.7 Sub-Requisito 3.3.2.3
3.3.8 Sub-Requisito 3.3.2.4
3.3.9 Sub-Requisito 3.3.2.5
3.3.10 Sub-Requisito 3.3.2.6
3.3.11 Sub-Requisito 3.3.2.7
3.3.12 Sub-Requisito 3.3.2.8
3.3.13 Não 3.3.3
3.3.14 Sub-Requisito 3.3.2.9
3.3.15 Sub-Requisito 3.3.4.1
3.3.16 Requisito Principal 3.3.4.0
3.3.17 Não 3.3.5
3.3.18 Sub-Requisito 3.3.2.10
3.3.19 Sub-Requisito 3.3.2.11
3.4. Maintaining the Classification Scheme

Referência Original Mudança Nova Referência Descrição de Novo Requisito

3.4.1 Requisito Principal 3.4.1.0
3.4.2 Requisito Principal 3.4.2.0
3.4.3 Requisito Principal 3.4.3.0
3.4.4 Requisito Principal 3.4.4.0
3.4.5 Sub-Requisito 3.4.1.1 & 3.4.4.1
3.4.1.2 & 3.4.2.1 &
3.4.6 Sub-Requisito
3.4.3.1 & 3.4.4.2
3.4.7 Sub-Requisito 3.4.1.3 & 3.4.4.3
3.4.8 Sub-Requisito 3.4.1.4
3.4.9 Sub-Requisito 3.4.4.4
3.4.10 Sub-Requisito 3.4.1.5
3.4.11 Sub-Requisito 3.4.1.6
3.4.12 Sub-Requisito 3.4.1.7 & 3.4.4.5
3.4.13 Sub-Requisito 3.4.1.8 & 3.4.4.6
3.4.14 Sub-Requisito 3.4.1.9 & 3.4.4.7
3.4.15 Sub-Requisito 3.4.1.10 & 3.4.4.8
3.4.16 Sub-Requisito 3.4.1.11
3.4.17 Não 3.4.5
3.4.18 Não 3.4.6
3.4.19 Não 3.4.7
3.4.20 Não 3.4.8
3.4.21 Não 3.4.9
3.4.22 Não 3.4.10
3.4.23 Não 3.4.11
3.4.24 Não 3.4.12
3.4.25 Não 3.4.13
3.4.26 Não 3.4.14
3.4.27 Não 3.4.15
3.4.28 Não 3.4.16
3.4.29 Não 3.4.17
4. Controls and Security
4.1. Access

Referência Original Mudança Nova Referência Descrição de Novo Requisito

4.1.1 Não -
The ERMS must allow administrative
roles to allocate, restric and maintain
access to records, sub-files, files,
- Novo Requisito Principal 4.1.2.0 classes and metadata to specified
users and/or user roles and/or user
groups and for specified periods of
time
4.1.2 Sub-Requisito 4.1.2.1
The ERMS must allow na
- Novo Requisito Principal 4.1.3.0 administrative role to set up and
maintain roles and/or groups of users
4.1.3 Sub-Requisito 4.1.3.1
4.1.4 Sub-Requisito 4.1.2.2
4.1.5 Sub-Requisito 4.1.2.3
- Novo Requisito Principal 4.1.4.0 The ERMS should allow remote access
4.1.6 Sub-Requisito 4.1.4.1
4.1.7 Sub-Requisito 4.1.3.2
4.1.8 Não 4.1.5
4.1.9 Não 4.1.6
4.1.10 Sub-Requisito 4.1.2.4
4.1.11 Sub-Requisito 4.1.2.5
4.1.12 Sub-Requisito 4.1.3.3
4.1.13 Sub-Requisito 4.1.3.4
4.1.14 Sub-Requisito 4.1.3.5
4.1.15 Não 4.1.7
4.1.16 Requisito Principal 4.1.8.0
4.1.17 Não 4.1.9
4.1.18 Sub-Requisito 4.1.3.6 & 4.1.8.1
4.1.19 Requisito Principal 4.1.10.0
4.1.20 Sub-Requisito 4.1.10.1
4.1.21 Sub-Requisito 4.1.4.2
The ERMS must assure that a user
- Novo Requisito Principal 4.1.11.0 can't access a record withou
permission to it
4.1.22 Sub-Requisito 4.1.11.1
4.1.23 Sub-Requisito 4.1.11.2
4.1.24 Sub-Requisito 4.1.11.3
4.2. Audit Trails

Referência Original Mudança Nova Referência Descrição de Novo Requisito

4.2.1 Requisito Principal 4.2.1.0
4.2.2 Sub-Requisito 4.2.1.1
The ERMS audit trail must be capable
- Novo Requisito Principal 4.2.2.0
of logging all system's events
4.2.3 Sub-Requisito 4.2.2.1
4.2.4 Requisito Principal 4.2.3.0
4.2.5 Sub-Requisito 4.2.3.1
4.2.6 Sub-Requisito 4.2.3.2
4.2.7 Não 4.2.4
4.2.8 Sub-Requisito 4.2.2.2
4.2.9 Sub-Requisito 4.2.2.3
4.2.10 Sub-Requisito 4.2.2.4
4.2.11 Sub-Requisito 4.2.2.5
4.2.12 Não 4.2.5
4.2.13 Requisito Principal 4.2.6.0
4.2.14 Sub-Requisito 4.2.6.1
4.2.15 Não 4.2.7
4.2.16 Sub-Requisito 4.2.2.6

4.3. Backup and Recovery

Referência Original Mudança Nova Referência Descrição de Novo Requisito

4.3.1 Requisito Principal 4.3.1.0
4.3.2 Sub-Requisito 4.3.1.1
4.3.3 Sub-Requisito 4.3.1.2
4.3.4 Sub-Requisito 4.3.1.3
4.3.5 Sub-Requisito 4.3.1.4

4.4. Vital Records

Referência Original Mudança Nova Referência Descrição de Novo Requisito

4.4.1 Requisito Principal 4.4.1.0
4.4.2 Sub-Requisito 4.4.1.1
4.4.3 Sub-Requisito 4.4.1.2
4.4.4 Não 4.4.2
4.4.5 Sub-Requisito 4.4.1.3
5. Retention and Disposition
5.1. Retention and Disposition Schedules

Referência Original Mudança Nova Referência Descrição de Novo Requisito

5.1.1 Requisito Principal 5.1.1.0
5.1.2 Sub-Requisito 5.1.1.1
5.1.3 Sub-Requisito 5.1.1.2
5.1.4 Não 5.1.2
5.1.5 Não 5.1.3
5.1.6 Sub-Requisito 5.1.4.1
5.1.7 Sub-Requisito 5.1.4.2
5.1.8 Requisito Principal 5.1.4.0
5.1.9 Não 5.1.5
5.1.10 Requisito Principal 5.1.6.0
5.1.11 Sub-Requisito 5.1.6.1 & 5.1.7.1
5.1.12 Requisito Principal 5.1.7.0
5.1.13 Sub-Requisito 5.1.7.2
5.1.14 Sub-Requisito 5.1.1.3
5.1.15 Sub-Requisito 5.1.7.3
5.1.16 Sub-Requisito 5.1.6.2
5.1.17 Sub-Requisito 5.1.7.4
5.1.18 Sub-Requisito 5.1.6.3 & 5.1.7.5
5.1.19 Requisito Principal 5.1.8.0
5.1.20 Requisito Principal 5.1.9.0
5.1.21 Não 5.1.10
5.1.22 Sub-Requisito 5.1.9.1
5.1.23 Não 5.1.11
5.1.24 Sub-Requisito 5.1.9.2
5.1.25 Sub-Requisito 5.1.8.1
5.1.26 Sub-Requisito 5.1.8.2
5.1.27 Sub-Requisito 5.1.8.3
5.1.28 Sub-Requisito 5.1.9.3
5.1.29 Sub-Requisito 5.1.9.4
5.1.30 Sub-Requisito 5.1.9.5
5.1.31 Sub-Requisito 5.1.9.6
5.1.32 Não 5.1.12
5.1.33 Não 5.1.13
5.1.34 Requisito Principal 5.1.14.0
5.1.35 Sub-Requisito 5.1.14.1
5.1.36 Sub-Requisito 5.1.14.2
5.1.37 Sub-Requisito 5.1.14.3
5.1.38 Sub-Requisito 5.1.14.4
5.1.39 Sub-Requisito 5.1.14.5
5.1.40 Sub-Requisito 5.1.14.6
5.1.41 Sub-Requisito 5.1.14.7
5.1.42 Sub-Requisito 5.1.14.8
5.1.43 Sub-Requisito 5.1.14.9

5.2. Review of Disposition Actions

Referência Original Mudança Nova Referência Descrição de Novo Requisito

5.2.1 Não -
5.2.2 Sub-Requisito 5.2.3.1
5.2.3 Não 5.2.2
5.2.4 Requisito Principal 5.2.3.0
5.2.5 Sub-Requisito 5.2.3.2
5.2.6 Sub-Requisito 5.2.3.3
5.2.7 Sub-Requisito 5.2.3.4
5.2.8 Não 5.2.4
5.3. Transfer, Export and Destruction

Referência Original Mudança Nova Referência Descrição de Novo Requisito

5.3.1 Não -
5.3.2 Sub-Requisito 5.3.2.1
5.3.3 Requisito Principal 5.3.2.0
5.3.4 Sub-Requisito 5.3.2.2
5.3.5 Sub-Requisito 5.3.2.3
5.3.6 Sub-Requisito 5.3.2.4
5.3.7 Sub-Requisito 5.3.2.5
5.3.8 Sub-Requisito 5.3.2.6
5.3.9 Sub-Requisito 5.3.2.7
5.3.10 Sub-Requisito 5.3.2.8
5.3.11 Sub-Requisito 5.3.2.9
5.3.12 Sub-Requisito 5.3.2.10
5.3.13 Sub-Requisito 5.3.2.11
5.3.14 Sub-Requisito 5.3.2.12
5.3.15 Sub-Requisito 5.3.2.13
5.3.16 Sub-Requisito 5.3.2.14
5.3.17 Não 5.3.3
5.3.18 Não 5.3.4
5.3.19 Requisito Principal 5.3.5.0
5.3.20 Sub-Requisito 5.3.5.1
5.3.21 Sub-Requisito 5.3.5.2
5.3.22 Sub-Requisito 5.3.5.3
5.3.23 Sub-Requisito 5.3.2.15
5.3.24 Não 5.3.6
6. Capturing and Declaring Records
6.1. Capture

Referência Original Mudança Nova Referência Descrição de Novo Requisito

6.1.1 Requisito Principal 6.1.1.0
6.1.2 Sub-Requisito 6.1.1.1
6.1.3 Requisito Principal 6.1.2.0
6.1.4 Sub-Requisito 6.1.2.1
6.1.5 Sub-Requisito 6.1.2.2
6.1.6 Sub-Requisito 6.1.2.3
6.1.7 Não 6.1.3
6.1.8 Requisito Principal 6.1.4.0
6.1.9 Sub-Requisito 6.1.4.1
6.1.10 Sub-Requisito 6.1.1.2
6.1.11 Sub-Requisito 6.1.4.2
6.1.12 Não 6.1.5
6.1.13 Não 6.1.6
6.1.14 Requisito Principal 6.1.7.0
6.1.15 Não 6.1.8
6.1.16 Não 6.1.9
6.1.17 Não 6.1.10
6.1.18 Não 6.1.11
6.1.19 Não 6.1.12
6.1.20 Não 6.1.13
6.1.21 Não 6.1.14
6.1.22 Não 6.1.15
6.1.23 Requisito Principal 6.1.16.0
6.1.24 Sub-Requisito 6.1.16.1
6.1.25 Sub-Requisito 6.1.16.2
6.1.26 Sub-Requisito 6.1.16.3
6.1.27 Não 6.1.17
6.1.28 Sub-Requisito 6.1.16.4
6.1.29 Não 6.1.18

The ERMS must be able to warn a user

- Novo Requisito Principal 6.1.19.0
if some action requires attention

6.1.30 Sub-Requisito 6.1.19.1

6.1.31 Não 6.1.20
6.1.32 Não 6.1.21
6.1.33 Não 6.1.22
6.1.34 Sub-Requisito 6.1.7.1
6.1.35 Sub-Requisito 6.1.7.2
6.1.36 Não 6.1.23
6.1.37 Sub-Requisito 6.1.19.2
6.1.38 Sub-Requisito 6.1.19.3
6.1.39 Sub-Requisito 6.1.19.4
6.1.40 Sub-Requisito 6.1.19.5
6.1.41 Não 6.1.24

6.2. Bulk Importing

Referência Original Mudança Nova Referência Descrição de Novo Requisito
6.2.1 Requisito Principal 6.2.1.0
6.2.2 Não 6.2.2
6.2.3 Sub-Requisito 6.2.1.1
6.2.4 Sub-Requisito 6.2.1.2
6.2.5 Sub-Requisito 6.2.1.3
6.2.6 Sub-Requisito 6.2.1.4
6.2.7 Sub-Requisito 6.2.1.5
6.2.8 Sub-Requisito 6.2.1.6
6.3. E-Mail Management

Referência Original Mudança Nova Referência Descrição de Novo Requisito

6.3.1 Não -
6.3.2 Não -
6.3.3 Não -
6.3.4 Não -
6.3.5 Não -
6.3.6 Não -
6.3.7 Requisito Principal 6.3.7.0
6.3.8 Sub-Requisito 6.3.7.1
6.3.9 Sub-Requisito 6.3.7.2
6.3.10 Requisito Principal 6.3.8.0
6.3.11 Sub-Requisito 6.3.8.1
6.3.12 Não 6.3.9
6.3.13 Não 6.3.10
6.3.14 Não 6.3.11
6.3.15 Não 6.3.12
6.3.16 Não 6.3.13
6.3.17 Não 6.3.14
6.3.18 Não 6.3.15

6.4. Record Types

Referência Original Mudança Nova Referência Descrição de Novo Requisito

6.4.1 Requisito Principal 6.4.1.0
6.4.2 Sub-Requisito 6.4.1.1
6.4.3 Sub-Requisito 6.4.1.2
6.4.4 Sub-Requisito 6.4.1.3
6.4.5 Sub-Requisito 6.4.1.4

6.5. Scanning and Imaging

Referência Original Mudança Nova Referência Descrição de Novo Requisito

6.5.1 Requisito Principal 6.5.1.0
6.5.2 Sub-Requisito 6.5.1.1
6.5.3 Sub-Requisito 6.5.1.2
6.5.4 Sub-Requisito 6.5.1.3
6.5.5 Sub-Requisito 6.5.1.4
6.5.6 Sub-Requisito 6.5.1.5
6.5.7 Requisito Principal 6.5.2.0
6.5.8 Sub-Requisito 6.5.2.1
6.5.9 Sub-Requisito 6.5.2.2
6.5.10 Não 6.5.3
6.5.11 Não 6.5.4
6.5.12 Não 6.5.5
6.5.13 Não 6.5.6
6.5.14 Não 6.5.7
6.5.15 Requisito Principal 6.5.8.0
6.5.16 Sub-Requisito 6.5.8.1
6.5.17 Sub-Requisito 6.5.8.2
6.5.18 Não 6.5.9
6.5.19 Não 6.5.10
6.5.20 Não 6.5.11
6.5.21 Não 6.5.12
6.5.22 Não 6.5.13
6.5.23 Não 6.5.14
7. Referencing
7.1. Classification Codes

Referência Original Mudança Nova Referência Descrição de Novo Requisito

7.1.1 Requisito Principal 7.1.1.0
7.1.2 Requisito Principal 7.1.2.0
7.1.3 Sub-Requisito 7.1.2.1
7.1.4 Sub-Requisito 7.1.1.1
7.1.5 Sub-Requisito 7.1.3.1
7.1.6 Sub-Requisito 7.1.2.2
7.1.7 Sub-Requisito 7.1.2.3
7.1.8 Requisito Principal 7.1.3.0
7.1.9 Sub-Requisito 7.1.3.2
7.1.10 Sub-Requisito 7.1.3.3

7.2. System Identifiers

Referência Original Mudança Nova Referência Descrição de Novo Requisito

7.2.1 Requisito Principal 7.2.1.0
7.2.2 Sub-Requisito 7.2.1.1
7.2.3 Sub-Requisito 7.2.1.2
7.2.4 Sub-Requisito 7.2.1.3
7.2.5 Sub-Requisito 7.2.1.4
7.2.6 Sub-Requisito 7.2.1.5
8. Searching, Retrieval and Presentation
8.1. Search and Retrieval

Referência Original Mudança Nova Referência Descrição de Novo Requisito

8.1.1 Não -
8.1.2 Não -
8.1.3 Não -
8.1.4 Requisito Principal 8.1.4.0
8.1.5 Sub-Requisito 8.1.4.1
8.1.6 Não 8.1.5
8.1.7 Não 8.1.6
8.1.8 Não 8.1.7
8.1.9 Não 8.1.8
8.1.10 Não 8.1.9
8.1.11 Não 8.1.10
8.1.12 Não 8.1.11
8.1.13 Não 8.1.12
8.1.14 Requisito Principal 8.1.13.0
8.1.15 Sub-Requisito 8.1.13.1
8.1.16 Requisito Principal 8.1.14.0
8.1.17 Sub-Requisito 8.1.14.1
8.1.18 Sub-Requisito 8.1.14.2
8.1.19 Sub-Requisito 8.1.14.3
8.1.20 Não 8.1.15
8.1.21 Não 8.1.16
8.1.22 Não 8.1.17
8.1.23 Não 8.1.18
8.1.24 Não 8.1.19
8.1.25 Não 8.1.20
8.1.26 Requisito Principal 8.1.21.0
8.1.27 Sub-Requisito 8.1.21.1
8.1.28 Requisito Principal 8.1.22.0
8.1.29 Sub-Requisito 8.1.22.1
8.1.30 Não 8.1.23
8.1.31 Não 8.1.24
8.1.32 Não 8.1.25
8.1.33 Não 8.1.26

8.2. Presentation: Displaying Records

Referência Original Mudança Nova Referência Descrição de Novo Requisito

8.2.1 Não
8.2.2 Não
8.2.3 Não
8.3. Presentation: Printing

Referência Original Mudança Nova Referência Descrição de Novo Requisito

8.3.1 Requisito Principal 8.3.1.0
8.3.2 Sub-Requisito 8.3.1.1
8.3.3 Sub-Requisito 8.3.1.2
8.3.4 Sub-Requisito 8.3.1.3
8.3.5 Requisito Principal 8.3.2.0
8.3.6 Sub-Requisito 8.3.2.1
8.3.7 Não 8.3.3
8.3.8 Não 8.3.4
8.3.9 Não 8.3.5
8.3.10 Não 8.3.6
8.3.11 Requisito Principal 8.3.7.0
8.3.12 Sub-Requisito 8.3.7.1
8.3.13 Sub-Requisito 8.3.7.2
8.3.14 Requisito Principal 8.3.8.0
8.3.15 Sub-Requisito 8.3.8.1
8.3.16 Requisito Principal 8.3.9.0
8.3.17 Sub-Requisito 8.3.9.1
8.3.18 Não 8.3.10
8.3.19 Não 8.3.11

8.4. Presentation: Other

Referência Original Mudança Nova Referência Descrição de Novo Requisito

8.4.1 Não -
9. Administrative Functions
9.1. General Administration

Referência Original Mudança Nova Referência Descrição de Novo Requisito

9.1.1 Não -
9.1.2 Não -
9.1.3 Não -
9.1.4 Não -
9.1.5 Não -

9.2. Reporting

Referência Original Mudança Nova Referência Descrição de Novo Requisito

9.2.1 Não -
9.2.2 Não -
9.2.3 Não -
9.2.4 Não -
9.2.5 Não -
9.2.6 Não -
9.2.7 Não -
9.2.8 Não -
9.2.9 Não -
9.2.10 Não -
9.2.11 Requisito Principal 9.1.11.0
9.2.12 Requisito Principal 9.1.12.0
9.2.13 Sub-Requisito 9.1.11.1 & 9.1.12.1
9.2.14 Não 9.1.13
9.2.15 Sub-Requisito 9.1.11.2
9.2.16 Não 9.1.14
9.2.17 Não 9.1.15
9.2.18 Não 9.1.16
9.2.19 Não 9.1.17
The ERMS must be able to produce
reports about the retention and
- Novo Requisito Principal 9.1.18.0
disposition schedules and all actions
related to them
9.2.20 Sub-Requisito 9.1.18.1
9.2.21 Sub-Requisito 9.1.18.2
9.2.22 Sub-Requisito 9.1.18.3
9.2.23 Não 9.1.19
9.2.24 Não 9.1.20
9.2.25 Sub-Requisito 9.1.18.4
9.2.26 Sub-Requisito 9.1.18.5
9.2.27 Sub-Requisito 9.1.18.6
9.2.28 Sub-Requisito 9.1.18.7
9.2.29 Sub-Requisito 9.1.18.8
9.2.30 Sub-Requisito 9.1.18.9
9.2.31 Não 9.1.21
9.2.32 Não 9.1.22
9.2.33 Sub-Requisito 9.1.18.10
9.2.34 Sub-Requisito 9.1.18.11
9.3. Changing, Deleting and Redacting Records

Referência Original Mudança Nova Referência Descrição de Novo Requisito

9.3.1 Requisito Principal 9.3.1.0
9.3.2 Requisito Principal 9.3.2.0
9.3.3 Sub-Requisito 9.3.1.1
9.3.4 Sub-Requisito 9.3.2.1
9.3.5 Requisito Principal 9.3.3.0
9.3.6 Sub-Requisito 9.3.3.1
9.3.7 Sub-Requisito 9.3.3.2
9.3.8 Requisito Principal 9.3.4.0
9.3.9 Sub-Requisito 9.3.4.1
9.3.10 Requisito Principal 9.3.5.0
9.3.11 Sub-Requisito 9.3.5.1
9.3.12 Sub-Requisito 9.3.5.2
9.3.13 Sub-Requisito 9.3.5.3
9.3.14 Sub-Requisito 9.3.5.4
9.3.15 Sub-Requisito 9.3.5.5
9.3.16 Não 9.3.6
9.3.17 Sub-Requisito 9.3.5.6
9.3.18 Sub-Requisito 9.3.5.7
9.3.19 Sub-Requisito 9.3.5.8
9.3.20 Não 9.3.7
ANEXO IV – RESULTADOS QUANTITATIVOS COMPLETOS DA AVALIAÇÃO
POR LISTA PONDERADA.

Tabela 1. Resultados da avaliação por lista ponderada discriminados por obrigatoriedade dos requisitos.
Tabela 2. Resultados da avaliação por lista ponderada nos requisitos principais discriminados por obrigatoriedade dos requisitos.
Tabela 3. Resultados da avaliação por lista ponderada nos requisitos normais discriminados por obrigatoriedade dos requisitos.
Tabela 4. Resultados da avaliação por lista ponderada nos sub-requisitos discriminados por obrigatoriedade dos requisitos
Tabela 5. Resultados da avaliação por lista ponderada discriminados por respostas quantitativas