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
Com Propagação
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
Com Propagação
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
NFR-4 Performance
Requisitos de Performance
| 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 |