Elos de Pós-Rastreabilidade¶

Introdução¶

A rastreabilidade de requisitos é um pilar fundamental para a gerência e a qualidade no desenvolvimento de software. Ela é definida como a "habilidade de acompanhar e descrever a vida de um requisito, em ambas as direções". Um requisito não pode ser efetivamente gerenciado sem rastreabilidade.

Este documento adota o Meta-modelo de Toranzo, uma abordagem que estrutura a rastreabilidade classificando as informações em quatro níveis distintos: ambiental, organizacional, gerencial e desenvolvimento. (Sayão e Leite. Rastreabilidade de Requisitos) [1]; (Milene Serrano e Maurício Serrano. Requisitos – Aula 26) [2]

A metodologia foca em dois tipos principais de rastreabilidade:

Pré-Rastreabilidade (Origem dos Requisitos):
Backward-from: Estabelece o vínculo de cada requisito às suas fontes originais (stakeholders, documentos e técnicas de elicitação como Análise de Documentos e Observação), respondendo às perguntas “quem solicitou”, “com qual objetivo” e “com base em qual evidência”.
Pós-Rastreabilidade (Implementação dos Requisitos):
Forward-from: Estabelece o vínculo de cada requisito aos artefatos produzidos durante o desenvolvimento — como Cenários, Léxicos, Casos de Uso, Especificação Suplementar, Histórias de Usuário, Backlog e NFR Framework — permitindo verificar cobertura de implementação, validar consistência entre artefatos e identificar lacunas ou impactos de mudança.

Classificação por Níveis de Informação (Meta-modelo de Toranzo)¶

Conforme o Meta-modelo de Toranzo, os requisitos são classificados em quatro níveis de informação:

Nível Ambiental¶

Contexto: Mercado de Magic: The Gathering e comunidade de jogadores
Regulamentações: LGPD (Lei nº 13.709/2018), Código de Defesa do Consumidor
Padrões de segurança: Diretrizes do Banco Central do Brasil
Aspectos sociais: Necessidades da comunidade de colecionadores e jogadores

Nível Organizacional¶

Políticas internas: Política de Proteção de Dados Pessoais da LigaMagic
Estrutura de negócios: Modelo de marketplace e comércio eletrônico
Objetivos estratégicos: Facilitação de transações e construção de comunidade
Relacionamento com parceiros: Compartilhamento de dados e integração de serviços

Nível Gerencial¶

Gestão de projeto: Controle de desenvolvimento e implementação
Controle de qualidade: Testes e validação de requisitos
Cronogramas: Marcos de entrega e planejamento
Monitoramento: Acompanhamento de métricas e performance

Nível de Desenvolvimento¶

Requisitos funcionais e não funcionais: Especificações técnicas detalhadas
Artefatos de modelagem: Casos de uso, cenários, histórias de usuário
Especificações técnicas: Implementação de funcionalidades
Testes: Validação e verificação de componentes

Estratégias de Toranzo Aplicadas¶

O Meta-modelo de Toranzo utiliza quatro estratégias principais:

Classificação por Níveis: Estruturação em Ambiental, Organizacional, Gerencial e Desenvolvimento
Tipos de Elo: Satisfação, Recurso, Responsabilidade, Representação, Alocado, Agregação
Direcionamento: Backward-from (origem) e Forward-from (destino)
Perspectiva de Informação: Estruturação hierárquica das informações de rastreabilidade

Objetivo¶

O objetivo deste documento é estruturar e gerenciar os requisitos do sistema LigaMagic utilizando o Meta-modelo de Toranzo. Esta abordagem visa garantir que todos os requisitos sejam claramente ligados às suas fontes (elos backward-from) e aos artefatos criados durante o projeto (elos forward-from).

Metodologia¶

Para aplicar o modelo, cada requisito ou artefato rastreável do LigaMagic é documentado em um cartão estruturado. Este cartão detalha o nível de informação, a origem do requisito, os elementos envolvidos e os elos de rastreabilidade, conforme o modelo da Tabela 1. A partir desta versão:

A origem do requisito (fonte de elicitação) é explicitada em campo próprio, preservando a evidência do vínculo.
Os elos Backward-from e Forward-from registram o tipo do relacionamento e sua justificativa, sem listar diretamente os artefatos de destino.

Tabela 1: Modelo de cartão

Item	Descrição
Descrição do requisito	Qual requisito está sendo tratado (RFx, RNFx, etc.)
Categoria	Nível de informação (Ambiental, Organizacional, Gerencial ou Desenvolvimento)
Origem do requisito	Técnica/fonte de elicitação e evidência (ex: ADx, OBSx, ENx)
Elementos	Elementos rastreáveis associados (ex: UCx, CEx, USx, Backlog)
Elos Backward-from (tipo e justificativa)	Tipo do elo e por que se aplica à origem do requisito (ex: Recurso — a fonte fornece a evidência)
Elos Forward-from (tipo e justificativa)	Tipo do elo e por que se aplica à relação com artefatos de desenvolvimento (ex: Representação — modela)

Fonte: Estrutura adaptada do Meta-modelo de Toranzo (Sayão e Leite Rastreabilidade de Requisitos; Milene Serrano e Maurício Serrano Requisitos – Aula 26).

Legenda¶

As tabelas a seguir detalham os identificadores e relacionamentos utilizados neste documento para garantir a correta aplicação do Meta-modelo de Toranzo.

Tabela 2: Níveis de Informação.

Nível de Informação	Descrição
Ambiental	Informações oriundas do contexto no qual a organização está inserida.
Organizacional	Informações pertencentes à organização
Gerencial	Informações que auxiliam a gerência do projeto.
Desenvolvimento	Informações associadas aos diversos artefatos gerados ao longo do processo de desenvolvimento (requisitos, diagramas, etc).

Fonte: (Sayão e Leite. Rastreabilidade de Requisitos); (Milene Serrano e Maurício Serrano. Requisitos – Aula 26).

Tabela 3: Elementos identificadores.

Elemento	Identificador / Descrição
Requisito	RFx, RNFx
Caso de uso	UCx
Cenário	CEx
História de usuário	USx
Técnica de elicitação	OBx, ADx, Ex
NFR Framework	NFRx
Especificação suplementar	ESx

Tabela 4: Tipos de Elo.

Tipo de Elo	Descrição
Backward-from	Indica a origem do requisito, ligando requisitos às suas fontes.
Forward-from	Indica como o requisito contribui para outros elementos, ligando requisitos a artefatos criados.

Fonte: (Sayão e Leite. Rastreabilidade de Requisitos); (Milene Serrano e Maurício Serrano. Requisitos – Aula 26).

Tabela 5: Relacionamento entre Informações.

Relacionamento	Descrição
Satisfação	Classe origem tem dependência de satisfação com a classe destino.
Recurso	Classe origem tem dependência de recurso com a classe destino.
Responsabilidade	Registra a participação, responsabilidade e ação de pessoas sobre artefatos.
Representação	Captura a representação ou modelagem dos requisitos em outras linguagens.
Alocado	Classe origem está relacionada à classe destino, que representa um subsistema.
Agregação	Indica "composição" de elementos.

Fonte: (Sayão e Leite. Rastreabilidade de Requisitos); (Milene Serrano e Maurício Serrano. Requisitos – Aula 26).

Dependências entre Requisitos¶

A rastreabilidade entre requisitos mapeia dependências importantes para o sistema:

Requisito Origem	Requisito Destino	Tipo de Dependência	Justificativa
RF01 (Cadastro)	RF03 (Login)	Recurso	Login depende de dados de cadastro existentes para autenticação
RF02 (Verificação)	RF01 (Cadastro)	Recurso	Verificação precisa da base de usuários cadastrados para detectar duplicações
RF13 (Uso de dados)	RF12 (Dados pessoais)	Recurso	Utilização de dados depende da coleta prévia de informações pessoais
RF17 (Cookies)	RF03 (Login)	Recurso	Personalização via cookies depende do sistema de autenticação
RF23 (Compra)	RF20 (Pesquisa)	Recurso	Processo de compra depende da funcionalidade de pesquisa de cartas
RF24 (Histórico)	RF23 (Compra)	Recurso	Histórico de compras depende de transações realizadas
RF31 (Alerta preço)	RF20 (Pesquisa)	Recurso	Alertas dependem da identificação prévia de cartas via pesquisa

Conteúdo¶

Sistemas Agregados¶

Sistema de Gerenciamento de Usuário¶

Item	Descrição
Descrição	Agregação de requisitos de gerenciamento de usuário
Categoria	Desenvolvimento
Elementos (partes)	RF01 (Cadastro), RF02 (Verificação duplicação), RF03 (Login), RF12 (Dados pessoais), RF15 (Direitos), RF19 (Atualização)
Elos de Agregação (tipo e justificativa)	Agregação — O sistema completo de gerenciamento de usuário é composto pelos requisitos individuais de cadastro, verificação, autenticação, gestão de dados e direitos. Cada parte é essencial para o funcionamento do todo, formando um subsistema coeso.

Sistema de Busca e Interação com Cartas¶

Item	Descrição
Descrição	Agregação de requisitos de busca e interação com cartas
Categoria	Desenvolvimento
Elementos (partes)	RF20 (Pesquisa), RF21.1-21.3 (Filtros), RF27 (Detalhes), RF30 (Informações), RF32 (Busca decks), RF36 (Compartilhar)
Elos de Agregação (tipo e justificativa)	Agregação — O sistema de interação com cartas é decomposto em funcionalidades específicas: pesquisa básica, filtragem avançada, visualização detalhada e compartilhamento. A união dessas partes forma a experiência completa de descoberta e interação com cartas.

Sistema de E-commerce¶

Item	Descrição
Descrição	Agregação de requisitos de comércio eletrônico
Categoria	Desenvolvimento
Elementos (partes)	RF23 (Compra), RF24 (Histórico), RF31 (Alerta preço), RF33 (Preço médio), RF34 (Histórico preços), RF35 (Listas)
Elos de Agregação (tipo e justificativa)	Agregação — O sistema de e-commerce é composto por funcionalidades de transação, acompanhamento de preços, histórico de compras e gestão de listas. Cada componente contribui para a experiência completa de comércio na plataforma.

Requisitos Funcionais¶

RF01 – Cadastro de usuário¶

Item	Descrição
Descrição do requisito	RF01 – Cadastro de usuário
Categoria	Desenvolvimento
Origem do requisito	AD01
Elementos	História de Usuário: US09
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD01) demonstra a necessidade do cadastro como requisito básico de acesso, servindo como fonte de evidência.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário modela o comportamento esperado para o processo de cadastro, descrevendo etapas e validações necessárias. Alocado — Requisito alocado ao subsistema de Gerenciamento de Usuário da aplicação.

Fonte: Angélica, 2025.

RF02 – Deve verificar duplicação de cadastros¶

Item	Descrição
Descrição do requisito	RF02 – Deve verificar duplicação de cadastros
Categoria	Desenvolvimento
Origem do requisito	AD02
Elementos	História de Usuário: US03
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD02) fornece a evidência necessária para a formulação do requisito, caracterizando dependência de recurso. Depende do banco de dados de usuários existentes para verificar duplicações.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem como a verificar de cadastros deve operar. Recurso — Fornece dados validados para o sistema de autenticação (RF03), que consome essas informações para permitir ou negar acessos.

Fonte: Samuel, 2025.

RF03 – Permitir acesso via login e senha¶

Item	Descrição
Descrição do requisito	RF03 – Cadastro de usuário
Categoria	Desenvolvimento
Origem do requisito	AD03
Elementos	História de Usuário: US10
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD03) evidencia que apenas usuários autenticados podem acessar áreas privadas do sistema.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário modela o comportamento esperado para o processo de autenticação, garantindo acesso seguro às funcionalidades privadas do sistema. Alocado — Alocado ao subsistema de Autenticação e Segurança da aplicação.

Fonte: Angélica, 2025.

RF04 – O sistema deve restringir anúncios a produtos e serviços relacionados ao jogo Magic: The Gathering¶

Item	Descrição
Descrição do requisito	RF04 – O sistema deve restringir anúncios a produtos e serviços relacionados ao jogo Magic: The Gathering
Categoria	Desenvolvimento
Origem do requisito	AD04
Elementos	História de Usuário: US15
Elos Backward-from (tipo e justificativa)	A análise de documento (AD04) identificou a necessidade de manter a integridade temática do sistema, limitando os anúncios apenas a produtos e serviços relacionados ao universo de Magic: The Gathering.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem como o sistema deve validar e limitar o conteúdo dos anúncios antes da publicação.

Fonte: Marcelo. 2025.

RF05 – O sistema deve verificar veracidade de dados cadastrados¶

Item	Descrição
Descrição do requisito	RF05 – O sistema deve implementar mecanismos de validação de informações fornecidas pelos usuários.
Categoria	Desenvolvimento
Origem do requisito	AD05
Elementos	História de Usuário: US37
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD05) fornece a evidência necessária para a formulação do requisito, identificando inconsistências nos dados inseridos pelos usuários. Caracteriza-se como dependência de recurso, pois a necessidade foi inferida a partir do comportamento observado no sistema.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem e casos de uso descrevem como o sistema deve validar as informações inseridas, representando o comportamento de verificação de veracidade de dados. Opta-se por Representação, pois o requisito é modelado e não apenas satisfeito.

Fonte: Guilherme. 2025.

RF06 – Inclusão de textos, descrição e fotos nos anúncios¶

Item	Descrição
Descrição do Requisito	RF06 – Deve permitir inclusão de textos, descrição e fotos nos anúncios
Categoria	Desenvolvimento
Origem do Requisito	AD06
Elementos	História de Usuário: US34
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de serviços de upload de imagens, armazenamento de textos e gerenciamento de dados do anúncio para funcionar corretamente. Esses recursos foram identificados na Análise de Documentos (AD06).
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de inclusão de textos, descrição e fotos nos anúncios. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica.

Fonte: Vera. 2025.

RF09 – O sistema deve permitir troca de mensagens privadas¶

Item	Descrição
Descrição do requisito	RF09 – O sistema deve permitir que usuários troquem mensagens privadas de forma segura.
Categoria	Desenvolvimento
Origem do requisito	AD09
Elementos	História de Usuário: US38
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD09) fornece a evidência necessária para a formulação do requisito, identificando a necessidade de comunicação direta e reservada entre usuários. Configura uma dependência de recurso, pois o requisito foi derivado a partir de especificações e funcionalidades identificadas em sistemas semelhantes.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem e diagramas de interação representam o comportamento esperado da troca de mensagens privadas, incluindo a segurança e a privacidade na comunicação. Escolhe-se Representação, pois o requisito é modelado nos diagramas e fluxos de comunicação.

Fonte: Guilherme. 2025.

RF10 – Deve permitir criação de páginas pessoais¶

Item	Descrição
Descrição do requisito	RF10 – Deve permitir criação de páginas pessoais: O sistema deve permitir que cada usuário personalize e mantenha sua página pessoal/profissional
Categoria	Desenvolvimento
Origem do requisito	AD10
Elementos	Cenário: CE06; Caso de Uso: UC05; História de Usuário: US22
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD10) fornece evidência da necessidade de personalização de páginas pessoais/profissionais pelos usuários.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem como a funcionalidade de personalização de perfil deve operar. Prefere-se Representação pois modela o comportamento sem comprovar implementação.

Fonte: Marcelo, 2025.

RF11 – Deve permitir envio e respostas a mensagens no fórum¶

Item	Descrição
Descrição do requisito	RF11 – Deve permitir envio e respostas a mensagens no fórum
Categoria	Desenvolvimento
Origem do requisito	AD11
Elementos	Cenário: CE11; Caso de Uso: UC09; História de Usuário: US01
Elos Backward-from (tipo e justificativa)	Recurso — A fonte documental AD11 sustenta a existência do requisito, logo o requisito depende do recurso informacional. Não é Representação (não traduz o requisito) nem Satisfação (não implementa a solução).
Elos Forward-from (tipo e justificativa)	Representação — Os modelos (cenários, casos de uso e histórias) representam o comportamento de fórum. Preferido a Satisfação, pois ainda não atesta implementação, apenas formaliza o entendimento.

Fonte: Samuel, 2025.

RF12 – Registrar dados pessoais do usuário¶

Item	Descrição
Descrição do requisito	RF12 – Registrar dados pessoais do usuário: O sistema deve permitir o registro de dados como Nome, RG, CPF, Telefone, E-mail, Data de Nascimento e Endereço
Categoria	Desenvolvimento
Origem do requisito	AD12
Elementos	História de Usuário: US21
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD12) fornece evidência da necessidade de coleta de dados pessoais para identificação e gestão de usuários.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o processo de registro de dados pessoais. Opta-se por Representação pois descreve os campos e validações esperadas sem atestar implementação técnica.

Fonte: Thiago, 2025.

RF13 – O sistema deve utilizar cookies para personalização¶

Item	Descrição
Descrição do requisito	RF13 – O sistema deve usar os dados pessoais para identificação, contato, gestão contratual, melhoria de serviços e envio de comunicações.
Categoria	Desenvolvimento
Origem do requisito	AD13
Elementos	História de Usuário: US41
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD13) fornece a evidência necessária para a formulação do requisito, identificando a necessidade de definir claramente as finalidades do uso de dados pessoais conforme princípios da LGPD. Trata-se de uma dependência de recurso, pois a análise dos documentos de design e requisitos funcionais evidencia a necessidade de retenção de preferências e autenticação simplificada.
Elos Forward-from (tipo e justificativa)	Representação — O requisito é representado nos artefatos de modelagem e fluxos de gestão de serviços, descrevendo como os dados pessoais são utilizados de forma controlada e rastreável. Opta-se por Representação, pois o requisito é modelado como parte dos processos de gerenciamento de dados e comunicação.

Fonte: Guilherme. 2025.

RF15 – O sistema deve garantir os direitos dos titulares de dados¶

Item	Descrição
Descrição do requisito	RF15 – O sistema deve permitir que o usuário solicite acesso, correção, exclusão ou anonimização de seus dados pessoais.
Categoria	Desenvolvimento
Origem do requisito	AD15
Elementos	História de Usuário: US39
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD15) fornece a evidência necessária para a formulação do requisito, ao identificar a obrigatoriedade de atender aos direitos dos titulares conforme a LGPD. Trata-se de uma dependência de recurso, pois a origem documental (legislação e políticas de privacidade) sustenta a necessidade do requisito.
Elos Forward-from (tipo e justificativa)	Representação — O requisito é representado nos diagramas de casos de uso e nos fluxos de gerenciamento de dados de usuários, descrevendo as ações de solicitação e tratamento de dados pessoais. Opta-se por Representação, pois o requisito é modelado como parte das funcionalidades de controle de privacidade.

Fonte: Guilherme. 2025.

RF16 – Oferecer canal de contato para solicitações¶

Item	Descrição
Descrição do requisito	RF16 – Oferecer canal de contato para solicitações: O sistema deve disponibilizar canal (e-mail ou link) para o exercício dos direitos do titular
Categoria	Desenvolvimento
Origem do requisito	AD16
Elementos	História de Usuário: US24
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD16) fornece evidência legal (LGPD) da necessidade de canal de contato para exercício de direitos do titular.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa como o canal de contato deve ser disponibilizado. Opta-se por Representação pois formaliza o requisito legal sem atestar implementação.

Fonte: Thiago, 2025.

RF17 – O sistema deve utilizar cookies para personalização¶

Item	Descrição
Descrição do requisito	RF17 – O sistema deve utilizar cookies para facilitar o login e personalizar a experiência de navegação.
Categoria	Desenvolvimento
Origem do requisito	AD17
Elementos	História de Usuário: US40
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD17) fornece a evidência necessária para a formulação do requisito, ao identificar práticas comuns de personalização de experiência de usuário baseadas em cookies. Trata-se de uma dependência de recurso, pois a análise dos documentos de design e requisitos funcionais evidencia a necessidade de retenção de preferências e autenticação simplificada.
Elos Forward-from (tipo e justificativa)	Representação — O requisito é representado nos diagramas de casos de uso e nas especificações de interface, que descrevem como os cookies armazenam preferências e dados de sessão. Escolhe-se Representação, pois o comportamento de personalização é modelado como parte da navegação do sistema.

Fonte: Guilherme. 2025.

RF19 – Solicitar atualização de dados pessoais¶

Item	Descrição
Descrição do requisito	RF19 – Solicitar atualização de dados pessoais
Categoria	Gerenciamento de Usuários
Origem do requisito	AD19
Elementos	Cenário: CE06; História de Usuário: US11
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD19) indica que usuários precisam alterar dados cadastrais para manter suas informações atualizadas, justificando o requisito.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem representam como o requisito será atendido, descrevendo comportamento esperado e validação funcional.

Fonte: Angélica, 2025.

RF20 – Pesquisa de cartas pelo nome¶

Item	Descrição
Descrição do requisito	RF20 – Pesquisa de cartas pelo nome
Categoria	Desenvolvimento
Origem do requisito	OBS01
Elementos	Cenário: CE03; Caso de Uso: UC02; Histórias de Usuário: US04, US08
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS01) provê evidência do contexto de uso e necessidade do usuário.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem como a busca deve operar. Alocado — Requisito alocado ao subsistema de Busca e Filtragem da plataforma web. Recurso — Fornece dados de cartas para o processo de compra (RF23) e alertas de preço (RF31).

Fonte: Samuel, 2025.

RF21.1 – Filtrar cartas por preço¶

Item	Descrição
Descrição do requisito	RF21.1 – Filtrar cartas por preço
Categoria	Desenvolvimento
Origem do requisito	OBS02
Elementos	História de Usuário: US05
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS02) identifica a necessidade real de filtragem por preço.
Elos Forward-from (tipo e justificativa)	Representação — A história descreve a regra de filtragem. Representação é adequada pois comunica a lógica esperada, sem atestar implementação (logo não é Satisfação).

Fonte: Samuel, 2025.

RF21.2 – Filtragem de Cartas por Qualidade/Condição¶

Item	Descrição
Descrição do requisito	RF21.2 – Filtragem de Cartas por Qualidade/Condição
Categoria	Desenvolvimento
Origem do requisito	OBS02
Elementos	Cenário: CE07; Caso de Uso: UC06; História de Usuário: US14
Elos Backward-from (tipo e justificativa)	Recurso — A observação (OBS02) identificou a necessidade de os usuários filtrarem cartas com base em sua qualidade física e condição de conservação, otimizando a experiência de busca.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem a forma como o sistema deve aplicar e exibir os filtros de condição de carta.

Fonte: Marcelo. 2025.

RF23 – Realizar compra de cartas¶

Item	Descrição
Descrição do Requisito	RF23 – Realizar compra de cartas: Deve permitir que o usuário compre cartas cadastradas, incluindo dados pessoais e endereço de entrega
Categoria	Desenvolvimento
Origem do Requisito	OBS04
Elementos	História de Usuário: US31
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de serviços de autenticação do usuário, do banco de dados de produtos e do sistema de pagamento para que a compra seja processada corretamente. Esses elementos são fundamentais para permitir a execução completa da funcionalidade.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de realização de compra de cartas. Alocado — Alocado ao subsistema de E-commerce, especificamente aos módulos de pagamento e gestão de pedidos da plataforma. Recurso — Fornece dados de transações para o histórico de compras (RF24).

Fonte: Vera, 2025.

RF24 – Histórico de compras¶

Item	Descrição
Descrição do requisito	RF24 – Histórico de compras
Categoria	Desenvolvimento
Origem do requisito	OBS05
Elementos	História de Usuário: US12
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS05) evidenciou o padrão de comportamento dos usuários que consultam compras anteriores para acompanhar transações e gastos. Recurso — Depende dos dados de transações gerados pelo sistema de compras (RF23).
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário modela a funcionalidade necessária para exibição e detalhe das compras realizadas, representando o requisito. Alocado — Alocado ao subsistema de Gerenciamento de Usuário para controle de dados pessoais.

Fonte: Angélica, 2025.

RF27 – Visualização de Detalhes da Carta¶

Item	Descrição
Descrição do requisito	RF27 – Visualização de Detalhes da Carta
Categoria	Desenvolvimento
Origem do requisito	OBS08
Elementos	História de Usuário: US16
Elos Backward-from (tipo e justificativa)	Recurso — A observação (OBS08) mostrou que os usuários desejam visualizar informações completas das cartas, justificando a necessidade de uma página ou modal detalhado.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem demonstram o comportamento esperado da interface ao exibir detalhes da carta, como imagem, edição, tipo e raridade.

Fonte: Marcelo. 2025.

RF29 – Permitir que o usuário avalie ou dê feedback sobre vendedores ou decks¶

Item	Descrição
Descrição do requisito	RF29 – Permitir que o usuário avalie ou dê feedback sobre vendedores ou decks
Categoria	Desenvolvimento
Origem do requisito	OBS10
Elementos	Cenário: CE13; Caso de Uso: UC11; História de Usuário: US19
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS10) fornece a evidência da necessidade de avaliação e feedback dos usuários, caracterizando dependência de recurso informacional.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem como o sistema de avaliação deve operar. Opta-se por Representação em vez de Satisfação, pois a modelagem descreve o comportamento esperado da funcionalidade de feedback.

Fonte: Thiago, 2025.

RF30 – Exibição de Informações Detalhadas da Carta¶

Item	Descrição
Descrição do requisito	RF30 – Exibição de Informações Detalhadas da Carta
Categoria	Desenvolvimento
Origem do requisito	OBS11
Elementos	História de Usuário: US17
Elos Backward-from (tipo e justificativa)	Recurso — A observação (OBS11) indicou a importância de apresentar informações detalhadas sobre cada carta, como histórico de versões, preço médio e disponibilidade.
Elos Forward-from (tipo e justificativa)	Representação — Os elementos de modelagem descrevem como o sistema exibe informações aprofundadas da carta selecionada.

Fonte: Marcelo. 2025.

RF31 – Alerta de preço¶

Item	Descrição
Descrição do Requisito	RF31 – Alerta de preço: Deve permitir que o usuário defina um alerta de preço para a carta selecionada
Categoria	Desenvolvimento
Origem do Requisito	OBS12
Elementos	Cenário: CE04 Caso de Uso: UC03 História de Usuário: US36
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de um serviço de monitoramento de preços e de notificações, além de dados de preço das cartas. Esses recursos são necessários para verificar variações e enviar alertas aos usuários.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de configuração de alertas de preço. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica.

Fonte: Vera. 2025.

RF32 – Permitir que o usuário busque decks que utilizam a carta selecionada¶

Item	Descrição
Descrição do requisito	RF32 – Permitir que o usuário busque decks que utilizam a carta selecionada
Categoria	Desenvolvimento
Origem do requisito	OBS13
Elementos	US18
Elos Backward-from (tipo e justificativa)	Recurso — A observação (OBS11) destacou o interesse dos usuários em explorar decks existentes que utilizam uma carta específica, justificando o desenvolvimento da busca relacionada.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem o comportamento da busca e a exibição dos decks correspondentes.

Fonte: Marcelo. 2025.

RF33 – Preço médio por edição¶

Item	Descrição
Descrição do Requisito	RF33 –Preço médio por edição: Deve permitir que o usuário visualize o preço médio da carta em diferentes edições e condições
Categoria	Desenvolvimento
Origem do Requisito	OBS14
Elementos	História de Usuário: US33
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de dados consolidados de preços por edição e condição de carta, obtidos de fontes de mercado ou base interna. Esses dados são essenciais para gerar os cálculos de média e exibir os resultados ao usuário.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de exibição de preços médios por edição. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica.

Fonte: Vera. 2025.

RF34 – Histórico de preços¶

Item	Descrição
Descrição do Requisito	RF34 – Histórico de preços: Deve permitir que o usuário acesse o histórico de preços da carta em formato gráfico
Categoria	Desenvolvimento
Origem do Requisito	OBS15
Elementos	História de Usuário: US32
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de registros históricos de preços armazenados em banco de dados e de um componente gráfico para exibição visual. Esses recursos são necessários para gerar e apresentar a evolução dos valores de forma compreensível.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de visualização do histórico de preços. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica.

Fonte: Vera. 2025.

RF35 – Adicionar a diferentes listas: Permitir que o usuário adicione a carta a diferentes listas¶

Item	Descrição
Descrição do requisito	RF35 – Adicionar a diferentes listas: Permitir que o usuário adicione a carta a diferentes listas (coleção, deck, lista de desejos, carrinho)
Categoria	Desenvolvimento
Origem do requisito	OBS16
Elementos	História de Usuário: US23
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS16) fornece evidência do comportamento dos usuários ao organizar cartas em diferentes contextos (compra, desejo, coleção, deck).
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de organização de cartas em múltiplas listas. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica.

Fonte: Thiago, 2025.

RF36 – Compartilhar carta¶

Item	Descrição
Descrição do requisito	RF36 – Compartilhar carta
Categoria	Desenvolvimento
Origem do requisito	OBS17
Elementos	Cenário: CE12; Caso de Uso: UC10; História de Usuário: US02
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS17) fornece a necessidade de compartilhar por link direto; é insumo e não uma representação/solução.
Elos Forward-from (tipo e justificativa)	Representação — Os modelos capturam como o compartilhamento deve ocorrer. Prefere-se Representação, pois descrevem a interação esperada ao invés de comprovar implementação.

Fonte: Samuel, 2025.

RF37 – Reportar problemas¶

Item	Descrição
Descrição do Requisito	RF37 – Reportar problemas: Deve permitir que o usuário reporte problemas relacionados à carta (erros de informação, anúncios suspeitos, etc.)
Categoria	Desenvolvimento
Origem do Requisito	OBS18
Elementos	Cenário: CE05 Caso de Uso: UC04 História de Usuário: US35
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de um sistema de registro de feedbacks e de comunicação com a equipe administrativa. Esses recursos são essenciais para receber, armazenar e tratar os relatórios enviados pelos usuários.
Elos Forward-from (tipo e justificativa)	Representação — A história de usuário representa o comportamento de envio de reportes de problemas. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica.

Fonte: Vera. 2025.

RF38 – Os usuários devem ser capazes de catalogar e gerenciar sua coleção pessoal de cartas¶

Item	Descrição
Descrição do requisito	RF38 – Os usuários devem ser capazes de catalogar e gerenciar sua coleção pessoal de cartas
Categoria	Desenvolvimento
Origem do requisito	EN01
Elementos	Cenário: CE14; Caso de Uso: UC12; História de Usuário: US20
Elos Backward-from (tipo e justificativa)	Recurso — A Entrevista (EN01) identifica a necessidade dos usuários de gerenciar suas coleções pessoais, fornecendo a base informacional para o requisito.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem descrevem como a funcionalidade de catalogação e gerenciamento de coleção deve operar. Prefere-se Representação, pois formaliza o comportamento esperado sem atestar implementação.

Fonte: Thiago, 2025.

RF39 – Os usuários devem ser capazes de visualizar decks¶

Item	Descrição
Descrição do requisito	RF25 – Os usuários devem ser capazes de visualizar decks publicados, com lista de cartas
Categoria	Desenvolvimento
Origem do requisito	OBS06
Elementos	Cenário: CE08; Caso de Uso: UC07; História de Usuário: US30
Elos Backward-from (tipo e justificativa)	Fonte — A estrutura de níveis de informação (Ambiental, Organizacional, Gerencial, Desenvolvimento) serve como base conceitual para a organização e visualização dos decks, estabelecendo a fundamentação teórica.
Elos Forward-from (tipo e justificativa)	Representação — A visualização de decks materializa a estrutura conceitual em interface prática, permitindo aos usuários navegar e compreender as informações conforme os níveis estabelecidos.

Fonte: Raissa, 2025.

RF40 – Os usuários devem ser capazes de responder no fórum¶

Item	Descrição
Descrição do requisito	RF26 – Os usuários devem ser capazes de visualizar decks publicados, com lista de cartas
Categoria	Desenvolvimento
Origem do requisito	OBS07
Elementos	Cenário: CE11; Caso de Uso: UC09; História de Usuário: US27
Elos Backward-from (tipo e justificativa)	Recurso — A Observação evidencia a necessidade de um espaço colaborativo para discussão e troca de informações entre os usuários do sistema.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem definem como as funcionalidades do fórum devem operar, incluindo criação de tópicos, respostas e moderação, modelando o comportamento esperado.

Fonte: Raissa, 2025.

RF41 – Os usuários devem ser capazes de reportar problemas¶

Item	Descrição
Descrição do requisito	RF37 – Os usuários devem ser capazes de reportar problemas relacionados à carta
Categoria	Desenvolvimento
Origem do requisito	OBS18
Elementos	Cenário: CE05; Caso de Uso: UC04; História de Usuário: US28
Elos Backward-from (tipo e justificativa)	Recurso — A Observação demonstra a necessidade de um canal estruturado para coleta e tratamento de problemas reportados pelos usuários.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem especificam o fluxo de reporte de problemas, incluindo categorização, priorização e acompanhamento, modelando o comportamento esperado do sistema.

Fonte: Raissa, 2025.

RF42 – Os usuários devem ser capazes de permitir controle de cookies¶

Item	Descrição
Descrição do requisito	RF38 – O sistema deve permitir que o usuário configure seu navegador para aceitar ou bloquear cookies
Categoria	Desenvolvimento
Origem do requisito	AD17
Elementos	Cenário: --; Caso de Uso: --; História de Usuário: US25
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD18) comprova a necessidade de conformidade com leis de proteção de dados e privacidade, exigindo controle explícito de cookies.
Elos Forward-from (tipo e justificativa)	Representação — Os artefatos de modelagem definem a interface e fluxos para gerenciamento de cookies, modelando as interações do usuário com as configurações de privacidade.

Fonte: Raissa, 2025.

Requisitos Não Funcionais¶

RNF01 – Deve cumprir legislações aplicáveis¶

Item	Descrição
Descrição do requisito	RNF01 – O sistema deve cumprir a LGPD (Lei nº 13.709/2018), o Código de Defesa do Consumidor e demais legislações aplicáveis.
Categoria	Ambiental
Origem do requisito	AD20
Elementos	NFR Framework: NFR04
Elos Backward-from (tipo e justificativa)	Recurso — A Análise de Documentos (AD20) fornece a evidência necessária para a formulação do requisito, identificando obrigações legais que o sistema deve atender. Configura dependência de recurso, pois a origem documental define explicitamente os requisitos normativos.
Elos Forward-from (tipo e justificativa)	Representação — O requisito é representado nos artefatos de modelagem de segurança, privacidade e processos administrativos, descrevendo como o sistema atenderá às legislações. Alocado — Requisito distribuído entre todos os subsistemas da aplicação para garantir conformidade legal abrangente.

Fonte: Guilherme, 2025.

RNF05 – Exigir consentimento e concordância explícita¶

Item	Descrição
Descrição do requisito	RNF05 – O sistema deve garantir que o usuário declare ciência e concordância com a política ao usar o portal.
Categoria	Legal e Regulatório
Origem do requisito	AD24
Elementos	NFR Framework: NFR06
Elos Backward-from (tipo e justificativa)	Recurso — Analise de documentos(AD24) apontou necessidade de aderência legal (ex.: LGPD), garantindo consentimento informado para uso e tratamento de dados pessoais.
Elos Forward-from (tipo e justificativa)	Representação — Conecta com RF19 e os casos de uso de criação/gerenciamento de usuário, pois o consentimento deve ser explicitamente solicitado antes do processamento dos dados. Também está detalhado no NFR06 do NFR Framework.

Fonte: Angélica, 2025.

RNF07 – Garantir que anúncios incluam informações fiscais corretas¶

Item	Descrição
Descrição do requisito	RNF07 – Garantir que anúncios incluam informações fiscais corretas
Categoria	Desenvolvimento
Origem do requisito	AD26
Elementos	Especificação Suplementar: Con01 NFR Framework: NFR02
Elos Backward-from (tipo e justificativa)	Restrição — A Análise de Documento (AD26) identificou a necessidade de que os anúncios incluam informações fiscais corretas, assegurando conformidade com as normas legais e tributárias aplicáveis.
Elos Forward-from (tipo e justificativa)	Representação — A especificação suplementar e o NFR Framework descrevem os mecanismos de verificação das informações fiscais nos anúncios. Prefere-se Representação, pois formaliza o comportamento esperado sem comprovar a implementação técnica.

Fonte: Marcelo, 2025.

RNF08 – Responsividade: O site deve ser totalmente responsivo¶

Item	Descrição
Descrição do requisito	RNF08 – Responsividade: O site deve ser totalmente responsivo, garantindo boa visualização e funcionalidade em computador, tablet e smartphone
Categoria	Desenvolvimento
Origem do requisito	OBS19
Elementos	Especificação Suplementar: US03; NFR Framework: NFR07
Elos Backward-from (tipo e justificativa)	Recurso — A Observação (OBS19) fornece evidência do comportamento dos usuários em diferentes dispositivos e a necessidade de adaptação responsiva da interface.
Elos Forward-from (tipo e justificativa)	Representação — A especificação suplementar e o NFR Framework descrevem os requisitos de usabilidade relacionados à responsividade. Alocado — Requisito alocado ao subsistema de Interface de Usuário para implementação em todas as telas da aplicação.

Fonte: Thiago, 2025.

RNF09 – Organização visual¶

Item	Descrição
Descrição do requisito	RNF09 – Organização visual: As informações sobre cartas, anúncios e decks devem ser organizadas de forma clara, com boa legibilidade e espaçamento adequado, facilitando a navegação
Categoria	Desenvolvimento
Origem do requisito	OBS20
Elementos	Especificação Suplementar: US01; NFR Framework: NFR05
Elos Backward-from (tipo e justificativa)	Recurso — O requisito depende de diretrizes de design de interface, padrões de espaçamento e organização visual, identificados na Observação (OBS20). Esses recursos garantem clareza e legibilidade durante a navegação do usuário.
Elos Forward-from (tipo e justificativa)	Representação — A especificação suplementar e o NFR Framework representam o comportamento esperado de organização visual das informações. Alocado — Requisito alocado ao subsistema de Interface de Usuário, implementado em todos os módulos visuais da plataforma.

Fonte: Vera, 2025.

RNF14 – Padronização de mensagens¶

Item	Descrição
Descrição do requisito	RNF14 – As mensagens de alerta, erro e confirmação devem aparecer de forma padronizada e visível, para evitar confusões
Categoria	Usabilidade
Origem do requisito	OBS25
Elementos	Especificação Suplementar: US02
Elos Backward-from (tipo e justificativa)	Recurso — OBS25 identificou a necessidade de manter consistência visual e textual nas mensagens para facilitar compreensão do usuário.
Elos Forward-from (tipo e justificativa)	Representação — Esse requisito impacta qualquer funcionalidade que exiba alertas e mensagens ao usuário, como feedbacks de ações em RF19 (atualização de dados) e RF24 (histórico de compras). Também impacta a conformidade da Especificação Suplementar US02, garantindo diretrizes de mensagens unificadas.

Fonte: Raissa, 2025.

Referências¶

1. SAYÃO, Miriam; LEITE, Julio Cesar Sampaio do Prado. Rastreabilidade de Requisitos.

2. SERRANO, Milene; SERRANO, Maurício. Requisitos – Aula 26.

Agradecimentos¶

O Grupo 02 agradece o apoio das ferramentas de Inteligência Artificial Generativa — ChatGPT e Google Gemini — na revisão e padronização de nossos artefatos. Essas tecnologias foram utilizadas para auxiliar na organização do repositório. Todo o conteúdo, incluindo a precisão técnica e as ideias apresentadas, é de responsabilidade dos autores.

Nível de Contribuição dos Integrantes¶

Nome	% de Contribuição
Samuel	14,28
Thiago	14,28
Angélica	14,28
Vera	14,28
Marcelo	14,28
Raissa	14,28
Guilherme	14,28

Histórico de versão¶

Versão	Data	Descrição	Autor(es)	Revisor
1.0	23/10/2025	Criação inicial do documento	Samuel	Vera
1.1	25/10/2025	Adição das seções (Introdução, Objetivo, Metodologia, Legenda)	Samuel, Thiago	Vera
1.1.1	25/10/2025	Adição dos elos (RF02, RF11, RF20, RF21.1, RF36)	Samuel	Thiago
1.1.2	25/10/2025	Adição dos elos (RF29, RF38, RF35, RF16, RF10, RF12, RNF08)	Thiago	Samuel
1.2	26/10/2025	Adição dos elos (RF06, RF23, RF31, RF33, RF34, RF37 E RNF09)	Vera	Angélica
1.3	26/10/2025	Adição dos elos (RF04, RF21.2, RF27, RF30, RF32 E RNF07)	Marcelo	Thiago
1.4	27/10/2025	Adição dos elos (RF01, RF03, RF19, RF24, RNF05 E RNF14)	Angélica	Samuel
1.5	28/10/2025	Adição dos elos 39 a 41	Raissa	Vera
1.6	28/10/2025	Adição dos elos (RF05, RF09, RF13, RF15, RF17 E RNF01)	Guilherme	Vera
1.7	18/11/2025	Implementação das correções	Samuel	Thiago