Aluno : Eronildo Júnior.

Atividade Museu – 22/05/2023

1- Categorização e lista de requisitos:

Requisitos funcionais:
RF01- Cadastro de obras (pinturas) com título, data, tema, estilo
de época, descrição, técnica, autor e número da sala de exibição.
RF02- Cadastro de autores com nome, data de nascimento,
cidade e país de nascimento, biografia e estilos de época
aderidos.
RF03- Cadastro de estilos de época com denominação, período,
características e escola mais representativa.
RF04- Associação de documentos relacionados às obras (cartas,
fotografias, entrevistas).
RF05- Pesquisa sobre pessoas retratadas nas obras e seu
cadastro.
RF06- Registro de empréstimo de obras para eventos externos,
incluindo período, nome do evento, responsável e tema.
RF07- Solicitação de visitas com roteiros pré-estabelecidos por
turistas e escolas.
RF08- Confirmação, cancelamento e agendamento de visitas
escolares.
RF09- Controle de autorização de entrada para crianças,
acompanhantes e professores.
RF10- Sistema de pesquisa no acervo com múltiplos critérios.
RF11- Acesso controlado às informações de valores de compra
de obras, criptografado e restrito ao diretor.

2- Requisitos não funcionais:

RNF01- Interface intuitiva e de fácil utilização para turistas.
RNF02- Disponibilidade da aplicação em várias mídias.
RNF03- Tempo máximo de resposta da pesquisa: 7 minutos.
RNF04- Tempo máximo de downtime do sistema de pesquisa: 10
minutos.
RNF05- Segurança das informações sensíveis, como valores de
compra.
RNF06- Personalização do roteiro de visitas pelos turistas.
RNF07- Campanha publicitária destacando a aplicação como
carro chefe.

3- Estratégias para o levantamento de requisitos:

- Realizar entrevistas com os funcionários do museu responsáveis
pela administração do acervo e pelos atendimentos aos turistas.
- Observar o fluxo de trabalho dos funcionários no museu.
- Realizar pesquisas com turistas e escolas para entender suas
necessidades e expectativas.
 - Realizar sessões de brainstorming com a equipe de
desenvolvimento para gerar idéias e sugestões de
funcionalidades.

3.1- Usuários e perguntas para tirar dúvidas:

Turistas:
- Como você gostaria de personalizar seu roteiro de visita ao museu?
- Quais informações são mais importantes para você sobre as obras
e artistas?
- Quais mídias você prefere utilizar para acessar informações sobre o
museu?
- Como podemos tornar a visita ao museu mais agradável e menos
confusa para você?

Funcionários do museu:
- Quais são as principais dificuldades que você enfrenta no
gerenciamento do acervo e no atendimento aos turistas?
- Que tipo de informações você considera mais relevante registrar
sobre as obras e artistas?
- Quais são as informações que você precisa acessar em relação aos
valores de compra das obras?
- Quais são os principais critérios de pesquisa utilizados pelos
usuários do sistema?

4- Modelo de processo de desenvolvimento de software:

Considerando as características do projeto, sugiro adotar o modelo de
desenvolvimento ágil, com base em Scrum. Isso permitirá um desenvolvimento
iterativo e incremental, com entregas frequentes de funcionalidades e a
possibilidade de receber opinião dos usuários ao longo do processo. Será
importante contar com um Product Owner que represente os interesses dos
usuários e possa priorizar as funcionalidades de acordo com as necessidades
identificadas.

5- Restrições:
o Restrições de tempo:
• - O tempo máximo de resposta da pesquisa no acervo é de 7
minutos.
• - O sistema de pesquisa nunca deve ficar fora do ar por mais de
10 minutos.

o Restrições de acesso:
• - Acesso aos valores de compra das obras é restrito ao diretor.
• - Os valores de compra devem ser criptografados.

o Restrições de interface:
• - A aplicação deve ser intuitiva e de fácil utilização para turistas.
• - A aplicação deve estar disponível em várias mídias.
6- Premissas:

o Os funcionários do museu estarão disponíveis para

fornecer as informações necessárias para o cadastro das
obras, autores e demais dados do sistema.

o Os usuários estarão dispostos a fornecer informações

necessárias para o agendamento de visitas, como datas e
roteiros pré-estabelecidos.

o Será fornecido acesso adequado aos recursos de

infraestrutura necessários para hospedar e manter o
sistema em funcionamento.

o Os dados do acervo, autores e demais informações serão

disponibilizados de forma precisa e completa para o
cadastro inicial no sistema.

o O museu fornecerá recursos financeiros adequados para o

desenvolvimento, implementação e manutenção contínua
do sistema.

o As informações e requisitos fornecidos pelos usuários

serão precisos e completos, garantindo uma compreensão
adequada de suas necessidades e expectativas.

o O sistema será desenvolvido de acordo com as leis e

regulamentos aplicáveis, como o estatuto da criança e do
adolescente.

o Os funcionários do museu serão treinados para utilizar o

sistema e fornecer suporte adequado aos usuários.

o Será fornecido suporte técnico e manutenção contínua

para garantir o bom funcionamento do sistema e a solução
de eventuais problemas.
 ( Continuação Atividade - 29/05/2023)
7- Possíveis subsistemas do software para o museu de pinturas:

o Subsistema de Cadastro de Obras:

• - Responsável pelo cadastro e gerenciamento das informações
das pinturas, incluindo título, data, tema, estilo de época,
descrição, técnica, autor e número da sala de exibição.
• - Nome sugerido: "Artwork Management System" (Sistema de
Gerenciamento de Obras de Arte).

o Subsistema de Cadastro de Autores:

• - Responsável pelo cadastro e gerenciamento das informações
dos autores, incluindo nome, data de nascimento, cidade e país
de nascimento, biografia e estilos de época aderidos.
• - Nome sugerido: "Author Database" (Banco de Dados de
Autores).

o Subsistema de Pesquisa:
• - Responsável pela pesquisa e consulta de informações no acervo
do museu, permitindo pesquisas por autores, obras, estilos de
época, eventos, etc.
• - Nome sugerido: "Artwork Search Engine" (Motor de Busca de
Obras de Arte).

o Subsistema de Gerenciamento de Empréstimos:

• - Responsável pelo registro e acompanhamento dos empréstimos
de obras para eventos externos, incluindo período, nome do
evento, responsável e tema.
• - Nome sugerido: "Loan Management System" (Sistema de
Gerenciamento de Empréstimos).

o Subsistema de Agendamento de Visitas:

• - Responsável pelo agendamento, confirmação e cancelamento
de visitas de turistas e escolas, incluindo seleção de roteiros pré-
estabelecidos.
• - Nome sugerido: "Visit Scheduling System" (Sistema de
Agendamento de Visitas).

o Subsistema de Controle de Acesso:

• - Responsável pelo controle de autorização de entrada no museu,
verificando requisitos como autorização por escrito para crianças,
acompanhantes e professores.
• - Nome sugerido: "Access Control System" (Sistema de Controle
de Acesso).

o Subsistema de Gerenciamento Financeiro:

• - Responsável pelo registro e criptografia dos valores de compra
de obras, com acesso restrito ao diretor.
• - Nome sugerido: "Financial Management System" (Sistema de
Gerenciamento Financeiro).

o Subsistema de Personalização de Roteiros:

• - Responsável por auxiliar os turistas na customização de seus
roteiros de visita ao museu, tornando a experiência mais
personalizada.
• - Nome sugerido: "Custom Itinerary Planner" (Planejador de
Roteiros Personalizados).

o Subsistema de Publicidade e Marketing:

• - Responsável por gerenciar a aplicação como "carro chefe" da
nova campanha publicitária e disponibilizar a aplicação em várias
mídias.
• - Nome sugerido: "Advertising and Marketing Hub" (Central de
Publicidade e Marketing).
 Cenário encontrado de modo geral na Juntada de Requisições - 29/05/2023

Um servidor chamado Pedro, desempenha um papel importante nesse

processo. Pedro trabalha na área de requisição e seu objetivo é garantir que os
documentos enviados ao sistema PJe sejam devidamente validados e
autorizados para a liberação de pagamentos a beneficiários.
Vamos seguir o fluxo descrito:
1. Pedro acessa o PJe que é onde estão armazenados os dados dos
beneficiários e outros registros relevantes ao processo. Ele utiliza
suas credenciais de servidor para fazer login no sistema.
2. Dentro do Pje, Pedro realiza uma busca específica para capturar os
dados necessários. Esses dados podem ser informações pessoais,
histórico de contribuições, registros dos advogados, entre outros,
dependendo do tipo de documento que será processado.
3. Após a captura dos dados, Pedro precisa inseri-los no Oracle, que é
o sistema utilizado para a elaboração e preparação dos
documentos que serão enviados para validação judicial. O Oracle
possui ferramentas para criação de documentos, incluindo recursos
para formatar e organizar as informações corretamente.
4. Uma vez que o documento está pronto no Oracle, Pedro envia o
arquivo para o juiz responsável pela validação. O documento
contém todas as informações necessárias para o juiz tomar uma
decisão informada sobre a autorização do pagamento ao
beneficiário.
5. O juiz recebe o documento através de um sistema específico
utilizado pelo Judiciário, onde pode analisar detalhadamente todas
as informações apresentadas. Ele avalia se o beneficiário atende
aos critérios legais para receber os pagamentos solicitados, como
tempo de contribuição, incapacidade ou outros requisitos
estabelecidos pelas leis previdenciárias.
6. Após a análise, o juiz emite uma decisão sobre a validação do
documento. Se aprovado, o documento é liberado para postagem
no Pje. Caso contrário, o juiz pode solicitar correções ou rejeitar o
documento, iniciando um processo de revisão ou complementação
das informações.
7. Após a liberação pelo juiz, o documento é disponibilizado no Oracle
novamente. Pedro, como servidor responsável pela documentação,
acessa o Oracle, faz o download do documento validado para seu
computador e realiza uma assinatura digital utilizando uma
ferramenta adequada de criptografia.
8. Com o documento assinado digitalmente em mãos, Pedro retorna
ao Pje e realiza o upload do arquivo para o sistema. A assinatura
digital garante a autenticidade do documento, certificando que ele
não foi alterado após a validação do juiz.
9. Ao receber o documento assinado digitalmente, o PJe processa a
informação e, caso todas as condições sejam atendidas, notifica os
 interessados no processo sobre o pagamento conforme
especificado no documento.
10. O beneficiário recebe o pagamento de acordo com as regras
estabelecidas pela Agência de Previdência Social, garantindo assim
o acesso aos seus benefícios conforme validado pelo juiz.

Com relação a este fluxo, Pedro demora muito para fazê-lo sendo que
só uma juntada destas demora cerca de 10 minutos e com um fluxo de 200 a
300 tarefas dessa por mês fica impraticável exercer outras atividades que não
relacionadas às requisições de pagamento. Somando lentidão de sistemas e
possíveis erros com formatação de arquivo que nos sistemas Oracle e PJe
acontece, ele gostaria de uma solução sobre automatização dessa tarefa.
Pedro pediu à área de TI uma ferramenta para facilitar sua vida, e pensando
nisso a equipe pensou em desenvolver uma automação que roda em
background para executar a parte da tarefa que não é necessária intervenção
humana.
A automação vai partir do momento que o juiz libera a requisição de
pagamento para juntada no PJe, uma pasta vai ser disponibilizada para Pedro
colocar todas as requisições assinadas pelo juiz e autuadas.

1) A automação pegará esses arquivos, separando-os por RPV ou

Precatório (de acordo com as normas de cada).
2) Anexará uma certidão informando que os documentos foram
juntados pela automação.
3) Entrará no PJe e fará o upload dos documentos gerando um log
de acerto ou falha para registro.
4) Caso a falha os arquivos com falha ficarão lá para revisão ou
nova tentativa de juntada automática (caso de falha por parte do
PJe).
5) Essa automação irá ser executada como rotina diária as 22:00.

Após validação de Pedro, a automação vai ser replicada para outros

setores atendendo as especificações de seu documentos e ambientes.
 História de usuário – 05/06/2023

• Como Diretora eu quero consultar as listas de doações concluídas e em

processo de análise do museu para ter o controle do que já foi emprestado e
do que está sendo solicitado.
• Como Diretora eu quero receber alertas sobre pendências jurídicas
relacionadas a doações de obras do museu para possíveis atuações de forma
a agilizar o processo.
• Como Diretora eu quero que o acesso a valores das obras seja possível
de uma máquina que esteja no museu para se ter uma maior segurança no
acesso à informação.
• Como Diretora eu desejo consultar as exposições indicando as que
foram sucesso de público e as que não foram, para análise das boas práticas e
correção de possíveis deficiências que acarretam no insucesso de
determinadas exposições.
• Como Diretora eu quero acessar as obras, inclusive com os valores de
compra.

Casos de uso:

Análise de exposições

Ator: Diretor(a) do museu.

Fluxo Normal:
1. Autenticar usuário.
2. Diretor informa o período das exposições.
3. O sistema retorna lista das exposições por ordem cronológica, informando
o nível de sucesso das mesmas.

Extensões:
2.a - Se a data final for menor que a data inicial o sistema retorna mensagem de
erro.
3.a - Se no período especificado não houver nenhum evento, o sistema retorna
mensagem informando.

Nome do caso de uso Consulta Status de doações

Caso de uso geral -

Ator Principal Diretor(a)

Ator Secundário -
Resumo Este caso de uso descreve as etapas percorridas pelo
diretor(a) para ter acesso ao status das doações.

Pré-Condições O diretor(a) deve estar logado.

Deve existir ao menos uma doação em trânsito.

Pós-Condições -

Ações do ator Ações do Sistema

1. O diretor(a)
informa um
período.

2. Sistema retorna doações e seus status no

período informado.