Embed Size (px)
Citation preview
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
1
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.
2
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;
3
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;
4
Í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
5
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
6
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 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
TABELA 11. LISTA DE PROPOSTAS DE DESENVOLVIMENTO PARA O SMARTDOCS OBTIDA ATRAVÉS DA ANÁLISE DE INTERVALOS.
...................................................................................................................................................... 52
7
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
8
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
9
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.
10
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)
11
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.
12
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.
13
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,
as definições aqui identificadas foram obtidas da norma ISO 15489, do site da AIIM1 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/
14
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
15
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.
16
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
17
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).
18
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
19
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
20
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.
21
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).
22
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
23
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).
24
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:
•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 Modelação de Conteúdo
•Controlo de Versões.
•Ferramentas de Auditoria.
•Relações entre Documentos.
Serviços de Biblioteca
•Pesquisa simples e avançada.
•Pesquisa através do Internet Explorer ou Firefox.
Serviços de Pesquisa
•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 Colaboração
•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.
Serviços de Segurança
25
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.
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.
•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 Gestão e Controlo do Ciclo de Vida 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.
Serviços de Suporte ao Destino do Documento
26
As funcionalidades presentes em cada uma das áreas seguintes encontram-se listadas na
figura 7.
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
•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
Captura e Armazenamento 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.
Gestão de Documentos
•Criação de Fluxos de Trababalho Simples e Complexos.
Fluxo de Trabalho e Colaboração
•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.
Entrega de Documentos
•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 Documentos de Arquivo
•Criação de Relatórios Simples e Avançados configuráveis.
•Criação de Templates de Relatórios.
Gestão de Relatórios
27
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).
28
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
Funcionalidade Âmbito da Área
Plano de
Classificação
Funções para criação e manutenção de uma estrutura ou base para o
armazenamento e identificação dos documentos.
Identificação e
Categorização
Inclui todas as funções que permitem uma melhor identificação do documento
como suporte de metadados, anotações, atribuir categorias, etc.
Captura de
Documentos
Diversos métodos de captura como aplicações de gestão de correio
electrónico, aplicações Office, entre outras aplicações geradoras de
conteúdo.
Serviços de Biblioteca
Categoria que inclui funcionalidades para uma melhor gestão dos
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.
Fluxo de Trabalho
Funções para criação e gestão de fluxos de trabalho que optimizem a
deslocação de documentos entre utilizadores para aprovação, revisão, entre
outros.
29
Segurança
Gestão de Permissões de acesso, e outras acções, sobre os documentos,
utilizadores, grupos de utilizadores e papéis de utilizadores. Autenticação de
utilizadores.
Prazo de Retenção Funcionalidades relacionadas com a criação, alteração e suspensão de
prazos de retenção e à associação dos mesmos aos documentos.
Suporte ao Destino
dos Documentos
O sistema tem que ter funcionalidades que suportem os varios destinos do
documento após a sua vida útil como a sua eliminação, exportação para um
repositório, posterior avaliação, entre outros.
Tabela 2. Descrição das funcionalidades base de um SGDA
30
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
31
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.
32
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.
33
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
Funcionalidade Funções Presentes no SmartDocs
Plano de Classificação Arquivo e as funções sobre este; Exportação e Importação de Registos.
Identificação e
Categorização Capa, Anotações e Localização do Registo; Descritores;
Captura de
Documentos
Perfil do Registo; Anexos; Captura de Correio Electrónico através de
integração com o Outlook
Serviços de Biblioteca
Impressão de Registo; Certificar Documentos; Duplicação de Registos;
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;
Prazo de Retenção Não possui funcionalidades para gerir os prazos de retenção de um
documento.
Suporte ao Destino
dos Documentos Não possui funcionalidades para gerir o suporte ao destino 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
34
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
versions;
allows a single final version of a
record to exist;
may allow documents to be deleted by
their owners;
prevents records from being deleted
except in certain strictly controlled
circumstances;
may include some retention controls; must include rigorous retention
controls;
may include a document storage
structure, which may be under the
control of users;
must include a rigorous record
arrangement structure (the
classification scheme) which is
maintained by an administrative role;
is intended primarily to support day-to-
day use of documents for ongoing
business.
may support day-to-day working, but
is primarily intended to provide a
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)
35
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
36
Figura 8 Planeamento das novas versões do MoReq1
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
37
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.
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.
req Requirements Model [Legendas]...
Requisito YRequisito X
Agrupamento de Requisitos. Todos os
requisitos dentro da caixa pertencem ao
assunto, funcionalidade ou categoria
indicada.
<Assunto, Funcionalidade ou
Categoria dos Requisitos>
Referência
<Resumo do Requisito>O cumprimento do Requisito Y depende
do cumprimento do Requisito X
Requisito Opcional
Requisito Obrigatório
Referência
<Resumo do Requisito>
38
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.
39
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.
Figura 11 Modelo Entidade-Relação que representa a base de um SGDA segundo o MoReq2.
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.
1
1
1
Sub-file
1
0 - *
Component
1 - *
File
0 - *
1
Volume
0 - *
IS MADE
UP OF
APPLIES
TO
MAY
CONTAINMAY
CONTAIN
MAY BE
DIVIDED
INTO
MAY BE
DIVIDED
INTO
MAY BE
DIVIDED
INTO
MAY BE
DIVIDED
INTO
RecordDocument Record
Type1
1
0 - *1 - *
1 - *
HASIS FORMED
OF
Classification Scheme1
Classification Scheme1
1
1 - *
1 - *
CONTAINS CONTAINS
1 - *
0 - 1
1 - *
1
1 - *
1 - *
1 - *
APPLIES
TO
1 - *APPLIES
TO
1 - *
Retention &
Disposition
Schedule
1 - *
IS MADE
UP OF
1
1 - *
Document
Type
HAS
1
1 - *
IS STORED IN
IS STORED IN
IS MADE UP OF
IS MADE UP OF
Class
1
0 - *
Exactly one Zero or one Zero or more One or more Exclusive OR1 0 – 1 0 - * 1 - *
Key:
1
MAY BE
DIVIDED
INTO
MAY BE
DIVIDED
INTO
0 - *
Ref Requirement Test
13.1.1 The ERMS must provide … Y
NUMBER REQUIREMENT TESTABILITY
40
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.
41
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.
42
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.
43
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.
44
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.
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.
Ref. Essencial Justificação Cumprimento
9.1.1 x O Administrador de sistema é o único com possibilidade de visualizar e reconfigurar as definições de sistema.
X
9.1.2 x O Administrador pode atribuir funções a utilizadores assim como atribuir papéis de utilizadores.
X
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 entre grupos e papéis.
X
Total 3 3 (67%)
45
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
Nú
mero
de
Req
uis
ito
s
Req
uis
ito
s
Cu
mp
rid
os
Req
uis
ito
s
Cu
mp
rid
os (
%)
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%
Requisitos Obrigatórios
46
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
47
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.
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
custom Configuring the Classification Scheme
3.1.11 Import/Export ::
MoReq2 XML Schema
3.1.1 Organization
Compatible
3.1.2 Internal Integrity
3.1.3 Identifier, Title and
Description
3.1.4 Hierarchy of Classes.
3.1.5 Administration
Management
3.1.6 User Management
3.1.7 Number of Levels
3.1.9 Titl ing Mechanism
3.1.10 Textual Scope Notes
3.1.12 Import ::
Classification Scheme
3.1.13 Import :: Retention
Schedules & Audit Trails
3.1.14 Import :: Exception
Report
3.1.15 Import :: Hierarchical
Code
3.1.16 Import :: Validation
Rules
3.1.17 Export ::
Classification Scheme
3.1.18 Export :: Select
Metadata3.1.19 Export :: Select
Retention Schedules
3.1.20 Export :: Select Audit
Trail3.1.21 Export ::
Documentation
3.1.22 Export :: XML
3.1.23 Copy :: Classification
Scheme3.1.24 Copy :: Retention
Schedules
3.1.25 Add Classes
3.1.26 Multiple Classification
SchemesCopying All or Part of the
Classification Scheme
Export All or Part of the Classification
Scheme
Import All or Part of the
Classification Scheme
3.1.8 Classification Scheme
Creation
48
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
medidas é a multiplicação das mesmas.
Requisito
Opcional (Peso 1)
Requisito
Obrigatório (Peso 2)
Requisito Principal (Peso 4) 4 8
Requisito Normal (Peso 3) 3 6
Sub-Requisito de um Requisito Principal
Obrigatório (Peso 2)
2 4
Sub-Requisito de um Requisito Principal
Opcional (Peso 1)
1 2
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
49
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.
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:
Req
uis
ito
s
Pri
ncip
ais
(%
)
Req
uis
ito
s
No
rmais
(%
)
Su
b-
Req
uis
ito
s (
%)
To
tal
(%)
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%
Requisitos Obrigatórios
50
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.
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%;
Cu
mp
re
To
talm
en
te(%
)
Cu
mp
re
Pra
ticam
en
te (
%)
Cu
mp
re
Parc
ialm
en
te (
%)
Não
Cu
mp
re (
%)
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%
Requisitos Obrigatórios
51
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).
52
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.
Ranking Título da Proposta Requisitos RelacionadosPeso da
Proposta
Cumprimento
da Proposta
Manutenção de Permissões 4.1.2-5; 4.1.19 40 13
Papeís de Utilizadores 4.1.2-4; 4.1.8; 4.1.10; 4.1.20 42 9
2 Captura e Classificação de Documentos
3.3.13; 6.1.1; 6.1.4-7; 6.1.12;
6.1.14-15; 6.1.17-19; 6.1.30;
6.1.33-35; 6.1.37-41
81 14
3 Opções de Pesquisa8.1.6-7; 8.1.21-22; 8.1.25-31;
8.1.3354 8
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
Conceito de Tabelas de Selecção3.4.13; 5.1.1-8; 5.1.10-13;
5.1.15-27; 5.1.29-30;133 0
Funções da Tabela de Selecção5.1.3; 5.1.9; 5.1.14; 5.1.28;
5.1.31-3336 0
Suporte ao Destino dos Documentos 5.2.1-8; 5.3.1-18; 5.3.24 114 0
Funções de Manutenção do Plano de Classificação3.1.25; 3.3.16-17; 3.4.2-3; 3.4.5;
3.4.7-16; 3.4.24; 3.4.28-2990 17
Conceito de Entidades Fechadas/Abertas3.3.4-12; 3.3.18-19; 3.4.10-11;
3.4.20-22; 6.1.4177 3
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
Metadados Automáticos3.2.8;3.2.10; 3.4.12; 6.1.17-18;
6.3.10; 6.3.13; 6.5.19-2056 1
Criação e Manutenção de Relatorios5.3.24; 9.2.1; 9.2.4-7; 9.2.10-14;
9.2.16-17; 9.2.19; 9.2.37-52122 12
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
1 Prevenções do Sistema 3.4.19; 8.1.20; 9.3.1; 9.3.3 12 2
Propostas de Adaptação
Propostas de Perfeição
1
3
Propostas de Correcção
1
2
53
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.
54
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.
55
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.
56
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.
57
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:
58
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.
59
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):
60
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.
61
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.
62
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).
63
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.
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.11 Import/Export ::
MoReq2 XML Schema
3.1.1 Organization
Compatible
3.1.2 Internal Integrity
3.1.3 Identifier, Title and
Description
3.1.4 Hierarchy of Classes.
3.1.5 Administration
Management
3.1.6 User Management
3.1.7 Number of Levels
3.1.9 Titl ing Mechanism
3.1.10 Textual Scope Notes
3.1.12 Import ::
Classification Scheme
3.1.13 Import :: Retention
Schedules & Audit Trails
3.1.14 Import :: Exception
Report
3.1.15 Import :: Hierarchical
Code
3.1.16 Import :: Validation
Rules
3.1.17 Export ::
Classification Scheme
3.1.18 Export :: Select
Metadata3.1.19 Export :: Select
Retention Schedules
3.1.20 Export :: Select Audit
Trail3.1.21 Export ::
Documentation
3.1.22 Export :: XML
3.1.23 Copy :: Classification
Scheme3.1.24 Copy :: Retention
Schedules
3.1.25 Add Classes
3.1.26 Multiple Classification
SchemesCopying All or Part of the
Classification Scheme
Export All or Part of the Classification
Scheme
Import All or Part of the
Classification Scheme
3.1.8 Classification Scheme
Creation
req Classes and Files
Use of Controlled Vocabulary TermsInherited Metadata
Classes and Files Metadata
Title and Classification Code
3.2.1 Capture, Mantain and
Present Metadata
3.2.2 Restrict the ability to
add Metadata
3.2.3 Hierarchical
Classification Code
3.2.4 Title
3.2.5 Use of Classification
Code and Textual File Title
3.2.6 Configure
Classification Code3.2.7 Configuration of
Classification Code
3.2.8 Date of
Opening/Closing Class or
File
3.2.9 Date of Creation of
a Class, File, Sub-File or
Volume
3.2.10 Inherited Metadata
3.2.11 Modify inherited
Metadata
3.2.12 All child inherit
Metadata
3.2.13 Controlled
Vocabulary Terms
compliant to ISO 2788
3.2.14 Controlled
vocabulary terms
compliant to ISO 5694
3.2.15 No Number Limit
of Classes or Files
3.2.16 Export a l ist of all
Files
3.2.17 Configura a Class
to store Records
custom Volumes and Sub-Files
Delete Volume
Open/Close Volumes
Create Volumes and/or Sub-Files within Files
3.3.1 Ability to create
Sub-Files and/or Volumes
3.3.2 Allow only Sub-Files
within Files3.3.3 Allow only Volumes
within Files
3.3.4 Open/Close Volumes
3.3.5 Prevent adding
Records to closed Volumes3.3.6 Add Volume to
Sub-File not closed3.3.7 Add Sub-Files to File
not closed
3.3.8 Close Sub-File3.3.9 Date of Volume or
Sub-File Opening
3.3.10 Common parent fi le's
metadata
3.3.11 Identifier of Volume
3.3.12 Volume Close Date
3.3.13 Most recently created
volume
3.3.14 Creation of Multiple
open Sub-Files
3.3.15 Delete an Empty
Volume
3.3.16 Delete and re-open
Volumes
3.3.17 Template of
Sub-Files
3.3.18 Automatically close
sub-fi les
3.3.19 Allow Users to close
Volumes
exclusive
exclusiveexclusive
req Maintaining the Classification Scheme [Maintaining the Classification Scheme] ...
Other Maintance OperationsMaintaining Classification Scheme Operations
Copy RulesRellocate & Copy RulesRellocate Rules
3.4.1 Relocate a Class
3.4.2 Combine two Classes 3.4.3 Divide a Class
3.4.4 Copy a Class
3.4.5 Classes reclassified
3.4.6 Relocate, divide,
combine and copy without
import and/or export
3.4.7 Relocato or copy
according to the rules
3.4.8 Rellocate Records with
Classes and/or Files
3.4.9 Copy Records with
Classes and/or Files
3.4.10 Mantain Close Status
while Relocating
3.4.11 Close or reference
open Files3.4.12 Inheritance in
relocation
3.4.13 Apply inheritable
Retention and Disposition
Schedules during relocation or
copy
3.4.14 Reason for relocation
or copying
3.4.15 Log status prior to the
relocation or copying
3.4.16 Log values of their
metadata pior to the
relocation
3.4.17 Mark as inactive
3.4.18 Delete an empty class
3.4.19 Prevent deletion of File
and contents
3.4.20 Allow File to be Closed
3.4.21 Close Volume
automattically
3.4.22 Equal visualization of
Open and Close entities
3.4.23 Cross-references
between Files
3.4.24 Multiple entries of
Records without duplication
3.4.25 Reporting tools
3.4.26 Ad hoc reports of
activity
3.4.27 Navigate throught
context and parents
3.4.28 Reason for changing
keyword
3.4.29 Clear trace of
Keywords
4.Controls and Security
req Acess [Acess]
Acess Denied
Profile Acess Rights
Administrator Remote Acess
Administrator can create rules and roles
Administrator Groups, Roles and Lists Rights
Administrator Acess Rights4.1.1. Only authorised users
4.1.2 Administrator allocate
acess
4.1.3 No limit to number of
roles or groups
4.1.4 Administrator maintain
permissions
4.1.5 Administrator can
restric/denie acess
4.1.6 Acess throught
integrated network log-on
4.1.7 Administrator
add/remove users from
roles/groups
4.1.8 Administration rights
over Classification Scheme
4.1.9 Mark user as inactive
4.1.10 Define same access
rights to user roles as for
users
4.1.11 Selecions of access
across roles
4.1.12 Administrator set up
and mantain groups of users
4.1.13 User can be member
of zero or more groups
4.1.14 Administrator can set
ad hoc lists of users
4.1.15 Systems functions only
to Administrator
4.1.16 Administrator set up
users profiles
4.1.17 User with ownership
can set acess
4.1.18 Only Administrator
make changes to groups,
roles or users profiles
4.1.19 Administrator can set
up and manage rules of
acess
4.1.20 Administrator can
create roles
4.1.21 Administrator can
provide acess throught
another application system
4.1.22 Only show records with
acess in a search result
4.1.23 ERMS must have
different responses to access
denied
4.1.24 Acess denied
response is set on classes
req Audit Trails [Rotinas de Auditoria]
Audit Trail Search
Audit Trail Data
Audit Trail Parameters
Unalterable Audit Trail
4.2.1 The ERMS must
keep and unalterable
audit trail
4.2.2 Audit trail data can
be transfer out of the
ERMS maintaining integrity
and structure
4.2.3 Audit Trail must log
any acess
4.2.4 The audit trail
parameters configurable
4.2.5 All changes to audit
trail parameters must be
logged
4.2.6 Track actions
automatically after audit
trail set of parameters
4.2.7 Preserve Audit Trail
4.2.8 All actions performed
in entities of the
classification scheme must
be logged
4.2.9 Changes to
metadata must be logged
4.2.10 Annotation and
amendment to a record
must be logged
4.2.11 Changes to
Administrative parameters
must be logged
4.2.12 Audit Trail always
available for inspection
4.2.13 Allow authorised
users to search for
information in audit trail
4.2.14 Search of Audit
Trail must include specified
events, objects, users,
groups, etc
4.2.15 Export specified
parts of the audit trail
4.2.16 ERMS must
capture and store acess
violation
req Backup and Recov ery [Backup and Recov ery] ...
Backup and Recovery
4.3.1 ERMS must provide
automated backup and
recovery procedures
4.3.2 Administrator schedule
backup routines
4.3.3 Administrator can
restore backups
4.3.4 After a restore system
must have full integrity of the
data
4.3.5 Only administratores can
set checkpoints and database
roll-forwards
req Vital Records [Vital Records]
Vital Records Backup and Recover
4.4.1 ERMS must have the
concept of "vital records"
4.4.2 ERMS must have extra
backup to vital records
4.4.3 After recover of "vital
backup" system must be fully
operational
4.4.4 ERMS must have two
methods of restoring
4.4.5 Records can be
marked as no longer vital
5.Retention and Disposition
req Reav aliação [Reav aliação] ...
Review Process5.2.1 Administrator must be notified
of retention and dispositions
schedules wich will come into force
5.2.2 ERMS must support the
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
destruction, transfer, further review
or infinite retention
5.2.5 Date of review must be
logged
5.2.6 Reviewers can enter reasons
of review decisions
5.2.7 ERMS must keep an
unalterable history of review
decisions including reasons
5.2.8 If an entitie refered by
another one is about to be
destroyed the administrador should
be notified
req Transferência, Exportação e Eliminação [Transferência, Exportação e Eliminação]
Metada Stub
Transfer Process
Data Transferred or Exported
Export Process
5.3.1 Export Records
compliant with MoReq2
XML Schema
5.3.2 In a transfer or
export all components
must go with the record
and preserve their
relantionships
5.3.3 ERMS must have a
transfer process
5.3.4 Export Records in
form of a submission
information package as
defined by OAIS standard
5.3.5 When
transfering/exporting all
content "below" in
classification scheme must
go along
5.3.6 All implicit metada
must be explicit in a export
or transfer process
5.3.7 The retention and
disposition schedules
must be exported or
transfered along or printed
explicited
5.3.8 The access rights
must be exported or
transfered along or printed
explicited
5.3.9 In a transfer or
export the content,
structure, components
and links are preserved
5.3.10 If one of the record
exported or transfered has
a pointer then the content
pointed must also go
along
5.3.11 In a transfer or
export the format of a
record must be preserved
5.3.12 In a transfer or
export the format of
renditions must be
preserved
5.3.13 ERMS can migrate
transfered or exported
records to another format
5.3.14 ERMS must retain
all data being transferred
until confirmation of a
successful transfer
5.3.15 ERMS must delete
all data transfered after
confirmation except
metada retained as stub
5.3.16 ERMS exported
classes preserve relative
location and can rebuild
the whole parent class
branch
5.3.17 ERMS can add
user-defined metadata
elements for achival
management purposes
5.3.18 ERMS must ensure
complete destruction of a
record
5.3.19 ERMS must have
the ability to retain a
metadata stub for entities
wich have been destroyed
or transferred
5.3.20 Metada Stub
includes date,
classification code, title,
description, user
responsible, reason and
references
5.3.21 Administrator can
specify more metada as
stub
5.3.22 Metadata stubs
can also be exported
along with records.
5.3.23 Information can be
exported more than once
5.3.24 ERMS must
provide a report after
information transfer or
export
6.Capturing and Declaring Records
req Bulk Importing [Bulk Importing]
Bulk Import
6.2.1 ERMS must
be able to bulk
import records
consistent with
MoReq2 XML
schema
6.2.2 ERMS must
be ablte to
capture
transactional
records
generated by
other systems
6.2.3
Automatically
capture metadata
in a bulk import
6.2.4 ERMS
needs to validade
metadata in a
bulk import just
l ike manual
capture
6.2.5 Audit Trails
can be imported
along with
imported records
6.2.6 The audit
trails imported in
6.2.5 dont go to
the audit trail of
the ERMS
6.2.7 ERMS must
manage input
queues
6.2.8
Administrator can
choose to close
the enitities
imported
req e-Mail Management [e-Mail Management]...
Methods to Capture E-mails
Metadata of Captured E-mails
6.3.1 A captured e-mail
must retain header
information
6.3.2 The capture of a
e-mail can be done within
the e-mail application
6.3.3 The ERMS must be
totally configurable about
capturing sent mails
6.3.4 The ERMS must be
totally configurable about
capturing received mails
6.3.5 ERMS must
automatically support the
extraction of metada in
outgoing and incoming
mails
6.3.6 User can capture
an e-mail by dragging it
from an e-mail client to
the ERMS
6.3.7 User can select if
he wants just the e-mail,
just the attachments or
both
6.3.8 Records and
attachments captured
separately must be linked
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
6.3.11 A user capturing
an e-mail can edit the
record title
6.3.12 If a user captures
a delivery status
notification report the
ERMS should link it to the
respective e-mail record
6.3.13 Metadata of
e-mails and attachments
must be captured
automatically
6.3.14 User can set date
sent and date received of
an e-mail record
6.3.15 A user can
capture several e-mails in
one action
6.3.16 The ERMS should
capture automatically an
e-mail type specified by a
user
6.3.17 Users can save
proprietary format mails in
open formats
6.3.18 ERMS should
capture display names
rather than address fields
7.Referencing
req Record Types [Record Types]
Record Types
6.4.1 Records
types can be
defined and
mantain
6.4.2 All records
must have exactly
one record type
6.4.3 Definition
and maintenance
of record types is
exclusive to
Administrators
6.4.4
Administrator can
restricte the
creation of record
types to specified
group of users
6.4.5
Administrator can
define a record
type as default
who can be used
by all users
req Scanning and Imaging [Scanning and Imaging]
Annotation Funcionality
OCR Funcionality
Scanning Solution
6.5.1 At least one
scanning solution can
be integred
6.5.2 The scanning
solution should support
monochrome and colour
scanning
6.5.3 Scanning result
must be in standard
formats
6.5.4 Scanning feature
must be capable of
saving images at
different resolutions
6.5.5 Scanning feature
should be capable of
saving images in colour
or greyscale
6.5.6 Scanning feature
must handle at least A4
and A3 paper format
6.5.7 Scanning feature
should have OCR
6.5.8 When OCR is
present it must be able
to treat image and text
as a single record
6.5.9 When OCR is
present it must allow full
text search
6.5.10 ERMS should
identify single
documents in a bulk
scanning process
6.5.11 Scanning feature
must be able to send
scanned images to a
queue after scanning
6.5.12 ERMS should
support inspection of
scanned images
6.5.13 Administrator can
set a threshold for image
information
6.5.14 ERMS can have
different set-up scanning
parameters for different
document types
6.5.15 User can
annotate images
6.5.16 Anotation of
images cant be changed
or removed
6.5.17 Annotations must
have identity of user,
time and date, attached
6.5.18 A scanning
session should be
logged
6.5.19 ERMS should
automatically capture
relevant metadata when
scanning
6.5.20 ERMS should
have automated
classification based on
metadata that was
automatically captured
6.5.21 ERMS should be
capable of bulk import
scanned imagens and
their metadata
6.5.22 Thumbnails of
scanned imagens
should be display to hel
navigation and search
6.5.23 Users can
capture scanned images
as records
req Classification Codes [Classification Codes]
Manual/Automatic Classification Codes
Fully-Qualified Classification Codes
Classification Codes
7.1.1 Classes, Files, Sub-Files,
Volumes, Records and
Components must have a
Classification Code
7.1.2 The Fully-Qualified
Classification Code is unique
within a classification scheme
hierarchy
7.1.3 After a realocation the
Fully-Qualified Classification
Codes and Classification
Codes must be unique
7.1.4 Classification Codes must
be stored as metadata
7.1.5 Administrator can
configure the Classification
Codes
7.1.6 Fully-Qualified
Classification Codes must
consist in several Classification
Codes separated by a
separator character
7.1.7 Separator character can
be selected from a list
7.1.8 Administrator can
configure the system to accept
manual or automatic
Classification Codes
7.1.9 ERMS must generate
next sequence number in
Classification Code
7.1.10 ERMS must validate a
Classification Code inputed by
a user
req System Identifiers [System Identifiers]
System Identifiers
7.2.1 All Classification Schemes,
Classes, Files, Sub-Files,
Volumes, Records, redactions,
retention and disposition
schedules and document hava a
system identifier.
7.2.2 The System Identifier must
be unique in the classification
scheme and ERMS instance
7.2.3 Metadata elements can
refer to entities by their system
identifiers
7.2.4 System Identifiers should be
globally unique
7.2.5 ERMS should use the UUID
algorithm to generate globally
unique system identifiers
7.2.6 Users never enter any
System Identifier for any ERMS
function
8.Searching, Retrieval and Presentation
req Search and Retriev al [Search and Retriev al] ...
Result DisplayThesaurus Use
Search Terms8.1.1 ERMS search function
only shows result who have
security clearance to the user
8.1.2 Users can search all
entities of the Classification
Scheme
8.1.3 Users can specify any
combination of metadata
elements as search terms
8.1.4 Users can specify wich
type of entity they are
searching
8.1.5 Search function should
appear the same to users
regardless of entity search
8.1.6 Users can search text
content of records
8.1.7 Search can be used as
part of declaration process
8.1.8 User can use any
combination of metadata
elements and/or textual
record content in a search
8.1.9 Seach should operate
in an integrated and
consistent manner across
both record content and
metadata
8.1.10 A search must present
the number of result and how
many are being displayed
8.1.11 Users can re-fine a
search without having to
re-enter search criteria
8.1.12 Administrator can
configure the elements shown
to diference results of 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
8.1.18 If thesaurus compliant
with ISO 2788 or ISO 5694 is
being used the ERMS should
use full features
8.1.19 Administrator is
responsable to mantain
thesaurus
8.1.20 Keywords can only be
changed by an Administrator
8.1.21 ERMS should support
partial match of search term
8.1.22 ERMS should support
word proximity searching
8.1.23 Users can limit the
scope of any search
8.1.24 When retrieving a
entity it most show all
contents and contextual
metadata associated
8.1.25 ERMS must behave in
an identical manner when
searching regardless of
location of results
8.1.26 Users can save and
re-use search terms
8.1.27 Users can share saved
search terms
8.1.28 Users can specify time
intervals in calendar
8.1.29 Time intervals in
search should be specified
either as dates or in natural
language
8.1.30 Administrator can
configure display of search
results
8.1.31 ERMS should provide
implicit or explicit relevance
ranking of the search results
8.1.32 When a result is a
redaction the ERMS should
relate the record from wich it
has generated
8.1.33 ERMS can set other
search engine other than the
default one
req Presentation: Displaying Records [Presentation: Displaying Records]
Displaying Records
8.2.1 ERMS must
be able to
present the
contents of
Classification
Scheme entities
by a mouse click
or keystroke
8.2.2 ERMS
should be able to
present records
even if the
software
associated with
them are not
present
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]
Printable Elements
Printing Configuration
8.3.1 ERMS must be able to print the
content of records and metadata
8.3.2 ERMS can print all or specified
metadata
8.3.3 ERMS must allow multiple
record printing in one operation
8.3.4 Users can create a summary of
selected metadata for selected
aggregations of records
8.3.5 Administrator can choose
metadata default that are printed with
a record
8.3.6 Users can amend the dafault
metada elements that are appended
to printouts
8.3.7 Users can print results of a
search
8.3.8 Administrator can print all or
selected administrative parameters
8.3.9 Administrator can print retention
and disposition schedules
8.3.10 Administrator can print
thesaurus
8.3.11 ERMS can print a l ist of each
controlled vocabulary
8.3.12 ERMS should be able to
export a l ist of each controlled
vocabulary
8.3.13 When controlled vocabulary is
a thesaurus ERMS should print all
terms and relationships
8.3.14 Authorised user can print all or
part of the Classification Scheme
8.3.15 User can specify the content
and format of the printed
Classification Scheme
8.3.16 Administrator can print a l ist of
all fi les classified against a specified
class
8.3.17 User can specify the
sequence, content and format of the
printed list of fi les from specified class
8.3.18 Administrator can print all or
parts of audit trails
8.3.19 ERMS printings must preserve
the layout and include all printable
components of a record
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,
display and re-configure system
parameters and settings
9.1.2 Administrator can allocate
functions to users and roles
and alocates users to roles
9.1.3 Administrator must be
warned when available storage
is below a level set at
configuration time
9.1.4 If ERMS supports error
rate reporting then
Administrator should be warned
about excessive error rate
9.1.5 Administrator can easily
move users between user
groups and roles
req Reporting [Reporting]
Retention and Dispostion Schedules ReportsReport Configuration
Types of Reports
9.2.1 Administrator can
produce periodic reports
and specify ad hoc reports
9.2.2 ERMS must include
features to print, visualize
and store reports
9.2.3 User can capture a
report as a record
9.2.4 Reports should
covered a specified date
range or time interval
9.2.5 ERMS must allow
sorting and selecting
information included in
reports
9.2.6 ERMS should have
features for totall ing and
summarising report
information
9.2.7 ERMS should have
graphical reporting
9.2.8 Reports requests can
be saved for future re-use
9.2.9 Reports can be
exported for use in other
application
9.2.10 ERMS must have
reports on total number and
location of several
combinations of entities
9.2.11 ERMS must have
reports about rate of
capture, retrieval and
creation
9.2.12 If ERMS have a
document management
then must able to provide
reports about it
9.2.13 Reports can be
specified to cover only part
of the system, specified
users or/and specified dates
9.2.14 ERMS should have
reports on actions sorted by
user, workstation and
network address
9.2.15 Reports described in
9.2.11 should cover
specified time interval
9.2.16 ERMS must have
reports l isting fi les, sub-fi les
and volumes for all or part
of the classification scheme
9.2.17 ERMS must have
report about system storage
in use and available
9.2.18 ERMS must have
reports on the audit trail
9.2.19 Administrator can
produce audit trails reports
based on security
categories, user groups or
other metadata
9.2.20 ERMS must have
reports on the outcome of a
disposition process
indicating any failure
9.2.21 ERMS must have
reports on the outcome of
an export process indicating
any failure
9.2.22 ERMS must have
reports on disposition
activity indicating disposition
actions that are overdue
9.2.23 Administrator can
restrict acess to selected
reports
9.2.24 Administrator can
produce report on
attempted acess control
and other security policy
violations
9.2.25 Administrator should
be able to specify the
frequency of retention and
disposition schedule, the
information reported and
highlighting exceptions9.2.26 ERMS should have
reports of records about to
be reviewed 9.2.27 ERMS should
support reporting and
analysis tools for the
management of retention
and disposition schedules
9.2.28 ERMS should
accumulate statistics of
review decisions and
provide reports about it
9.2.29 ERMS should
accumulate statistics of the
imposition and lifting of
disposal holds and provide
reports about it
9.2.30 ERMS must have
report about any failure
during a transfer, export,
destruction or deletion
9.2.31 ERMS must have
report about any failure
during an importation
9.2.32 ERMS should
support the import process
by tracking and reporting on
its progress and status
9.2.33 ERMS should be
able to sort fi les selected for
transfer into ordered lists
according to selected
metadata 9.2.34 ERMS should be
able to produce
user-defined reports
describing fi les and records
being exported or
transferred
req Changing, Deleting and Redacting Records [Changing, Deleting and Redacting Records]
System Configuration
Redaction
Administrator Rights and Responsability
9.3.1 ERMS must
have
configuration that
prevent any
record from being
deleted or moved
even by
Administrators
9.3.2 ERMS must
have
configuration that
allow deleting
and moving a
record
9.3.3 If option
9.3.1 is selected
then ERMS
simulates deletion
and copies or
moves records in
relocation
9.3.4 If option
9.3.2 is selected
then ERMS really
delet and move
the record
9.3.5
Administrator can
delete Classes,
Files, Sub-Files,
Volumes and
Records
9.3.6 Users can
mark Classes,
Files, Sub-Files,
Volumes and
Records as
candidates for
deletion
9.3.7 A deletion
implies logging,
reporting,
deleting, ensure
that ERMS stays
consistent, warn
about l inks to
other fi les and
maintain integrity
of the metadata
9.3.8
Administrator can
change any
user-entered
metadata
9.3.9 All changes
to metadata must
be logged
9.3.10
Administrator can
create one or
more redactions
of a record
9.3.11 ERMS
must allow
removal or hiding
of sensitive
information within
a redaction
9.3.12 During
redaction creation
date, time and
creator must be
stored in
redaction and
record metadata
9.3.13 During
redaction creation
user must enter a
reason to be
stored in record
and redaction
metadata
9.3.14
Redactions
should be
considered
records and be
classified in the
same
aggregation
9.3.15 During
redaction creation
metadata can be
copied from
record
9.3.16 ERMS
should enable
amendment of
selected metdada
values to users
with permission
9.3.17 Records
and redaction
should be
cross-reference
9.3.18 In a record
user can see all
the redactions
made from that
record
9.3.19 In a
redaction, user
can see the
original record
9.3.20 Any
change made as
result of any
requirement in
this section must
be logged
ANEXO II – RESULTADOS QUANTITATIVOS COMPLETOS DA AVALIAÇÃO
POR LISTA DE VERIFICAÇÃO.
Tabela 1. Resultados da avaliação por lista de verificação discriminados pela obrigatoriedade dos requisitos.
Nú
mero
de
Req
uis
ito
s
Req
uis
ito
s
Cu
mp
rid
os
Req
uis
ito
s
Cu
mp
rid
os (
%)
Nú
mero
de
Req
uis
ito
s
Req
uis
ito
s
Cu
mp
rid
os
Req
uis
ito
s
Cu
mp
rid
os (
%)
Nú
mero
de
Req
uis
ito
s
Req
uis
ito
s
Cu
mp
rid
os
Req
uis
ito
s
Cu
mp
rid
os (
%)
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%
Requisitos Obrigatórios Requisitos Opcionais Total
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
- Novo Requisito Principal 3.1.14.0The ERMS must support the copying of
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
3.3. Volumes and Sub-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
- Novo Requisito Principal 3.2.2.0
The ERMS must support the creation,
maintenance and use of a classification
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
- Novo Requisito Principal 3.2.6.0
The ERMS should support the allocation
of controlled vocabulary terms as
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
Referência Original Mudança Nova Referência Descrição de Novo Requisito
- Novo Requisito Principal 3.3.1.0
It must be possible for and
administrative role to configure the
ERMS at configuration time or later to
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.6 Sub-Requisito3.4.1.2 & 3.4.2.1 &
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 -
- Novo Requisito Principal 4.1.2.0
The ERMS must allow administrative
roles to allocate, restric and maintain
access to records, sub-files, files,
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
- Novo Requisito Principal 4.1.3.0
The ERMS must allow na
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
- Novo Requisito Principal 4.1.11.0
The ERMS must assure that a user
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
4.3. Backup and Recovery
4.4. Vital Records
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
- Novo Requisito Principal 4.2.2.0The ERMS audit trail must be capable
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
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
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
5.2. Review of Disposition Actions
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
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
6.2. Bulk Importing
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
- Novo Requisito Principal 6.1.19.0The ERMS must be able to warn a user
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
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
6.4. Record Types
6.5. Scanning and Imaging
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
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
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
7.2. System Identifiers
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
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
8.2. Presentation: Displaying Records
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
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
8.4. Presentation: Other
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
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
9.2. Reporting
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 -
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
- Novo Requisito Principal 9.1.18.0
The ERMS must be able to produce
reports about the retention and
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
