Backward-From
Introdução
Compreendendo a Rastreabilidade Backward-From
A rastreabilidade backward-from é uma abordagem estratégica no gerenciamento de requisitos de sistemas. Seu objetivo principal é estabelecer relações diretas entre os requisitos e suas origens, proporcionando uma visão clara e organizada do ciclo de vida de desenvolvimento. Isso não só facilita o entendimento sobre como os requisitos foram definidos, mas também garante maior controle sobre mudanças, alinhamento com as necessidades do cliente e aumento da qualidade geral do produto final.
Fundamentação do Método
O método backward-from facilita a identificação das fontes dos requisitos, que podem variar de demandas específicas de clientes a processos organizacionais ou normativas legais. A aplicação prática dessa abordagem é amplamente discutida em materiais como os slides da aula 26 e o livro Requirements Engineering Fundamentals, de Klaus Pohl e Chris Rupp. Esses recursos destacam como conectar requisitos a suas origens ajuda no acompanhamento de mudanças e na validação dos sistemas.
Benefícios da Rastreabilidade Backward-From
A adoção dessa prática é fundamental para os processos de validação e verificação. Ela permite identificar inconsistências ou lacunas nos requisitos desde as etapas iniciais, resultando em menor retrabalho e economia de recursos. Além disso, essa rastreabilidade fortalece a comunicação entre as partes interessadas e assegura que o sistema final esteja alinhado com as expectativas do cliente, promovendo maior confiança no produto.
Metodologia
A metodologia adotada neste projeto fundamenta-se no meta-modelo de rastreabilidade de Toranzo, adaptado para as necessidades do Sympla. O foco está em garantir uma análise estruturada e adaptativa dos requisitos, permitindo uma visão abrangente de suas origens, interdependências e implementações. Essa abordagem visa alinhar os processos organizacionais e de desenvolvimento, promovendo rastreabilidade eficiente e integrada.
Estruturação das Informações Rastreáveis
Os requisitos foram organizados em categorias distintas para garantir clareza e detalhamento, com base em adaptações específicas para o contexto do Sympla:
- Regulatória e Ambiental: Contempla normas, regulamentações e padrões aplicáveis ao sistema, como a LGPD e as obrigações fiscais relacionadas a eventos.
- Organizacional: Agrupa regras de negócio e fluxos operacionais que regem a plataforma, como políticas de cancelamento e gerenciamento de eventos.
- Gerencial: Abrange aspectos relacionados ao planejamento do projeto, incluindo prazos, orçamentos e metas específicas.
- Técnica e de Desenvolvimento: Centraliza os requisitos funcionais e não funcionais, assim como os artefatos técnicos e de implementação.
Adaptação do Meta-Modelo
O meta-modelo de Toranzo foi ajustado para incluir novas conexões que otimizam o rastreamento de requisitos no contexto do Sympla. Entre as principais adaptações, destacam-se:
- Inclusão do Processo de Pós-Rastreabilidade: Essa etapa adicional permite rastrear não apenas os requisitos desde suas origens, mas também a maneira como foram implementados e validados ao longo do ciclo de vida do projeto.
- Adaptação do Elo de Responsabilidade: Esse novo elo vincula diretamente os requisitos e artefatos às equipes ou indivíduos responsáveis por sua concepção, implementação ou validação, promovendo maior transparência.
Definição dos Elos de Rastreabilidade
Foram definidos os seguintes elos para estruturar e organizar os requisitos no projeto:
- Satisfação: Representa a relação entre os requisitos e as funcionalidades que os atendem.
- Recurso: Define as dependências entre requisitos e os recursos necessários para sua implementação.
- Responsabilidade: Relaciona os requisitos e artefatos às equipes ou pessoas responsáveis.
- Representação: Identifica formas alternativas de descrever ou modelar os requisitos.
- Alocação: Vincula os requisitos aos módulos ou componentes do sistema.
- Agregação: Mostra a composição e inter-relações entre os elementos que formam o sistema.
Aplicação Prática do Meta-Modelo
No contexto do Sympla, o meta-modelo foi aplicado para estabelecer uma trilha clara de rastreabilidade, desde a origem dos requisitos até sua validação final. Isso envolveu:
- Mapeamento dos requisitos iniciais com base em suas fontes principais.
- Conexão desses requisitos a artefatos técnicos
- Validação cruzada para assegurar que cada requisito tenha uma correspondência clara com suas funcionalidades implementadas e com os responsáveis associados.
Essa abordagem garantiu uma rastreabilidade bidirecional eficiente, permitindo tanto rastrear os requisitos até suas origens quanto verificar sua implementação no sistema final.
Tabelas de Requisitos Funcionais
Esta seção é dedicada à construção da tabela de rastreamento dos requisitos funcionais, apresentada na Tabela 1:
Legenda:
- RF: Requisito Funcional
- RNF: Requisito Não Funcional
- ENT: Entrevista
- OBS: Observação
- IS: Introspecção
- X: Variável representando o número da entrevista
Tabela 1: Requisitos funcionais elicitados
| Tipo e versão | Descrição | Rastreabilidade | Implementado |
|---|---|---|---|
RF01 /1.4 |
O sistema permite filtrar eventos por Estado e Município. | IS01, OBS01 | Sim |
RF02 /1.4 |
O sistema exibe detalhes importantes do evento, como horário de entrada e local. | 2ENT02, 1ENT03, OBS16, IS02 | Sim |
RF03 /1.4 |
O sistema envia notificações ou lembretes sobre os eventos comprados. | 2ENT03, 1ENT04, QS03, IS18 | Sim |
RF04 /1.4 |
O sistema fornece uma ampla variedade de eventos. | 2ENT04, QS04 | Sim |
RF05 /1.4 |
O aplicativo permite compartilhar o evento por meio das redes sociais. | OBS03 | Sim |
RF06 /1.4 |
Deve ser possível adicionar vários ingressos ao carrinho antes de finalizar a compra. | 1ENT01 | Não |
RF07 /1.4 |
Deve ser possível retirar vários ingressos do carrinho adicionados. | 1ENT02 | Não |
RF08 /1.4 |
O sistema permite cancelamento e transferências de ingressos diretamente na plataforma. | 2ENT07, OBS12, IS08, IS10 | Não |
RF09 /1.4 |
Deve ser possível visualizar a planta do local para a escolha de assentos (quando aplicável). | 2ENT08, OBS08 | Sim |
RF10 /1.4 |
O sistema disponibiliza um histórico completo das compras realizadas pelo usuário. | 2ENT09, OBS21 | Sim |
RF11 /1.4 |
O sistema simplifica filas de compra. | 2ENT10 | Não |
RF12 /1.4 |
O usuário deve permanecer logado por um tempo determinado para não precisar relogar frequentemente. | 1ENT05 | Não |
RF13 /1.4 |
O aplicativo fornece uma funcionalidade de busca eficiente para facilitar a localização dos produtos. | QS01, OBS02, IS09 | Sim |
RF14 /1.4 |
O aplicativo permite a escolha da quantidade de ingressos que o usuário deseja comprar. | OBS04 | Sim |
RF15 /1.4 |
O aplicativo permite selecionar poltronas para pessoas idosas, crianças, obesas ou com deficiência, caso existam. | OBS05 | Sim |
RF16 /1.4 |
O aplicativo permite selecionar as poltronas especiais. | OBS06 | Sim |
RF17 /1.4 |
Na seleção de ingresso, o aplicativo permite adicionar um cupom de desconto. | OBS07 | Sim |
RF18 /1.4 |
O aplicativo permite a doação por parte do usuário para fundações. | OBS09 | Sim |
RF19 /1.4 |
O aplicativo permite a realização da compra dos ingressos. | OBS10, IS04 | Sim |
RF20 /1.4 |
O aplicativo possui uma função para entrar em contato com o suporte. | OBS11, IS17 | Sim |
RF21 /1.4 |
O aplicativo permite ao usuário alterar seus dados. | OBS13 | Sim |
RF22 /1.4 |
O aplicativo possui uma função que auxilia na recuperação da conta do usuário. | OBS14 | Sim |
RF23 /1.4 |
O aplicativo oferece diversas opções de pagamento para a compra de ingressos. | QS02, IS07 | Sim |
RF24 /1.4 |
As opções de pagamento são seguras, utilizando criptografia para proteger os dados financeiros do usuário. | QS05 | Sim |
RF25 /1.4 |
O sistema é acessível por dispositivos móveis, computadores e notebooks, com uma interface responsiva. | QS06 | Sim |
RF26 /1.4 |
O Sympla possibilita filtrar eventos por categorias. | IS03 | Não |
RF27 /1.4 |
O Sympla oferece funcionalidades para cadastro e login de usuários. | IS05 | Sim |
RF28 /1.4 |
O Sympla possibilita a exclusão do cadastro de usuários. | IS06 | Sim |
RF29 /1.4 |
O Sympla oferece a opção imprimir ingressos. | IS19 | Sim |
RF30 /1.4 |
O aplicativo dá sugestões de eventos com base no histórico de buscas do usuário. | IS11 | Não |
RF31 /1.4 |
O usuário é capaz de conectar uma carteira digital. | IS12 | Sim |
RF32 /1.4 |
O usuário é capaz de mudar o idioma do app. | IS13 | Não |
RF33 /1.4 |
O usuário é capaz de entrar na aba de configurações. | IS14 | Não |
RF34 /1.4 |
O sistema apresenta uma aba de acessibilidades. | IS15 | Não |
RF35 /1.4 |
O usuário é capaz de criar preferências de eventos. | IS16 | Não |
RF36 /1.4 |
Deve ser possível cadastrar diferentes métodos de pagamento. | 2ENT11 | Não |
RF37 /1.4 |
O Sympla permite criar, gerenciar e divulgar eventos de forma intuitiva. | IS19 | Não |
RF38 /1.4 |
O Sympla fornece relatórios detalhados de vendas e participação em eventos. | IS20 | Não |
RF39 /1.4 |
O Sympla possibilita a customização dos ingressos, incluindo preços e lotes. | IS21 | Não |
RF40 /1.4 |
O Sympla tem uma área para produtores de eventos. | IS22 | Não |
Fonte: Gabriel Scheidt e Milena Rocha, 2025
Tabelas de requisitos não-funcionais
Este seguimento é destinado para a elaboração da tabela de rastreamento de requisitos não-funcionais, que está sendo demonstrado na tabela 2 a seguir:
Tabela 2 - Requisitos não funcionais
| Tipo e versão | Descrição | Rastreabilidade | Implementado |
|---|---|---|---|
RNF01 /1.4 |
O envio do ingresso deve ser rápido. | 2ENT05 | Não |
RNF02 /1.4 |
O sistema deve ser seguro para uso comercial. | 2ENT06 | Sim |
RNF03 /1.4 |
O login deve ser estável, evitando falhas frequentes que exijam que o usuário se autentique novamente. | 1ENT06 | Não |
RNF04 /1.4 |
O sistema processa compras de ingressos rapidamente, sem atrasos perceptíveis. | 1ENT07 | Sim |
RNF05 /1.4 |
O aplicativo garante um bom desempenho, evitando travamentos ou lentidão durante o uso. | QS07 | Sim |
RNF06 /1.4 |
O sistema exibe preços competitivos de forma clara e transparente. | QS08 | Não |
RNF07 /1.4 |
O sistema aloca os eventos de acordo com a região selecionada para facilitar a busca e a filtragem. | OBS15 | Sim |
RNF08 /1.4 |
Deve adaptar a tela de seleção de poltronas de acordo com as poltronas já escolhidas. | OBS17 | Sim |
RNF09 /1.4 |
Deve apresentar ao usuário o feedback da confirmação de suas ações. | OBS18 | Sim |
RNF10 /1.4 |
Deve apresentar uma página acessível de suporte e de perguntas frequentes com, no máximo, 1 clique. | OBS19 | Sim |
RNF11 /1.4 |
Deve apresentar uma tela com os dados da conta com ao menos uma etapa de segurança. | OBS20, IS16 | Sim |
RNF12 /1.4 |
Deve permitir a filtragem dos eventos com apenas 1 clique. | OBS22 ,2ENT01 | Sim |
RNF13 /1.4 |
O sistema apresenta eventos de forma personalizada, com base na atividade do usuário. | IS19 | Sim |
RNF14 /1.4 |
O usuário deve conseguir acessar informações como data, local e preço do ingresso em, no máximo, 2 cliques durante a busca no Sympla. | IS20 | Sim |
RNF15 /1.4 |
O Sympla deve permitir que o usuário acesse seus ingressos em, no máximo, 3 cliques. | IS21 | Sim |
RNF16 /1.4 |
O Sympla deve oferecer atendimento especial para idosos e pessoas com deficiência durante o processo de compra de ingressos. | IS22 | Não |
RNF17 /1.4 |
O aplicativo mostra os eventos de preferência escolhida pelo usuário ao abrir. | OBS23 | Não |
RNF18 /1.4 |
O Sympla deve incluir um mecanismo de autenticação seguro, permitindo que os usuários façam login com suas credenciais. | IS23 | Sim |
RNF19 /1.4 |
O Sympla deve contar com uma área para que os usuários reportem erros de funcionamento da plataforma. | IS24 | Sim |
Fonte: Gabriel Scheidt e Milena Rocha, 2025
Elos de rastrabilidade
Nesta seção, analisaremos os vínculos associados aos requisitos apresentados nas tabelas 1. Conforme a metodologia adotada, todos os requisitos foram classificados de acordo com o tipo de vínculo correspondente. Vale destacar que todos esses requisitos pertencem exclusivamente à categoria de Desenvolvimento, uma vez que derivam de artefatos produzidos ao longo do processo de elaboração do trabalho, sem conexão direta com aspectos organizacionais ou de gestão do projeto. Com base nesses requisitos, foi elaborada a tabela 3, que consolida e descreve todos os vínculos (elos) identificados.
Tabela 3: Elos de rastreabilidade
Legenda:
- ELO: Elo
- B: Backward From
| ID | Requisitos | Tipo de elo | Descrição do elo |
|---|---|---|---|
| ELOB01 | RF01 | Representação | O requisito RF01, que especifica que o sistema permite filtrar eventos por Estado e Município, tem como fonte a introspecção (IS01) e observação (OBS01). O tipo de elo é de representação, pois reflete os métodos utilizados para modelar os requisitos. |
| ELOB02 | RF02 | Satisfação | O requisito RF02, que exige que o sistema exiba detalhes importantes do evento, tem como fontes entrevistas (2ENT02 e 1ENT03), observação (OBS16) e introspecção (IS02). O tipo de elo é de satisfação, pois conecta o requisito às funcionalidades desenvolvidas para atendê-lo. |
| ELOB03 | RF03 | Recurso | O requisito RF03, que indica que o sistema envia notificações ou lembretes sobre os eventos comprados, está associado às entrevistas (2ENT03 e 1ENT04), questionário (QS03) e introspecção (IS18). O tipo de elo é de recurso, pois representa a dependência dos requisitos em relação aos recursos necessários para sua implementação. |
| ELOB04 | RF04 | Satisfação | O requisito RF04, que estabelece que o sistema fornece uma ampla variedade de eventos, tem como fontes entrevistas (2ENT04) e questionário (QS04). O tipo de elo é de satisfação, conectando os requisitos às funcionalidades que os atendem. |
| ELOB05 | RF05 | Representação | O requisito RF05, que determina que o aplicativo permite compartilhar eventos por meio das redes sociais, tem como fonte a observação (OBS03). O elo de representação reflete como o requisito é modelado e apresentado. |
| ELOB06 | RF06 | Recurso | O requisito RF06, que define que o aplicativo deve permitir adicionar vários ingressos ao carrinho, tem como fonte a entrevista (1ENT01). O tipo de elo é de recurso, pois conecta o requisito aos elementos necessários para sua implementação. |
| ELOB07 | RF07 | Recurso | O requisito RF07, que determina que o usuário pode remover ingressos do carrinho, tem como fonte a entrevista (1ENT02). O tipo de elo é de recurso, representando a dependência para sua implementação. |
| ELOB08 | RF08 | Representação | O requisito RF08, que define que o sistema deve permitir cancelamento e transferências de ingressos, está associado à entrevista (2ENT07), observação (OBS12) e introspecção (IS08 e IS10). O tipo de elo é de representação, pois descreve como os requisitos são capturados e expressos. |
| ELOB09 | RF09 | Satisfação | O requisito RF09, que especifica que o usuário pode visualizar a planta do local para escolha de assentos, está associado à entrevista (2ENT08) e observação (OBS08). O tipo de elo é de satisfação, pois conecta a funcionalidade ao requisito. |
| ELOB10 | RF10 | Satisfação | O requisito RF10, que permite ao sistema disponibilizar um histórico de compras, está associado à entrevista (2ENT09) e observação (OBS21). O elo de satisfação garante que a funcionalidade atende ao requisito. |
| ELOB11 | RF11 | Recurso | O requisito RF11, que simplifica filas de compra, está associado à entrevista (2ENT10). O tipo de elo é de recurso, indicando a dependência para sua implementação. |
| ELOB12 | RF12 | Representação | O requisito RF12, que define que o usuário permanece logado por um período determinado, tem como fonte a entrevista (1ENT05). O tipo de elo é de representação. |
| ELOB13 | RF13 | Satisfação | O requisito RF13, que fornece uma busca eficiente para localizar produtos, tem como fontes o questionário (QS01), observação (OBS02) e introspecção (IS09). O tipo de elo é de satisfação. |
| ELOB14 | RF14 | Representação | O requisito RF14, que permite ao usuário escolher a quantidade de ingressos, está associado à observação (OBS04). O elo de representação reflete como o requisito é expresso. |
| ELOB15 | RF15 | Representação | O requisito RF15, que permite selecionar poltronas especiais para necessidades específicas, está associado à observação (OBS05). O tipo de elo é de representação. |
| ELOB16 | RF16 | Representação | O requisito RF16, que possibilita selecionar poltronas especiais, está associado à observação (OBS06). O elo de representação reflete como o requisito foi modelado. |
| ELOB17 | RF17 | Recurso | O requisito RF17, que permite adicionar cupons de desconto ao selecionar ingressos, tem como fonte a observação (OBS07). O tipo de elo é de recurso. |
| ELOB18 | RF18 | Representação | O requisito RF18, que permite doações para fundações, tem como fonte a observação (OBS09). O elo de representação reflete como o requisito foi capturado. |
| ELOB19 | RF19 | Satisfação | O requisito RF19, que permite realizar compras de ingressos, tem como fontes a observação (OBS10) e introspecção (IS04). O tipo de elo é de satisfação. |
| ELOB20 | RF20 | Recurso | O requisito RF20, que permite entrar em contato com o suporte, está associado à observação (OBS11) e introspecção (IS17). O tipo de elo é de recurso. |
| ELOB21 | RF21 | Representação | O requisito RF21, que permite ao usuário alterar seus dados, tem como fonte a observação (OBS13). O tipo de elo é de representação. |
| ELOB22 | RF22 | Representação | O requisito RF22, que auxilia na recuperação da conta do usuário, está associado à observação (OBS14). O elo de representação reflete como o requisito é modelado. |
| ELOB23 | RF23 | Satisfação | O requisito RF23, que oferece diversas opções de pagamento, está associado ao questionário (QS02) e introspecção (IS07). O elo de satisfação conecta a funcionalidade ao requisito. |
| ELOB24 | RF24 | Recurso | O requisito RF24, que assegura opções de pagamento seguras, tem como fonte o questionário (QS05). O tipo de elo é de recurso. |
| ELOB25 | RF25 | Representação | O requisito RF25, que assegura uma interface responsiva para diferentes dispositivos, está associado ao questionário (QS06). O elo de representação reflete como o requisito foi expressado. |
| ELOB26 | RF26 | Satisfação | O requisito RF26, que permite filtrar eventos por categorias, tem como fonte a introspecção (IS03). O elo de satisfação conecta o requisito à funcionalidade desenvolvida. |
| ELOB27 | RF27 | Satisfação | O requisito RF27, que oferece cadastro e login de usuários, tem como fonte a introspecção (IS05). O tipo de elo é de satisfação. |
| ELOB28 | RF28 | Recurso | O requisito RF28, que permite exclusão de cadastro de usuários, está associado à introspecção (IS06). O tipo de elo é de recurso. |
| ELOB29 | RF29 | Representação | O requisito RF29, que oferece a opção de imprimir ingressos, está associado à introspecção (IS19). O tipo de elo é de representação. |
| ELOB30 | RF30 | Recurso | O requisito RF30, que sugere eventos com base no histórico de buscas, tem como fonte a introspecção (IS11). O tipo de elo é de recurso. |
| ELOB31 | RF31 | Representação | O requisito RF31, que permite conectar uma carteira digital, está associado à introspecção (IS12). O elo de representação reflete como o requisito foi expresso. |
| ELOB32 | RF32 | Representação | O requisito RF32, que permite alterar o idioma do aplicativo, tem como fonte a introspecção (IS13). O tipo de elo é de representação. |
| ELOB33 | RF33 | Representação | O requisito RF33, que permite acessar a aba de configurações, está associado à introspecção (IS14). O elo de representação reflete como o requisito foi modelado. |
| ELOB34 | RF34 | Representação | O requisito RF34, que apresenta uma aba de acessibilidades, tem como fonte a introspecção (IS15). O elo de representação reflete como o requisito foi capturado. |
| ELOB35 | RF35 | Representação | O requisito RF35, que permite criar preferências de eventos, está associado à introspecção (IS16). O tipo de elo é de representação. |
| ELOB36 | RF36 | Recurso | O requisito RF36, que permite cadastrar métodos de pagamento, tem como fonte a entrevista (2ENT11). O tipo de elo é de recurso. |
| ELOB37 | RF37 | Satisfação | O requisito RF37, que permite criar e divulgar eventos de forma intuitiva, tem como fonte a introspecção (IS19). O elo de satisfação conecta o requisito à funcionalidade. |
| ELOB38 | RF38 | Representação | O requisito RF38, que fornece relatórios detalhados de vendas, está associado à introspecção (IS20). O tipo de elo é de representação. |
| ELOB39 | RF39 | Representação | O requisito RF39, que possibilita customização de ingressos, tem como fonte a introspecção (IS21). O tipo de elo é de representação. |
| ELOB40 | RF40 | Representação | O requisito RF40, que define uma área para produtores de eventos, tem como fonte a introspecção (IS22). O tipo de elo é de representação. |
Fonte: Gabriel Scheidt e Milena Rocha, 2025
Elos: Análise e Classificação
Neste trecho, exploramos os vínculos associados aos requisitos listados nas tabelas 2. De acordo com a metodologia adotada, cada requisito será classificado com base em seu tipo de vínculo, considerando os elos de rastreabilidade. É importante observar que todos os requisitos identificados pertencem à categoria de Desenvolvimento, ou seja, surgem como artefatos gerados durante a criação do projeto. Esses requisitos não têm uma conexão direta com os aspectos organizacionais ou gerenciais do projeto.
A análise e classificação dos requisitos resultaram na elaboração da Tabela 3 e 4, que detalha os elos relacionados a cada requisito. Os elos são classificados conforme os tipos: Responsabilidade, Satisfação, Recurso, Representação, Alocado e Agregação, de acordo com a contribuição e o papel que desempenham no sistema e na interação com o usuário.
Tabela 4: Eixos de Rastreabilidade
| ID | Requisito | Tipo de Elo | Descrição do Elo |
|---|---|---|---|
| ELOB01 | RNF01 | Representação | Este requisito especifica que o envio do ingresso deve ser rápido, representando o objetivo de um sistema ágil. |
| ELOB02 | RNF02 | Satisfação | Este requisito assegura que o sistema seja seguro, atendendo à necessidade do usuário de proteção de seus dados. |
| ELOB03 | RNF03 | Responsabilidade | Este requisito atribui ao sistema a responsabilidade de manter estabilidade no login para evitar falhas recorrentes. |
| ELOB04 | RNF04 | Satisfação | Este requisito garante que o processamento de compras seja rápido, satisfazendo a necessidade de eficiência do usuário. |
| ELOB05 | RNF05 | Representação | Este requisito representa a necessidade de um sistema com bom desempenho, evitando travamentos e lentidão. |
| ELOB06 | RNF06 | Agregação | Este requisito agrega clareza e transparência aos preços apresentados, melhorando a experiência do usuário. |
| ELOB07 | RNF07 | Alocado | Este requisito aloca a funcionalidade de organização regional de eventos, facilitando a busca pelo usuário. |
| ELOB08 | RNF08 | Representação | Este requisito representa a necessidade de adaptar a seleção de poltronas às escolhas já realizadas. |
| ELOB09 | RNF09 | Satisfação | Este requisito busca satisfazer o usuário ao fornecer feedback imediato após confirmações de ações. |
| ELOB10 | RNF10 | Responsabilidade | Este requisito define a responsabilidade do sistema em oferecer suporte e perguntas frequentes acessíveis. |
| ELOB11 | RNF11 | Agregação | Este requisito agrega segurança adicional aos dados da conta com etapas extras de autenticação. |
| ELOB12 | RNF12 | Recurso | Este requisito especifica que os eventos devem ser filtrados rapidamente, contribuindo para a usabilidade. |
| ELOB13 | RNF13 | Recurso | Este requisito conecta a personalização dos eventos ao histórico do usuário, destacando a utilidade dessa função. |
| ELOB14 | RNF14 | Satisfação | Este requisito satisfaz a necessidade de acesso rápido a informações como data, local e preço de ingressos. |
| ELOB15 | RNF15 | Satisfação | Este requisito assegura que o usuário possa acessar seus ingressos com facilidade em até 3 cliques. |
| ELOB16 | RNF16 | Responsabilidade | Este requisito define a responsabilidade de atender necessidades especiais de idosos e pessoas com deficiência. |
| ELOB17 | RNF17 | Representação | Este requisito representa o objetivo de mostrar eventos de preferência ao abrir o aplicativo. |
| ELOB18 | RNF18 | Recurso | Este requisito conecta a funcionalidade de autenticação segura à proteção dos dados do usuário. |
| ELOB19 | RNF19 | Responsabilidade | Este requisito atribui ao sistema a responsabilidade de permitir que os usuários reportem problemas da plataforma. |
Fonte: Gabriel Scheidt e Milena Rocha, 2025
Conclusão
A metodologia proposta permite uma rastreabilidade eficiente dos requisitos do Sympla, assegurando que cada funcionalidade seja devidamente associada a seus objetivos iniciais e promovendo uma visão clara e organizada do progresso do projeto. A adaptação do meta-modelo de Toranzo e o foco na categoria de desenvolvimento garantem que as necessidades específicas deste projeto sejam atendidas de forma eficaz.
Referência Bibliografia
Requirements Engineering Fundamentals. Disponível em: https://aprender3.unb.br/pluginfile.php/2972415/mod_resource/content/2/Rastreabilidade.pdf. Acesso em: 16 jan. 2025.
Slides da Aula 26 da Professora Milene Serrano. Disponível em: https://aprender3.unb.br/pluginfile.php/2972560/mod_resource/content/1/Requisitos%20-%20Aula%20026.pdf. Acesso em: 16 jan. 2025.
Histórico de Versões
| Versão | Descrição | Autor | Data | Revisor |
|---|---|---|---|---|
| 1.0 | Inserção do requisitos funcionais e não funcionais | Gabriel Scheidt | 16/01/2025 | Milena Rocha |
| 1.1 | Criação da introdução e referências | Gabriel Scheidt | 16/01/2025 | Milena Rocha |
| 1.2 | Criação da metodologia e elos | Milena Rocha | 16/01/2025 | Gabriel Scheidt |
| 1.3 | Correções | Milena Rocha | 19/01/2025 | Gabriel Scheidt |
| 1.4 | Correções | Milena Rocha | 19/01/2025 | Gabriel Scheidt |