Elaborado: Levy Augusto - DGOVI
Sistema Single Sign-On Desenvolvimento
– Arquitetura de
Versão: 1.0
Software
Sistema Single Sign-On
Arquitetura de Software
Diretoria de Governança e Tecnologia da Informação
Coordenação de Tecnologia da Informação e Comunicação
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
Seleção RioSaúde
Gestor do Projeto Gerente de Projeto
Reginaldo Tavares Levy Augusto
[Link]@[Link] [Link]@[Link]
+55 21 97953-5694 +55 21 99211-0192
Objetivo deste Documento
Este documento tem como objetivo descrever as principais decisões de projeto tomadas pela equipe de desenvolvimento e
os critérios considerados durante a tomada destas decisões. Suas informações incluem a parte de hardware e software do
sistema.
Histórico de Revisão
Data Demanda Autor Descrição Versão
08/05/2025 N/A Levy Augusto G. Silva Primeira elaboração da documentação do 1.0
sistema.
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
Sumário
1. Introdução 6
1.1 Análise de requisitos 6
1.2 Fundamentos da AR 6
1.3 Requisitos Funcionais e Não Funcionais
1.4 Papel do analista de requisitos em um projeto de software
1.5 Importancia da análise de requisitos no sucesso de um sistema 7
2. Técnica de Elicitação de Requisitos
2.1 Brainstorming e Workshops
2.2 Observação direta
2.3 Entrevista com usuários
2.4 Prototipagem
2.5 Questionário e pesquisas 8
3. Modelagem de requisitos
3.1 Casos de uso (User cases)
3.2 Diagrama de requisitos cm UML
3.3 Diagrama de usuário (USER STORIES) e critérios de aceitação
3.4 Documento de especificação de requisitos com exemplos práticos 9
4. Visão de Implementação 14
6.1 Visão de Implementação (Front-End) 14
6.1 Visão de Implementação (Back-End) 15
6.3 Diagrama de Classe 17
6.4 Diagrama de Sequência 18
6.4.1 Diagrama de Sequência – Login com Sucesso 18
6.4.2 Diagrama de Sequência – Cadastro com Sucesso 19
6.4.3 Diagrama de Sequência – Solicitação de Redefinição de Senha 20
6.4.4 Diagrama de Sequência – Execução da Redefinição de Senha 21
5. Visão de Implantação 22
7.1 Componentes de Software Implantados 22
7.2 Dispositivos Físicos e Ambientes de Execução 23
7.3 Protocolos e Comunicação 23
7.3 Segurança e Isolamento 23
7.3 Escalabilidade 23
7.4 Diagrama de Implantação 23
Dimensionamento e Performance 24
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
8.1 Volume 24
8.2 Performance 25
Qualidade 25
1. INTRODUÇÃO
1.1 Finalidade
Este documento descreve a arquitetura do sistema de Single Sign-On - SSO, adotando o modelo “4+1”
de Kruchten como referência para representar diferentes aspectos arquiteturais do sistema. O objetivo principal
é capturar e comunicar as decisões arquiteturais mais relevantes, promovendo entendimento comum entre todos
os stakeholders envolvidos,
1. FUNDAMENTOS DA ANÁLISE DE REQUISITOS
1.1 Fundamentos da AR
Os Fundamentos da Análise de Requisitos (AR) referem-se aos princípios e conceitos essenciais que
norteiam o processo de identificar, documentar e gerenciar as necessidades para um sistema de software. Eles
englobam a compreensão da importância de elicitar as informações corretas dos stakeholders, a capacidade de
analisar e organizar esses dados de forma clara e não ambígua, a necessidade de validar os requisitos com os
usuários para garantir que o que será construído realmente atenda às suas expectativas, e a prática de gerenciar
as mudanças e o ciclo de vida dos requisitos ao longo do projeto. Em essência, são as bases para garantir que o
software certo seja construído.
1.2 Análise de Requisitos
Análise de requisitos é o processo de entender e documentar as necessidades dos usuários e as restrições
de um sistema. É a etapa fundamental para garantir que o produto atenda às expectativas e resolva os problemas
propostos. Em outras palavras, é como descobrir "o que" o software deve fazer antes de começar a desenvolvê-
lo
1.3 Requisitos Funcionais e Não Funcionais
Requisitos Funcionais: Definem o que o software deve fazer, ou seja, as funcionalidades e
comportamentos que ele deve apresentar. Requisitos Não Funcionais: Especificam como o software deve se
comportar, abrangendo aspectos como desempenho, segurança, confiabilidade e usabilidade. Em resumo,
enquanto os requisitos funcionais focam nas ações do sistema, os não funcionais tratam das qualidades e
restrições do sistema.
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
1.4 Ciclo de Vida de Requisitos (Elicitação ~ Análise ~Validação ~Gerenciamento)
Elicitação: É a fase de descoberta e coleta de informações sobre o que o sistema deve fazer. Envolve
interagir com os usuários e outras partes interessadas para entender suas necessidades, desejos e restrições.
Técnicas comuns incluem entrevistas, workshops, questionários e análise de documentos.
Análise: Nesta fase, as informações coletadas são examinadas, refinadas e organizadas. O objetivo é
transformar os requisitos brutos em especificações claras, consistentes e não ambíguas. Isso pode envolver a
criação de modelos, diagramas e a identificação de conflitos ou lacunas.
Validação: A validação garante que os requisitos estejam corretos e realmente representem as
necessidades dos usuários. É a verificação de que o que foi documentado é o que o cliente realmente quer.
Revisões, prototipagem e testes de aceitação são métodos comuns nesta fase.
Gerenciamento: Esta fase abrange o controle e a manutenção dos requisitos ao longo do ciclo de vida
do projeto. Inclui o rastreamento de mudanças, a priorização de requisitos, o controle de versões e a
comunicação de atualizações a todas as partes interessadas. É um processo contínuo que se estende por todo o
desenvolvimento do sistema.
1.5 Papel do Analista de Requisitos em um projeto de software
O Analista de Requisitos atua como uma ponte entre as partes interessadas (clientes, usuários) e a
equipe de desenvolvimento. Seu papel principal é identificar, documentar e gerenciar as necessidades do
negócio e dos usuários, traduzindo-as em requisitos claros e compreensíveis para que o software a ser
construído atenda às expectativas e resolva os problemas propostos. Ele garante que todos estejam alinhados
sobre o "o quê" do projeto antes de iniciar o "como”
1.6 Importância da Análise de Requisitos no sucesso de um sistema
A Análise de Requisitos é crucial para o sucesso de um sistema porque ela garante que o software certo
seja construído. Ao entender e documentar as necessidades dos usuários e do negócio desde o início, ela evita
retrabalho, custos extras e insatisfação do cliente. É a base que alinha as expectativas, reduz riscos e aumenta
significativamente as chances de entregar um produto que realmente resolva os problemas e agregue valor.
2. TÉCNICA DE ELICITAÇÃO DE REQUISITOS
2.1 Entrevista com usuários
Entrevista com usuários é um tipo de pesquisa bastante útil no início do processo de design, na fase
Preparar do nosso Processo cafetivo. Elas servem para levantar informações qualitativas sobre usuários que
já usam ou poderiam usar o seu produto digital. Essas informações te ajudam a entender seus clientes e se
tornam a matéria prima para seus mapas de empatia e personas.
2.2 Questionários e pesquisas
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
Questionários e pesquisas são ferramentas de coleta de dados que usam uma série de perguntas
padronizadas para obter informações de um grupo de pessoas. São eficazes para coletar dados quantitativos
ou qualitativos em larga escala, permitindo entender opiniões, comportamentos ou características de uma
amostra.
2.3 Observação direta
A observação direta é uma técnica de coleta de dados onde o analista acompanha e registra diretamente
as atividades dos usuários ou o funcionamento de um sistema em seu ambiente natural. Isso permite
entender o contexto real, identificar fluxos de trabalho, desafios e necessidades que talvez não sejam
explícitas em entrevistas ou documento
2,4 Brainstorming e workshops
Brainstorming: é uma técnica de grupo utilizada para estimular a criatividade e a resolução de
problemas. Consiste em uma reunião em que os participantes têm liberdade para expor suas ideias e debater
sobre as contribuições dos colegas. As principais etapas incluem definir o problema, gerar ideias sem
críticas e, em seguida, avaliar e selecionar as melhores soluções. Essa técnica é amplamente utilizada em
ambientes de trabalho e educacionais para promover a inovação e a colaboração.
Workshops: são sessões interativas e colaborativas, geralmente com duração maior que uma reunião,
em que os participantes trabalham juntos para atingir um objetivo comum. Eles são usados para coletar
informações, gerar ideias, resolver problemas ou tomar decisões, promovendo a participação ativa e o
alinhamento entre os envolvidos.
2.5. Prototipagem
A prototipagem é um processo de desenvolvimento iterativo que cria versões preliminares de um
produto ou sistema, chamadas protótipos. O objetivo principal é testar ideias rapidamente, coletar feedback
de usuários e identificar problemas ou melhorias antes da fase final de produção. Ela permite validar
conceitos, refinar o design e a funcionalidade, e garantir que o produto final atenda às necessidades dos
usuários de forma mais eficiente e com menor custo.
2.6 Análise de documentos existentes
A análise de documentos existentes é um processo crucial para entender um sistema, projeto ou
domínio, revisando e interpretando informações já disponíveis. Isso inclui manuais, relatórios,
especificações, diagramas, dados históricos e até mesmo e-mails ou registros de reuniões. O objetivo é
extrair conhecimento, identificar requisitos, entender processos e validar informações sem a necessidade de
criar dados do zero. É uma forma eficiente de obter um panorama completo e fundamentado, economizando
tempo e recursos.
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
3. MODELAGEM DE REQUISITOS
3.1 Casos de uso (Use cases)
Casos de uso são descrições textuais de como um usuário interage com um sistema para atingir um
objetivo específico. 🎯 Eles detalham as ações do usuário (ator) e as respostas do sistema, cobrindo cenários
de sucesso e alternativos (erros ou exceções). A principal finalidade dos casos de uso é capturar requisitos
funcionais de forma clara e compreensível, servindo como uma ponte entre as necessidades do negócio e o
desenvolvimento técnico. Eles ajudam a garantir que o sistema entregue valor ao usuário.
Exemplo: Sistema de Compras Online/ Caso de Uso: Realizar compra/ Ator Principal: Cliente/ Objetivo: O
cliente deseja comprar um ou mais produtos. / Cenário Principal: O cliente navega pelos produtos e
adicionar itens ao carrinho.
3.2 Diagramas de requisitos com UML
Quem são os convidados? (Na informática, a gente chama de "Atores"). Por exemplo, você,
seus amigos, o palhaço, o entregador de pizza. 2. O que cada um pode fazer na festa? (Na informática, a
gente chama de "Casos de Uso"). · Você (o aniversariante) pode "Abrir presentes", "Cortar o bolo". · Seus
amigos podem "Brincar nos jogos", "Comer salgadinhos". · O palhaço pode "Fazer mágica", "Pintar rostos".
· O entregador de pizza pode "Entregar as pizzas". E você desenha linhas ligando os convidados ao que eles
podem fazer. Assim, todo mundo que olha o mapa entende rapidinho: "Ah, o palhaço faz mágica!" ou "A
criança brinca nos jogos!". Esse mapa serve para que todo mundo que está ajudando a organizar a festa (ou
a construir um programa de computador) entenda o que precisa ser feito e por quem, de um jeito bem fácil e
visual. É como um desenho que mostra todas as funções e quem vai usar cada uma delas. Então, um
Diagrama de Requisitos com UML é um desenho especial que mostra quem usa um programa ou sistema e
o que essa pessoa pode fazer com ele. Ajuda a organizar as ideias para que o programa seja feito do jeito
certo!
3.3 Diagramas de usuário (User Stories) e critérios de aceitação
User Stories (Histórias de Usuário) são descrições simples e concisas de funcionalidades do
sistema, escritas da perspectiva do usuário final. Elas focam no valor que a funcionalidade entrega e
geralmente seguem o formato: "Como um [tipo de usuário], eu quero [alguma funcionalidade] para que
[algum benefício]".
Os Critérios de Aceitação são as condições detalhadas que devem ser satisfeitas para que uma User
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
Story seja considerada completa e funcionando corretamente. Eles definem os limites da
funcionalidade e são essenciais para testar e validar se o que foi construído atende às expectativas.
Juntos, User Stories e Critérios de Aceitação garantem que a equipe de desenvolvimento e os stakeholders
tenham um entendimento claro do que precisa ser entregue.
3.4 Especificação de requisitos com exemplos práticos
A Especificação de Requisitos é como uma lista super detalhada é importante que você faça para a
pessoa que vai criar seu videogame. Nessa lista, você escreve EXATAMENTE tudo o que você quer que o
videogame faça. · Por exemplo, você não só diria "quero um videogame". Você escreveria: · "O videogame
tem que ligar em 5 segundos." (Uma regra de desempenho) · "Tem que ter um controle com botões grandes
e macios." (Uma regra de como ele é) · "Tem que ter um jogo de corrida de carrinhos." (Uma regra do que
ele faz) · "E tem que ser fácil de pausar o jogo." (Uma regra de facilidade de uso) Essa lista de "regras" é
muito importante porque garante que o videogame que for construído seja exatamente do jeito que você
sonhou, sem esquecer nada. É como um contrato ou um manual de instruções Super completo que você dá
para quem vai fazer o brinquedo, para que ele saiba tudo o que precisa entregar! A Especificação de
Requisitos é basicamente um documento detalhado que diz TUDO o que um produto (como um videogame,
um aplicativo ou até um robô) precisa ter e fazer para ser perfeito e atender a quem vai usar. Se não tiver
essa lista, o criador pode fazer um videogame que não é o que você queria, certo?
4. FERRAMENTAS E DOCUMENTAÇÃO
4.1 Documento de Especificação de Requisitos de Software (ERS)
Um Documento de Especificação de Requisitos de Software (ERS), também conhecido como SRS
(Software Requirements Specification), é um documento formal e abrangente que detalha todas as
funcionalidades e restrições de um sistema de software. Ele serve como um contrato entre os
stakeholders e a equipe de desenvolvimento, descrevendo o "o quê" o sistema deve fazer, sem
especificar o "como" ele será implementado.
O ERS aborda requisitos funcionais (o que o sistema faz), requisitos não funcionais (qualidade,
desempenho, segurança) e restrições (tecnológicas, orçamentárias). Ele é crucial para garantir que todos
os envolvidos tenham um entendimento comum do projeto, minimizando mal-entendidos e retrabalhos
ao longo do ciclo de desenvolvimento do software.
4.2 Ferramentas populares de análise (Jira, Trello, Figma, Lucidchart)
Jira e Trello são plataformas amplamente utilizadas para gerenciamento de projetos e
acompanhamento de tarefas, especialmente em metodologias ágeis. O Jira é mais robusto, ideal para
equipes de desenvolvimento de software com funcionalidades avançadas para rastreamento de bugs e
fluxo de trabalho. Já o Trello é mais visual e simples, baseado em quadros Kanban, ótimo para
organização de tarefas e colaboração em equipe.
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
O Figma é uma ferramenta colaborativa de design de interface de usuário (UI) e experiência do usuário
(UX). Ele permite que designers criem protótipos interativos, mockups e wireframes, facilitando a
colaboração em tempo real e o feedback entre as equipes.
Por fim, o Lucidchart é uma ferramenta para criação de diagramas e fluxogramas. É excelente para
visualizar processos, sistemas e estruturas organizacionais, ajudando na compreensão e comunicação de
informações complexas de forma clara e concisa.
4.3 Templates de documentação de requisitos
Um Template de Documentação de Requisitos é exatamente como uma receita ou um formulário
pré-pronto que te ajuda a escrever tudo o que um projeto (como um jogo novo, um aplicativo ou até um
robô) precisa ter e fazer. É um papel (ou um arquivo no computador) que já vem com os "espaços em
branco" e as "perguntas" certas para você não esquecer nada. Ele tem partes como: "O que esse jogo vai
ser?" (Para você escrever qual é o objetivo do jogo.) "Quem vai jogar?" (Para você dizer se é para
crianças, adultos etc.) "Quais botões ele vai ter?" (Para listar as funções do jogo.) "Ele precisa ser
rápido?" (Para você dizer o quão rápido o jogo precisa carregar ou funcionar.) E assim por diante! Usar
um "template" (uma receita pronta) é Super importante porque: Não te deixa esquecer nada: Garante que
você pense em todas as partes importantes. Deixa tudo organizado: Ajuda a colocar as ideias em ordem.
Facilita para todo mundo entender: Quando alguém for construir o jogo, vai ter tudo explicado no lugar
certo, sem bagunça.
5. BOAS PRÁTICAS E ERROS COMUNS
5.1 Como lidar com requisitos ambíguos
Lidar com requisitos ambíguos é fundamental para o sucesso de qualquer projeto de software. A
estratégia principal é buscar clareza e detalhe o mais cedo possível. Isso envolve comunicação constante
com os stakeholders, fazendo perguntas diretas e pedindo exemplos concretos e cenários de uso.
Também é útil realizar workshops para discussões aprofundadas, criar protótipos e mockups para
visualização e definir critérios de aceitação específicos para cada funcionalidade. Manter a
documentação atualizada e realizar validação contínua com os usuários ajuda a garantir que o produto
final atenda às expectativas, transformando incertezas em especificações claras.
5.2 Mudanças de requisitos ao longo do projeto
Mudança de requisitos ao longo do projeto é quando, depois que vocês já começaram a planejar a
festa (já escolheram o lugar, chamaram alguns convidados etc.), alguém tem uma ideia nova ou percebe
que algo precisa ser diferente. · Pode ser uma ideia nova: De repente, um amigo fala: "Ei, e se a gente
colocar uma piscina de bolinhas? Seria muito mais legal!" Ou a mãe decide: "Filho, em vez de
brigadeiro, vamos fazer cupcakes!" · Pode ser algo que não funciona: Vocês descobrem que o lugar que
escolheram não tem espaço para a caça ao tesouro, então precisam mudar a brincadeira. · Pode ser algo
Levy Augusto/Gustavo
Sistema Single Sign- Elaborado: Valle – DGOVI
Desenvolvimento
On – Arquitetura de
Software Versão 001
que faltou: Alguém lembra: "Esquecemos de planejar as bebidas!" Todas essas são mudanças de
requisitos.
Ideias Novas: Às vezes, as pessoas que pediram o projeto (os "clientes") têm ideias melhores
depois que veem o que está sendo feito, ou se inspiram em algo novo. Problemas Descobertos: Durante
a construção, a equipe pode descobrir que uma ideia inicial não vai funcionar, ou que é muito difícil e
cara de fazer, e precisa mudar o plano. Coisas que faltaram: No começo, nem todo mundo pensou em
tudo. Conforme o projeto avança, a gente percebe coisas que foram esquecidas.
5.3 Comunicação entre analista, cliente e equipe técnica.
A comunicação eficaz entre o analista, o cliente e a equipe técnica é a espinha dorsal de qualquer
projeto de software bem-sucedido. O analista atua como uma ponte crucial: ele traduz as necessidades e
expectativas do cliente (muitas vezes expressas em linguagem de negócios e com alto nível de
abstração) em requisitos claros e acionáveis que a equipe técnica possa entender e implementar.
Para que isso funcione, o analista deve ser um ouvinte ativo, fazer perguntas pertinentes para
desambiguar os requisitos do cliente, e, ao mesmo tempo, ter conhecimento técnico suficiente para
comunicar à equipe as funcionalidades desejadas, considerando as viabilidades e limitações. A equipe
técnica, por sua vez, precisa fornecer feedback sobre os desafios de implementação, e o cliente deve
estar disponível para validação e esclarecimentos, garantindo um alinhamento contínuo e evitando
retrabalhos.
5.4 Validação e verificação de requisitos
A validação e verificação de requisitos são processos essenciais para garantir a qualidade do
software. A verificação foca em "construir o produto certo?", ou seja, verifica se os requisitos estão
corretos, consistentes, completos e sem ambiguidades antes mesmo da codificação. Isso envolve revisões,
inspeções e análises estáticas dos documentos.
Já a validação questiona "construir o produto certo?", ou seja, se o software desenvolvido
realmente atende às necessidades e expectativas do cliente e dos usuários finais. A validação geralmente
ocorre após a implementação, por meio de testes de aceitação, prototipagem e feedback do usuário,
confirmando que o sistema resolve o problema para o qual foi projetado. Ambos os processos são cruciais e
complementares para assegurar que o que foi especificado é o que deve ser construído e o que é realmente
útil.