NFR Framework
Introdução
O Framework de Requisitos Não Funcionais (NFR) é um método estruturado para lidar com requisitos não funcionais no desenvolvimento de software. Foi criado com o objetivo de auxiliar engenheiros e analistas de sistemas na identificação, representação, análise e monitoramento da satisfação de requisitos não funcionais (como desempenho, segurança, confiabilidade, manutenibilidade, entre outros) ao longo da vida útil do software.
Metodologia
Para que este documento possa ser produzido, foram utilizados os requisitos não funcionais presentes no nosso projeto e elicitados no artefato de de requisitos elicitados, que trata dos requisitos elicitados em relação ao aplicativo Caesb Autoatendimento.
Para a verificação foi feita uma reunião com o PO para validação dos NFR, os participantes estão contidos na tabela 1
| Participante | Função | Local | Data |
|---|---|---|---|
| Natan Almeida | Desenvolvedor | Gama - DF | 17/12/2024 |
| Matheus Barros | Desenvolvedor | Gama - DF | 17/12/2024 |
| João Paulo | Product Owner | Gama - DF | 17/12/2024 |
Vídeo 01: Entrevista com o PO
Autor(a): Natan Almeida e Matheus BarrosEsse framework leva em consideração o conceito de "softgoal", eles se referem a um objeto desprovido de definição clara e critérios de satisfação sólidos, esses softgoals são utilizados para representar Requisitos não-funcionais e podem estar conectados entre si, refletindo as influências que eles exercem entre si.
Existem três categorias de softgoals, abaixo segue (Tabela 2) uma explicação sobre cada tipo:
| Tipo de Softgoal | Descrição |
|---|---|
| Softgoals NFR | Representam os requisitos não funcionais e podem ser organizados hierarquicamente no desenvolvimento do projeto. |
| Softgoals de Operacionalização | Representam as soluções de implementação para atender aos softgoals NFR ou outros softgoals de operacionalização. Incluem operações, processos, estruturas de dados e restrições no sistema para cumprir as necessidades indicadas. |
| Softgoals de Afirmação ( CLAIM ) | Consideram as características do domínio, como prioridades e carga de trabalho, no processo de tomada de decisão. Servem como justificativa para apoiar ou negar a priorização e seleção de componentes, facilitando a revisão, justificativa, melhoria do sistema e rastreamento das decisões de desenvolvimento. |
Autor: (CHUNG et al., 2000).
Após determinarmos o tipo de softgoal, devemos fazer uma avaliação, esse processo de avaliação determina o quanto os requisitos não funcionais são satisfatórios por meio de um conjunto de decisões. Para tal atribuimos os rótulos de "satisfeito", "parcialmente satisfeito", "não atendido", "parcialmente não atendido", "conflitante" e "indeterminado"
Autor: (CHUNG et al., 2000).
Depois de fazermos a identificação deles e relacionarmos devemos atribuir a eles as contribuições e decomposições, que serão explicadas na Tabela 3:
| Tipo de Contribuição | Descrição |
|---|---|
Contribuições Positivas (+) |
Indicadores de que uma decisão ou elemento contribui para a satisfação de um softgoal. |
++ (Forte Positiva) |
Uma contribuição muito significativa e positiva. |
+ (Fraca Positiva) |
Uma contribuição positiva moderada. |
Contribuições Negativas (-) |
Indicadores de que uma decisão ou elemento dificulta a satisfação de um softgoal. |
-- (Forte Negativa) |
Um impacto muito significativo e prejudicial. |
- (Fraca Negativa) |
Um impacto negativo moderado. |
| Decomposição AND | Todos os sub-softgoals precisam ser atendidos para que o softgoal pai seja satisfeito. |
| Decomposição OR | Apenas um ou mais sub-softgoals precisam ser atendidos para que o softgoal pai seja satisfeito. |
Requisitos Não-Funcionais:
| ID | DESCRIÇÃO | RASTREABILIDADE | IMPLEMENTADO |
|---|---|---|---|
| RQ31 | O aplicativo deve incluir um tutorial inicial para ajudar novos usuários a se familiarizarem. | ADD10 | Não |
| RQ32 | O aplicativo deve oferecer suporte a múltiplos idiomas para atender usuários diversificados. | ADD04, INT25 | Não |
| RQ33 | O aplicativo deve ser compatível com as versões mais recentes do Android e iOS. | INT07, OBS16 | Sim |
| RQ34 | O aplicativo deve garantir segurança com os dados dos usuários. | ADD06, ADD07 | Sim |
| RQ35 | O aplicativo deve estar em conformidade com os padrões de acessibilidade da última versão da WCAG. | ADD13, INT26, OBS18 | Não |
| RQ36 | O aplicativo deve ter uma interface intuitiva, organizada e fácil de usar. | INT08, ENT02, B15, B13, ENT10 | Sim |
| RQ37 | O número de cliques necessários para realizar uma ação deve ser de 3 a 5. | B14, OBS19 | Sim |
| RQ38 | O aplicativo deve se adaptar a diferentes tamanhos de tela. | OBS17, INT10 | Não |
| RQ39 | O aplicativo deve permitir suporte offline para funcionalidades básicas, como visualização de contas armazenadas. | ADD14 | Não |
| RQ40 | O aplicativo deve ter tempos de resposta inferiores a 2 segundos para a maioria das funcionalidades. | INT22 | Não |
NFR Framework - NFR01: Usabilidade
De acordo com Jakob Nielsen usabilidade é um atributo de qualidade que avalia a facilidade de uso das interfaces de usuário. Nielsen define usabilidade como um conjunto de componentes que determinam o quão eficaz, eficiente e satisfatória é a interação do usuário com um sistema. Os requisitos utilizados para esse NFR foram:
- RQ31: O aplicativo deve incluir um tutorial inicial para ajudar novos usuários a se familiarizarem.
- RQ32: O aplicativo deve oferecer suporte a múltiplos idiomas para atender usuários diversificados.
- RQ36: O aplicativo deve ter uma interface intuitiva, organizada e fácil de usar.
- RQ38: O aplicativo deve se adaptar a diferentes tamanhos de tela.
Com isso em mente, segue a Figura número 3 com o NFR relativo a usabilidade:
Propagação de impactos - NFR01
| NFR | Impacto | Avaliador |
|---|---|---|
| Usabilidade | ✓ (satisfeito) | Matheus Barros |
| Interface intuitiva | ✓ (satisfeito) | Matheus Barros |
| Tutorial | 𝒲+ (fracamente satisfeito) | Matheus Barros |
| Adaptar a diferentes tamanhos de tela | ✓ (satisfeito) | Matheus Barros |
| Interface padronizada | ✓ (satisfeito) | Matheus Barros |
| Funcionalidades fáceis de encontrar | 𝒲+ (fracamente satisfeito) | Matheus Barros |
NFR Framework - NFR02: Eficiência
Eficiência é um atributo de qualidade de um sistema que se refere à sua capacidade de executar as funções especificadas de maneira otimizada, utilizando o mínimo de recursos necessários. Esse atributo é fundamental para garantir que o sistema ofereça respostas rápidas e mantenha um desempenho estável, mesmo sob condições de carga elevada. É um dos requisitos não funcionais (NFRs) mais relevantes em sistemas computacionais modernos, especialmente em aplicações onde o desempenho é importante.
- RQ37: O número de cliques necessários para realizar uma ação deve ser de 3 a 5.
- RQ40: O aplicativo deve ter tempos de resposta inferiores a 2 segundos para a maioria das funcionalidades.
Com isso em mente, segue a Figura número 4 com o NFR relativo a eficiência:
Propagação de impactos - NFR02
| NFR | Impacto | Avaliador |
|---|---|---|
| Eficiência | ✓ (satisfeito) | Leandro de Almeida |
| Otimizar tarefas | 𝒲+ (fracamente satisfeito) | Leandro de Almeida |
| Reduzir tarefas repetitivas | 𝒲+ (fracamente satisfeito) | Leandro de Almeida |
| Facilitar a navegação do usuário com fluxos lógicos | ✓ (satisfeito) | Leandro de Almeida |
| Executar com 3 ou 5 cliques | ✓ (satisfeito) | Leandro de Almeida |
| Limitações | 𝒲+ (fracamente satisfeito) | Leandro de Almeida |
| Tempo de resposta | ✓ (satisfeito) | Leandro de Almeida |
| Processar em até 2 segundos | ✓ (satisfeito) | Leandro de Almeida |
| Organização intuitiva do menu | ✓ (satisfeito) | Leandro de Almeida |
NFR Framework - NFR03: Confiabilidade
Confiabilidade é um atributo de qualidade de um sistema que se refere à sua capacidade de executar as funções especificadas de maneira consistente, correta e sem falhas em um determinado período de tempo ou sob condições específicas. É um dos requisitos não funcionais (NFRs) mais importantes em sistemas computacionais, pois está diretamente relacionado à confiança que os usuários depositam no sistema. Os requisitos utilizados para esse NFR foram:
- RQ34 - O aplicativo deve garantir segurança com os dados dos usuários.
Com isso em mente, segue a Figura número 5 com o NFR relativo a confiabilidade:
Propagação de impactos - NFR03
| NFR | Impacto | Avaliador |
|---|---|---|
| Confiabilidade | ✓ (satisfeito) | Letícia Resende |
| Segurança | ✓ (satisfeito) | Letícia Resende |
| Solicitar autenticação | ++ (fortemente satisfeito) | Letícia Resende |
| Notificar novos logins | 𝒲+ (fracamente satisfeito) | Letícia Resende |
| Implementar criptografia | ++ (fortemente satisfeito) | Letícia Resende |
| Transparência | ✓ (satisfeito) | Letícia Resende |
| Política de Privacidade | + (satisfeito) | Letícia Resende |
| Termos de Uso | + (satisfeito) | Letícia Resende |
| Suporte ao Usuário | ✓ (satisfeito) | Letícia Resende |
| FAQs sobre segurança | 𝒲+ (fracamente satisfeito) | Letícia Resende |
| Suporte dedicado ao usuário | + (satisfeito) | Letícia Resende |
NFR Framework - NFR04: Suportabilidade
Suportabilidade é um atributo de qualidade de um sistema que se refere à sua capacidade de ser mantido, adaptado ou expandido com facilidade ao longo de seu ciclo de vida. Esse atributo é fundamental para garantir que o sistema possa evoluir diante de mudanças nos requisitos, corrigir problemas rapidamente e incorporar novas funcionalidades sem comprometer sua estabilidade ou desempenho. É um dos requisitos não funcionais (NFRs) mais relevantes em sistemas modernos, especialmente em contextos onde a manutenção contínua e a escalabilidade são cruciais para atender às demandas do negócio.
- RQ32: O aplicativo deve oferecer suporte a múltiplos idiomas para atender usuários diversificados.
- RQ33: O aplicativo deve ser compatível com as versões mais recentes do Android e iOS.
- RQ38: O aplicativo deve se adaptar a diferentes tamanhos de tela.
Com isso em mente, segue a Figura número 5 com o NFR relativo a suportabilidade:
Propagação de impactos - NFR04
| NFR | Impacto | Avaliador |
|---|---|---|
| Suportabilidade | ✓ (satisfeito) | Natan Almeida |
| Estabilidade | ✓ (satisfeito) | Natan Almeida |
| Múltiplos idiomas | 𝒲+ (fracamente satisfeito) | Natan Almeida |
| Adaptar a diferentes tamanhos de tela | ✓ (satisfeito) | Natan Almeida |
| Compatibilidade Multi-plataforma | ✓ (satisfeito) | Natan Almeida |
NFR Framework - NFR05: Manutenibilidade
A manutenibilidade de um sistema se refere à facilidade com que um sistema pode ser mantido, ajustado ou melhorado ao longo de seu ciclo de vida. Em outras palavras, é a capacidade do sistema de ser modificado para corrigir defeitos, melhorar o desempenho ou adaptar-se a novos requisitos, sem causar grandes interrupções ou custos excessivos.
- RQ35: O aplicativo deve estar em conformidade com os padrões de acessibilidade da última versão da WCAG.
- RQ39: O aplicativo deve permitir suporte offline para funcionalidades básicas, como visualização de contas armazenadas.
Com isso em mente, segue a Figura número 6 com o NFR relativo a manutenibilidade:
Propagação de impactos - NFR05
| NFR | Impacto | Avaliador |
|---|---|---|
| Conformidade com os padrões de acessibilidade da última versão da WCAG | 𝒲+ (fracamente satisfeito) | Joao Victor Marques |
| Suporte offline para funcionalidades básicas | 𝒲+ (fracamente satisfeito) | Joao Victor Marques |
Referências Bibliográficas
[1] Chung, Lawrence; A. Nixon, Brian; Mylopoulos, John. Non-Functional Requirements in Software Engineering. Acesso em 13 de Dezembro de 2024.
[2] SILVA, R. NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. Tese (Mestrado em Engenharia de Software) - Centro de Informática, Universidade Federal de Pernambuco. Recife, p. 155. 2019. Acesso em: 13 de Dezembro de 2022
[3]NIELSEN, Jakob. Usability Engineering. San Francisco: Morgan Kaufmann, 1994.
[4] Sommerville, I. (2011). Engenharia de Software (9ª Edição). Acesso em 14 de Dezembro de 2024.
Histórico de versão
| Versão | Data | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
| 1.0 | 13/12/2024 | Criação da introdução, metodologia e NFR de usabilidade | Matheus Barros | Natan Almeida |
| 1.1 | 14/12/2024 | Adicionando NFR de confiabilidade e impactos | Letícia Resende | Matheus Barros |
| 1.2 | 14/12/2024 | Adiciona NFR02: Eficiência | Leandro de Almeida | Natan Almeida |
| 1.3 | 15/12/2024 | Adiciona NFR04: suportabilidade | Natan Almeida | Matheus Barros |
| 1.4 | 17/12/2024 | Adiciona NFR05: manutenibilidade | Joao Victor Marques | Matheus Barros |
| 1.5 | 17/12/2024 | Adiciona vídeo 01 | Natan Almeida | Matheus Barros |