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.
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).
Conteúdo¶
Requisitos Funcionais¶
RF01 – Cadastro de usuário¶
| Item | Descrição |
|---|---|
| Descrição do requisito | RF01 – Cadastro de usuário |
| Categoria | Gerenciamento de Usuários |
| 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. |
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. Não é Representação (não modela) nem Satisfação (não é solução). |
| Elos Forward-from (tipo e justificativa) | Representação — Os artefatos de modelagem descrevem como a verificar de cadastros deve operar. Opta-se por Representação em vez de Satisfação, pois a modelagem descreve o comportamento esperado. |
Fonte: Samuel, 2025.
RF03 – Permitir acesso via login e senha¶
| Item | Descrição |
|---|---|
| Descrição do requisito | RF03 – Cadastro de usuário |
| Categoria | Autenticação e Segurança |
| 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. |
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 origem documental sustenta a obrigatoriedade de uso limitado e transparente dos dados. |
| 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. Não é Satisfação, pois não demonstra implementação/teste; é a formalização do comportamento requerido. |
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 | OBS27 |
| 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. Opta-se por Representação pois descreve a interação esperada sem comprovar implementação técnica. |
Fonte: Vera. 2025.
RF24 – Histórico de compras¶
| Item | Descrição |
|---|---|
| Descrição do requisito | RF24 – Histórico de compras |
| Categoria | Gerenciamento de Usuários |
| 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. |
| 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. |
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: CE04Caso de Uso: UC03Histó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: CE05Caso de Uso: UC04Histó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 | Legal e Regulatório |
| 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. Opta-se por Representação, pois o requisito é modelado e não apenas satisfeito diretamente. |
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. Prefere-se Representação pois formaliza as características esperadas da interface. |
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 | Usabilidade |
| 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. Opta-se por Representação pois descrevem a interação e a disposição esperadas sem comprovar implementação técnica. |
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 |