NFR Framework

Introdução

No contexto do desenvolvimento de sistemas de software, os Requisitos Não-Funcionais (RNFs) desempenham um papel essencial ao definir qualidades e restrições que afetam diretamente a experiência do usuário, a segurança, o desempenho e a conformidade legal dos sistemas. Dentre esses requisitos, destaca-se a necessidade de que os dados sejam tratados em conformidade com legislações específicas de proteção de dados, como etapa indispensável antes da operação de qualquer sistema.

Com o objetivo de representar e analisar de maneira estruturada esses requisitos, este trabalho adota o NFR Framework, uma abordagem proposta por Chung et al. (2000). Esse framework permite a modelagem dos RNFs por meio de softgoals, objetivos que não possuem critérios de satisfação precisos, mas que são fundamentais para a qualidade do produto. A representação gráfica dos softgoals é feita através de um grafo SIG (Softgoal Interdependency Graph), que explicita suas interdependências, influências e possíveis conflitos.

O presente estudo concentra-se no tratamento de Requisitos Não-Funcionais de Produto do aplicativo FGTS, utilizando a notação do NFR Framework para expressar os RNFs contidos no catálogo NFR4ES. A aplicação desse framework visa apoiar a tomada de decisões no processo de desenvolvimento e evolução do app FGTS, tornando-o mais robusto, seguro e alinhado tanto às necessidades dos usuários quanto ao contexto legal vigente, especialmente no que se refere à proteção de dados e à confiabilidade do sistema.

SIG - Softgoal Interdependency Graph

O NFR Framework funciona por meio da construção e análise de um grafo chamado Softgoal Interdependency Graph (SIG), que representa graficamente os Requisitos Não-Funcionais (softgoals), suas interdependências, alternativas e justificativas. Esse grafo registra as decisões de desenvolvimento e permite avaliar se os requisitos de alto nível foram atendidos.

Tipos de SIG

O SIG é dividido em três tipos principais:

Softgoals NFR: representam alternativas técnicas e soluções práticas (como processos, restrições ou estruturas) para atender aos softgoals NFR.
Softgoals de Operacionalização: representa os softgoals e suas interdependências, permitindo identificar conflitos, sinergias e decisões de projeto justificáveis.
Softgoals de Afirmação: trazem justificativas baseadas em características do domínio (como prioridades e carga de trabalho), apoiando decisões, revisões e a rastreabilidade do sistema.

Figura 1: Tipos de Softgoal

Fonte: SILVA, 2019

Tipos e Interdependências de Softgoals no NFR Framework

O NFR Framework utiliza três tipos de softgoals, representados por diferentes estilos de nuvens:
Softgoals NFR: nuvens claras
Softgoals de Operacionalização: nuvens com linhas grossas
Softgoals de Afirmação: nuvens com linhas tracejadas
Cada softgoal NFR possui um tipo (ex: Confiabilidade) e um tópico (ex: Infusor), que indicam a parte específica do sistema a que se refere.
As interdependências entre os softgoals são classificadas em:
Refinamentos (top-down), onde um softgoal pai gera filhos mais específicos, podendo ser:
- Decomposição de Softgoal NFR: divide um requisito não-funcional em outros mais específicos
- Decomposição de Operacionalização: refina soluções implementáveis
- Decomposição de Afirmação: detalha justificativas de projeto
- Priorização: refina um softgoal destacando sua prioridade
Essa estrutura ajuda a representar, refinar e justificar requisitos não-funcionais no desenvolvimento de sistemas.

Figura 2: Tipos e Interdependências de Softgoals no NFR Framework

Fonte: SILVA, 2019

Contribuições e Tipos no NFR Framework

Durante o refinamento dos softgoals, um softgoal descendente pode contribuir positiva ou negativamente, de forma total ou parcial, para a satisfação do softgoal ascendente.
"Satisfação de softgoal" indica que o requisito não-funcional deve ser atendido dentro de limites aceitáveis, não necessariamente de forma absoluta.
AND: todos os descendentes precisam ser satisfeitos para o ascendente ser satisfeito.
OR: algum descendente satisfeito basta para o ascendente ser satisfeito.
MAKE (++): contribuição altamente positiva; se o descendente for satisfeito, o ascendente será satisfeito.
BREAK (--): contribuição altamente negativa; se o descendente for satisfeito, o ascendente será negado.
HELP (+): contribuição parcialmente positiva; satisfação parcial do descendente leva à satisfação parcial do ascendente.
HURT (-): contribuição parcialmente negativa; satisfação do descendente prejudica parcialmente o ascendente.
UNKNOWN (?): contribuição desconhecida, pode ser positiva ou negativa.
EQUALS: o descendente só é satisfeito se o ascendente for satisfeito; se o ascendente for negado, o descendente também é negado.
SOME: sinal conhecido (positivo ou negativo), mas grau de contribuição incerto; usado em casos de incerteza entre HELP/MAKE ou HURT/BREAK.

Procedimento de Avaliação no NFR Framework

O procedimento de avaliação determina o grau em que os requisitos não funcionais (softgoals) são satisfeitos por um conjunto de decisões.
Cada softgoal ou interdependência do Softgoal Interdependency Graph (SIG) recebe um rótulo para indicar seu status.
Tipos de rótulos usados:
- ✓ (satisfeito): O requisito não funcional é plenamente satisfeito.
- 𝒲+ (fracamente satisfeito): Satisfação parcial; impacto positivo, mas menos forte que ✓.
- X (negado): O requisito não é satisfeito e pode até contradizer os objetivos do sistema.
- 𝒲- (fracamente negado): Negação parcial; impacto negativo, mas mais brando que X.
- 🗲 (conflitante): Há conflitos entre requisitos; coexistem aspectos positivos e negativos.
- u (indeterminado): Não há dados suficientes para determinar o impacto entre os requisitos.
A avaliação começa pelos softgoals de nível mais baixo na hierarquia, relacionados a decisões específicas do projeto.
O procedimento propaga os rótulos hierarquicamente, avaliando o impacto das decisões nos softgoals de níveis superiores, até alcançar o topo do SIG.

Figura 3: Procedimento de Avaliação no NFR Framework

Fonte: SILVA, 2019

Metodologia

Para aplicar o NFR Framework ao desenvolvimento do aplicativo, adotamos uma abordagem em etapas estruturadas, com o objetivo de identificar, modelar, analisar e tomar decisões relacionadas aos requisitos não funcionais (softgoals) do sistema. A metodologia compreende as seguintes fases:

1. Identificação dos Requisitos Não Funcionais (Softgoals)

Nesta etapa, foram identificados os principais requisitos não funcionais relevantes ao contexto do aplicativo, como:

Usabilidade
Desempenho
Segurança
Acessibilidade
Confiabilidade
Portabilidade

Essa identificação foi baseada em entrevistas com stakeholders, análise de mercado e levantamento de requisitos funcionais relacionados. Os requisitos não funcionais são representados como softgoals, que expressam intenções qualitativas sem critérios rígidos de satisfação.

2. Modelagem com o NFR Framework

A modelagem foi realizada utilizando a notação proposta por Chung et al. (2000), representando os softgoals em uma estrutura hierárquica com relacionamentos de contribuição entre eles. Foram utilizados os seguintes tipos de contribuição:

MAKE (++)
HELP (+)
HURT (-)
BREAK (--)
OR
AND
EQUALS
UNKNOWN (?)
SOME

Também foram especificadas as operacionalizações, ou seja, decisões de projeto que implementam cada softgoal.

Uso do Cartão de Especificação

Durante essa fase de modelagem, utilizou-se o Cartão de Especificação como instrumento de apoio à documentação e análise. Cada cartão foi preenchido com os seguintes elementos:

Nome do softgoal
Descrição do requisito não funcional
Alternativas de operacionalização
Contribuições com outros softgoals
Justificativa das decisões
Responsável e data da análise

A Tabela 1 ilustra o modelo adotado para a elaboração dos cartões de especificação.

Tabela 1: Template de cartão de especificação

Requisito Não Funcional – RNFXX
Classificação	Classificação do RNF conforme a hierarquia do catálogo.
Descrição	Declaração única do significado do requisito.
Justificativa	Justificativa sobre a criação do requisito
Origem do Requisito	Origem do requisito (stakeholder, norma técnica e etc...)
Critério de Aceitação	Métrica do requisito que possa ser testada e que deve ser satisfeita.
Dependências	Requisitos relacionados a este.
Prioridade	Um número usado para decidir a importância relativa deste requisito entre os outros RNFs (varia de 1 a 10). A prioridade mínima é 1 e a máxima é 10.
Conflitos	Requisitos conflitantes com este.
História	Data de criação e de modificações.

Fonte: Leticia Arisa

O cartão facilitou a rastreabilidade, clareza e consistência das informações, além de permitir uma análise comparativa entre alternativas e apoiar a comunicação com os stakeholders durante a modelagem dos requisitos.

3. Avaliação dos Softgoals

Após modelar os softgoals e suas contribuições, foi realizado o procedimento de avaliação, no qual cada softgoal recebeu um rótulo indicando o grau de satisfação:

✓ Satisfeito: Requisito não funcional plenamente atendido.
𝒲+ Fracamente satisfeito: Satisfação parcial.
X Negado: Requisito contradiz outro.
𝒲- Fracamente negado: Impacto negativo moderado.
🗲 Conflitante: Conflito entre requisitos.
u Indeterminado: Impacto incerto ou desconhecido.

A avaliação começou pelos softgoals de nível mais baixo (operacionalizações), subindo até os níveis superiores da hierarquia para analisar o impacto global das decisões.

4. Tomada de Decisão

Com base nas análises e rótulos atribuídos, foram tomadas decisões de projeto priorizando alternativas que maximizassem a satisfação dos softgoals mais relevantes. Em casos de conflito entre requisitos (ex: desempenho vs. segurança), foram feitas ponderações com stakeholders para encontrar o melhor compromisso possível.

5. Validação

Por fim, a validação da modelagem seguiu duas frentes:

Rastreabilidade com as histórias de usuário: verificou-se se os softgoals contemplam os desejos e expectativas expressas por cada persona.
Análise de cobertura: analisou-se se os principais atributos de qualidade exigidos para um app público financeiro (como disponibilidade, desempenho e segurança) foram devidamente modelados.

Essa validação permite garantir que os RNFs não sejam apenas documentados, mas também rastreáveis, justificáveis e compatíveis com os requisitos funcionais do aplicativo.

Cronograma de Participantes

Tabela 2: Cronograma de Participantes

Nome	Data	Hora
Danielle Soares	01/06/2025	13:30
Eduardo de Pina	01/06/2025	11:32
Enzo Emir	31/05/2025	11:45
Leticia Arisa	31/05/2025	20:17
Marcelo Makoto	31/05/2025	08:52
Maria Eduarda	31/05/2025	00:45
Victor Pontual	01/06/2025	12:30

Fonte: Marcelo Makoto

Requisitos não-funcionais

A Tabela 3 a seguir lista os Requisitos Não-Funcionais utilizados para a criação do NFR Framework.

Tabela 3: Requisitos não-funcionais

Código	Versão	Descrição	Origem
RNF02	1.0	O processo de login deve ser simplificado	EN08
RNF03	1.0	O sistema deve apresentar informações de forma transparente e confiável	EN09
RNF04	1.0	Os prazos informados no app devem ser cumpridos fielmente	EN10
RNF05	1.0	O aplicativo deve ser confiável e evitar falhas ou inconsistências nos processos	EN11
RNF06	1.0	O aplicativo deve funcionar corretamente mesmo com conexão instável	EN12
RNF07	1.0	O aplicativo deve fornecer as mesmas funcionalidades para diferentes plataformas e versões	IS18
RNF08	1.0	Os menus devem fornecer informações não repetidas	IS19
RNF09	1.0	O aplicativo deve aplicar princípios de acessibilidade	IS21
RNF10	1.0	O aplicativo deve estar disponível para outras plataformas, como web	IS22
RNF11	1.0	O aplicativo deve proporcionar segurança de dados pessoais	IS23
RNF12	1.0	O aplicativo deve proporcionar agilidade ao acessar as funcionalidades	IS24
RNF13	1.0	O sistema deve garantir segurança firme com verificação de dados pelo usuário	OB10
RNF21	1.0	Os menus devem ser autoexplicativos, com estrutura hierárquica lógica e nomenclatura padronizada	IS19, OB11
RNF22	1.0	A aplicação deve estar em conformidade com diretrizes de acessibilidade, garantindo acesso a pessoas com deficiência visual, auditiva ou motora	IS20

Fonte: Leticia Arisa

Cartões de Especificação

Tabela 4: Processo Login

Requisito Não Funcional – RNF02
Classificação	Usabilidade
Descrição	O processo de login deve ser simplificado.
Justificativa	Um login simples melhora a experiência do usuário, reduz a frustração e torna o acesso ao aplicativo mais eficiente.
Origem do Requisito	EN08
Critério de Aceitação	O usuário deve conseguir realizar o login com no máximo duas etapas, sem a necessidade de preencher dados excessivos.
Dependências	Sistema de autenticação
Prioridade	9
Conflitos	Nenhum
História	31/05/2025

Fonte: Danielle Soares

Tabela 5: Diferentes Funcionalidades

Requisito Não Funcional – RNF07
Classificação	Portabilidade
Descrição	O aplicativo deve fornecer as mesmas funcionalidades para diferentes plataformas e versões.
Justificativa	Garantir a consistência da experiência do usuário, independentemente do dispositivo ou sistema operacional utilizado.
Origem do Requisito	IS18
Critério de Aceitação	As funcionalidades disponíveis devem ser idênticas em todas as versões do aplicativo para Android, iOS e Web.
Dependências	Frameworks multiplataforma, compatibilidade entre sistemas
Prioridade	9
Conflitos	Pode haver limitações específicas em versões mais antigas de sistemas operacionais.
História	31/05/2025

Fonte: Danielle Soares

Tabela 6: Agilidade de Funcionalidades

Requisito Não Funcional – RNF12
Classificação	Usabilidade
Descrição	O aplicativo deve proporcionar agilidade ao acessar as funcionalidades.
Justificativa	Um acesso rápido melhora a experiência do usuário, reduz o tempo de espera e aumenta a eficiência no uso do aplicativo.
Origem do Requisito	IS24
Critério de Aceitação	O usuário deve conseguir acessar qualquer funcionalidade em menos de 3 segundos.
Dependências	Infraestrutura do sistema, otimização do código
Prioridade	10
Conflitos	Nenhum
História	31/05/2025

Fonte: Maria Eduarda

Tabela 7: Menus Autoexplicativos

Requisito Não Funcional – RNF21
Classificação	Usabilidade
Descrição	Os menus devem ser autoexplicativos, com estrutura hierárquica lógica e nomenclatura padronizada.
Justificativa	Menus intuitivos facilitam a navegação do usuário, reduzem o tempo de aprendizado e aumentam a eficiência no uso do aplicativo.
Origem do Requisito	IS19, OB11
Critério de Aceitação	O usuário deve ser capaz de encontrar funcionalidades com facilidade, sem precisar acessar mais de três níveis de menu e com nomes consistentes e compreensíveis.
Dependências	Design de Interface, Padrões de Navegação
Prioridade	10
Conflitos	Nenhum
História	31/05/2025

Fonte: Maria Eduarda

Tabela 8: Aplicativo com Segurança

Requisito Não Funcional – RNF05
Classificação	Confiabilidade
Descrição	O aplicativo deve ser confiável e evitar falhas ou inconsistências nos processos.
Justificativa	A confiabilidade é essencial para garantir que os usuários tenham uma experiência estável e segura, principalmente ao realizar tarefas importantes.
Origem do Requisito	EN11
Critério de Aceitação	O sistema deve passar em testes de estresse e testes de integridade sem apresentar falhas ou perda de dados.
Dependências	Testes automatizados, tratamento de erros
Prioridade	9
Conflitos	Nenhum
História	31/05/2025

Fonte: Leticia Arisa

Tabela 9: Conformidade de Diretrizes

Requisito Não Funcional – RNF22
Classificação	Acessibilidade
Descrição	A aplicação deve estar em conformidade com diretrizes de acessibilidade, garantindo acesso a pessoas com deficiência visual, auditiva ou motora.
Justificativa	Garantir acessibilidade promove inclusão digital e atende a requisitos legais e éticos, ampliando o público-alvo do sistema.
Origem do Requisito	IS20
Critério de Aceitação	A interface deve permitir navegação por teclado, ser compátivel com leitores de tela e conter alternativas textuais para elementos visuais.
Dependências	Equipe de design e desenvolvimento front-end
Prioridade	10
Conflitos	Nenhum
História	31/05/2025

Fonte: Leticia Arisa

Tabela 10: Funcionamento em Conexão Instável

Requisito Não Funcional – RNF06
Classificação	Confiabilidade
Descrição	O aplicativo deve funcionar corretamente mesmo com conexão instável.
Justificativa	Usuários em áreas com cobertura irregular de internet precisam acessar informações críticas do FGTS sem erros ou travamentos.
Origem do Requisito	EN12
Critério de Aceitação	O app deve manter funcionalidades mínimas (ex.: consulta de saldo e extrato) mesmo com perdas intermitentes de conexão.
Dependências	Equipe de backend e gerenciamento de cache local
Prioridade	8
Conflitos	Maior uso de memória local pode impactar desempenho em dispositivos antigos
História	31/05/2025

Fonte: Marcelo Makoto

Tabela 11: Segurança de Dados Pessoais

Requisito Não Funcional – RNF11
Classificação	Segurança
Descrição	O aplicativo deve proporcionar segurança de dados pessoais.
Justificativa	Proteção de informações sensíveis como CPF, conta bancária e saldo do FGTS é essencial para evitar fraudes e vazamentos.
Origem do Requisito	IS23
Critério de Aceitação	Os dados devem ser armazenados e transmitidos com criptografia; autenticação deve usar biometria ou múltiplos fatores.
Dependências	Equipe de segurança da informação e infraestrutura
Prioridade	10
Conflitos	Maior nível de segurança pode exigir autenticação adicional, impactando usabilidade para alguns usuários
História	31/05/2025

Fonte: Marcelo Makoto

Tabela 12: Cumprimento dos Prazos

Requisito Não Funcional – RNF04
Classificação	Confiabilidade
Descrição	Os prazos informados no app devem ser cumpridos fielmente.
Justificativa	O cumprimento de prazos aumenta a credibilidade do sistema e evita frustrações por parte dos usuários.
Origem do Requisito	EN10
Critério de Aceitação	O sistema deve garantir que as datas e prazos exibidos sejam atendidos, exceto em casos devidamente justificados por instâncias externas.
Dependências	Integração com sistemas oficiais de processamento e saque
Prioridade	10
Conflitos	Prazos externos sujeitos a mudanças fora do controle do aplicativo
História	31/05/2025

Fonte: Enzo Emir

Tabela 13: Princípios de Acessibilidade.

Requisito Não Funcional – RNF09
Classificação	Acessibilidade
Descrição	O aplicativo deve aplicar princípios de acessibilidade.
Justificativa	A aplicação de princípios de acessibilidade garante que pessoas com deficiência também possam utilizar o sistema com autonomia e facilidade.
Origem do Requisito	IS21
Critério de Aceitação	O app deve seguir as Diretrizes de Acessibilidade para Conteúdo Web (WCAG), implementando recursos como contraste adequado, navegação por teclado e leitores de tela.
Dependências	Equipe de design com conhecimento em acessibilidade; frameworks compatíveis
Prioridade	9
Conflitos	Pode haver necessidade de maior tempo de desenvolvimento para adaptações específicas
História	31/05/2025

Fonte: Enzo Emir

Tabela 14: Confiabilidade de informações.

Requisito Não Funcional – RNF03
Classificação	Segurança
Descrição	O sistema deve apresentar informações de forma transparente e confiável.
Justificativa	A confiabilidade e a transparência são requisitos básicos em uma aplicação que trabalha com dados bancários.
Origem do Requisito	EN09
Critério de Aceitação	O usuário deve conseguir acessar os seus dados de forma segura e transparente, sem que haja desconforto ou desconfiança.
Dependências	Verificação de informações junto ao banco e sistema de autenticação.
Prioridade	10
Conflitos	A acessibilidade pode modificar a maneira como as informações são exibidas.
História	01/06/2025

Fonte: Eduardo de Pina

Tabela 15: Unicidade na exibição de informações.

Requisito Não Funcional – RNF08
Classificação	Confiabilidade
Descrição	Os menus devem fornecer informações não repetidas.
Justificativa	A existência de informações repetidas nos menus pode impactar na confiabilidade que o usuário tem no sistema, bem como confundí-lo.
Origem do Requisito	IS19
Critério de Aceitação	O usuário não pode encontrar menus que contenham botões, textos, caixas ou dados repetidos.
Dependências	Planejamento de design e de front-end do aplicativo.
Prioridade	7
Conflitos	Nenhum.
História	01/06/2025

Fonte: Eduardo de Pina

Tabela 16: O aplicativo deve estar disponível para outras plataformas, como web.

Requisito Não Funcional – RNF10
Classificação	Portabilidade
Descrição	O aplicativo deve estar disponível para outras plataformas além do celular, como navegadores web.
Justificativa	Expandir a acessibilidade do sistema para diferentes perfis de usuário, incluindo aqueles que preferem utilizar computadores ou que não têm acesso fácil a dispositivos móveis.
Origem do Requisito	IS22
Critério de Aceitação	O sistema deve estar acessível por navegadores modernos em computadores pessoais (Windows, Linux, MacOS).
Dependências	Planejamento e desenvolvimento de uma versão responsiva ou adaptada para web.
Prioridade	10
Conflitos	Nenhum.
História	01/06/2025

Fonte: Victor Pontual

Tabela 17: O sistema deve garantir segurança firme com verificação de dados pelo usuário

Requisito Não Funcional – RNF13
Classificação	Segurança
Descrição	O sistema deve permitir e incentivar a verificação ativa de dados pelo usuário para prevenir fraudes ou acessos indevidos.
Justificativa	Garantir que o usuário esteja ciente dos dados utilizados e possa confirmar suas informações aumenta a segurança e a confiabilidade do sistema.
Origem do Requisito	OB10
Critério de Aceitação	O sistema deve exibir resumos dos dados antes de cada ação crítica (como saque ou alteração de conta), solicitando confirmação do usuário.
Dependências	Integração com módulos de segurança e lógica de interface voltada à confirmação de dados.
Prioridade	10
Conflitos	Nenhum.
História	01/06/2025

Fonte: Victor Pontual

NFR00: Geral

A Figura 4 a seguir demonstra o Softgoal Interdependency Graph de uma maneira geral.

Figura 4: Geral

Fonte: Danielle Soares

NFR01: Portabilidade

Descrição

Este SIG (Softgoal Interdependency Graph) foi elaborado a partir de requisitos não funcionais relacionados à portabilidade do sistema. Esses requisitos garantem que o sistema seja acessível em diferentes ambientes.

Requisitos

Requisitos utilizados para desenvolver o SIG da Figura 5:

RFN07: O aplicativo deve fornecer as mesmas funcionalidades para diferentes plataformas e versões.
RFN10: O aplicativo deve estar disponível para outras plataformas, como web.

Figura 5: SIG Portabilidade

Fonte: Leticia Arisa

Propagação dos impactos

A Tabela 18, apresentada a seguir, mostra a avaliação da propagação dos impactos representados na Figura 5.

Tabela 18: Tabela de impactos.

NFR	Impacto	Avaliador
Portabilidade	✓	Leticia Arisa
Manter as mesmas funcionalidades	𝒲+	Leticia Arisa
Disponibilidade em outras plataformas	𝒲+	Leticia Arisa

Fonte: Leticia Arisa

NFR02: Confiabilidade

Descrição

Este SIG (Softgoal Interdependency Graph) foi elaborado com base nos requisitos não funcionais relacionados à confiabilidade do sistema. A confiabilidade garante que o sistema execute suas funções de maneira consistente, sem falhas, mesmo em situações adversas, como conexões instáveis ou dependências externas.

Requisitos

Requisitos utilizados para desenvolver o SIG da Figura 6:

RNF03: O sistema deve apresentar informações de forma transparente e confiável.
RNF04: Os prazos informados no app devem ser cumpridos fielmente.
RNF05: O aplicativo deve ser confiável e evitar falhas ou inconsistências nos processos.
RNF06: O aplicativo deve funcionar corretamente mesmo com conexão instável.

Figura 6: SIG Confiabilidade

Fonte: Enzo Emir

Propagação dos impactos

A Tabela 19, apresentada a seguir, mostra a avaliação da propagação dos impactos representados na Figura 6.

Tabela 19: Tabela de impactos.

NFR	Impacto	Avaliador
Confiabilidade (RNF05 - evitar falhas ou inconsistências)	✓	Enzo Emir
Funcionamento em conexão instável (RNF06)	𝒲+	Enzo Emir
Cumprimento de prazos (RNF04)	𝒲+	Enzo Emir
Transparência e precisão das informações (RNF03)	✓	Enzo Emir

Fonte: Enzo Emir

NFR03: Segurança

Descrição

Este SIG (Softgoal Interdependency Graph) foi elaborado com base nos requisitos não funcionais relacionados à segurança do sistema no que tange ao dados. A segurança é responsável por garantir que os dados do usuário e de todas as partes envolvidas no uso do sistema tenham uma camada de proteção contra a exposição indesejada das suas informações.

Requisitos

Requisitos utilizados para desenvolver o SIG da Figura 7:

RNF11: O aplicativo deve proporcionar segurança de dados pessoais
RNF13: O sistema deve garantir segurança firme com verificação de dados pelo usuário.

Figura 7: SIG Segurança

Fonte: Eduardo de Pina

Propagação dos impactos

A Tabela 20, apresentada a seguir, mostra a avaliação da propagação dos impactos representados na Figura 7.

Tabela 20: Tabela de impactos.

NFR	Impacto	Avaliador
Segurança de dados pessoais (RNF11)	✓	Eduardo de Pina
Verificação dos dados pelo usuário (RNF13)	𝒲+	Eduardo de Pina

Fonte: Eduardo de Pina

NFR04: Usabilidade

Descrição

Este Softgoal Interdependency Graph (SIG) foi elaborado para representar visualmente os aspectos relacionados à usabilidade no sistema FGTS. Ele demonstra como certos requisitos não funcionais influenciam positivamente ou negativamente esse atributo de qualidade, estruturando os relacionamentos entre metas e submetas de forma hierárquica.

Requisitos

Requisitos utilizados para compor o SIG da Figura 8:

RNF02: O processo de login deve ser simplificado
Origem: EN08
RNF08: Os menus devem fornecer informações não repetidas
Origem: IS19
RNF21: Os menus devem ser autoexplicativos, com estrutura hierárquica lógica e nomenclatura padronizada
Origem: IS19, OB11
RNF12: O aplicativo deve proporcionar agilidade ao acessar as funcionalidades
Origem: IS24

Figura 8: SIG Usabilidade

Fonte: Victor Pontual

Propagação dos Impactos

A Tabela 21 apresenta a avaliação da propagação dos impactos identificados na Figura 8.

Tabela 21: Avaliação dos Impactos dos Requisitos sobre Usabilidade

NFR	Impacto	Avaliador
RNF02 – Login simplificado	✓	Victor Pontual
RNF08 – Não repetir informações	❌	Victor Pontual
RNF21 – Menus autoexplicativos	𝒲⁺	Victor Pontual
RNF12 – Proporcionar agilidade	✓	Victor Pontual

Fonte: Victor Pontual

NFR05: Acessibilidade

Descrição

Este SIG (Softgoal Interdependency Graph) foi elaborado a partir de requisitos não funcionais relacionados à acessibilidade do sistema. Esses requisitos garantem que o aplicativo seja inclusivo e acessível a todos os usuários, incluindo aqueles com deficiências visuais, auditivas ou motoras, promovendo uma experiência mais equitativa e usável.

Requisitos

Requisitos utilizados para desenvolver o SIG da Figura 9:

RFN09: O aplicativo deve aplicar princípios de acessibilidade.
RFN22: A aplicação deve estar em conformidade com diretrizes de acessibilidade, garantindo acesso a pessoas com deficiência visual, auditiva ou motora.

Figura 9: SIG Acessibilidade

Fonte: Maria Eduarda

Propagação dos impactos

A Tabela 22, apresentada a seguir, mostra a avaliação da propagação dos impactos representados na Figura 9.

Tabela 22: Tabela de impactos.

NFR	Impacto	Avaliador
Acessibilidade	✓	Maria Eduarda
Aplicar princípios de acessibilidade	𝒲+	Maria Eduarda
Atender diretrizes de acessibilidade	𝒲+	Maria Eduarda
Seguir as Diretrizes WCAG	𝒲+	Maria Eduarda
Garantir acesso a pessoas com deficiência visual, auditiva ou motora	𝒲+	Maria Eduarda

Fonte: Maria Eduarda

NFR06: SIG Completo

Descrição

Este SIG (Softgoal Interdependency Graph) foi elaborado a partir de todos os requisitos não funcionais elicitados do sistema. Ele mostra todas as relações entre os SIGs anteriores em um único grafo, possibilitando a visualização geral das dinâmicas entre eles.

Requisitos

Requisitos utilizados para desenvolver o SIG da Figura 10:

RFN07: O aplicativo deve fornecer as mesmas funcionalidades para diferentes plataformas e versões.
RFN10: O aplicativo deve estar disponível para outras plataformas, como web.
RNF03: O sistema deve apresentar informações de forma transparente e confiável.
RNF04: Os prazos informados no app devem ser cumpridos fielmente.
RNF05: O aplicativo deve ser confiável e evitar falhas ou inconsistências nos processos.
RNF06: O aplicativo deve funcionar corretamente mesmo com conexão instável.
RNF11: O aplicativo deve proporcionar segurança de dados pessoais
RNF13: O sistema deve garantir segurança firme com verificação de dados pelo usuário.
RNF02: O processo de login deve ser simplificado
RNF08: Os menus devem fornecer informações não repetidas
RNF21: Os menus devem ser autoexplicativos, com estrutura hierárquica lógica e nomenclatura padronizada
RNF12: O aplicativo deve proporcionar agilidade ao acessar as funcionalidades
RFN09: O aplicativo deve aplicar princípios de acessibilidade.
RFN22: A aplicação deve estar em conformidade com diretrizes de acessibilidade, garantindo acesso a pessoas com deficiência visual, auditiva ou motora.

Figura 10: SIG Completo

Fonte: Marcelo Makoto

Propagação dos impactos

A Tabela 23, apresentada a seguir, mostra a avaliação da propagação dos impactos representados na Figura 10.

Tabela 23: Tabela de impactos.

NFR	Impacto	Avaliador
Portabilidade	✓	Leticia Arisa
Manter as mesmas funcionalidades	𝒲+	Leticia Arisa
Disponibilidade em outras plataformas	𝒲+	Leticia Arisa
Confiabilidade (RNF05 - evitar falhas ou inconsistências)	✓	Enzo Emir
Funcionamento em conexão instável (RNF06)	𝒲+	Enzo Emir
Cumprimento de prazos (RNF04)	𝒲+	Enzo Emir
Transparência e precisão das informações (RNF03)	✓	Enzo Emir
Segurança de dados pessoais (RNF11)	✓	Eduardo de Pina
Verificação dos dados pelo usuário (RNF13)	𝒲+	Eduardo de Pina
RNF02 – Login simplificado	✓	Victor Pontual
RNF08 – Não repetir informações	X	Victor Pontual
RNF21 – Menus autoexplicativos	𝒲⁺	Victor Pontual
RNF12 – Proporcionar agilidade	✓	Victor Pontual
Acessibilidade	✓	Maria Eduarda
Aplicar princípios de acessibilidade	𝒲+	Maria Eduarda
Atender diretrizes de acessibilidade	𝒲+	Maria Eduarda
Seguir as Diretrizes WCAG	𝒲+	Maria Eduarda
Garantir acesso a pessoas com deficiência visual, auditiva ou motora	𝒲+	Maria Eduarda

Fonte: Marcelo Makoto

Validação

Parte 01:

Parte 02:

Referências Bibliográficas

1. SILVA, Reinaldo Antônio da. NFR4ES: um catálogo de requisitos não-funcionais para sistemas embarcados. 2019. 154 f. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Pernambuco, Recife, 2019.

2. CHUNG, Lawrence; NIXON, Brian A.; YU, Eric; MYLLOPULOS, John. Non-functional requirements in software engineering. Springer Science & Business Media, 2000.

Figura 4: Foto referência

Fonte: SILVA, 2019

Histórico de Versão

Versão	Data	Descrição	Autor(es)	Revisor(es)
`1.0`	28/05/2025	Criação da página	Marcelo Makoto	Leticia Arisa
`1.1`	31/05/2025	Cartões de Especificação RNF02 e RNF07	Danielle Soares	Maria Eduarda
`1.2`	31/05/2025	Atualização da Página	Maria Eduarda	Leticia Arisa
`1.3`	31/05/2025	Cartões de Especificação RNF12 e RNF21	Maria Eduarda	Leticia Arisa
`1.4`	31/05/2025	Cartões de Especificação RNF05 e RNF22	Leticia Arisa	Marcelo Makoto
`1.5`	31/05/2025	Cartões de Especificação RNF06 e RNF11	Marcelo Makoto	Danielle Soares
`1.6`	31/05/2025	Cartões de Especificação RNF04 e RNF09	Enzo Emir	Leticia Arisa
`1.7`	01/06/2025	Tabela de Requisitos Não-Funcionais utilizadas	Leticia Arisa	Enzo Emir
`1.8`	01/06/2025	Adição do NRF01	Leticia Arisa	Enzo Emir
`1.9`	31/05/2025	Cartões de Especificação RNF03 e RNF08	Eduardo de Pina	Enzo Emir
`2.0`	01/06/2025	NFR 00 - Geral	Danielle Soares	Victor Pontual
`2.1`	01/06/2025	Cartões de Especificação RNF10 e RNF13	Victor Pontual	Enzo Emir
`2.2`	01/06/2025	Adição do NFR02	Enzo Emir	Eduardo de Pina
`2.3`	01/06/2025	Adição do NFR03	Eduardo de Pina	Victor Pontual
`2.4`	01/06/2025	Adição do NFR04	Victor Pontual	Maria Eduarda
`2.5`	01/06/2025	Adição do NFR05	Maria Eduarda	Marcelo Makoto
`2.6`	01/06/2025	Adição do NFR06	Marcelo Makoto	Eduardo de Pina
`2.7`	01/06/2025	Adição das prioridades dos cartões de especificação definidas pelo usuário	Marcelo Makoto	Eduardo de Pina
`2.8`	01/06/2025	Adicionando parte 2 video validação	Maria Eduarda	Eduardo de Pina
`2.9`	04/06/2025	Correção de links	Eduardo de Pina	Marcelo Makoto
`3.0`	21/06/2025	Adição de versões dos requisitos	Marcelo Makoto	Danielle Soares