Lisboa, 19 de Dezembro de 2003

Transcrição

1 Lisboa, 19 de Dezembro de 2003 Realizado por: o Bruno Martins Nº o Cátia Chasqueira Nº o João Almeida Nº

2 Índice 1 Versões Introdução Finalidade Objectivos Definições, acrónimos e abreviaturas Descrição Genérica Posicionamento do Produto Operação Esboço para a Interface com o Utilizador Interfaces para Hardware Interfaces para Software Interfaces de Comunicações Restrições de Memória Operações Requisitadas Requisitos de Adaptabilidade Funcionalidades do Produto Subsistema de Entrada Subsistema de Gestão Documental Subsistema de Administração Subsistema de Workflow Subsistema de Gestão de Utilizadores Perfil do Utilizador Restrições a Impor ao Desenvolvimento Requisitos Detalhados Diagrama de Pacotes Requisitos de Dados Documento Pacote Imagem Template Notificação Tipo de Documento Grupo Nível de permissão Log Versão de Documento Estado de Documento Nota Parecer/Despacho Check-Out/Check-In Pasta Utilizador Área de utilizador Requisitos funcionais Subsistema de Entrada UC E1 - Digitalizar Documento UC E2 - Digitalizar Pacote de Documentos UC E3 - Separar Documentos de um Pacote

3 UC E4 - Criar Template UC E5 - Criar Documento a partir de template UC E6 - Receber Documento Digitalmente via UC E7 - Receber Documento Digitalmente via Fax UC E8 - Registar Documento UC E9 - Classificar Atributos Básicos UC E10 - Classificar Atributos Detalhados Subsistema de Gestão Documental UC D1 - Pesquisar Documentos UC D2 - Versionar Documento UC D3 - Alterar Estado de Documento UC D4 - Enviar Notificação UC D5 - Enviar Documento para o Exterior UC D6 - Emitir parecer/despacho/nota UC D7 - Check-Out de Documento UC D8 - Check-In de Documento UC D9 - Dar permissões UC D10 - Adicionar/Renomear/Remover Pastas UC D11 - Remover documento Subsistema de Administração UC A1 - Criar Tipo de Documento UC A2 - Definir Atributos do Tipo UC A3 - Definir Grupos/Permissões Gerais do Tipo UC A4 - Definir Estados do Tipo UC A5 - Associar Processo a Tipo de Documento Subsistema de Workflow UC W1 - Iniciar Processo UC W2 - Devolver Lista de Processos UC W3 - Associar Documento a Tarefa do Processo UC W4 - Associar Componente de Pesquisa no idocument a form de tarefa Subsistema de Gestão de Utilizadores UC U1 - Criar Utilizador UC U2 - Criar Grupos UC U3 - Atribuir Utilizador a Grupo UC U4 - Verificar Permissões Conclusão Bibliografia

4 Índice de Figuras Figura 1 Exemplo de Web Part Figura 2 Imagem comum ao idocument e Ultimus Figura 3 Exemplo de Grupos Figura 4 Exemplo de Acções Figura 5 - Ecrã Inicial (Inbox) no idocument Inbox Figura 6 - Ecrã Outbox no idocument Figura 7 - Ecrã de Organização de Pastas no idocument Figura 8 - Ecrã de Digitalização no idocument Figura 9 - Ecrã de Registo de Documentos no idocument Figura 10 - Ecrã de Administração no idocument Figura 11 - Ecrã Inicial (Iniciar processos) no Ultimus Figura 12 - Ecrã Inbox de Tarefas no Ultimus Figura 13 - Diagrama de Use Cases do Subsistema Entrada Figura 14 - Diagrama de Use Case do Subsistema Gestão Documental Figura 15 - Diagrama de Use Cases de Subsistema de Administração Figura 16 - Diagrama de Use Case de Subsistema de Workflow Figura 17 - Diagrama de Use Case de Gestão de Utilizadores Figura 18 - Diagrama de Pacotes do idocument Figura 19 - Diagrama de Actividades de Digitalizar Documentos Figura 20 - Diagrama de Actividades de Digitalizar Pacote de Documentos Figura 21 - Diagrama de Actividades de Separar Documentos de um Pacote Figura 22 - Diagrama de Actividades de Criar Templates Figura 23 - Diagrama de Actividades de Criar Documento a Partir de Template Figura 24 - Diagrama de Actividades de Registar Documento Figura 25 - Diagrama de Actividades de Pesquisar Documentos Figura 26 - Diagrama de Actividades de Versionar Documento Figura 27 - Diagrama de Actividades de Enviar Notificação Figura 28 - Diagrama de Actividades de Enviar Documento para o Exterior Figura 29 - Diagrama de Actividades de Dar Permissões Figura 30 - Diagrama de Actividades de Criar Tipo de Documento Figura 31 - Diagrama de Actividades de Iniciar Processo Figura 32 - Diagrama de Actividades de Devolver Lista de Processos Figura 33 - Diagrama de Actividades de Associar Documento a Tarefa de Processo Figura 34 - Diagrama de Actividades de Associar Componente de Pesquisa de idocument a um form de Tarefa Figura 35 - Diagrama de Actividades de Criar Utilizador Figura 36 - Diagrama de Actividades de Criar Grupo Figura 37 - Diagrama de Actividades de Atribuir Utilizador a Grupo Figura 38 - Diagrama de Actividades de Verificar Permissões

5 1 Versões Versão Data Descrição /12/2003 Primeira Versão do documento Caderno de Requisitos 5

6 2 Introdução 2.1 Finalidade Na fase de análise de requisitos, espera-se que surja como preocupação essencial a especificação das funcionalidades do sistema em construção, partindo de uma visão global e seguindo os fios do novelo até se alcançar a escala atómica, onde se espera conseguir definir todos os pormenores pertencentes ao sistema idocument. Este caderno tem o intuito de documentar os resultados dessa análise, representados na forma mais adequada aos receptores. No caso, optou-se por representar os requisitos do sistema. A análise de requisitos de um sistema é uma actividade largamente estudada e sobre a qual se reconhecem métodos e especificações concretas para se alcançarem os objectivos propostos. Foi com base nesta premissa que o grupo decidiu adoptar o modelo de funcionamento mais adequado ao problema, que passa por uma análise com recurso ao conceito de objectos e a toda a envolvente da metodologia orientada a objectos, aliada ao saber empírico e transmitido por docentes e colegas ao longo do curso de IGE. O pragmatismo dos métodos da empresa acolhedora Case, também foram tidos em conta. Neste documento usou-se como referência a norma IEEE Omitiram-se alguns tópicos por se ter concluído serem de menor importância, alterando-se outros para se adaptar o documento a uma análise que respeite a metodologia orientada aos objectos. Este documento está organizado em 3 secções. As primeiras duas destinam-se principalmente a reflectir uma análise voltada para os clientes do sistema, mas também serão interessantes para os técnicos que colaborem no processo de desenvolvimento e de manutenção do sistema em estudo. Na terceira secção pretende ilustrar-se a parte mais técnica dos requisitos, sendo o público-alvo composto dos desenhadores e programadores da solução. 2.2 Objectivos A construção do sistema integra-se no âmbito da cadeira de Projecto do 5º ano do curso de IGE. A aplicação a produzir a partir das especificações compiladas neste documento será designada de idocument Sistema Integrado de Gestão Documental e Workflow. Em traços largos, o sistema idocument deverá integrar as seguintes funcionalidades: Gestão Documental: na vertente integrada, segundo o conceito de ECM. Arquivo: armazenamento secundário de documentos, de forma durável e inviolável, permitindo registar todas operações e realizar audite ao sistema. Workflow: permitindo a gestão dos processos de negócio da organização sejam eles centrados na tarefa ou no documento, e acesso a ferramentas de análise, funcionando segundo o conceito de BPM. 6

7 2.3 Definições, acrónimos e abreviaturas Use Case Conjunto de especificações usadas para descrever funções de um sistema BD Base de Dados IGE Informática e Gestão de Empresas ECM Enterprise Content Management BPM Business Process Management IEEE Prática recomendada para a especificação de requisitos ao nível de desenvolvimento de aplicações informáticas. Workflow Designação atribuída às aplicações orientadas para a gestão de processos de negócio. 7

8 3 Descrição Genérica Neste ponto damos a conhecer as características essenciais do produto a desenvolver, tentando mostrar, principalmente aos futuros utilizadores, o aspecto visual e funcional do sistema de gestão documental, bem como uma possível integração com um motor de Workflow. Note-se que o sistema assenta em duas visões: O funcionamento isolado, sem um motor de Workflow, constituindo-se assim, única e exclusivamente, como um sistema de Gestão Documental; ou um sistema integrado de Gestão Documental e Workflow, permitindo à organização retirar maiores proveitos de ambos os sistemas. 3.1 Posicionamento do Produto O mercado dos sistemas de Gestão Documental caracteriza-se como sendo um mercado maduro, onde existem diversos produtos de qualidade, ainda que não sejam em elevado número, com uma forte presença em termos de liderança. Neste mercado existe uma oportunidade clara no sector das pequenas e médias organizações. É objectivo do idocument apresentar-se como uma solução viável, de baixo custo, e que reúna as funcionalidades de base dos produtos líderes. Para o produto informático resultante dos estudos e resoluções da equipa de trabalho, podem identificar-se diversas soluções concorrentes no mesmo mercado: Pode considerar-se como rival o sistema de Gestão Documental comercializado pela Documentum, que apresenta um produto maduro, escalável e robusto. O sistema de Gestão Documental comercializado pela FileNet é igualmente um produto líder, com provas dadas no mercado de elevada performance. O produto em desenvolvimento pode posicionar-se favoravelmente em relação aos seus concorrentes pelas características próprias da sua arquitectura. Tendo como base a plataforma SharePoint Portal Server 2003, o suporte de grande quantidades de informação e a performance estão à partida garantidas pela qualidade dos produtos Microsoft. Outra grande mais valia do sistema em desenvolvimento é a sua integração com um motor de Workflow, também ele líder de mercado no seu segmento, que garante desde logo uma perfeita integração entre dois conceitos complementares. Para o cliente final, esta junção de dois sistemas num só, representa uma mais valia quer em termos de custos, quer em termos de esforço de implementação, como também de performance controlada nas duas vertentes. 8

9 3.1.1 Operação A função principal do sistema é efectuar a gestão de documentos ao longo do ciclo de vida de um documento, que se inicia no momento da criação do documento e finaliza com o seu arquivo. O objectivo é facilitar o tempo de acesso à informação, reduzir os custos associados à comunicação interna/externa, garantir o registo de todos os documentos, bem como conhecer todos os intervenientes que tenham acesso ao documento e a acção levada a cabo por estes funções de audit. Por outro lado, o sistema deve criar uma ligação estreita entre os documentos e os processos de negócio, constituindo-se assim como uma ferramenta de apoio à gestão dos processos de negócio. O sistema é composto por cinco módulos de operação distintos: Entrada Gestão Documental Workflow (Integração) Gestão de Utilizadores Administração Os actores do sistema são: Receptor de Documentos Separador de Documentos Colaborador Genérico Administrador Desenhador de Processos Sistema de Fax Sistema de Sistema de Workflow Desenhador de Processos À partida todos os módulos devem ser instalados, podendo dispensar-se o módulo de integração com Workflow. Este só necessita de ser instalado quando também exista um motor de Workflow, que será necessariamente o Ultimus, assim este módulo assegura a integração entre os dois sistemas. Para além da instalação do sistema de Gestão Documental e do Motor de Workflow, é necessário proceder em primeiro lugar à instalação do SharePoint Portal Server Este constituirá a base sobre a qual a aplicação de Gestão Documental irá assentar. No entanto, e antes de instalar as aplicações, é necessário proceder à instalação dos respectivos motores de base de dados: em ambas as aplicações será sempre o Microsoft SQL Server. 9

10 3.1.2 Esboço para a Interface com o Utilizador O objectivo principal deste ponto do relatório é a familiarização com os interfaces de utilizador, para que os programadores do sistema possam, em tempo útil, encaminhar o desenvolvimento do programa no sentido de que este sirva como auxiliar de trabalho e não como empecilho. Os ecrãs apresentados em seguida foram construídos com base em reuniões realizadas com a presença da equipa e do coordenador José Costa, e depois de discutidos todos os pormenores no decorrer de reuniões internas à equipa de desenvolvimento. Acreditamos que os esboços desenhados permitem ao cliente aperceber-se do que vai ser o programa final, o qual se pretende que tenha características de simplicidade de utilização e de facilitador das operações antes realizadas artesanalmente. Muitas das funções serão construídas recorrendo a Web Parts, possibilitando deste modo que a organização do ecrã seja da responsabilidade do utilizador, para além de outras vantagens inerentes a esta técnica. As Web Parts são facilmente identificadas pela barra azul/cinzenta que se encontra na parte superior de cada função (vide Figura 1). Figura 1 Exemplo de Web Part No processo de desenho dos ecrãs, tivemos sempre em consideração a base sobre a qual a aplicação irá assentar Microsoft Share Point Portal. A homogeneidade, da imagem e localização das funções, foi considerada uma característica à qual devemos atribuir elevada importância. Deste modo, este primeiro esboço, o qual não pretende constituir os ecrãs finais tanto mais porque apenas representa as funcionalidades mais gerais da aplicação, segue um padrão definido pela Micorosft e aplicado ao SharePoint Portal Server Relativamente aos ecrãs do idocument, há a realçar a separação visual dos diferentes ambientes de trabalho, ainda que estejam fortemente integrados: gestão documental e gestão de processos. Esta separação de ambientes de trabalho está representada apenas nos 4/5 inferiores do ecrã. Existe uma zona que é comum tanto às aplicações idocument e Ultimus como também ao SharePoint Portal Server, apesar de, existirem alguma diferenças para este último em termos de funcionalidades. Este espaço comum de trabalho apresenta alguns dados informativos, tais como o número de notificações novas e o número de processos novos, nos casos em que o ultimus está instalado, o nome do ultilizador para além de funções de procura dentro no idocument. 10

11 Este espaço representa também o menu de navegação para o idocument, Ultimus e Intranet da organização. Figura 2 Imagem comum ao idocument e Ultimus Especificamente relacionado com a gestão documental importa referir que nestes ecrãs apenas se encontram representadas as principais funcionalidades. Essas funcionalidades são seis: inbox de notificações, outbox de notificações, organização das pastas (pessoais), digitalização de documentos, registo de documentos e administração. A cada uma destas funções existe sempre associado um conjunto de operações, cuja localização é na parte esquerda do ecrã. O conjunto de operações associadas a cada funcionalidade mais geral é identica para as primeiras cinco funcionalidades: Inbox, Outbox, Pastas, Digitalização e Registo. As opções de grupo representam uma forma de organização. Cada utilizador pode pertencer a um ou mais grupos, assim ao seleccionar um grupo, de entre os quais pertence, apenas vai visualizar, a partir desse momento, os documentos a ele associados (vide Figura 3). Figura 3 Exemplo de Grupos As acções são o outro conjunto de operações disponíveis para cada uma das primeiras cinco funcionalidades. Em conjunto todas estas funções representam as funcionalidades do sistema de gestão documental (vide Figura 4). Figura 4 Exemplo de Acções 11

12 Figura 5 - Ecrã Inicial (Inbox) no idocument Inbox Sempre que o ultilizador entre no idocument o ecrã que será sempre apresentado em primeiro lugar será a Inbox de Notificações. Este ecrã representa a lista de novas notificações recebidas bem como outras notificações recentes. No limite são os documentos sobre os quais o utilizador tem interesse em determinado espaço de tempo. Figura 6 - Ecrã Outbox no idocument 12

13 O ecrã de outbox representa o conjunto notificações sobre documentos que tenham sido enviados para o exterior e/ou interior, através de , fax ou mesmo em formato papel. Estes documentos têm a particularidade de pertecerem ao estado de arquivo, ou seja, chegaram ao fim do seu ciclo de vida. Figura 7 - Ecrã de Organização de Pastas no idocument Com o objectivo de proporcionar um local de trabalho mais flexível e adaptado a cada utilizador, criou-se o conceito de pastas. Aqui cada utilizador pode organizar os documentos, aos quais tem acesso, da forma que lhe seja mais familiar. Esta organização apenas é visível a cada utilizador individualmente, ou seja, são regras criadas indivualmente para o utilizador e não para o documento. 13

14 Figura 8 - Ecrã de Digitalização no idocument O Ecrã de digitalização serve apenas dar inicio ao processo de passagem da informação contida no papel para o formato digital. Todas as outras operações, encontram-se no momento da digitalização desactivadas. Figura 9 - Ecrã de Registo de Documentos no idocument Registar documento é uma das principais funcionalidades de qualquer sistema de gestão documental, e sem a qual certamente nenhum sistema faria sentido. Esta operação pretendesse simples de executar por qualquer utilizador do sistema. Por uma lógica de 14

15 organização dos documentos e de funcionalidade sentiu-se a necessidade separar a classificação básica da detalhada. Figura 10 - Ecrã de Administração no idocument O ecrã de administração é inacessivel à maioria dos comuns utilizadores do sistema. Apenas os utilizadores que desempenham o papel de administrador têm acesso a este ecrã. Aqui são disponibilizadas um conjunto de accções que permitem a administração do sistema de idocument (vide Figura 10). Um exemplo do tipo funções que o administrador desempenha é a criação de tipos de documentos (vide Figura 10). 15

16 Figura 11 - Ecrã Inicial (Iniciar processos) no Ultimus Figura 12 - Ecrã Inbox de Tarefas no Ultimus 16

17 Os ecrãs anteriores demonstram de que forma o motor de Workflow Ultimus estará integrado com a aplicação idocument. Com um ponto de acesso único o utilizador pode navegar pela gestão de documentos e pela gestão de processos de negócio. Mesmo no ambiente específico de trabalho do Ultimus irão existir componentes do idocument para acesso a documentos Interfaces para Hardware O sistema de Gestão Documental tem um interface específico para: Servidor de Fax Servidor de Scanner Impressora Interfaces para Software O sistema de Gestão Documental tem um interface específico para: Sistema de Motor de Workflow Ultimus Base de Dados Active Directory Microsoft Office Interfaces de Comunicações O sistema vai estar disponível através da intranet da organização. Este será o ponto de acesso ao sistema, constituindo-se assim como uma plataforma colaborativa e única a toda a organização. O acesso será feito através de browser Restrições de Memória 128MB de memória e menos de 10MB de disco devem ser o suficiente, em cada máquina, para se poder trabalhar como utilizador. Como o acesso se faz por browser, as restrições de memória secundária aplicam-se apenas a ficheiros temporários criados pelo browser. O servidor onde se irá colocar a base de dados e as aplicações, idocument e Ultimus, deve ser suficientemente generoso em termos de disco rígido: nunca abaixo de 200 GB para uso exclusivo da base de dados, com tendência para subir em implementações de maior escala. 17

18 3.1.7 Operações Requisitadas A entrada no sistema passa, obrigatoriamente, pela autenticação do utilizador, e todas as acções efectuadas por este são alvo de autenticação automática de acordo com a operação inicial. Um dos mais importantes requisitos num sistema de Gestão Documental é a possibilidade de auditar, de forma a garantir a fiabilidade e autenticidade do próprio sistema. Todas as operações efectuadas pelos utilizadores têm que ficar registadas no sistema e nenhuma acção efectuada pode ser alterada ou eliminada. Outro requisito importante é o histórico do sistema - toda a informação tem que ser guardada, obrigatoriamente, num sistema de armazenamento secundário e por um período igual ou superior ao estabelecido na lei Requisitos de Adaptabilidade Não se aplica a este sistema. 18

19 3.2 Funcionalidades do Produto Subsistema de Entrada Criar Template Criar Documento A Partit de Templat e Colaborador Genérico Digitalizar Docume nto Classificar - Atributos Básico s «uses» Registar Documento «extends» Classificar - Atributos Detalhad os Receptor de Documentos Digitalizar Pacotes de Documentos Separar Documentos de Pacote Separador de Documentos Sistem de Receber Documento Digitalmente - via Receber Documento Digitalmente - via Fax Sistema de Fax Figura 13 - Diagrama de Use Cases do Subsistema Entrada 19

20 Actores: Receptor de Documentos, Separador de Documentos, Colaborador Genérico, Sistema de Fax, Sistema de UC E1 - Digitalizar Documento A digitalização de documentos tem como principal objectivo registar em formato digital todos os documentos, em formato papel, que chegam à organização. Os documentos são digitalizados um a um e ficam guardados como imagem no sistema. Logo após a digitalização é efectuado o registo do documento no sistema, ficando disponível à organização. Sobre os documentos digitalizados não é permitido qualquer tipo de alteração. A digitalização deve proceder-se com consciência da importância que adquire a preparação das folhas a digitalizar. É uma fase constantemente negligenciada mas que assume uma importância fulcral para que as imagens resultantes da digitalização substituam definitivamente o papel, e não seja necessário recorrer ao último para clarificar zonas pouco explícitas nas imagens. UC E2 - Digitalizar Pacote de Documentos Tal como o Use Case Digitalizar Documentos, também este transfere a imagem no papel para formato digital, sendo que este procede à digitalização de um conjunto de documentos, o qual se designa por pacote de documentos. Após a digitalização, os documentos são colocados numa lista de espera com o fim de serem registados no sistema. UC E3 - Separar Documentos de um Pacote A separação de documentos de um pacote pretende dividir e agrupar os documentos digitalizados, agora imagens, de forma lógica. Dado que um documento pode ser composto por mais do que uma página e que, após a digitalização, todas as páginas são igualmente imagens, é necessário que se torne a agrupar as páginas e identificá-las como um único documento, perante o sistema. UC E4 - Criar Template A criação de templates permite definir uma estrutura para criar documentos que deverão obedecer a determinadas regras ou seguir determinada estrutura. Os templates criados são usados, posteriormente, para criar novos documentos que utilizem a estrutura definida. O objectivo dos templates é, por um lado, facilitar a criação de documentos e, por outro, definir estruturas semi-rígidas, impostas pela própria organização ou outra entidade, e que obrigam os documentos a seguirem a estrutura definida pelo template. O utilizador define a estrutura do template, associando variáveis a zonas específicas e o sistema cria um formulário que será utilizado para preencher o template com a informação necessária para essas variáveis. Entende-se que estes templates são documentos reconhecidos pelo Microsoft Word. UC E5 - Criar Documento a Partir de Template Este Use Case pretende permitir criar um documento a partir de um template, apresentando um formulário ao utilizador, que este deverá preencher com informação a 20

21 constar no documento (definida sob a forma de variáveis colocadas em pontos específicos do template no momento da sua criação). O sistema irá gerar o documento com base na estrutura definida no template e apresenta-o ao utilizador para que este o edite e posteriormente registe no sistema. UC E6 - Receber Documento Digitalmente via O sistema prevê a integração com um Sistema de para permitir a registo de e- mails no sistema idocument. A integração é realizada disponibilizando um botão no sistema de (Microsoft Outlook) para que, a partir deste, o utilizador possa registar os documentos. Assim, o sistema disponibiliza uma caixa de correio para os utilizadores, sendo que os s deverão ser registados da mesma forma que os documentos. UC E7 - Receber Documento Digitalmente via Fax Da mesma forma que se prevê a integração com um Sistema de , também irá existir integração com um Sistema de Fax para permitir a recepção de faxes através do sistema. Isto permite que os faxes possam ser recebidos em formato electrónico, em substituição do formato tradicional (papel), podendo ser imediatamente registados no sistema (sem terem que ser digitalizados). Considera-se que existe uma pasta no sistema onde o Sistema de Fax coloca os faxes recebidos, acontecendo que o Sistema idocument estará atento a novas entradas nessa pasta e coloca-as numa lista de espera destinada a ser tratada por alguém com funções alargadas no registo de documentos. UC E8 - Registar Documento O registo de um documento no sistema é feito usando dois outros use cases classificar atributos básicos e classificar atributos detalhados e permite indexar o documento no âmbito do sistema. O conjunto de imagens ou ficheiros necessitam de ser registados para que o sistema os possa identificar como um documento maduro. Até lá, considera-se como um documento sem Registo, o que lhe confere a característica de estar guardado numa zona temporária, sendo transferido para o contexto em que se insere apenas depois de preenchidos os atributos detalhados (registo completo). UC E9 - Classificar Atributos Básicos Este Use Case, utilizado pelo anterior, permite a classificação de um documento, preenchendo os seus atributos básicos, ou seja, os atributos comuns a todos os documentos e que não implicam qualquer conhecimento sobre o mesmo. Esta classificação faz parte do registo de um documento e, como tal, é efectuada sempre que se proceda ao registo. Esta classificação deve ser preenchida automaticamente pelo sistema no momento da entrada do documento, de modo a disponibilizar o documento imediatamente no sistema, apesar de não estar ainda registado. UC E10 - Classificar Atributos Detalhados Este Use Case, utilizado também pelo Use Case registar documento, permite classificar um documento preenchendo os seus atributos detalhados, ou seja, os atributos que 21

22 dependem do tipo do documento a que pertence. Para realizar esta operação é necessário um razoável conhecimento da estrutura de classificação de documentos no sistema, e do assunto constante no documento. Caso o utilizador que recebe o documento não possua conhecimentos necessários a esta classificação, deve remeter o documento a alguém com competência para o fazer o destinatário do documento ou um utilizador responsável por este tipo de tarefa. Só após a classificação detalhada é que o documento passa a estar completamente registado e disponível à organização inserido no contexto apropriado Subsistema de Gestão Documental Pesquisar Document os Versionar Document o Alterar Estado de Documento Enviar Notificação Enviar Documento Para Exterior Sistema Colaborador Genérico Emitir Parecer/ Despacho/Nota Check-Out de Documento Remover Documento Dar Permissões Check-In de Docume nto Adicionar/Renomear/ Remover Pastas Figura 14 - Diagrama de Use Case do Subsistema Gestão Documental 22

23 Actores: Colaborador Genérico UC D1 - Pesquisar Documentos A pesquisa de documentos no sistema pode ser feita de duas formas por chave de pesquisa ou pesquisando em árvore, e permite a um utilizador aceder ao documento desejado. A pesquisa é fundamental para o sistema, dela dependem vários Use Cases. A pesquisa pode ser feita no decorrer de uma tarefa ou simplesmente isolada de qualquer tarefa. Uma pesquisa consiste na definição de um contexto e de uma chave de pesquisa, acontecendo o retorno, pelo sistema, dos documentos considerados relevantes, a que o utilizador tem acesso, e no contexto definido. UC D2 - Versionar Documento O versionamento de documentos permite editar documentos mantendo sempre a versão antiga no sistema. Quando um documento é editado, o sistema não permite que ele seja substituído pelo documento editado, mas cria uma nova versão do documento, passando a versão antiga para histórico. A grande vantagem desta funcionalidade é que permite, a qualquer momento, saber a evolução das alterações de cada documento, bem como toda a informação associada à criação de um novo documento autor, data, etc. UC D3 - Alterar Estado de Documento Este Use Case permite a alteração do estado de um documento pelo utilizador ou pelo próprio sistema, sempre que aconteça uma qualquer acção que contribua para essa alteração. A alteração do estado pode ser originada pelo percurso do documento num processo e pode, ela própria, originar a alteração do percurso do documento no processo. Esta alteração pode também ter em vista a origem de um evento ou pode ser de carácter meramente informativo. UC D4 - Enviar Notificação O envio de uma notificação pode ser de carácter automático ou não. Uma notificação automática será uma notificação pré-definida que acontece na sequência de uma acção realizada sobre o sistema registo de um documento, criação de uma nova versão de um documento, mudança do estado de um documento, envio interno de um documento, etc. e é, sobretudo de carácter informativo. Por exemplo, quando um documento é registado no sistema, é enviada uma notificação automática a todos os utilizadores interessados no tipo a que o documento pertence (de acordo com o grupo onde estão inseridos ver UC A3 - Definir Grupos/Permissões Gerais do Tipo), indicando que o documento deu entrada no sistema. A notificação permite que o utilizador que efectuou o registo do documento preencha alguns campos da notificação, mas o seu envio é automático. Da mesma forma que se processa uma notificação de registo de documento, as restantes notificações processam-se da mesma forma. Por outro lado, uma notificação não automática pode ocorrer em qualquer momento, mas é sempre iniciada pelo utilizador. Esta notificação pode ser de carácter meramente informativo ou pode servir para solicitar a determinado utilizador que realize uma acção sobre um determinado documento. Como caso particular deste envio de notificação, temos o envio de um documento internamente na organização. Como o documento, em termos físicos, não é enviado é apenas enviado um caminho para aceder ao documento optou-se por tratar 23

24 este envio da mesma forma que o envio de notificação, em que o conteúdo da notificação será o caminho para o documento. UC D5 - Enviar Documento para o Exterior Este Use Case está especificado para o envio de documentos para o exterior da empresa, dado que o envio dentro da empresa é definido como envio de notificação. O envio do documento pode ser feito por via electrónica (fax, ) ou por papel (sendo necessário imprimir o documento para proceder ao envio). É importante garantir que um documento enviado para o exterior seja mantido como versão final e arquivado para não permitir alterações. UC D6 - Emitir parecer/despacho/nota Este Use Case permite ao utilizador adicionar uma nota, um parecer ou um despacho a um documento, que serão anexados ao documento como informação adicional, mas que deverão acompanhar o documento durante o seu ciclo de vida. O sistema permite exibir, quando solicitado, uma lista de todos os pareceres, despachos e notas associados ao documento. UC D7 - Check-Out de Documento A opção de check-out sobre um documento permite a um utilizador reservar para si um qualquer documento, para proceder a alterações. Enquanto o documento estiver na posse do utilizador, ou seja, checked-out, os restantes utilizadores com acesso apenas poderão consultar o documento. As operações de check-out e check-in devem ficar registadas no histórico do sistema, como forma de se saber, a cada momento, onde e com que utilizador está o documento. UC D8 - Check-In de Documento A opção de check-in sobre um documento permite a um utilizador libertar o acesso a um documento que se encontrava em seu poder. Após o check-in do documento, todas as operações sobre o documento estarão disponíveis para todos os utilizadores com acesso, até que alguém faça de novo check-out, sendo que o processo se repete da mesma forma. As operações de check-out e check-in devem ficar registadas no histórico do sistema, como forma de se saber, a qualquer momento, onde e com que utilizador está o documento. UC D9 - Dar permissões Este Use Case permite a um utilizador conceder permissões a outro sobre determinado documento. Esta funcionalidade torna-se importante quando um documento disponibilizado para um determinado grupo merece/deve ser visto por um utilizador externo ao grupo. Neste caso, um dos utilizadores do grupo concede permissões a esse utilizador para aceder ao documento. 24

25 UC D10 - Adicionar/Renomear/Remover Pastas Este Use Case permite ao utilizador efectuar alterações sobre a forma como estão organizados os seus documentos (documentos aos quais tem acesso). O utilizador pode adicionar, renomear ou remover pastas, podendo, consequentemente, alterar a localização dos documentos dentro das pastas. UC D11 - Remover documento A remoção de um documento do sistema está associada a um atributo do documento que permite deixá-lo visível ou não aos utilizadores do sistema, dado que um documento que entre no sistema jamais poderá ser apagado ou deixar de existir. Assim, quando um utilizador remove um documento, ele apenas deixa de estar visível, continuando arquivado no sistema Subsistema de Administração «uses» Definir Atributos do Tipo Criar Tipos de Documento «uses» «uses» Definir Grupos/ Permissões Gerais do Tipo Administrador Definir Estados do Tipo «uses» Associar Processo a Estado do Tipo Figura 15 - Diagrama de Use Cases de Subsistema de Administração Actores: Administrador UC A1 - Criar Tipo de Documento A criação de um tipo de documento permite definir um conjunto de atributos que deverão ser comuns a todos os documentos que pertençam a esse tipo. Desta forma, os documentos são agrupados de uma forma organizada e coerente, facilitando a pesquisa, atribuição de permissões ou de caminhos estruturados. 25

26 UC A2 - Definir Atributos do Tipo Este Use Case é utilizado pelo Criar Tipo de Documento e permite que, quando se cria um tipo de documento, se definam os atributos que deverão ser comuns a todos os documentos desse tipo, ou seja, um documento, por ser de determinado tipo, deverá ter na sua descrição, para além dos atributos gerais e comuns a todos os documentos, os atributos que resultam do facto de pertencer a esse tipo. Os atributos têm um nome e um tipo. UC A3 - Definir Grupos/Permissões Gerais do Tipo Este Use Case é utilizado pelo Criar Tipo de Documento e permite que, quando se cria um tipo de documento, se definam os grupos que poderão aceder aos documentos daquele tipo, bem como as permissões (pesquisa, envio, edição, etc.) de cada elemento do grupo sobre os mesmos documentos. No momento da criação e edição do Tipo de Documento apenas são definidos os grupos que podem vir a ter acesso a documentos desse tipo (quem estiver fora desses grupos não pode, por defeito, aceder a documentos desse tipo), mas é no momento do registo de um documento que se define que grupos da lista de possíveis, têm acesso a esse documento. UC A4 - Definir Estados do Tipo Este Use Case é utilizado pelo Criar Tipo de Documento e permite que, quando se cria um tipo de documento, se definam os estados que esse documento poderá ter ao longo do seu ciclo de vida. UC A5 - Associar Processo a Tipo de Documento Este Use Case permite associar um tipo de documento a um determinado processo, sendo que existem processos previamente definidos no motor de Workflow e que esta associação define que os documentos desse tipo devem sempre despoletar o início do mesmo processo. Este Use Case não permite a criação de processos, apenas permite associar tipos de documentos a processos já criados. 26

27 3.2.4 Subsistema de Workflow Iniciar Processo Devolver Lista de Processos Colaborador Genérico Associar Documento a Tarefa de Process o Sistema Associar Documento de Pesquisa idocument A Um Form de Tarefa Desenhador de Processos Figura 16 - Diagrama de Use Case de Subsistema de Workflow Actores: Sistema de Workflow, Sistema, Desenhador de Processos, Colaborador Genérico UC W1 - Iniciar Processo O início de um processo é despoletado pelo próprio sistema, mediante as condições definidas na criação dos Tipos de Documento por exemplo quando o documento tem determinado estado ou quando é verificada uma determinada condição num dos seus atributos. Uma vez iniciado o processo, o Sistema de Workflow será responsável por conduzi-lo até ao fim. UC W2 - Devolver Lista de Processos Este Use Case serve para definir uma das duas interacções específicas do Sistema de Workflow com o nosso sistema. A devolução da lista de processos, previamente definidos pelo Sistema de Workflow ocorre no momento em que um utilizador pretende criar um tipo de documento e associá-lo a um processo. Dado que os processos já definidos se encontram guardados no Sistema de Workflow, pretende-se que esse sistema devolva uma lista desses processos com o fim de o utilizador poder escolher o processo a associar ao tipo de documento. UC W3 - Associar Documento a Tarefa do Processo Pretende-se, com este Use Case, permitir que o Sistema de Workflow possa associar documentos a qualquer tarefa do processo e em qualquer altura. Para tal, será disponibilizado no Sistema de Workflow um componente que permite efectuar pesquisa 27

28 de documentos na Gestão Documental. Uma vez encontrado o documento, o Sistema cria um link para o documento no Sistema de Workflow. UC W4 - Associar Componente de Pesquisa no idocument a um form de tarefa Este Use Case acontece durante a utilização do motor de Workflow, aquando da definição dos formulários para as tarefas de um determinado processo. O idocument disponibiliza um componente COM para colocar no formulário e permitir, quando o utilizador estiver a realizar a tarefa através do formulário, a pesquisa de documentos no idocument (em contraste com a pesquisa no disco local) para poder associar um ou mais documentos do idocument à tarefa do processo Subsistema de Gestão de Utilizadores Criar Utilizador Criar Grupos Atribuir Grupo A Utilizador Administrador de Utilizadores Sistema Verificar Permissõ es Figura 17 - Diagrama de Use Case de Gestão de Utilizadores Actores: Administrador de Utilizadores UC U1 - Criar Utilizador Este Use Case permite a criação de utilizadores no sistema. Um utilizador é criado, definindo-se o seu perfil bem como as suas permissões perante o sistema. Estas permissões podem ser sobre o sistema (ex: permissões de administração, utilização, etc.) ou sobre os grupos em que o utilizador será inserido (e consequentemente sobre os documentos desse grupo). UC U2 - Criar Grupos A criação de grupos permite organizar os utilizadores de acordo com uma estrutura que deve ser definida pela própria empresa. A criação dos grupos será importante para posteriormente estes serem associados a tipos de documentos. Um grupo terá permissões específicas sobre determinado tipo de documento e, dentro do grupo, cada 28

29 utilizador poderá ter ainda permissões mais específicas sobre o tipo de documento ou sobre um documento em particular. UC U3 - Atribuir Utilizador a Grupo Este Use Case permite inserir um utilizador num determinado grupo pré-definido. Os grupos são definidos pelo administrador do sistema, bem como a atribuição dos utilizadores aos grupos. No entanto, um utilizador pode atribuir outro ao seu grupo, em qualquer altura, desde que tenha permissões de administração sobre esse grupo. Quando um utilizador é inserido num grupo, são definidas as suas permissões enquanto membro desse grupo. UC U4 - Verificar Permissões Este Use Case é utilizado sempre que o sistema necessite de saber sobre as permissões de determinado utilizador ou grupo, sendo que a sua função é apenas essa sempre que um utilizador realize uma acção sobre o sistema, para a qual tenha que ter permissões, é accionado este Use Case, que devolve uma resposta afirmativa se o utilizador tiver permissões para a acção solicitada. 3.3 Perfil do Utilizador Os utilizadores deste sistema podem ser divididos em dois tipos: Administrador responsável por parametrizar o sistema de acordo com as necessidades da organização. Prevê-se que este tipo de utilizador tenha um conhecimento aprofundado sobre a própria organização, o seu funcionamento e dos seus processos de negócio; Utilizador genérico a sua função será a de utilizar o sistema previamente parametrizado. Dado que se pretende alcançar um sistema bastante intuitivo, o utilizador não necessitará de ter outros conhecimentos além de informática na óptica do utilizador. Há, no entanto, alguns utilizadores mais específicos, como é o caso dos utilizadores que lidam com as interfaces de hardware, que necessitam de ter conhecimento sobre os equipamentos que irão utilizar. 3.4 Restrições a Impor ao Desenvolvimento O desenvolvimento do sistema estará, à partida, restrito pelas tecnologias escolhidas. A plataforma de gestão de conteúdos sobre a qual será desenvolvido o sistema, por ser tecnologia Microsoft, impõe o uso da mesma tecnologia quer para o motor de base de dados a utilizar quer para a linguagem a escolher para a implementação. Estas restrições estão melhor documentadas no RET - Relatório de Escolha das Tecnologias. Em termos de ambiente de desenvolvimento, as restrições impõem-se principalmente ao nível da capacidade dos equipamentos, sendo que o pretendido será desenvolver em equipamentos com um processador de elevada performance (Pentium 4 ou semelhante) e com memória RAM entre os 512 e os 1024Mb. 29

30 4 Requisitos Detalhados 4.1 Diagrama de Pacotes Subsistema de Entrada Subsistem a de Utilizadores Subsistem a de Gestão Docum ental Subsistema de Workflow Subsistem a de Adm inistração Figura 18 - Diagrama de Pacotes do idocument 4.2 Requisitos de Dados Os dados apresentados em seguida têm relevância no âmbito de todo o sistema, estando portanto inseridos num ponto genérico do Caderno de Requisitos, por se considerar não haver necessidade de especificar nesta fase os dados de cada sub-sistema. Cada requisito de dados é especificado através de uma descrição e indicam-se os dados que compõem cada instância de um requisito de dados Documento Descrição: É o centro do sistema. Considera-se como sendo um pedaço de informação em formato digital. Como tal, deve ser organizado, no caso recorrendo a uma estruturação de documentos em árvore e à sua tipificação. 30

31 Dados: Id Data de Entrada Caminho Estado Tipo Checked Out Descrição Pacote Descrição: Conjunto de folhas em formato digital, após serem digitalizadas. Cada sub-conjunto de folhas seguidas corresponde a um Documento, e um pacote tem sempre mais do que um documento. Existe quando o processo de digitalização não se efectua para cada documento individualmente, considerando-se então 3 fases consecutivas (não obrigatoriamente em momentos seguidos): digitalização, separação em documentos e registo. Dados: Id Número de imagens Número de documentos (marca de segurança) Data de digitalização Imagem Descrição: Representação digital de informação contida numa página. Cada imagem de um fax também é considerada uma imagem. Dados: Id Caminho Template Descrição: Documento de formato padrão usado como base para novos documentos. Serve para uniformizar o funcionamento da organização no contexto da sua documentação. Dados: Id Variáveis Caminho Data de criação 31

32 4.2.5 Notificação Descrição: Aviso que aparece na área de um utilizador sempre que ocorra uma operação relevante num documento ao qual o utilizador tenha acesso, por exemplo: envio interno/externo de documento, versionamento, entre outros. Os utilizadores, se desejarem, podem bloquear certas notificações que lhe estejam destinadas, por exemplo no caso de um utilizador considerar que notificações sobre um certo documento, ou uma determinada categoria de notificação se apresentem como lixo na sua Inbox. Dados: Id Tipo Data Hora Documento associado Descrição Remetente Destinatário Tipo de Documento Descrição: Base do sistema de classificação dos documentos. Cada documento que entra no idocument pertence a um tipo. Dados: Id Nome Grupos Estados Data de criação Processo Associado Grupo Descrição: Um ou mais utilizadores com permissão para realizar operações sobre determinado documento. Dados: Id Utilizadores Permissões Data de Criação 32

33 4.2.8 Nível de permissão Descrição: O nível de permissão de um utilizador a um documento é a definição dos limites sobre as operações que esse utilizador pode realizar sobre o documento. Será utilizado o mecanismo de permissões disponibilizado pelo Sharepoint, que permite definir permissões de leitura, versionamento, entre outros. Dados: Id Nível Log Descrição: O idocument regista todas as operações sobre documentos num Log, no sentido de fornecer um apoio à função de Audit. Para utilizadores regulares, o Log funciona como histórico para cada documento a que tenham acesso. Dados: Id Data Utilizador Operação Versão de Documento Descrição: Cada documento terá uma versão actual, que será visível directamente, e poderá ter versões antigas, que sofreram modificações e, por essa razão, deixaram de poder considerar actuais. Dados: Id Documento Número Data Estado de Documento Descrição: Todos os documentos têm, pelo menos, dois estados: Entrada e Arquivo. No momento da instalação do idocument, e cada vez que se acrescentam novos tipos de documentos, devem adicionar-se estados intermédios que estarão disponíveis para todos os documentos desse tipo. 33

34 Dados: Id Estado Limite de Tempo Nota Descrição: Informação preenchida por um Utilizador no sentido de acrescentar algo ao documento. Uma nota pode ter apenas interesse para a pessoa que a criou ou para todo o grupo com permissões para operar sobre o documento. As notas aparecem sempre associadas às pessoas que as escreveram, e são visíveis ao longo de todo o caminho do documento. Dados: Id Documento Utilizador Descrição Data Hora Parecer/Despacho Descrição: Indicação, ordem ou informação dada por um Utilizador a outro no acto de envio interno de um documento. Dados: Id Documento Utilizador Descrição Data Hora Check-Out/Check-In Descrição: Check-Out: Reservar um documento para edição por um determinado utilizador. Nenhum outro utilizador pode editar o documento enquanto se mantiver esta reserva. Check-In: Libertar a reserva de um documento para edição. 34

35 Dados: Id Pasta Descrição: Meio de organização, em árvore, dos documentos para um utilizador. Estas pastas funcionam da mesma forma que as pastas no sistema operativo Windows. Cada utilizador terá associado à sua área um sistema de pastas para organizar os documentos aos quais tem acesso. Dados: Id Utilizador Caminho da Pasta Referências para documentos Utilizador Descrição: É considerado utilizador todo o indivíduo com acesso ao idocument. Cada utilizador deve ser criado no Sub-Sistema de Gestão de Utilizadores, para que seja definida a sua situação no âmbito da gestão documental e nos processos da organização onde o idocument está implementado. Dados: Id Nome Função Caminho para Área de Utilizador Área de utilizador Descrição: Local, na forma de site, que um determinado utilizador tem disponível para realizar operações no sistema idocument. O acesso é verificado através do login de entrada no Windows ou é pedida autenticação no início de cada utilização do sistema. Dados: Id Design Dados 35

36 4.3 Requisitos funcionais Subsistema de Entrada UC E1 - Digitalizar Documento Form "Digitalizar Documento" Preparar Folhas para Digitalização [se imagens incorrectamente digitalizadas] [confirma digitalização] Display de Ecrã "Documento Digitalizado" Compara imagens digitais com ecrã [cancela digitalização] [se imagens correctmente digitalizadas] Display Mensagem de Sucesso O fim desta acção origina o inicio do Use Case Registar Documento Figura 19 - Diagrama de Actividades de Digitalizar Documentos 36

37 Actores Receptor de Documentos Colaborador Genérico Procedimentos 1. O Actor selecciona a opção Digitalizar Documento 2. O Actor prepara a(s) folha(s) para digitalização retirar clips, agrafos, etc. 3. O Actor insere a(s) folha(s) na máquina de digitalização 4. O Actor confirma a opção de digitalização 5. O Actor visualiza as imagens no seu ecrã 6. O Actor confirma a qualidade da digitalização Após conclusão do Use Case Digitalizar Documento processa-se de seguida o Use Case Registar Documento. 37