UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA Ciência da Computação, Engenharia da Computação e Pós-Graduação Especificação de Requisitos Sistema de Gerenciamento Para Escritórios de Advocacia Equipe: Diocleciano Dantas (ddn2@cin.ufpe.br) Lino Alves de Oliveira Júnior (laoj@cin.ufpe.br) Renato Celso Santos Rodrigues (rcsr@cin.ufpe.br) Társis Wanderley Toledo (twt@cin.ufpe.br) Professor: Jaelson Castro (jbc@cin.ufpe.br) Monitores: Diego Dermeval Medeiros (ddmcm@cin.ufpe.br) Joao Henrique Correia Pimentel (jhcp@cin.ufpe.br) RECIFE, OUTUBRO DE 2011.
SUMÁRIO 1. INTRODUÇÃO... 5 1.1 MOTIVAÇÃO... 5 1.2 DESCRIÇÃO DO PROBLEMA... 6 1.3 A ORGANIZAÇÃO... 6 1.4 CONVENÇÕES... 6 Identificação dos Requisitos... 7 Identificação dos Casos de Uso... 7 2. REQUISITOS ORGANIZACIONAIS... 8 3. REQUISITOS FUNCIONAIS... 8 3.1 Autenticação e Tela Inicial da Aplicação... 8 [RF01] Fazer Login... 8 [RF02] Fazer Logoff... 8 [RF03] Organizar Informação... 9 3.2 Gerenciar Clientes... 9 [RF04] Gerenciar Clientes... 9 [RF05] Cadastrar Cliente... 9 [RF06] Buscar Cliente... 9 [RF07] Editar Cliente... 10 [RF08] Excluir Cliente... 10 3.3 Gerenciar Processos... 10 [RF09] Gerenciar Processo... 10 [RF10] Cadastrar Processo... 10 [RF11] Excluir Processo... 11 [RF12] Editar Processo... 11 [RF13] Listar Processo... 11 [RF14] Buscar Processo... 11 3.4 Buscar Informação do Meio Oficial... 12 [RF15] Buscar Informação... 12 [RF16] Cadastrar E-mail... 12 [RF17] Remover E-mail... 12 3.5 Gerência do Escritório... 12 [RF18] Gerar Relatório... 12 4. REQUISITOS NÃO-FUNCIONAIS... 13 4.1 REQUISITOS DE PROCESSO... 13 [NFR01] Utilizar Scrum como metodologia de desenvolvimento... 13 2
[NFR02] Utilizar Linguagem Java para Web (J2EE)... 13 [NFR03] Utilizar Banco de Dados MySQL... 13 [NFR04] Utilizar Hibernate... 14 4.2 REQUISITOS DE PRODUTO... 14 4.2.1 Confiabilidade... 14 4.2.2 Usabilidade... 15 4.3 REQUISITOS EXTERNOS... 15 [NFR09] Custos... 15 [NFR10] Entrega do sistema... 15 5. MODELAGEM ORGANIZACIONAL... 16 5.2 MODELAGEM DE DEPENDÊNCIA ESTRATRÉGICA... 16 5.3 MODELO ESTRATÉGICO DA RAZÃO... 17 6. MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO)... 20 7. MODELAGEM DOS REQUISITOS NÃO-FUNCIONAIS... 21 8. CONCLUSÃO... 22 REFERÊNCIAS... 23 FORMULÁRIO DO RELATÓRIO DA EQUIPE... 24 ANEXO A TÉCNICA DE COLETA DE DADOS... 25 ANEXO B DESCRIÇÃO DOS CASOS DE USO... 26 Autenticação... 26 [UC01] Fazer login... 26 [UC02] Fazer login por Credencial... 26 [UC03] Efetuar login Biométrico... 27 [UC04] Fazer logoff... 27 Organização da Informação... 27 [UC05] Organizar Informação... 27 Clientes... 28 [UC06] Gerenciar Clientes... 28 [UC07] Cadastrar Cliente... 29 [UC08] Buscar Cliente... 29 [UC09] Editar Cliente... 30 [UC10] Excluir Cliente... 31 Gerenciar Processos... 31 [UC11] Gerenciar Processos... 31 [UC12] Cadastrar Processo... 32 [UC13] Buscar Processo... 32 [UC14] Editar Processo... 33 [UC15] Excluir Processo... 34 [UC16] Listar Processo... 34 3
Buscar Informação... 35 [UC17] Buscar Informação... 35 [UC18] Cadastrar E-mail... 35 [UC19] Remover E-mail... 36 Gerar Relatório... 37 [UC20] Gerar Relatório... 37 GLOSSÁRIO... 38 4
1. INTRODUÇÃO Este relatório tem como objetivo documentar e descrever os requisitos para a solução do problema de gerenciamento de parte das informações em um escritório de advocacia. A solução, bem como sua discussão, encontra-se no documento de Estudo de Viabilidade. Tal solução diz respeito à melhoria do gerenciamento das informações no fluxo de trabalho do escritório. O gerenciamento de informações no ramo jurídico tem alavancado a eficiência e agilidade com o início da informatização nos sistemas jurídicos do Brasil, porém sentese a necessidade de soluções para organizar as informações em formatos eletrônicos, para que profissionais inseridos nesse meio possam usufruir de todos os benefícios trazidos pela tecnologia. Observando-se essa carência, um sistema foi idealizado provido com a capacidade de colher dados e informações dos diversos tribunais e organizá-los de forma a facilitar a atuação dos profissionais na área judicial. Será tomado como definição de gerenciamento de informações toda e qualquer atividade cujo principal objeto é a informação associada direta ou indiretamente a qualquer uma das principais entidades envolvidas. 1.1 MOTIVAÇÃO Abaixo segue breve uma descrição do problema encontrado no gerenciamento das informações. Mais detalhes estão disponíveis no documento do Estudo de Viabilidade. Figura 1: Fluxo de informação em escritórios. A figura 1 ilustra, de uma forma geral, como se dá o fluxo da informação no escritório de advocacia do cliente deste trabalho e as entidades envolvidas. Um Cliente busca o Escritório de advocacia (ou um Advogado específico) para que este o aconselhe e haja legalmente como seu representante perante a Justiça mediante alguma causa. No modelo jurídico vigente, para que a Justiça tome algum posicionamento, em geral, ela deve ser provocada. As decisões tomadas pela Justiça são eventualmente publicadas em um Meio Oficial, sendo o mais amplamente conhecido o Diário Oficial, acompanhadas ou não de uma correspondência por escrito. É obrigação do Advogado ficar atento às publicações no Meio Oficial, pois estas publicações possuem informações essenciais sobre decisões, convocações e prazos sobre a causa em questão. 5
O domínio de um escritório de advocacia é o legal, e as atividades ligadas diretamente a este domínio serão doravante denominadas primárias. Embora as atividades de gerenciamento de informação sejam necessárias para o mantimento da ordem em um escritório e demandam boa parte do tempo e do espaço, elas não são o foco primário do escritório, e por isso serão de agora em diante denominadas secundárias. 1.2 DESCRIÇÃO DO PROBLEMA Para diminuir o peso envolvido nas atividades secundárias de um escritório é preciso torná-las mais fáceis e triviais. Manter estas informações poderá fornecer a inteligência de negócio necessária para apoiar as decisões administrativas do escritório. A Figura 2 evidencia os pontos onde o gerenciamento de informações é recorrente e um potencial ponto de gargalo. Figura 2: Pontos de interesse para o estudo da otimização do fluxo da informação Adicionalmente, a informação obtida através da observação do Meio Oficial é, segundo relatado pelo cliente, o ponto de maior dificuldade de gerenciamento. Esta atividade necessita atenção especial do advogado para que seja interpretada e tratada de acordo. 1.3 A ORGANIZAÇÃO A organização Escritório é composta por um agregado de Advogados, como já foi mostrado na Figura 1. Adicionalmente, certas atividades são delegadas a uma ou mais Secretárias, especialmente aquelas denotadas como secundárias. Entretanto, nem todo advogado tem uma secretária, sendo assim responsável tanto pelas atividades primárias como secundárias de sua função. 1.4 CONVENÇÕES Para melhor compreender a formalização dos requisitos que será apresentada nas seções posteriores, serão aqui apresentadas as convenções adotadas por este documento para descrever casos de uso, requisitos funcionais e não-funcionais. 6
Identificação dos Requisitos Por convenção, os requisitos são indicados e referenciados por um indicador no formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de uso relacionados. E cada indicador de um requisito funcional ou não funcional é único e insubstituível. Identificação dos Casos de Uso Por convenção, os casos de uso são indicados e referenciados por um indicador no formato [UCxx], onde xx se refere ao número do caso de uso. E cada indicador de um caso de uso é único e insubstituível. Estrutura dos casos de uso Cada caso de uso terá o seguinte formato: Atores: Os modelos de usuário que utilizarão o caso de uso; Prioridade: Prioridade de implementação deste caso de uso; Entradas: Variáveis que serão passadas ao sistema; Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser executado; Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso seja concluído, podendo incluir fluxos de eventos secundários e/ou alternativos; Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso for executado; Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser finalizado. Prioridades dos casos de uso Os casos de uso são classificados como: Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o projeto perderá sua utilidade. Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado. Contudo, essa utilização se dá de forma não satisfatória pelo cliente. Desejável: Esse tipo de caso de uso poderá ser implementado em versões posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema atende as suas funcionalidades básicas. 7
Descrição dos Atores Os atores são aqueles que interagem de alguma forma com o sistema ou estão envolvidos ou afetados indiretamente pelo sistema. 2. REQUISITOS ORGANIZACIONAIS Os requisitos organizacionais são aqueles que elucidam a necessidade da organização que aceita o sistema como uma solução para seu problema. São eles: 1. Facilitar o fluxo de informação dentro da organização, de modo a tornála mais ágil e eficiente; 2. Automatizar o máximo de tarefas possíveis. 3. Permitir fácil acesso e gerenciamento sobre as informações inerentes às interações das entidades envolvidas. 3. REQUISITOS FUNCIONAIS Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos estão agrupados de acordo com suas características. 3.1 Autenticação e Tela Inicial da Aplicação [RF01] Fazer Login Casos de Uso relacionados: [RF01] Fazer login [UC 01], [UC 02] e [UC 03] Permite que um usuário tenha acesso às informações e funcionalidades do sistema. Pode ser realizado através do uso de credenciais como senha e login ou através de informação biométrica. [RF02] Fazer Logoff Casos de Uso relacionados: [RF02] Fazer logoff [UC 04] Permite que o usuário saia do sistema. 8
[RF03] Organizar Informação [RF03] Organizar Informação Casos de Uso relacionados: [UC 05] Permite a inserção, atualização, remoção e consulta de dados no sistema. A partir deste ponto o ator pode acessar a tela de gerenciamento de clientes ou de processos. 3.2 Gerenciar Clientes [RF04] Gerenciar Clientes [RF04] Gerenciar Clientes Casos de Uso relacionados: [UC 06] Disponibiliza a listagem dos clientes cadastrados, a partir da qual é possível escolher um cliente específico para alteração de informações ou para exclusão de seu registro do cadastro de clientes. [RF05] Cadastrar Cliente Casos de Uso relacionados: [RF05] Cadastrar Cliente [UC07] Realiza a inserção de um novo registro de cliente no banco de dados do sistema, armazenando suas informações pessoais. [RF06] Buscar Cliente [RF06] Buscar Cliente Casos de Uso relacionados: [UC 08] Permite a busca de um cliente específico pelo fornecimento de algumas de suas informações como parâmetro de busca. 9
[RF07] Editar Cliente [RF07] Editar Cliente Casos de Uso relacionados: [UC 09] Permite a alteração de uma ou mais informações de um cliente que já esteja cadastrado no sistema. [RF08] Excluir Cliente [RF08] Excluir Cliente Casos de Uso relacionados: [UC 10] O registro do cliente é alterado para excluído na base de dados do sistema, o qual o tratará como inexistente a partir desta exclusão. Os dados do cliente, entretanto, permanecem no banco de dados do sistema, para uma eventual necessidade futura. 3.3 Gerenciar Processos [RF09] Gerenciar Processo Casos de Uso relacionados: [RF09] Gerenciar Processo [UC 11] Permite a atualização, remoção, busca e cadastro de dados referentes a processos. A partir deste ponto os demais casos de uso relativos ao gerenciamento de Processos são acessados. [RF10] Cadastrar Processo Casos de Uso relacionados: [RF10] Cadastrar Processo [UC 12] O advogado ou o dono do escritório cadastra um novo processo no banco de dados do sistema. É inserido o número do processo e o processo é associado a um cliente. 10
[RF11] Excluir Processo Casos de Uso relacionados: [RF11] Excluir Processo [UC 15] O advogado ou o dono do escritório remove um processo do banco de dados do sistema. Um pedido de confirmação deve ser requerido ao usuário, juntamente com uma mensagem informando que o processo será excluído. [RF12] Editar Processo Casos de Uso relacionados: [RF12] Editar Processo [UC 14] O advogado ou o dono do escritório edita os dados de um processo no banco de dados do sistema. [RF13] Listar Processo [RF13] Listar Processo Casos de Uso relacionados: [UC 16] Lista processos relacionados a um dado cliente ou a um dado advogado. [RF14] Buscar Processo [RF14] Buscar Processo Casos de Uso relacionados: [UC 13] O sistema deve permitir que o advogado ou o dono do escritório busquem os dados de um processo específico. A busca é feita através do número do processo. 11
3.4 Buscar Informação do Meio Oficial [RF15] Buscar Informação [RF15] Buscar Informação Casos de Uso relacionados: [UC 17] O sistema deve acessar o meio oficial e adquirir informações relacionadas aos processos que estão cadastrados no sistema. As informações estarão disponíveis através de um endereço de e-mail cadastrado nos sistemas push dos tribunais. [RF16] Cadastrar E-mail [RF16] Cadastrar E-mail Casos de Uso relacionados: [UC 18] O sistema deve permitir que o advogado ou o dono do escritório cadastrem um ou mais e-mails para recebimento e processamento das mensagens relativas as movimentações dos processos. [RF17] Remover E-mail [RF17] Remover E-mail Casos de Uso relacionados: [UC 19] O sistema deve permitir que o advogado ou o dono do escritório removam um e-mail cadastrado. 3.5 Gerência do Escritório [RF18] Gerar Relatório Casos de Uso relacionados: [RF18] Gerar Relatório [UC 20] O dono do escritório pode solicitar a geração de relatórios 12
fornecendo um período com data inicial e final. O relatório deve informar a quantidade de processos que estão sendo ou foram acompanhados por cada advogado mostrando dados como: tempo gasto em cada processo e o retorno financeiro de cada um. 4. REQUISITOS NÃO-FUNCIONAIS Nesta seção encontra-se uma descrição dos requisitos não-funcionais segundo a classificação do autor [Sommerville]. São elas: requisitos de processo, requisitos de produto e requisitos externos. 4.1 REQUISITOS DE PROCESSO [NFR01] Utilizar Scrum como metodologia de desenvolvimento [NFR01] Utilizar SCRUM como metodologia de desenvolvimento Casos de Uso relacionados: Todos. Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. [NFR02] Utilizar Linguagem Java para Web (J2EE) [NFR02] Utilizar Linguagem Java para Web (J2EE) Casos de Uso relacionados: Todos. Para disponibilizar o acesso remoto necessário à aplicação, ela deverá ser toda desenvolvida em Java para Web. Prioridade: Essencial Importante Desejável [NFR03] Utilizar Banco de Dados MySQL Casos de Uso relacionados: [NFR03] Utilizar Banco de Dados MySQL Todos. 13
Esse sistema de banco de dados oferece os recursos básicos necessários à aplicação e é economicamente viável. [NFR04] Utilizar Hibernate [NFR04] Utilizar Hibernate Casos de Uso relacionados: Todos. Facilitar o desenvolvimento de consultas ao bando de dados e permitir a independência do mesmo. 4.2 REQUISITOS DE PRODUTO 4.2.1 Confiabilidade [NFR05] Disponibilidade [NFR05] Disponibilidade Casos de Uso relacionados: Todos. O sistema deve ter o máximo de estabilidade e a estrutura de hardware deve ser redundante para prover uma alta disponibilidade. [NFR06] Segurança da Informação [NFR06] Segurança da Informação Casos de Uso relacionados: [UC05] O sistema deve certificar-se de que as informações nele contidas não serão acessadas indevidamente. Para isso deve utilizar protocolos de autenticação (por credencial ou biométrica), autorização e criptografia de dados. 14
4.2.2 Usabilidade [NFR07] Escrever documentação [NFR07] Escrever documentação Casos de Uso relacionados: Todos. O sistema deve ser acompanhado da descrição de suas funcionalidades em formato de manual eletrônico. [NFR08] Escrever em linguagem do usuário [NFR08] Escrever em linguagem do usuário Casos de Uso relacionados: Todos. As mensagens do sistema assim como a interface gráfica devem ser intuitivas e descritas na linguagem que o usuário esteja habituado. 4.3 REQUISITOS EXTERNOS [NFR09] Custos [NFR09] Custos Casos de Uso relacionados: Todos. O custo total de desenvolvimento e implantação do sistema não deve ultrapassar em 15% o estimado no Estudo de Viabilidade. Prioridade: Essencial Importante Desejável [NFR10] Entrega do sistema [NFR10] Entrega do sistema 15
Casos de Uso relacionados: Todos. O tempo para o sistema está implementado e operacional não deve exceder 15 dias do estimado no Estudo de Viabilidade. Prioridade: Essencial Importante Desejável 5. MODELAGEM ORGANIZACIONAL Utilizamos a notação i* (i estrela) para criar o modelo organizacional do escritório de advocacia contextualizado com o sistema de gerenciamento. 5.2 MODELAGEM DE DEPENDÊNCIA ESTRATRÉGICA Figura 3 Modelagem de dependência estratégica com o sistema inserido no contexto do escritório. 16
5.3 MODELO ESTRATÉGICO DA RAZÃO Figura 4 Modelo estratégico da razão com o ator advogado expandido e suas relações com outros atores evidenciadas.. 17
Figura 5 Modelo estratégico da razão com o ator cliente expandido e suas relações com outros atores evidenciadas. 18
Figura 6 Modelo estratégico da razão com o ator sistema expandido e suas relações com outros atores evidenciadas. 19
6. MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO) Nesta seção apresentamos o diagrama dos casos de uso, baseado nos requisitos funcionais especificados na seção 3. Figura 7 Modelagem dos requisitos funcionais. No anexo B encontra-se a descrição detalhada dos casos de uso apresentados aqui. 20
7. MODELAGEM DOS REQUISITOS NÃO-FUNCIONAIS Nesta seção apresentaremos a modelagem dos requisitos não-funcionais utilizando a técnica NFR Framework. Figura 9 Modelagem dos requisitos não-funcionais. 21
8. CONCLUSÃO Baseando-se no documento de Estudo de Viabilidade e levantamento de dados junto ao nosso cliente, conseguimos modelar o sistema de gerenciamento para o escritório de advocacia com as funcionalidades e estrutura necessárias para atender satisfatoriamente as expectativas do nosso cliente. Neste documento podemos encontrar vários tipos de modelagens interrelacionadas: modelagem organizacional (i*), modelagem de requisitos não-funcionais (NRF Framework) e modelagem de requisitos funcionais (diagrama de casos de uso). Oferecendo uma visão global de como o sistema deverá se comportar implantado no ambiente do escritório. Podemos também observar como o sistema impactará na rotina prévia dos stakeholders envolvidos (Advogado e dono do escritório). Este documento foi apresentado e explicado pessoalmente aos stakeholders envolvidos em 24 de outubro de 2011 e obtivemos um feedback positivo quanto as funcionalidades e estruturas modeladas. Apesar do sistema ter uma estrutura simples suas funcionalidades são extremamente úteis e eficazes tornando o dia a dia no escritório de advocacia mais dinâmica e produtiva. Visto que atingimos a satisfação dos nossos clientes com a estrutura sugerida, assumimos sucesso nesta fase inicial para o desenvolvimento e implantação do sistema. 22
REFERÊNCIAS [Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and Techniques, John Wiley & Sons, 1998. [Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas. <http://www.cin.ufpe.br/~if716/material.php>. [i*] i* - An Agent-oriented Modelling Framework. <http://www.cs.toronto.edu/km/istar/>. 23
FORMULÁRIO DO RELATÓRIO DA EQUIPE Equipe Participação Assinatura Diocleciano Dantas 25% Lino Alves 25% Renato Celso 25% Társis Tolêdo 25% 24
ANEXO A TÉCNICA DE COLETA DE DADOS Entrevista foi a técnica escolhida pela equipe para realizar a coleta das informações necessárias para o advento dos documentos de viabilidade e de requisitos. Abaixo está transcrita a parte principal da entrevista onde a maioria dos dados foi coletada. De uma forma geral, como funciona o fluxo do trabalho no escritório? Em primeiro lugar, o cliente nos procura para avaliarmos e darmos uma opinião sobre alguma questão legal. A esta questão damos o nome de causa. Depois de analisar a causa, é preciso tomar a decisão de acionar ou não a justiça. Caso a justiça seja acionada por meio de uma ação judicial (via de regra, porque podemos ser provocados enquanto réus para responder a processo), é preciso aguardar que ela se posicione sobre o caso; esse posicionamento se concretiza através de divulgação em meio oficial, como o Diário Oficial. É preciso sempre ficar atento as estes posicionamentos, pois nós temos prazos a serem cumpridos, e se um prazo é perdido, então o cliente certamente sairá prejudicado! Dependendo ainda deste posicionamento, decidimos como é dado prosseguimento ao processo com a adição de atos processuais e o ciclo continua até que uma decisão sólida seja tomada. Quais as principais dificuldades encontradas neste fluxo? Uma vez percebida a publicação, o controle de prazos é feito internamente e o escritório precisa ter uma boa equipe pra se organizar diariamente, visto que o volume de prazos que chegam diariamente é enorme. Muitas vezes, o advogado não tem como agendar todos os prazos do dia, assim como suas audiências e reuniões, porque tem que fazer inúmeras outras coisas além de controlar as malditas publicações de prazo! O difícil é ter controle sobre quem fez o que, quando, e o que precisa ser feito no futuro. Quer dizer, manter um histórico das decisões e interações do passado, cadastro dos nossos clientes e parceiros e manter a agenda bem atualizada e sempre cumprida (risos)! Essa é o que se chama a parte secretarial do escritório. Na parte que é específica do nosso trabalho, estar sempre atento as decisões que a justiça toma sobre as causas que estão sobre nossa responsabilidade. Há momentos em que temos muitas causas que correm com rapidez, em vez de processos longos e delicados e por isso controlar essas informações e a nossa agenda se torna um desafio. Isso demanda o tempo que não temos e pode até comprometer o resultado do serviço que prestamos. Não é raro ver um advogado se queixando do acúmulo de prazos processuais e isso com certeza seria minimizado com uma melhor estrutura organizacional. Como você vislumbra uma solução para estas dificuldades? Sem dúvida nenhum estamos na era da informação. A própria justiça tem investido na digitalização dos seus acervos, e processos tramitam virtualmente; nada mais justo que nós, profissionais da área entremos na mesma onda. Em primeiro lugar, normalizar como as informações dos clientes e processos são guardados aqui, atualizando nossas práticas, visto que isso ainda é feito de modo primitivo: arquivos físicos, e anotações e agendamentos feitos pela secretaria. Não temos como distribuir atribuições a outros advogados, tampouco como fechar as tarefas que já foram concluídas. Ela pode ser útil para tentar avaliar o nosso próprio trabalho no futuro. Segundo, melhorar o máximo possível a interação que temos com a justiça e sua decisões. Quanto mais automatizado isso puder ser, melhor para a nós, por que poderemos tomar decisões rápidas e gerenciar nosso tempo melhor. 25
ANEXO B DESCRIÇÃO DOS CASOS DE USO Autenticação [UC01] Fazer login Identificador: [UC 01] Autentica o usuário no sistema. Atores: Advogados e dono do escritório. Prioridade: Essencial Pré-condições: Não se aplica. Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito. Fluxo de Eventos Principal 1. Estando na tela inicial do sistema, o ator escolhe a opção fazer login por credencial extend [UC02] ou fazer login biométrico extend [UC03]; 2. O ator então clica no botão OK. [UC02] Fazer login por Credencial Identificador: [UC 02] Autentica o usuário no sistema através de login e senha. Atores: Advogados e dono do escritório. Prioridade: Essencial Pré-condições: Não se aplica. Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito. Fluxo de Eventos Principal 1. Estando na tela inicial do sistema, o ator deve preencher os campos login e senha ; 2. O ator então clica no botão OK. Fluxo Secundário 1 1. O ator fornece um login não cadastrado no sistema; 2. A mensagem Usuário inexistente é exibida. Fluxo Secundário 1 O ator fornece um login e uma senha não correspondentes; A mensagem Senha incorreta é exibida. 26
[UC03] Efetuar login Biométrico Identificador: [UC 03] Autentica o usuário no sistema através de dados biométricos. Atores: Advogados e dono do escritório. Prioridade: Essencial Pré-condições: Não se aplica. Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito. Fluxo de Eventos Principal 1. O sistema pede que o ator posicione a digital no scanner. 2. O ator deve posicionar a digital no scanner; 3. O sistema lê a digital do ator e realiza a autenticação. [UC04] Fazer logoff Identificador: [UC 04] Finaliza o acesso ao sistema. Atores: Advogados e dono do escritório. Prioridade: Essencial Pré-condições: O ator deve estar logado no sistema no momento da execução dessa operação. Pós-condições: O ator deixa de ter acesso às funcionalidades do sistema. O sistema retorna à tela inicial. Fluxo de Eventos Principal 1. O ator clica no botão Sair ; 2. O sistema finaliza todas as operações que estão em execução devido às requisições feitas por esse ator. Organização da Informação [UC05] Organizar Informação Identificador: [UC 05] Permite a inserção, atualização, remoção e consulta de dados no sistema. A partir deste ponto o ator pode acessar a tela de gerenciamento de clientes ou de processos. Ator: Advogado e o dono do escritório. Prioridade: Essencial Pré-condições: O ator deve estar cadastrado no sistema como advogado ou dono do escritório. Pós-condições: O usuário será direcionado para tela onde poderá realizar a operação desejada. 27
Fluxo de Eventos Principal 1. Include [UC01] 2. O sistema exibe menu com as opções gerenciar processos e gerenciar clientes ; 3. O ator escolhe a opção gerenciar processos extend [UC11] ou gerenciar clientes extend [UC06]; 4. O sistema redireciona o ator para uma nova tela de acordo com a opção escolhida. Fluxo Secundário 1 1. O ator não seleciona opção e solicita encerramento do sistema; 2. O sistema é finalizado. Clientes [UC06] Gerenciar Clientes Identificador: [UC 06] Disponibiliza a listagem dos clientes cadastrados, a partir da qual é possível escolher um cliente específico para alteração de informações ou para exclusão de seu registro do cadastro de clientes. Ator: Advogados ou dono do escritório. Prioridade: Essencial Pré-condições: O ator deve estar logado no sistema. Pós-condições: O ator é redirecionado para a tela que permite o gerenciamento de clientes. Fluxo de Eventos Principal 1. O sistema exibe uma tela contendo a listagem de clientes e as opções de gerenciamento: os botões Cadastrar, Buscar, e Voltar e, para cada cliente da lista, os botões Alterar e Excluir. 2. O ator clica no botão Voltar ; 3. O sistema retorna ao fluxo de eventos do caso de uso [UC 05] Organizar Informação. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator clica no botão Cadastrar ; 2. Incluir o fluxo de eventos do caso de uso [UC 07] Cadastrar Cliente ; Fluxo Secundário 2 1. No passo 2 do fluxo principal, o ator clica no botão Buscar ; 2. Incluir o fluxo de eventos do caso de uso [UC 08] Buscar Cliente ; Fluxo Secundário 3 28
1. No passo 2 do fluxo principal, o ator clica no botão Editar ; 2. Incluir o fluxo de eventos do caso de uso [UC 09] Editar Cliente ; Fluxo Secundário 4 1. No passo 2 do fluxo principal, o ator clica no botão Excluir ; 2. Incluir o fluxo de eventos do caso de uso [UC 10] Excluir Cliente ; [UC07] Cadastrar Cliente Identificador: [UC 07] Realiza a inserção de um novo registro de cliente no banco de dados do sistema, armazenando suas informações pessoais. Ator: Advogados ou dono do escritório. Prioridade: Essencial Pré-condições: Não deve existir um cliente já cadastrado com o mesmo CPF. Pós-condições: Haverá um novo cliente cadastrado no sistema. Fluxo de Eventos Principal 1. O sistema exibe o formulário de cadastro de cliente; 2. O ator informa os dados pessoais do cliente a ser cadastrado e clica em Cadastrar ; 3. O sistema cadastra as informações na base de dados; 4. O sistema exibe uma mensagem de sucesso da operação; 5. O sistema limpa os campos do formulário. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator clica no botão Cancelar ; 2. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes. Fluxo Secundário 2 1. No passo 2 do fluxo principal, o ator informa o CPF de um cliente já cadastrado e clica em Cadastrar ; 2. O sistema insere o registro do novo cliente na base de dados; 3. O sistema apresenta uma mensagem informando que já existe um cliente cadastrado com o CPF fornecido; 4. O sistema permanece na mesma tela com os campos preenchidos, e leva o cursor do mouse ao campo do CPF. [UC08] Buscar Cliente Identificador: [UC 08] Realiza a busca de um ou mais registros de clientes no banco de dados do sistema, com base em informações de pesquisa fornecidas em um formulário. 29
Ator: Prioridade: Pré-condições: Pós-condições: Advogados ou dono do escritório. Essencial Nenhuma. Uma listagem filtrada de clientes será exibida pelo sistema. Fluxo de Eventos Principal 1. O sistema exibe o formulário de pesquisa de clientes; 2. O ator informa os parâmetros de filtragem de busca e clica em Pesquisar ; 3. O sistema consulta a base de dados para verificar os registros que correspondam aos parâmetros de busca informados pelo ator; 4. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes, mas listando apenas os clientes encontrados na busca do passo anterior. Uma mensagem aparece no browser indicando que a listagem está filtrada. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator clica no botão Cancelar ; 2. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes. [UC09] Editar Cliente Identificador: [UC 09] Edita os dados de um cliente cadastrado. Ator: Advogados ou dono do escritório. Prioridade: Importante Pré-condições: O ator precisa estar logado no sistema. Pós-condições: As novas informações fornecidas pelo ator serão atualizadas no registro do cliente na base de dados. Fluxo de Eventos Principal 1. O sistema exibe o formulário contendo as informações do cliente; 2. O ator edita as informações do cliente que deseja alterar e clica no botão Alterar ; 3. O sistema atualiza os dados no registro do cliente, na base de dados; 4. O sistema exibe uma mensagem de sucesso da operação; 5. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator clica no botão Cancelar ; 2. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes. Fluxo Secundário 2 30
1. No passo 2 do fluxo principal, o ator informa o CPF de um cliente já cadastrado e clica em Alterar ; 2. O sistema apresenta uma mensagem informando que já existe um cliente cadastrado com o CPF fornecido; 3. O sistema permanece na mesma tela com os campos preenchidos, e leva o cursor do mouse ao campo do CPF. [UC10] Excluir Cliente Identificador: [UC 10] O registro do cliente é alterado para excluído na base de dados do sistema, o qual o tratará como inexistente a partir desta exclusão. Ator: Advogados ou dono do escritório. Prioridade: Essencial Pré-condições: O ator precisa estar logado no sistema. O cliente a ser excluído deve existir no sistema. Pós-condições: O registro do cliente é excluído logicamente do sistema. Seu registro ainda permanece no banco de dados, porém, desabilitado. Fluxo de Eventos Principal 1. O sistema pergunta se o ator realmente deseja excluir o cadastro deste cliente; 2. O ator clica em OK para confirmar a exclusão; 3. O sistema desabilita o registro do cliente na base de dados, permanecendo na tela de gerenciamento de clientes; 4. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator seleciona o botão Cancelar ; 2. O sistema retorna ao fluxo de eventos do caso de uso [UC 06] Gerenciar Clientes. Gerenciar Processos [UC11] Gerenciar Processos Identificador: [UC 11] Permite a atualização, remoção, busca e cadastro de dados referentes a processos. A partir deste ponto os demais casos de uso relativos ao gerenciamento de Processos são acessados. Ator: Advogado e o dono do escritório. Prioridade: Essencial Pré-condições: O ator escolheu a opção gerenciar processos no UC05. Pós-condições: O ator é redirecionado para tela que permita a realização da operação desejada. 31
Fluxo de Eventos Principal 1. O sistema exibe menu com opções de cadastrar, excluir, editar, buscar e listar processos; 2. O ator seleciona a opção desejada cadastrar extend [UC12], ou excluir extend [UC10], ou buscar extend [UC13] ou listar extend [UC16]; 3. O sistema redireciona o ator para tela correspondente a opção desejada. Fluxo Secundário 1 1. O ator não seleciona opção e solicita encerramento do sistema; 2. O sistema é finalizado. [UC12] Cadastrar Processo Identificador: [UC 12] Cadastra um novo processo no sistema. Ator: Advogado ou dono do escritório. Prioridade: Importante Pré-condições: O usuário deve estar logado no sistema e o novo processo não está cadastrado no sistema. Pós-condições: O novo processo passa a estar cadastrado no sistema. Fluxo de Eventos Principal 1. O sistema exibe formulário com campos para cadastro do processo; 2. O ator preenche os campos com dados válidos (pelo menos o número do processo e a identificação do cliente devem ser informados neste momento) e aciona o botão cadastrar ; 3. O sistema insere os dados no banco como um novo processo associado a um cliente; 4. O sistema informa ao usuário que a operação ocorreu com sucesso; 5. O sistema volta para tela de cadastro de processos; Fluxo Secundário 1 1. No passo 2 o ator seleciona o botão Cancelar ; 2. O sistema retorna para a tela de gerencia de processos. Fluxo Secundário 2 1. No passo 2 o ator informa dados inválidos ou número de processo já cadastrado; 2. O sistema exibe uma mensagem avisando que já existe um processo cadastrado com esse número ou que os dados são inválidos. [UC13] Buscar Processo Identificador: [UC 13] 32
Ator: Prioridade: Pré-condições: Pós-condições: Busca um processo no sistema. Advogado ou dono do escritório. Essencial Usuário deve estar logado e processo deve estar cadastrado no sistema. Os dados do processo são exibidos na tela. Fluxo de Eventos Principal 1. O sistema exibe tela com formulário para busca do processo; 2. O ator informa o número do processo; 3. O sistema exibe as informações do processo (nessas informações devem constar as movimentações do processo com suas respectivas datas de maneira formatada para facilitar a leitura); 4. O ator aciona o botão voltar ; 5. O sistema retorna para a tela de busca. 6. O sistema exclui o processo do sistema; Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator informa um número de processo inexistente; 2. O sistema apresenta uma mensagem informando que não existe processo com o número informado; 3. O sistema permanece na mesma tela com os campos preenchidos. [UC14] Editar Processo Identificador: [UC 14] Permite a edição de dados do processo no sistema. Ator: Advogado e dono do escritório. Prioridade: Essencial Pré-condições: O usuário deve estar logado no sistema e o processo deve estar cadastrado no sistema. Pós-condições: O processo informado tem seus dados alterados no sistema conforme solicitado. Fluxo de Eventos Principal 1. O sistema exibe tela com formulário para busca do processo a ser editado; 2. O ator informa o número do processo; 3. O sistema exibe as informações atuais do processo em campos editáveis; 4. O ator edita os campos que deseja e aciona o botão atualizar; 5. O sistema atualiza os dados com as informações passadas; 6. O sistema exibe mensagem para o ator informando que a operação foi realizada com sucesso. Fluxo Secundário 1 33
1. No passo 2 do fluxo principal, o usuário informa numero de processo inexistente; 2. O sistema informa que o processo não existe no sistema e retorna para a tela de busca de processo. [UC15] Excluir Processo Identificador: [UC 15] Exclui um processo do sistema. Ator: Advogado ou dono do escritório. Prioridade: Essencial Pré-condições: Usuário deve estar logado e processo deve estar cadastrado no sistema. Pós-condições: O processo não existirá mais no sistema. Fluxo de Eventos Principal 1. O sistema exibe tela com formulário para busca do processo a ser excluído; 2. O ator informa o número do processo; 3. O sistema exibe as informações do processo; 4. O ator aciona o botão excluir ; 5. O sistema pergunta ao ator se a operação deve ser realizada; 6. O ator confirma a operação; 7. O sistema exclui o processo do sistema; 8. O sistema exibe mensagem para o ator informando que a operação foi realizada com sucesso. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator informa um número de processo inexistente; 2. O sistema apresenta uma mensagem informando que não existe processo com o número informado; 3. O sistema permanece na mesma tela com os campos preenchidos. [UC16] Listar Processo Identificador: [UC 16] Exibi uma lista de processos. Ator: Advogado ou dono do escritório. Prioridade: Essencial Pré-condições: Usuário deve estar logado. Pós-condições: Lista de processos é exibida. Fluxo de Eventos Principal 34
1. O sistema exibe tela com formulário para busca dos processo a serem excluídos; 2. O ator informa o nome do cliente e/ou período de tempo e/ou advogado; 3. O sistema exibe uma lista contendo os processos relacionados ao cliente e ao advogado fornecidos e que foram cadastrados no sistema no período fornecido; 4. O ator aciona o botão voltar ; 5. O sistema retorna para tela anterior; Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator informa dados inexistentes; 2. O sistema apresenta uma mensagem informando que não existem processos compatíveis com os dados fornecidos; 3. O sistema permanece na mesma tela com os campos preenchidos. Buscar Informação [UC17] Buscar Informação Identificador: [UC 17] O sistema busca informação relacionada aos processos do sistema. Ator: Advogado ou dono do escritório. Prioridade: Essencial Pré-condições: Não possui. Pós-condições: Serão carregadas atualizações no banco de dados relativas aos processos. Fluxo de Eventos Principal 1. O sistema periodicamente acessa as caixas de entrada dos e-mails cadastrados nos sistemas push dos tribunais; 2. Ao acessar cada caixa de entrada o sistema verificará todos os email recebidos dos sistemas push desde a última checagem; 3. O sistema processa o e-mail e identifica o processo em questão e o tipo de movimentação sofrida pelo processo; 4. O sistema atualiza o banco de dados com a nova informação; Fluxo Secundário 1 1. No passo 2 caso não existam novos e-mails o sistema não realiza modificações no banco de dados. [UC18] Cadastrar E-mail Identificador: [UC 18] Cadastra um email para busca de informações dos processos. Ator: Advogado ou dono do escritório. 35
Prioridade: Pré-condições: Pós-condições: Essencial Usuário deve estar logado. O email estará cadastrado no sistema. Fluxo de Eventos Principal 1. O sistema exibe tela com formulário para cadastro de email; 2. O ator informa os dados pedidos; 3. O sistema pergunta ao usuário se a operação pode ser confirmada; 4. O ator confirma a operação; 5. O sistema cadastra o email no banco de dados do sistema. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator informa dados de formato inválido; 2. O sistema apresenta uma mensagem informando que os dados não estão em formato válido; 3. O sistema permanece na mesma tela com os campos preenchidos. [UC19] Remover E-mail Identificador: [UC 19] Remove um e-mail de busca de informações dos processos. Ator: Advogado ou dono do escritório. Prioridade: Essencial Pré-condições: Usuário deve estar logado e e-mail cadastrado no sistema. Pós-condições: O e-mail será removido do sistema. Fluxo de Eventos Principal 1. O sistema exibe tela com formulário para busca de e-mail; 2. O ator informa o endereço de e-mail; 3. O sistema pergunta ao usuário se a operação pode ser confirmada; 4. O ator confirma a operação; 5. O sistema remove o e-mail do banco de dados. Fluxo Secundário 1 1. No passo 2 do fluxo principal, o ator informa dados de formato inválido; 2. O sistema apresenta uma mensagem informando que os dados não estão em formato válido; 3. O sistema permanece na mesma tela com os campos preenchidos. 36
Gerar Relatório [UC20] Gerar Relatório Identificador: [UC 20] Gera relatório dos processos e advogados do sistema. Ator: Dono do escritório. Prioridade: Essencial Pré-condições: Usuário deve estar logado como dono do escritório. Pós-condições: O usuário terá acesso a relatório sobre processos e advogados. Fluxo de Eventos Principal 1. O ator aciona o botão gerar relatório 2. O sistema exibe formulário para preenchimentos de dados (identificação dos advogados e período de tempo); 3. O ator aciona o botão gerar ; 4. O sistema gera e exibi relatório com informações da quantidade e lista de processos de cada advogado, tempo médio gasto por causa e valor médio de ganho financeiro por processo. Além disso, o relatório deve conter gráfico mostrando relação entre ganho, tempo e natureza da causa dos processos. Fluxo Secundário 1 1. No passo 2 do fluxo principal, se o ator não informar as identificações dos advogados o sistema gerará o relatório para todos os advogados cadastrados. 37
GLOSSÁRIO Biométrica (credencial): Forma de identificação que utiliza medidas do corpo do credenciado para identificá-lo. Diário Oficial da União: Meio de comunicação onde se tornam públicas decisões de âmbito federal. Gargalo: Local onde a taxa de tarefas que se enfileiram para serem feitas é potencialmente maior do que a taxa de tarefas feitas. Hibernate: Object Relational Mapper, ou Mapeador Objeto Relactional, é uma aplicação que faz o mapeamento de objetos da linguagem Java para tabelas em banco de dados. i* ( i star ): Linguagem para modelagem de domínio de problema e requisitos organizacionais. J2EE: Java Enterprise Edition; coleção de bibliotecas e padrões que definem uma pilha de camadas para implementação de aplicações Web com a linguagem Java. Login: Ato de apresentar credenciais a um sistema de modo que este último possa reconhecer o primeiro. Logoff: Ato de pedir ao sistema que o retire da lista de usuários reconhecidos até o próximo Login. MySQL: Banco de dados de código aberto amplamente utilizado. NFR Framework: Non-functional Requirements Framework, ou Plataforma para Requisitos Não-funcionais, é uma plataforma para modelagem de objetivos com foco especial em requisitos não funcionais. Requisito Não-funcional: Necessidade identificada de um sistema que não diz respeito diretamente ao conjunto de funcionalidades essenciais de um sistema, também chamado de requisito colateral. Requisito: Necessidade identificada de um sistema que diz respeito ao conjunto de funcionalidades essenciais para seu funcionamento correto. Scrum: Conjunto de técnicas que compõe uma forma ágil e iterativa de desenvolvimento de software. Baseia-se em uma divisão simples de tarefas e prazos flexíveis e curtos. Stakeholder: Toda e qualquer entidade que está relacionada direta ou indiretamente com um sistema em questão. Sistemas Push dos tribunais: o sistema Push provê o envio de e-mails com informações sobre o andamento dos processos previamente cadastrados pelo usuário. Logado: estado em que o ator realizou a autenticação no sistema. 38