NFR framework
Introdução
NFR é um framework conceitual que utiliza o modelo Softgoal Interdependency Graph (SIG). Ele tem como foco os requisitos Não-Funcionais do aplicativo.
O Framework utiliza de softgoals, um objetivo que não possui uma clara definição nem critérios de satisfação precisos. São utilizados para representar Requisitos
Não-Funcionais e podem estar inter-relacionados, expressando a influência de uma softgoal em outro. ¹
Requisitos Não Funcionais Elicitados
Abaixo, na tabela 1, estão os requisitos não funcionais elicitados pela equipe.
ID |
Requisito |
Fonte |
RNF01 |
Ser capaz de usar a aplicação em dispositivos mobile (celulares e tablets) |
StoryTelling |
RNF02 |
Ser capaz de funcionar sem internet |
StoryTelling |
RNF03 |
O aplicativo salvará a nota em até 1 segundo |
Introspecção |
RNF04 |
O aplicativo abrirá em um tempo limite de até 2 segundos |
Introspecção |
RNF05 |
Estar disponível em diversos dispositivos (celulares, laptops, tablets, etc) |
Glossário |
RNF06 |
Ser capaz de ler e editar arquivos de texto de outras fontes |
Glossário |
RNF07 |
O aplicativo deve permitir a criação de notas de forma fácil e rápida, sem muitas etapas |
Entrevista |
RNF08 |
O aplicativo deve ser acessível em diferentes plataformas, como computadores, tablets e smartphones |
Entrevista |
RNF09 |
O aplicativo deve permitir a criação de backups automáticos ou manuais das notas para evitar perda de informação |
Entrevista |
RNF10 |
O aplicativo deve ter uma interface simples e fácil de usar, sem muitas opções desnecessárias |
Entrevista |
RNF11 |
O aplicativo deve permitir o login com diferentes opções, como e-mail, Google ou Facebook, para facilitar o acesso ao aplicativo após formatação ou troca de dispositivo |
Entrevista |
RNF12 |
O aplicativo deve ser confiável e estável, evitando falhas ou perda de dados. |
Brainstorm |
RNF13 |
O aplicativo deve ser responsivo e rápido, permitindo que os usuários criem e acessem suas notas rapidamente. |
Brainstorm |
RNF14 |
O aplicativo deve ser acessível para usuários com deficiências visuais ou motoras, com recursos como suporte a leitores de tela e opções de zoom. |
Brainstorm |
RNF15 |
O aplicativo deve estar disponível em várias plataformas, como iOS, Android, Windows e Mac, para garantir que os usuários possam acessar suas notas em qualquer dispositivo. |
Brainstorm |
RNF16 |
O aplicativo deve estar disponível para uso sempre que o usuário precisar, sem interrupções ou indisponibilidades não planejadas. |
Brainstorm |
RNF17 |
O aplicativo deve ser otimizado para usar recursos do dispositivo de forma eficiente, como CPU, memória e bateria. |
Brainstorm |
RNF18 |
O aplicativo deve ser facilmente mantido e atualizado, com um código limpo e bem documentado. |
Brainstorm |
RNF19 |
O aplicativo deve ser intuitivo e fácil de usar, com uma interface clara e simples. |
Brainstorm |
Tabela 1: Requisitos Não Funcionais Elicitados, Autor(a): Beatriz
Softgoals
Os softgoals são separados em 3 tipos: ¹
- NFR Softgoal: É um requisito não-funcional que é considerado durante a análise, a fim de determinar se ele será ou não implementado.
Esses requisitos são vistos como atributos de qualidade e são avaliados para garantir que o produto final atenda aos padrões desejados. Em outras palavras, eles são critérios usados para avaliar a qualidade do produto.
- Softgoal de Operacionalização: São funcionalidades que permitem viabilizar ou não as características abstratas. Ou seja, elas são responsáveis por transformar os requisitos não-funcionais em funcionalidades tangíveis, que podem ser implementadas no sistema.
Em resumo, as funcionalidades são a materialização das características abstratas em algo concreto e mensurável
- Claim Softgoal (Argumentation): É a notação que pode ser adicionada ao modelo para argumentar um ponto específico da modelagem e é escrita em linguagem natural.
Essa notação é uma forma de expressar ideias ou justificativas sobre o modelo e pode ajudar a explicar o raciocínio por trás de certas escolhas.
Além dessa separação, cada um desses softgoals podem ser especificados, serem descritos em formade sub-requisitos:
- Decomposição de Softgoal NFR: Essa técnica que permite uma melhor organização e compreensão dos softgoals NFR.
- Decomposição de Operacionalização: Essa técnica possibilita a definição de uma solução geral e a criação de casos mais especificos.
- Decomposição de Afirmação (Claims): Essa técnica permite reafirmar ou negar as justificativas específicas do projeto.
- Priorização: Essa é um tipo especial de separação, na qual um softgoal é refinado em outro softgoal com o mesmo tipo e tópicos, mas com uma prioridade associada.
Esse refinamento são especificações dos softgoals e são contribuições e existe 10 tipos. Esses são: ¹
Contribuição |
Descrição |
Notação |
MAKE |
FILHO com contribuição tão positiva a ponto de satisfazer o PAI sob a perspectiva dos envolvidos. |
++ |
HELP |
FILHO com contribuição positiva parcial, que sozinho não chega a satisfazer o PAI sob a perspectiva dos envolvidos. |
+ |
UNKNOWN |
FILHO não afeta o PAI. |
? |
HURT |
FILHO com contribuição negativa parcial, que sozinho não chega a negar o PAI sob a perspectiva dos envolvidos. |
- |
BREAK |
FILHO com contribuição tão negativa a ponto de negar o PAI sob a perspectiva dos envolvidos |
-- |
SOME + |
FILHO com contribuição positiva, cuja intensidade não se pode determinar. |
SOME + |
SOME - |
FILHO com contribuição negativa, cuja intensidade não se pode determinar |
SOME - |
AND |
“Pai” é satisfeito se_somente_se todos os “filhos” forem satisfeitos sob a perspectiva dos envolvidos |
AND |
OR |
“Pai” é satisfeito se_somente_se um dos “filhos” é satisfeito sob a perspectiva dos envolvidos |
OR |
EQUAL |
Ambos compartilham o mesmo label |
= |
Tabela 2: Refinamento, Autor(a): Mylena
Participantes
Nome |
Cargo |
Técnica |
Beatriz |
Equipe de modelagem |
Modelagem |
Leonardo |
Equipe de priorização |
Entrevistas da elicitação |
Mylena |
Equipe de elicitação |
Público alvo: questionário |
Paulo |
Product Owner |
Membro do grupo 4 |
Tabela 3: Participantes, Autor(a): Mylena
Legendas
Softgoals
Figura 1: Legenda Softgoals, Fonte: Beatriz
Rótulos
Figura 2: Legenda Rótulos, Fonte: NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados.¹
Descrição: ¹
- Satisfeito: Reflete que um requisito não funcional contribui de maneira positiva para a realização de outro requisito, resultando em satisfação.
- Fracamente satisfeito: ndica uma relação de impacto positiva, mas menos forte do que a notação satisfeito.
- Negado: Demonstrando que um requisito não funcional afeta adversamente outro requisito, anulando ou contradizendo sua concretização.
- Fracamente negado: Similar à notação negado, mas com uma relação de negação mais fraca.
- Conflitante: Indica uma relação de conflito entre requisitos não funcionais. Isso implica que os requisitos possuem características tanto positivas quanto negativas.
- Indeterminado: Refere-se a uma relação incerta ou desconhecida entre requisitos não funcionais. Isso ocorre quando há informações insuficientes para determinar o impacto de um requisito em outro.
NFR
Foram feitos 4 tipos de NFR: usabilidade (figura 3 e 4), disponibilidade (figura 5 e 6), portabilidade (figura 7 e 8) e performance (figura 9 e 10).
NFR-1 Usabilidade
Requisitos de Usabilidade
ID |
Requisito |
RNF07 |
O aplicativo deve permitir a criação de notas de forma fácil e rápida, sem muitas etapas |
RNF10 |
O aplicativo deve ter uma interface simples e fácil de usar, sem muitas opções desnecessárias |
RNF14 |
O aplicativo deve ser acessível para usuários com deficiências visuais ou motoras, com recursos como suporte a leitores de tela e opções de zoom. |
RNF19 |
O aplicativo deve ser intuitivo e fácil de usar, com uma interface clara e simples. |
Tabela 4: Requisitos de Usabilidade , Autor(a): Beatriz
Sem Propagação
Figura 3: NFR-1 Usabilidade Sem Propagação, Autor(a): Beatriz
Figura 4: NFR-1 Usabilidade com Propagação, Autor(a): Beatriz
Cartões de Especificação
Classificação |
Fácil Aprendizagem / Usabilidade |
Descrição |
O aplicativo deve ter uma interface simples e fácil de usar. |
Justificativa |
Com uma interface simples o usuario não vai ter dificuldade em aprender a usar o aplicativo, assim terá menos chances dele abandonar o uso e te uma experiencia melhor com o app. |
Origem do requisito |
RNF07, RNF10 e RNF19 |
Critério de aceitação |
Nenhum |
Prioridade |
Alta prioridade. Fonte: TLS |
Conflito |
Nenhum |
Historia |
26 de jun. 2023 |
Tabela 5: Cartão de Especificação - Fácil Aprendizagem, Autor(a): Beatriz
Classificação |
Acessibilidae / Usabilidade |
Descrição |
O aplicativo deve ser acessível para usuários com deficiências. |
Justificativa |
Proporcionar à maior quantidade possível de pessoas, independentemente da limitação de mobilidade ou percepção, a utilização de maneira autônoma do aplicativo |
Origem do requisito |
RNF14 |
Critério de aceitação |
Nenhum |
Prioridade |
Média prioridade. Fonte: TLS |
Conflito |
Nenhum |
Historia |
26 de jun. 2023 |
Tabela 6: Cartão de Especificação - Acessibilidae, Autor(a): Beatriz
NFR-2 Disponibilidade
Requisitos de Disponibilidade
ID |
Requisito |
RNF09 |
O aplicativo deve permitir a criação de backups automáticos ou manuais das notas para evitar perda de informação |
RNF11 |
O aplicativo deve permitir o login com diferentes opções, como e-mail, Google ou Facebook, para facilitar o acesso ao aplicativo após formatação ou troca de dispositivo |
RNF12 |
O aplicativo deve ser confiável e estável, evitando falhas ou perda de dados. |
RNF16 |
O aplicativo deve estar disponível para uso sempre que o usuário precisar, sem interrupções ou indisponibilidades não planejadas. |
RNF18 |
O aplicativo deve ser facilmente mantido e atualizado, com um código limpo e bem documentado. |
Tabela 7: Requisitos de Disponibilidade, Autor(a): Beatriz
Sem Propagação
Figura 5: NFR-2 Disponibilidade, Autor(a): Mylena
Figura 6: NFR-1 Disponibilidade com Propagação, Autor(a): Beatriz
Cartões de Especificação
Classificação |
Backup das notas do usuário / Disponibilidade |
Descrição |
O aplicativo deve permitir a criação de backups automáticos ou manuais das notas. |
Justificativa |
Evita perda de informação e o usuário pode ter acesso as suas notas sempre que necessário. |
Origem do requisito |
RNF09 |
Critério de aceitação |
Nenhum |
Prioridade |
Alta prioridade. Fonte: TLS |
Conflito |
Nenhum |
Historia |
26 de jun. 2023 |
Tabela 8: Cartão de Especificação - Backup das notas do usuário, Autor(a): Beatriz
Classificação |
Servidores executando a aplicação / Disponibilidade |
Descrição |
O aplicativo deve estar disponível para uso sempre que o usuário precisar, sem interrupções ou indisponibilidades não planejadas. E em caso de manutenção ele será avisado. |
Justificativa |
O usuário pode ter acesso as suas notas sempre que necessário e se houver manutenção ele será notificado. |
Origem do requisito |
RNF16, RNF18, RNF11 e RNF12 |
Critério de aceitação |
Servidores com preço acessivel |
Prioridade |
Alta prioridade. Fonte: TLS |
Conflito |
Nenhum |
Historia |
26 de jun. 2023 |
Tabela 9: Cartão de Especificação - Servidores executando a aplicação, Autor(a): Beatriz
NFR-3 Portabilidade
Requisitos de Portabilidade
ID |
Requisito |
RNF01 |
Ser capaz de usar a aplicação em dispositivos mobile (celulares e tablets) |
RNF05 |
Estar disponível em diversos dispositivos (celulares, laptops, tablets, etc) |
RNF06 |
Ser capaz de ler e editar arquivos de texto de outras fontes |
RNF08 |
O aplicativo deve ser acessível em diferentes plataformas, como computadores, tablets e smartphones |
RNF15 |
O aplicativo deve estar disponível em várias plataformas, como iOS, Android, Windows e Mac, para garantir que os usuários possam acessar suas notas em qualquer dispositivo. |
Tabela 10: Requisitos de Portabilidade, Autor(a): Beatriz
Sem Propagação
Figura 7: NFR-3 Portabilidade, Autor(a): Leonardo e Beatriz
### Com Propagação
Figura 8: NFR-1 Portabilidade com Propagação, Autor(a): Beatriz
Cartões de Especificação
Classificação |
Multiplataforma / Portabilidade |
Descrição |
O aplicativo deve ser acessível em diferentes plataformas. |
Justificativa |
O aplicativo deve estar disponível em várias plataformas, como iOS, Android, Windows e Mac, para garantir que os usuários possam acessar suas notas em qualquer dispositivo. |
Origem do requisito |
RNF01, RNF05, RNF08, RNF15 e RNF06 |
Critério de aceitação |
Recurso financeiro disponivel. |
Prioridade |
Alta prioridade. Fonte: TLS |
Conflito |
Custo elevado. |
Historia |
26 de jun. 2023 |
Tabela 11: Cartão de Especificação - Multiplataforma, Autor(a): Beatriz
ID |
Requisito |
RNF02 |
Ser capaz de funcionar sem internet |
RNF03 |
O aplicativo salvará a nota em até 1 segundo |
RNF04 |
O aplicativo abrirá em um tempo limite de até 2 segundos |
RNF13 |
O aplicativo deve ser responsivo e rápido, permitindo que os usuários criem e acessem suas notas rapidamente. |
RNF17 |
O aplicativo deve ser otimizado para usar recursos do dispositivo de forma eficiente, como CPU, memória e bateria. |
Tabela 12: Requisitos de Performance, Autor(a): Beatriz
Sem Propagação
Figura 9: NFR-4 Performance, Autor(a): Leonardo
### Com Propagação
Figura 10: NFR-1 Performance com Propagação, Autor(a): Beatriz
Cartões de Especificação
Classificação |
Otimização / Performance |
Descrição |
O aplicativo deve ser responsivo e rápido, permitindo que os usuários criem e acessem suas notas rapidamente. |
Justificativa |
O usuario vai ter uma navegação mais fluida e rapida pelo aplicativo. |
Origem do requisito |
RNF03, RNF02 e RNF13 |
Critério de aceitação |
Nenhum |
Prioridade |
Alta prioridade. Fonte: TLS |
Conflito |
Nenhum |
Historia |
26 de jun. 2023 |
Tabela 13: Cartão de Especificação - Otimização, Autor(a): Beatriz
Classificação |
Mémoria / Performance |
Descrição |
O aplicativo deve ser otimizado para usar recursos do dispositivo de forma eficiente. Possibilitando até o uso offline do aplicativo. |
Justificativa |
Extrair o melhor rendimento e uso do app. |
Origem do requisito |
RNF02 e RNF17 |
Critério de aceitação |
Nenhum |
Prioridade |
Média prioridade. Fonte: TLS |
Conflito |
Nenhum |
Historia |
26 de jun. 2023 |
Tabela 14: Cartão de Especificação - Mémoria, Autor(a): Beatriz
Referências
[1] SILVA, Reinaldo Antônio. NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. Centro de Informática UFPE, Recife, 2019. Disponível em: https://repositorio.ufpe.br/handle/123456789/34150. Acesso em: 26/06/2023
Histórico de versão
Versão |
Data |
Descrição |
Autor(es) |
Revisor(es) |
1.0 |
14/05/2023 |
Criação da documentação |
Mylena, Beatriz e Leonardo |
Ana Beatriz |
2.0 |
26/06/2023 |
Adicionando Propagação, RNF elicitados e Cartões de Especificação |
Beatriz |
Ana Beatriz |