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 ([email protected])
Lino Alves de Oliveira Júnior ([email protected])
Renato Celso Santos Rodrigues ([email protected])
Társis Wanderley Toledo ([email protected])
Professor:
Jaelson Castro ([email protected])
Monitores:
Diego Dermeval Medeiros ([email protected])
Joao Henrique Correia Pimentel ([email protected])
RECIFE, OUTUBRO DE 2011.
2
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
3
[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
4
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
5
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 sente-
se 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.
6
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.
7
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.
8
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
Identificação: [RF01] Fazer login
Casos de Uso
relacionados: [UC 01], [UC 02] e [UC 03]
Descrição:
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.
Prioridade: Essencial Importante Desejável
[RF02] Fazer Logoff
Identificação: [RF02] Fazer logoff
Casos de Uso
relacionados: [UC 04]
Descrição: Permite que o usuário saia do sistema.
Prioridade: Essencial Importante Desejável
9
[RF03] Organizar Informação
Identificação: [RF03] Organizar Informação
Casos de Uso relacionados: [UC 05]
Descrição:
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.
Prioridade: Essencial Importante Desejável
3.2 Gerenciar Clientes
[RF04] Gerenciar Clientes
Identificação: [RF04] Gerenciar Clientes
Casos de Uso relacionados: [UC 06]
Descrição:
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.
Prioridade: Essencial Importante Desejável
[RF05] Cadastrar Cliente
Identificação: [RF05] Cadastrar Cliente
Casos de Uso relacionados: [UC07]
Descrição:
Realiza a inserção de um novo registro de cliente no
banco de dados do sistema, armazenando suas
informações pessoais.
Prioridade: Essencial Importante Desejável
[RF06] Buscar Cliente
Identificação: [RF06] Buscar Cliente
Casos de Uso relacionados: [UC 08]
Descrição:
Permite a busca de um cliente específico pelo
fornecimento de algumas de suas informações como
parâmetro de busca.
Prioridade: Essencial Importante Desejável
10
[RF07] Editar Cliente
Identificação: [RF07] Editar Cliente
Casos de Uso relacionados: [UC 09]
Descrição: Permite a alteração de uma ou mais informações de um
cliente que já esteja cadastrado no sistema.
Prioridade: Essencial Importante Desejável
[RF08] Excluir Cliente
Identificação: [RF08] Excluir Cliente
Casos de Uso relacionados: [UC 10]
Descrição:
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.
Prioridade: Essencial Importante Desejável
3.3 Gerenciar Processos
[RF09] Gerenciar Processo
Identificação: [RF09] Gerenciar Processo
Casos de Uso
relacionados: [UC 11]
Descrição:
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.
Prioridade: Essencial Importante Desejável
[RF10] Cadastrar Processo
Identificação: [RF10] Cadastrar Processo
Casos de Uso
relacionados: [UC 12]
Descrição:
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.
Prioridade: Essencial Importante Desejável
11
[RF11] Excluir Processo
Identificação: [RF11] Excluir Processo
Casos de Uso
relacionados: [UC 15]
Descrição:
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.
Prioridade: Essencial Importante Desejável
[RF12] Editar Processo
Identificação: [RF12] Editar Processo
Casos de Uso
relacionados: [UC 14]
Descrição:
O advogado ou o dono do escritório edita os dados de um
processo no banco de dados do sistema.
Prioridade: Essencial Importante Desejável
[RF13] Listar Processo
Identificação: [RF13] Listar Processo
Casos de Uso relacionados: [UC 16]
Descrição: Lista processos relacionados a um dado cliente ou a um
dado advogado.
Prioridade: Essencial Importante Desejável
[RF14] Buscar Processo
Identificação: [RF14] Buscar Processo
Casos de Uso relacionados: [UC 13]
Descrição:
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.
Prioridade: Essencial Importante Desejável
12
3.4 Buscar Informação do Meio Oficial
[RF15] Buscar Informação
Identificação: [RF15] Buscar Informação
Casos de Uso relacionados: [UC 17]
Descrição:
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.
Prioridade: Essencial Importante Desejável
[RF16] Cadastrar E-mail
Identificação: [RF16] Cadastrar E-mail
Casos de Uso relacionados: [UC 18]
Descrição:
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.
Prioridade: Essencial Importante Desejável
[RF17] Remover E-mail
Identificação: [RF17] Remover E-mail
Casos de Uso relacionados: [UC 19]
Descrição: O sistema deve permitir que o advogado ou o dono do
escritório removam um e-mail cadastrado.
Prioridade: Essencial Importante Desejável
3.5 Gerência do Escritório
[RF18] Gerar Relatório
Identificação: [RF18] Gerar Relatório
Casos de Uso
relacionados: [UC 20]
Descrição: O dono do escritório pode solicitar a geração de relatórios
13
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.
Prioridade: Essencial Importante Desejável
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
Identificação: [NFR01] Utilizar SCRUM como metodologia de
desenvolvimento
Casos de Uso
relacionados:
Todos.
Descrição: Scrum é uma metodologia ágil para gestão e planejamento
de projetos de software.
Prioridade: Essencial Importante Desejável
[NFR02] Utilizar Linguagem Java para Web (J2EE)
Identificação: [NFR02] Utilizar Linguagem Java para Web (J2EE)
Casos de Uso
relacionados: Todos.
Descrição: 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
Identificação: [NFR03] Utilizar Banco de Dados MySQL
Casos de Uso
relacionados: Todos.
14
Descrição: Esse sistema de banco de dados oferece os recursos básicos
necessários à aplicação e é economicamente viável.
Prioridade: Essencial Importante Desejável
[NFR04] Utilizar Hibernate
Identificação: [NFR04] Utilizar Hibernate
Casos de Uso
relacionados: Todos.
Descrição: Facilitar o desenvolvimento de consultas ao bando de
dados e permitir a independência do mesmo.
Prioridade: Essencial Importante Desejável
4.2 REQUISITOS DE PRODUTO
4.2.1 Confiabilidade
[NFR05] Disponibilidade
Identificação: [NFR05] Disponibilidade
Casos de Uso
relacionados: Todos.
Descrição:
O sistema deve ter o máximo de estabilidade e a estrutura
de hardware deve ser redundante para prover uma alta
disponibilidade.
Prioridade: Essencial Importante Desejável
[NFR06] Segurança da Informação
Identificação: [NFR06] Segurança da Informação
Casos de Uso
relacionados: [UC05]
Descrição:
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.
Prioridade: Essencial Importante Desejável
15
4.2.2 Usabilidade
[NFR07] Escrever documentação
Identificação: [NFR07] Escrever documentação
Casos de Uso
relacionados: Todos.
Descrição: O sistema deve ser acompanhado da descrição de suas
funcionalidades em formato de manual eletrônico.
Prioridade: Essencial Importante Desejável
[NFR08] Escrever em linguagem do usuário
Identificação: [NFR08] Escrever em linguagem do usuário
Casos de Uso
relacionados: Todos.
Descrição:
As mensagens do sistema assim como a interface gráfica
devem ser intuitivas e descritas na linguagem que o usuário
esteja habituado.
Prioridade: Essencial Importante Desejável
4.3 REQUISITOS EXTERNOS
[NFR09] Custos
Identificação: [NFR09] Custos
Casos de Uso
relacionados: Todos.
Descrição:
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
Identificação: [NFR10] Entrega do sistema
16
Casos de Uso
relacionados: Todos.
Descrição:
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.
17
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.
.
18
Figura 5 – Modelo estratégico da razão com o ator “cliente” expandido e suas relações
com outros atores evidenciadas.
19
Figura 6 – Modelo estratégico da razão com o ator “sistema” expandido e suas relações
com outros atores evidenciadas.
20
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.
21
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.
22
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 inter-
relacionadas: 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.
23
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/>.
24
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%
25
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.”
26
ANEXO B – DESCRIÇÃO DOS CASOS DE USO
Autenticação
[UC01] Fazer login
Identificador: [UC 01]
Descrição: 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”.
Requisitos Não Funcionais Específicos -
[UC02] Fazer login por Credencial
Identificador: [UC 02]
Descrição: 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.
Requisitos Não Funcionais Específicos -
27
[UC03] Efetuar login Biométrico
Identificador: [UC 03]
Descrição: 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.
Requisitos Não Funcionais Específicos -
[UC04] Fazer logoff
Identificador: [UC 04]
Descrição: 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.
Requisitos Não Funcionais Específicos -
Organização da Informação
[UC05] Organizar Informação
Identificador: [UC 05]
Descrição: 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.
28
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.
Requisitos Não Funcionais Específicos -
Clientes
[UC06] Gerenciar Clientes
Identificador: [UC 06]
Descrição: 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
29
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”;
Requisitos Não Funcionais Específicos -
[UC07] Cadastrar Cliente
Identificador: [UC 07]
Descrição: 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.
Requisitos Não Funcionais Específicos -
[UC08] Buscar Cliente
Identificador: [UC 08]
Descrição: 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.
30
Ator: Advogados ou dono do escritório.
Prioridade: Essencial
Pré-condições: Nenhuma.
Pós-condições: 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”.
Requisitos Não Funcionais Específicos -
[UC09] Editar Cliente
Identificador: [UC 09]
Descrição: 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
31
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.
Requisitos Não Funcionais Específicos -
[UC10] Excluir Cliente
Identificador: [UC 10]
Descrição: 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”.
Requisitos Não Funcionais Específicos -
Gerenciar Processos
[UC11] Gerenciar Processos
Identificador: [UC 11]
Descrição: 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.
32
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.
Requisitos Não Funcionais Específicos -
[UC12] Cadastrar Processo
Identificador: [UC 12]
Descrição: 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.
Requisitos Não Funcionais Específicos -
[UC13] Buscar Processo
Identificador: [UC 13]
33
Descrição: Busca um processo no 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: 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.
Requisitos Não Funcionais Específicos -
[UC14] Editar Processo
Identificador: [UC 14]
Descrição: 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
34
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.
Requisitos Não Funcionais Específicos -
[UC15] Excluir Processo
Identificador: [UC 15]
Descrição: 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.
Requisitos Não Funcionais Específicos -
[UC16] Listar Processo
Identificador: [UC 16]
Descrição: 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
35
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.
Requisitos Não Funcionais Específicos -
Buscar Informação
[UC17] Buscar Informação
Identificador: [UC 17]
Descrição: 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.
Requisitos Não Funcionais Específicos -
[UC18] Cadastrar E-mail
Identificador: [UC 18]
Descrição: Cadastra um email para busca de informações dos processos.
Ator: Advogado ou dono do escritório.
36
Prioridade: Essencial
Pré-condições: Usuário deve estar logado.
Pós-condições: 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.
Requisitos Não Funcionais Específicos -
[UC19] Remover E-mail
Identificador: [UC 19]
Descrição: 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.
Requisitos Não Funcionais Específicos -
37
Gerar Relatório
[UC20] Gerar Relatório
Identificador: [UC 20]
Descrição: 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.
Requisitos Não Funcionais Específicos -
38
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.