NFR Framework
Introdução
Segundo Chung et al. (2000), criador do NFR framework, “foi adotado por propor uma abordagem específica para o tratamento de Requisitos Não-Funcionais e fornecer uma rica representação para expressar esses requisitos, além de suas relações e correlações” (Silva Reinaldo, 2019, p. 30,).
Metodologia
1. Identificar NFRs
Nessa etapa, identifica-se os principais requisitos não funcionais que o sistema específico em desenvolvimento deve atender e constrói-se um gráfico inicial de interdependência de objetivos flexíveis - Softgoal interdependency graph (Chung et al, 2000, p. 19). Para isso, foi desenvolvida, de maneira anterior, uma Taxonomia, visando "organizar e entender os Requisitos-Não Funcionais" (Silva Reinaldo, 2019, p. 44).
2. Decomposição de softgoals NFRs
Decompõe-se cada um dos softgoals em componentes menores (sub-softgoals) em busca de requisitos mais específicos a fim de satisfazer o softgoal de mais alto nível, hierarquicamente. Em seguida, cria-se um Soaftgoal interdependency graph com a união dos softgoals NFR encontrados.
3. Identificar operacionalizações e priozizações
Técnicas de desenvolvimento são opracionalizações para os NFR softgoals. Nessa etapa, busca-se fornecer meios de se alcançar os softgoals elicitados, enquanto que se prioriza também.
3. Inserir afirmações de design
Uma importante premissa do Framework NFR é que as decisões de design devem apresentar bons argumentos ou desgin racional. Essa atapa auxilia a próxima, onde são selecionadas alternativas para solução do desenvolvimento do aplicativo (Chung et al, 2000, p. 33).
5. Seleção entre alternativas
O processo de refinamento continua até que o desenvolvedor considere que as soluções possíveis para o sistema alvo sejam suficientemente detalhadas e que nenhuma outra alternativa precise ser considerada (Chung et al, 2000, p. 35). Sendo assim, escolhe-se dentre as possíveis operacionalizações para se produzir o aplicativo.
Identificar NFRs
Como citado anteriormente, em busca de organizar e entender os Requisitos-Não funcionais, foi desenvolvida uma Taxonomia, representada na figura 1. Segundo USMAN et al, 2017, "é um esquema de classificação, que permite descrição de termos e suas relações no contexto de uma área de conhecimento" (Silva Reinaldo, 2019, p. 44). Em seu desenvolvimento, aproveitou-se da metodologia FURPS+, utilizada na especificação suplementar e requisitos elicitados anteriormente.
Figura 1: Taxonomia de Requisitos Não-Funcionais.
Autor - José Filipi & Vitor Leonardo, 2024.
Utilizando o NFR Framework e a Taxonomia desenvolvida, representada na figura 1, constrói-se um Gráfico inicial de interdependência de softgoal com softgoals NFRs, exibido na figura 2. Estes são requisitos não funcionais principais, tratados como softgoals, para o desenvolvimento do aplicavo Meu INSS. Isto é, são objetivos que precisam ser esclarecidos, desambiguados, priorizados, elaborados, etc (Chung et al, 2000, p. 20).
Figura 2: Gráfico inicial de interdependência de softgoal com softgoals NFRs.
Autor - José Filipi & Vitor Leonardo, 2024.
Decomposição de softgoals NFRs
Em seguida, os oito softgoals representados na Figura 2 são decompostos individualmente, conforme mostrado nas Figuras 3, 4, 5, 6, 7, 8, 9 e 10.
Além disso, são criados cartões de especificação, que têm como objetivo ilustrar os Requisitos Não-Funcionais (RNFs) no contexto real de um sistema embarcado. A Tabela 1 apresenta o formato que deve ser seguido para a criação de um cartão de especificação.
Tabela 1 - Modelo para o cartão de especificação
| Nº Requisito: um número sequencial (classificação) | Classificação: Classificação do RNF conforme hierarquia do catálogo. |
|---|---|
| Descrição: | Descrição única do significado do requisito. |
| Justificativa: | Justificativa sobre a criação do requisito. |
| Origem do Requisito: | Origem do requisito. |
| 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 requisitos entre os outros RNFs (varia 1 e 10). A priordade mínima é 1 e a máxima é 10. |
| Conflitos: | Requisitos conflitantes com este. |
| História: | Data de criação e modificações. |
Autor - Johnny Lopes, 2024.
NFR01: Usabilidade
Figura 3: Decomposição do softgoal Usabilidade em requisitos não funcionais mais específicos.
Autor - Vitor Leonardo, 2024.
Tabela 2: Cartão de especificação NFR01
| Nº Requisito: 1 (NFR01) | Classificação: Usabilidade |
|---|---|
| Descrição: | O aplicativo deve possuir ferramentas de acessibilidade como navegação guiada, alto contraste, comando por voz e possibilidade de aumentar a fonte. |
| Justificativa: | As ferramentas de acessibilidade são essenciais para garantir que todos os usuários, incluindo aqueles com deficiência visual ou dificuldades motoras, possam utilizar o aplicativo de forma eficiente e confortável. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O sistema deve fornecer navegação guiada, opções de alto contraste, comandos por voz e ajuste de tamanho de fonte que possam ser testados e utilizados por pessoas com deficiências. |
| Dependências: | Padrões de acessibilidade, SDKs de acessibilidade dos sistemas operacionais |
| Prioridade: | 1,50 |
| Conflitos: | Nenhum |
| História: | 27/05/2024 |
Autor - Vitor Leonardo, 2024.
NFR02: Confiabilidade
Figura 4: Decomposição do softgoal Confiabilidade em requisitos não funcionais mais específicos.
Autor - Vitor Leonardo, 2024 & Chung et al, 2000, p. 24.
Tabela 3: Cartão de especificação NFR02
| Nº Requisito: 2 (NFR02) | Classificação: Confiabilidade |
|---|---|
| Descrição: | O aplicativo deve estar disponível 24 horas por dia, 7 dias por semana, com uma taxa de uptime de 99.9%. |
| Justificativa: | Alta disponibilidade é essencial para garantir que os usuários possam acessar o aplicativo a qualquer momento, aumentando a confiança e satisfação dos usuários. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O sistema deve ser monitorado continuamente e deve manter um uptime de 99.9% ou superior, calculado mensalmente. |
| Dependências: | Infraestrutura de servidores, rede de distribuição de conteúdo, manutenção e monitoramento contínuos |
| Prioridade: | 2,45 |
| Conflitos: | Nenhum |
| História: | 27/05/2024 |
Autor - Vitor Leonardo, 2024.
NFR03: Desempenho
Figura 5: Decomposição do softgoal Desempenho em requisitos não funcionais mais específicos.
Autor - Bianca Castro, 2024 & Chung et al, 2000, p. 24.
Tabela 4: Cartão de especificação NFR03.
| Nº Requisito: 3 (NFR03) | Classificação: Desempenho |
|---|---|
| Descrição: | O aplicativo deve responder a comandos do usuário em menos de 3 segundos. |
| Justificativa: | Um tempo de resposta rápido é essencial para garantir uma experiência de usuário satisfatória e eficiente. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O sistema deve ser testado para garantir que todas as respostas a comandos do usuário sejam executadas em menos de 3 segundos. |
| Dependências: | Desempenho do servidor, otimização do código, infraestrutura de rede |
| Prioridade: | 1,00 |
| Conflitos: | Nenhum |
| História: | 27/05/2024 |
Autor - Bianca Castro, 2024.
NFR04: Físico
Figura 7: Decomposição do softgoal Interface em requisitos não funcionais mais específicos.
Autor - Gabriel Souza, 2024.
Tabela 5: Cartão de especificação NFR04.
| Nº Requisito: 4 NFR04 (RE41) | Classificação: Físico |
|---|---|
| Descrição: | O aplicativo deve estar disponível 24 horas por dia, 7 dias por semana, com uma taxa de uptime de 99.9%. |
| Justificativa: | Uma aplicação que se mantenha estável quase que em 100% do tempo é fundamental para evitar possíveis frustrações vindas dos usuários. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O sistema deve ser testado em diversos momentos distintos para garantir que seu suporte esteja disponível segunda uma taxa de uptime de 99.9%. |
| Dependências: | Desempenho do servidor, infraestrutura de rede, qualidade do código, testes de software |
| Prioridade: | 5 |
| Conflitos: | Nenhum |
| História: | 22/06/2024 |
Autor - Gabriel Souza, 2024.
NFR05: Interface
Figura 7: Decomposição do softgoal Interface em requisitos não funcionais mais específicos.
Autor - José Filipi, 2024.
Tabela 6: Cartão de especificação NFR05.
| Nº Requisito: 5 (NFR05) | Classificação: Interface |
|---|---|
| Descrição: | O aplicativo deve ser fácil de usar e intuitivo, mesmo para usuários com conhecimento técnico limitado e que minimize o número de cliques para realizar uma tarefa. |
| Justificativa: | O aplicativo deve contemplar todos os públicos possíveis, uma vez que se trata de um serviço governamental de amplo acesso. Portanto, deve também oferecer um uso simples ao público que possui pouco ou nenhum contato com tecnologia. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O aplicativo deve ser testado com um público com baixa afinidade tecnológica e ser capaz de oferecer o serviço com pouca ou nenhuma intervenção. Além disso, pode ser testado a quantidade de cliques necessárias para executar a aplicação. |
| Dependências: | Otimização do código e testes com usuário |
| Prioridade: | 2,45 |
| Conflitos: | Nenhum |
| História: | 29/06/2024 |
Autor - José Filipi, 2024.
NFR06: Design
Figura 8: Decomposição do softgoal Design em requisitos não funcionais mais específicos.
Autor - Amanda Campos, 2024.
Tabela 7: Cartão de especificação NFR06.
| Nº Requisito: 6 (NFR06) | Classificação: Design |
|---|---|
| Descrição: | O sistema deve usar a biblioteca Spring Boot para o backend e a biblioteca React Navigation para a navegação no frontend. |
| Justificativa: | As tecnologias mencionadas possuem boa integração entre si , o que facilita a curva de desenvolvimento da equipe e a integração, além disso, possuem integração com ambientes mobile, a principal plataforma de acesso dos usuários deste serviço. |
| Origem do Requisito: | Projetista de Software - Especificação Suplementar |
| Critério de Aceitação: | O aplicativo deve possuir uma arquitetura funcional, dividida em backend e frontend, com uso de spring boot e react native respectivamente. |
| Dependências: | Conhecimento do desenvolvedor e suporte das liguagens aos objetivos da aplicação. |
| Prioridade: | NA (Requisito Originado na especificação suplementar) |
| Conflitos: | Nenhum |
| História: | NA (Requisito Originado na especificação suplementar) |
Autor - Amanda Campos, 2024.
NFR07: Implementação
Figura 9: Decomposição do softgoal Implementação em requisitos não funcionais mais específicos.
Autor - Johnny Lopes, 2024.
Tabela 8: Cartão de especificação NFR07.
| Nº Requisito: NFR07 (RF39) | Classificação: Implementação |
|---|---|
| Descrição: | O aplicativo deve garantir a segurança das informações pessoais dos usuários através de criptografia de dados e autenticação robusta. |
| Justificativa: | A proteção das informações pessoais é crucial para manter a confiança dos usuários e cumprir com regulamentações de privacidade e segurança de dados. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O sistema deve implementar e ser testado para garantir a criptografia de dados e métodos de autenticação robustos, conforme padrões de segurança. |
| Dependências: | Protocolos de criptografia, serviços de autenticação, regulamentos de segurança de dados |
| Prioridade: | 10 |
| Conflitos: | Nenhum |
| História: | 21/06/2024 |
Autor - Johnny Lopes, 2024.
NFR08: Suportabilidade
Figura 10: Decomposição do softgoal Suportabilidade em requisitos não funcionais mais específicos.
Autor - Paulo Borba, 2024.
Tabela 9: Cartão de especificação NFR08.
| Nº Requisito: 8 NFR08 (RE29) | Classificação: Suportabilidade |
|---|---|
| Descrição: | O aplicativo deve ser compatível com as versões mais recentes e anteriores dos sistemas operacionais iOS e Android, bem como com computadores. |
| Justificativa: | Garantir que o aplicativo possa ser utilizado pela maior quantidade possível de usuários, independentemente da versão do sistema operacional que estejam utilizando. |
| Origem do Requisito: | Projetista de Software |
| Critério de Aceitação: | O aplicativo deve funcionar corretamente nas versões especificadas dos sistemas operacionais iOS e Android, bem como em diferentes sistemas operacionais de computadores (Windows, macOS, Linux). |
| Dependências: | Atualizações de software, testes de compatibilidade. |
| Prioridade: | 1,73 |
| Conflitos: | Pode haver conflito com a necessidade de utilizar APIs ou recursos específicos de versões mais recentes dos sistemas operacionais. |
| História: | 27/06/2024 |
Autor - Paulo Borba, 2024.
Softgoal Interdependency Graph
Figura 11: Softgoals NFR do Meu INSS.
Autor - Amanda Campos, Bianca Castro, Gabriel Souza, Johnny Lopes, José Souza, Paulo Borba, Vitor Leonardo, 2024.
Operacionalização e priozição
Enquanto que o processo de refinamento até agora fornece interpretações mais especificas do que os NFRs iniciais, como "Usabilidade", significam, isso não fornece ainda meios para realmente alcançar o requisito. Em algum ponto, quando os requisitos funcionais forem suficientemente refinados, será possível identificar possíveis técnicas de desenvolvimento para alcançar tais requisitos (Chung et al, 2000, p. 27).
Figura 12: Identificação de operacionalizações e priorizações.
< Autores - Amanda Campos, Bianca Castro, Gabriel Souza, Johnny Lopes, José Souza, Paulo Borba, Vitor Leonardo, 2024.
Afirmações de design
Foca-se, aqui, na inserção de calim softgoals, ou seja, o terceiro tipo de softgoal, em que se anexa aos links de interdependência, dessa forma, argumentando a relação entre os concetados. Os claim softgoals são representadas como nuvens tracejadas no gráfico de interdependência de metas flexíveis. Seus vínculos de interdependência representam os argumentos (Chung et al, 2000, p. 33 e 35).
Figura 13: Inserção de afirmações de design.
Autores - Amanda Campos, Bianca Castro, Gabriel Souza, Johnny Lopes, José Souza, Paulo Borba, Vitor Leonardo, 2024.
Seleção entre alternativas
Nessa etapa, foram escolhidas as melhoras alteranativas, pelo desenvolvedores. Respretentadas na imagem 14.
Figura 14: Seleção das alternativas.
Autores - Amanda Campos, Bianca Castro, Gabriel Souza, Johnny Lopes, José Souza, Paulo Borba, Vitor Leonardo, 2024.
Bibliografia
Islam, S.M. Zahidul. “What are some ways to reduce network usage in a mobile app?” MUO, 15 de março de 2017. Disponível em: https://www.linkedin.com/advice/3/what-some-ways-reduce-network-usage-mobile-app-jjo1e. Acesso em : 30 mai. 2024.
Mwaura, Waweru. “Making HTTP requests with Axios.” CircleCI, 6 de fevereiro de 2023. Disponível em: https://circleci.com/blog/making-http-requests-with-axios/. Acesso em : 30 mai. 2024.
Ipsen, Adam. “Backup Software vs Data Recovery: Pros and Cons.” Cyber Resilience Blog, 9 de novembro de 2016. Disponível em: https://www.backupassist.com/blog/backup-software-vs-data-recovery-pros-and-cons. Acesso em : 30 mai. 2024.
Referências Bibliográficas
SILVA, Reinaldo Antônio. NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Dissertação (Mestrado em Ciência da Computação) - Centro de Informática da Universidade Federal de Pernambuco, [S. l.], 2019. Disponível em: https://aprender3.unb.br/pluginfile.php/2845051/mod_resource/content/2/DISSERTA%C3%87%C3%83O%20Reinaldo%20Ant%C3%B4nio%20da%20Silva.pdf. Acesso em: 27 mai. 2024.
Chung, L., Nixon, B. A., Yu, E., & Mylopoulos, J. (2000). Non-Functional Requirements in Software Engineering. Springer. Disponível em: https://link.springer.com/book/10.1007/978-1-4615-5269-7. Acesso em : 30 mai. 2024.
Histórico de Versões
| Versão | Data | Descrição | Autor(es) | Data de revisão | Revisor(es) |
|---|---|---|---|---|---|
1.0 |
27/05/2024 | Criação do documento | José Filipi & Vitor Feijó | 27/05/2024 | Paulo Borba |
1.1 |
30/06/2024 | Metodologia & Softgoal 1 e 2 | Vitor Feijó | 30/05/2024 | Paulo Borba |
1.2 |
30/05/2024 | Softgoal 3 | Bianca Castro | 30/05/2024 | Gabriel Souza |
1.3 |
30/05/2024 | Softgoal 4 | Gabriel Souza | 30/05/2024 | José Filipi |
1.4 |
30/05/2024 | Softgoal 5 | José Filipi | 30/05/2024 | Amanda Campos |
1.5 |
30/05/2024 | Softgoal 6 | Amanda Campos | 30/05/2024 | Johnny Lopes |
1.6 |
30/05/2024 | Softgoal 7 | Johnny Lopes | 30/05/2024 | Vitor Feijó |
1.7 |
30/05/2024 | Softgoal 8 | Paulo Borba | 30/05/2024 | Gabriel Souza |
1.9 |
02/06/2024 | Adição dos SIGs de operacionalização, afirmação e seleção de alternativas. | Vitor Feijó | 02/06/2024 | Bianca Castro |
2.0 |
21/06/2024 | Adição dos cartões de especificação. | Johnny Lopes | 22/06/2024 | Gabriel Souza |
2.1 |
22/06/2024 | Adição do cartão de especificação NFR04. | Gabriel Souza | 27/06/2024 | Paulo Borba |
2.2 |
27/06/2024 | Adição do cartão de especificação NFR08. | Paulo Borba | 27/06/2024 | Gabriel Souza |
2.3 |
29/06/2024 | Adição do cartão de especificação NFR05. | José Filipi | 29/06/2024 | Paulo Borba |