Backward From
1. Introdução
A rastreabilidade backward-from (para trás, a partir de) é um tipo de rastreabilidade que consiste em ligar os requisitos às suas fontes.
Em termos mais amplos, a rastreabilidade é uma característica de sistemas onde os requisitos são claramente conectados tanto às suas origens quanto aos artefatos que são criados ao longo do ciclo de vida de desenvolvimento do sistema. A criação desses artefatos é orientada pela própria baseline de requisitos. É fundamental para o gerenciamento eficaz dos requisitos, pois, sem ela, os requisitos não podem ser efetivamente gerenciados.
A rastreabilidade backward-from se alinha com o conceito de pré-rastreabilidade, que também envolve a ligação de requisitos às suas fontes.
2. Objetivos
Analisar o processo de rastreabilidade backward-from, focando em como os requisitos são sistematicamente vinculados às suas fontes. A finalidade é demonstrar a importância de compreender a origem e a justificativa de cada requisito para o gerênciamento e o alinhamento do projeto com os objetivos de negócio.
3. Metodologia
A metodologia de rastreabilidade backward-from se concentra em conectar sistematicamente os requisitos às suas origens. O processo é estruturado em três fases principais:
Definição do Modelo: Esta fase inicial estabelece as regras do rastreamento. Envolve identificar as entidades a serem rastreadas (requisitos e suas fontes, como documentos ou stakeholders) e selecionar as ferramentas de suporte, como Matrizes de Rastreabilidade, RichPicture.
Execução do Rastreamento:
Nesta fase, os elos entre os requisitos e suas fontes são registrados de forma explícita. Isso é feito preenchendo a matriz de rastreabilidade para documentar a origem de cada requisito e sua justificativa.
Utilização e Manutenção: A informação de rastreabilidade é usada para consultar a origem dos requisitos, apoiar a análise de impacto de mudanças e resolver conflitos ao identificar as fontes dos requisitos. Os elos devem ser mantidos e atualizados caso os documentos-fonte mudem.
Info
Foi usada a versão 2.0 dos Requisitos Elicitados
4. Cronograma
O cronograma seguido pela equipe se encontra na tabela 1.
Tabela 1: Cronograma de elaboração e validação do artefato
| Nome | Data | Hora | Função |
|---|---|---|---|
| Laryssa Felix | 07/05/2025 | 22:00 | Conteúdo da página |
| Caio Duarte, Gabriel Pinto, João Félix, Laryssa Felix, Letícia Monteiro, Ludmila Nunes e Mayara Marques | 08/06/2025 | 10:30 | Elaboradores da tabela de Backward From - Requisitos Funcionais |
| Ludmila Nunes | 08/06/2025 | 10:30 | Elaboradora da tabela de Backward From - Requisitos Não Funcionais |
| Caio Duarte | 22/06/2025 | 10:00 | Conserta rastreabilidade das tabelas |
Fonte: Caio Duarte, Gabriel Pinto, João Félix, Laryssa Felix, Letícia Monteiro, Ludmila Nunes e Mayara Marques, 2025.
5. Técnicas de Elicitação
Tabela 2: Técnicas de Elicitação
| Sigla | Técnica de Elicitação | Descrição do Requisito | |
|---|---|---|---|
| RFA* | Análise de Interface | Requisito Funcional de Análise de Interface. | |
| RFB* | Brainstorm | Requisito Funcional de Brainstorming | |
| RNFB* | Brainstorm | Requisito Não Funcional de Brainstorming | |
| RFI* | Introspecção | Requisito Funcional de Introspecção | |
| RFQ* | Questinário | Requisito Funcional de Questionário | |
| RFE* | Entrevista | Requisito Funcional de Entrevista |
Fonte: Laryssa Felix, 2025.
Info
* representa o ID correspondente.
6. Modelagem
Tabela 3: Modelagem
| Sigla | Técnica de Modelagem |
|---|---|
| US* | Histórias de Usuário (User story) |
| - | NFR Framework |
| - | Especificação Suplementar |
Fonte: Laryssa Felix, 2025.
7. Modelo
O modelo a ser seguido para realização do Backward From está representado na tabela 4 abaixo.
Tabela 4: Modelo de Tabela Backward From
| ID | Nome | Tema | Documento Fonte | Técnica de Elicitação | Modelagem |
|---|---|---|---|---|---|
| Identificador único do requisito, geralmente alfanumérico (ex: RFB01) | Nome resumido do requisito, que descreve de forma breve sua funcionalidade ou propósito. | Categoria ou área do sistema à qual o requisito pertence (ex: gráfico, dados). elicitado | Documento ou material de onde o requisito foi extraído | Técnica usada para obter o requisito (ex: Entrevista, Questionário) | Representação gráfica ou textual usada para descrever o requisito (ex: Especificação Suplementar, História de usuário). |
Fonte: Laryssa Felix, 2025.
8. Tabela - Requisitos Funcionais
A Tabela 6 a seguir apresenta o Backward From dos Requisitos Funcionais.
Tabela 5: Backward From RF
| ID | Descrição | Fonte | Implementado |
|---|---|---|---|
| RF01 | O sistema deve possuir notícias atualizadas sobre dados demográficos/socioeconômicos do Brasil, de seus estados e municípios. | RFA1 | Sim |
| RF02 | Sistema deve possuir uma funcionalidade de busca, que independe da tela em que o usuário se encontra. | RFA2 | Sim |
| RF03 | Se houver algum dado/indicador atrelado à notícia lida, esse indicador deve estar presente no topo da página da notícia. | RFA3 | Sim |
| RF04 | A notícia deve estar na aba de notícias do aplicativo. | RFA4 | Sim |
| RF05 | O aplicativo deve possuir uma navbar inferior que permita que o usuário navegue pelas diversas funcionalidades principais da aplicação. | RFA5 | Sim |
| RF06 | Sistema deve possuir a aba de indicadores, com principais dados do IBGE, prévia de gráfico e valor com coloração simbólica (verde/vermelha). | RFA6, RFB22 | Sim |
| RF07 | Ao clicar no dado, deve aparecer gráfico mais completo com evolução temporal do indicador. | RFA7 | Sim |
| RF08-A | A interface do sistema deve exibir, na tela do dado, as notícias que possuam relação com o indicador correspondente. | RFA8 | Sim |
| RF09 | Ao lado do nome do indicador, deve aparecer a definição daquele indicador. | RFA9, RFB3 | Sim |
| RF10 | Uma aba de calendário deve estar presente, com eventos/pesquisas principais do IBGE. | RFA10 | Sim |
| RF11-A | Cada dado exibido na aba “Síntese” do aplicativo deve apresentar, de forma visível e padronizada, a fonte oficial de onde foi extraído. | RFA12 | Sim |
| RF12-A | O sistema deve conter uma aba de "Extras", reunindo funcionalidades complementares ao uso principal do aplicativo. Essa aba deve incluir opções como: configurações do app, gerenciamento de login e conta, canais de atendimento ao usuário, convite para amigos, envio de feedback, além de outros recursos informativos ou de suporte que venham a ser disponibilizados. | RFA13 | Sim |
| RF13-A | O sistema deve oferecer uma opção de controle de tipos de notificações, permitindo que o usuário ative ou desative diferentes tipos de alertas de acordo com sua preferência. As notificações configuráveis podem incluir notificações sobre Notícias, Indicadores, Agenda, etc. | RFA14 | Sim |
| RF14 | O sistema deve notificar o usuário sobre novas notícias. | RFA15 | Sim |
| RF15-A | O sistema deve oferecer uma opção de avaliação do aplicativo acessível ao usuário. | RFA16 | Sim |
| RF15-B | A avaliação deve permitir a coleta voluntária do perfil do usuário, incluindo dados como faixa etária, localização e frequência de uso. | RFA16 | Sim |
| RF15-C | A avaliação deve incluir perguntas sobre o nível de satisfação com o aplicativo, considerando critérios como facilidade de uso, confiabilidade e design. | RFA16 | Sim |
| RF15-D | O sistema deve registrar as funcionalidades mais utilizadas pelo usuário, a fim de apoiar a análise de uso do app. | RFA16 | Sim |
| RF15-E | Deve haver um campo para o usuário enviar sugestões de melhoria, de forma livre e opcional. | RFA16 | Sim |
| RF16-A | O sistema deve disponibilizar uma funcionalidade que permita ao usuário compartilhar o aplicativo com outras pessoas, por meio de redes sociais, e-mail ou aplicativos de mensagem. | RFA17 | Sim |
| RF17-A | O sistema deve oferecer uma opção de suporte ao usuário, com acesso direto aos canais oficiais de atendimento do IBGE. Essa opção deve incluir redirecionamento para o site institucional, onde o usuário poderá acessar serviços como chat, telefone, e-mail e perguntas frequentes (FAQ), conforme disponibilizado pelo IBGE. | RFA18, RFE05 | Parcialmente |
| RF18 | As redes sociais do IBGE devem ser linkadas. | RFA19 | Sim |
| RF19 | As notícias devem ser compartilháveis. | RFA20 | Sim |
| RF20-A | O sistema deve destacar, no calendário, os dias que possuem eventos ou pesquisas agendadas utilizando uma cor diferenciada em relação aos demais dias. | RFA21 | Sim |
| RF21 | O calendário deve permitir visualização de meses passados e futuros em relação ao mês atual. | RFA22 | Sim |
| RF22 | Na aba “síntese”, dados como gentílico, área territorial, população, renda, orçamento, IDH, matrículas, salário médio, PIB per capita e mortalidade infantil devem estar disponíveis por estado e município. | RFA23, RFI3 | Sim |
| RF23-A | Filtros por estado e município devem estar disponíveis na aba “Síntese”. | RFA24, RFB9 | Sim |
| RF24 | Jogos educativos sobre geografia, demografia e temas sociais. | RFB1 | Não |
| RF25-A | O sistema deve ser capaz de baixar automaticamente, quando estiver conectado à internet, as informações necessárias para o funcionamento do modo offline. Esses dados devem ser armazenados localmente no dispositivo e exibidos ao usuário mesmo quando não houver conexão, garantindo acesso contínuo a conteúdos como indicadores, notícias e gráficos previamente carregados. | RFB2 | Não |
| RF26 | Central de Ajuda dentro do app, com informações sobre o uso do aplicativo | RFB6 | Não |
| RF27 | Notificações para notícias relevantes e atualizações dos indicadores favoritos. | RFB7 | Não |
| RF28 | O usuário pode favoritar indicadores e visualizar as últimas atualizações. | RFB8 | Não |
| RF29 | Comparativo de indicadores por região. | RFB10 | Não |
| RF30-A | Possibilidade de responder ao censo diretamente pelo app. | RFB11, RFB13, RFB14, RFQ04 | Não |
| RF31-A | Possibilidade de responder a questionários relacionados ao censo diretamente pelo aplicativo. | RFB11, RFB12 | Não |
| RF32-A | Possibilidade de realizar e preencher outros questionários disponibilizados pelo IBGE diretamente no aplicativo. | RFB12 | Não |
| RF33 | Acesso a dados de diferentes fontes como o IBGE, através do app. | RFB16 | Não |
| RF34 | Mapas interativos, com visualização de dados geográficos e demográficos. | RFB17, RFB19 | Não |
| RF35-A | Possibilidade de filtro por tipo de dado na aba "Indicadores" | RFB18 | Não |
| RF36 | Possibilidade de exportar gráficos e resumos em formatos como PDF. | RFB20 | Não |
| RF37 | Computar informações de dados e gerar relatórios para exportação. | RFB21 | Não |
| RF38-A | O sistema deve disponibilizar, de forma acessível no aplicativo, demais indicadores que atualmente estão disponíveis apenas no site do IBGE. | RFI1 | Não |
| RF39 | O sistema deve filtrar notícias por região e/ou tempo. | RFI2 | Não |
| RF41-A | O sistema deve integrar conteúdos produzidos em outras plataformas, como YouTube, TikTok e Instagram, em uma aba dedicada. | RFI4 | Não |
| RF42 | O sistema deve analisar os conteúdos acessados pelo usuário para recomendar conteúdos similares. | RFI5 | Não |
| RF43 | O sistema deve permitir a comparação dos censos realizados em diferentes anos. | RFI6 | Não |
| RF44 | O sistema deve exibir uma confirmação sobre a identidade do recenseador. | RFI7 | Não |
| RF45-A | O sistema deve realizar previsões sobre tendências futuras e indicar políticas públicas, com base nos dados disponibilizados pela plataforma em uma aba dedicada. | RFI8, RFI10 | Não |
| RF46-A | O sistema deve informar, de forma acessível ao usuário, os principais fatores que influenciam a variação de cada indicador apresentado no aplicativo, na especificação do indiciador. | RFI9 | Não |
| RF48 | O sistema deve comparar os locais com maior e menor taxa de resposta ao censo. | RFI11 | Não |
| RF49-A | O sistema deve permitir o compartilhamento de métricas e dados exibidos no aplicativo, garantindo que a fonte oficial do IBGE esteja sempre atribuída ao conteúdo compartilhado. | RFQ01, RFE04 | Não |
| RF51 | Opção de modo noturno. | RFB4, RFE10, RFQ06 | Não |
| RF52 | Opção de mudança de idiomas (Português, Inglês, Espanhol) | RFQ07 | Não |
| RF53 | Opção de alterar o tamanho da fonte (com botão) | RFB5, RFE11, RFQ08 | Não |
| RF54 | Opção de alto contraste do aplicativo (com botão) | RFB5, RFE11, RFQ09 | Não |
| RF56 | O sistema deve disponibilizar explicações simplificadas sobre os termos técnicos. | RFE02 | Não |
| RF57 | O sistema deve integrar-se com a conta Gov.br. | RFB23, RFE03 | Não |
| RF60 | O sistema deve possuir uma FAQ com respostas às dúvidas mais comuns. | RFE06 | Não |
| RF62 | O sistema deve permitir acesso às publicações completas de cada pesquisa com a metodologia detalhada. | RFE08 | Não |
Fonte: Caio Duarte, Gabriel Pinto, João Félix, Laryssa Felix, Letícia Monteiro, Ludmila Nunes e Mayara Marques, 2025.
9. Tabela - Requisitos Requisitos não Funcionais
A Tabela 6 a seguir apresenta o Backward From dos Requisitos Não Funcionais.
Tabela 6: Backward From RNF
| ID | Descrição | Fonte | Implementado |
|---|---|---|---|
| RNF01-A | O sistema deve manter consistência visual em todas as telas, adotando padrões unificados de cores, fontes, botões e elementos da interface. | RNF01, RNF75 | Sim |
| RNF02-A | Todas as ações do usuário devem gerar feedback visual e/ou sonoro imediato, como cliques, carregamentos ou envios de formulário. | RNF02, RNF73 | Não |
| RNF03 | O sistema deve permitir a alteração do tamanho da fonte em toda a interface. | RNF03 | Não |
| RNF04 | O sistema deve oferecer a opção de ativar o modo noturno, alterando o esquema de cores para tons escuros. | RNF04 | Não |
| RNF05-A | O sistema deve ser suficientemente intuitivo para que um novo usuário consiga concluir tarefas principais em até 5 minutos, sem depender de ajuda externa. | RNF05 | Sim |
| RNF06-A | A interface do sistema deve ser responsiva, adaptando-se automaticamente a diferentes tamanhos, resoluções e orientações de tela. | RNF06, RNF39, RNF77 | Não |
| RNF07 | O sistema deve informar o usuário, em tempo real, sobre o andamento de processos como carregamento de dados, envio de formulários ou sincronização, por meio de barras de progresso, ícones animados ou mensagens de status. | RNF07 | Não |
| RNF08 | O usuário deve poder desfazer ou refazer ações como desfavoritar indicadores, redefinir filtros ou cancelar comandos, evitando que erros exijam reinício completo da interação. | RNF08 | Parcialmente |
| RNF09-A | O sistema deve alertar o usuário antes de ações críticas, validar os dados inseridos e exibir mensagens de erro claras, sem jargões técnicos. | RNF09, RNF14 | Não |
| RNF10 | O sistema deve apresentar tempo médio entre falhas (MTBF - Mean Time Between Failures) superior a 100 horas de uso contínuo. | RNF10 | Não |
| RNF11-A | O aplicativo deve recuperar automaticamente sessões interrompidas e preservar a integridade dos dados mesmo em encerramentos inesperados. | RNF11, RNF13 | Não |
| RNF12 | Em caso de falha, o sistema deve registrar o erro localmente e sincronizar com o servidor assim que houver conexão, para fins de diagnóstico e correção. | RNF12 | Não |
| RNF15 | A comunicação entre o aplicativo e os servidores do IBGE deve utilizar protocolos seguros (ex: HTTPS), garantindo a confiabilidade na transferência de dados. | RNF15 | Não |
| RNF16 | O aplicativo deve passar por testes de estresse e de carga para garantir seu funcionamento estável mesmo com picos de acesso simultâneo. | RNF16 | Não |
| RNF17 | O sistema deve garantir interoperabilidade com diferentes versões dos principais sistemas operacionais móveis (Android e iOS), mantendo a estabilidade entre atualizações. | RNF17 | Não |
| RNF18 | O sistema deve apresentar tempo de resposta inferior a 2 segundos para carregamento de telas principais, como visualização de notícias, dados e gráficos. | RNF18 | Não |
| RNF19-A | O aplicativo não deve exceder 40% de uso da CPU nem 250 MB de RAM durante operações intensas, assegurando bom desempenho em dispositivos intermediários. | RNF19, RNF20 | Sim |
| RNF21 | O aplicativo deve estar disponível para acesso 99,5% do tempo ao longo do mês, considerando atualizações, falhas e manutenções. | RNF21 | Sim |
| RNF22 | O sistema deve suportar pelo menos 5.000 acessos simultâneos sem degradação perceptível de desempenho. | RNF22 | - |
| RNF23 | O tempo de sincronização de dados com o servidor não deve ultrapassar 5 segundos em redes 4G ou superiores. | RNF23 | Sim |
| RNF24-A | O aplicativo deve ter transições de até 1 segundo entre seções e tempo de inicialização inferior a 3 segundos em dispositivos de entrada compatíveis. | RNF24, RNF49 | Sim |
| RNF25 | O sistema deve realizar compressão de dados para reduzir o tempo de carregamento de conteúdo, principalmente em conexões móveis com baixa velocidade. | RNF25 | Não |
| RNF26 | O desempenho do aplicativo deve ser validado em pelo menos três modelos diferentes de smartphones (baixo, médio e alto desempenho), garantindo funcionalidade mínima em cada um deles. | RNF26 | Não |
| RNF27-A | O sistema deve estar totalmente em conformidade com a LGPD (Lei nº 13.709/2018), garantindo tratamento legal, seguro e transparente de dados pessoais. | RNF27, RNF72 | Sim |
| RNF28-A | Todos os dados pessoais devem ser criptografados em trânsito (TLS 1.2+) e em repouso (AES-256 ou superior). | RNF28, RNF29 | Não |
| RNF30-A | O sistema deve exibir termos de uso e política de privacidade claros antes da coleta de dados, acessíveis na tela inicial e no menu de configurações. | RNF30, RNF57, RNF65 | Não |
| RNF31-A | O sistema deve obter consentimento explícito para uso de dados pessoais e permitir sua correção, exclusão ou recusa de coleta anônima. | RNF31, RNF32, RNF69 | Não |
| RNF33-A | O sistema deve registrar e proteger logs de autenticação e envio de dados, com retenção mínima de 5 anos e acesso restrito por perfil. | RNF33, RNF34, RNF35, RNF36 | Não |
| RNF37 | O sistema deve realizar backups automáticos dos dados críticos diariamente, com retenção mínima de 30 dias e possibilidade de restauração em até 24 horas. | RNF37 | Não |
| RNF38-A | O design visual deve seguir a identidade institucional do IBGE, com uso oficial das cores e logotipo conforme diretrizes. | RNF38, RNF67 | Sim |
| RNF40-A | O design do sistema deve priorizar simplicidade, clareza e fluidez, facilitando a navegação e interpretação de dados com gráficos e elementos visuais intuitivos. | RNF40, RNF41, RNF42 | Sim |
| RNF43-A | O sistema deve ter arquitetura modular e design escalável para futura adição de novos dados, filtros e relatórios. | RNF43, RNF50 | Sim |
| RNF44 | O aplicativo deve estar apto a funcionar de forma offline para consulta de dados previamente sincronizados, com atualização automática quando a conexão for restabelecida. | RNF44 | Não |
| RNF45-A | O aplicativo deve ser desenvolvido com tecnologias e frameworks compatíveis com Android e iOS, adaptando-se a diversos tamanhos de tela. | RNF45, RNF48 | Sim |
| RNF46-A | O código-fonte deve seguir boas práticas, com versionamento, documentação e uso legal de bibliotecas licenciadas. | RNF46, RNF64 | Sim |
| RNF47 | O sistema deve ser compatível com bibliotecas gráficas modernas para renderização de gráficos estatísticos. | RNF47 | Não |
| RNF51-A | O aplicativo deve conter uma seção de ajuda com FAQs, tutoriais e instruções, redigidas em linguagem simples e acessível em diferentes dispositivos. | RNF51, RNF52, RNF53, RNF54, RNF55, RNF56 | Não |
| RNF58-A | Todos os dados exibidos devem respeitar as licenças de uso e conter as devidas citações e fontes do IBGE. | RNF58, RNF63 | Sim |
| RNF59-A | O software e componentes de terceiros devem ser licenciados adequadamente, preferencialmente sob licenças abertas compatíveis com uso governamental. | RNF59, RNF60,RNF76 | Sim |
| RNF61 | O uso do aplicativo será gratuito e restrito apenas a fins informativos e educacionais, conforme normas institucionais. | RNF61 | Sim |
| RNF62 | O sistema deve respeitar as leis brasileiras vigentes relacionadas à proteção de dados, propriedade intelectual, acessibilidade digital e direitos do consumidor. | RNF62 | Sim |
| RNF66-A | O sistema deve atender às diretrizes nacionais e internacionais de acessibilidade, incluindo compatibilidade com leitores de tela e o Modelo de Acessibilidade de Governo Eletrônico (eMAG), garantindo uso por pessoas com deficiência. | RNF66, RNF70, RNF71, RNF83 | - |
| RNF68 | O aplicativo deve ser registrado junto ao órgão responsável, quando aplicável, garantindo proteção contra uso indevido ou cópia não autorizada. | RNF68 | - |
| RNF73 | Padrão internacional para gestão da segurança da informação, recomendável para proteger dados sensíveis do sistema. | RNF73 | - |
| RNF74 | Norma brasileira que trata de ergonomia na interação humano-computador, aplicável à interface do sistema. | RNF74 | - |
| RNF78-A | Os elementos de navegação devem ser intuitivos, com rótulos claros e acessíveis em até dois toques, utilizando linguagem adequada ao público geral. | RNF78, RNF81 | Sim |
| RNF79 | Todas as telas devem possuir contraste mínimo de 4.5:1 entre texto e plano de fundo, conforme as diretrizes WCAG 2.1 de acessibilidade digital. | RNF79 | - |
| RNF82 | Os formulários devem apresentar mensagens de erro específicas e orientativas, posicionadas próximas aos campos com problemas. | RNF82 | Não |
| RNF84 | Os gráficos e mapas exibidos devem possuir alternativas textuais ou descrições acessíveis para garantir entendimento a todos os usuários. | RNF84 | - |
Fonte: Caio Duarte e Ludmila Nunes, 2025.
10. Histórico de Versões
Tabela 10: Histórico de versões
| Versão | Descrição | Autor | Data | Revisor |
|---|---|---|---|---|
| 1.0 | Criação de documento | Laryssa Felix | 05/06/2025 | Gabriel Pinto |
| 2.0 | Conteúdo do Documento | Laryssa Felix | 07/06/2025 | Ludmila Nunes |
| 2.1 | Tabela de Requisitos Funcionais | Caio Duarte, Gabriel Pinto, João Félix, Laryssa Felix, Letícia Monteiro, Ludmila Nunes e Mayara Marques | 08/06/2025 | Ludmila Nunes |
| 2.2 | Tabela de Requisitos Não Funcionais | Ludmila Nunes | 08/06/2025 | Laryssa Felix |
| 3.0 | Ajustes e correções | Laryssa Felix | 08/06/2025 | Ludmila Nunes |
| 3.1 | Retira coluna de modelagem das tabelas | Caio Duarte | 22/06/2025 | Mayara Marques |
Fonte: Caio Duarte, Gabriel Pinto, João Félix, Laryssa Felix, Letícia Monteiro, Ludmila Nunes e Mayara Marques, 2025.