Verificação do NFR Framework do Grupo
Introdução
Realizado o planejamento do que verificar, é o momento de realizar a inspeção em si. Esse documento apresenta os objetivos da verificação, a metodologia utilizada e os dados da verificação. Além disso, os principais problemas encontrados são sumarizados e analisados obtendo informações valiosas que serão utilizadas para sugerir ações corretivas para os mesmos.
Objetivo
O objetivo deste documento é relatar os resultados das verificações realizadas em cima do artefato do NFR Framework da Etapa 3 do Grupo.
Metodologia
Os resultados da verificação do artefato foram obtidos a partir das checklists elaboradas na página de planejamento. Para responder às perguntas apresentadas nas checklist o avaliador usará as opções Sim, Não, Incompleto ou Não se aplica. O avaliador poderá também escrever observações em cada pergunta detalhando pontos que achar necessários. A checklist foi feita com base na dissertação de mestrado de Reinaldo Antônio da Silva1.
Cronograma e Participantes
Os participantes serão os integrantes do Grupo 1: Arthur de Melo, que será responsável por realizar a avaliação e Rafael Ferreira, que realizará a revisão do artefato produzido pelo avaliador. Em relação ao cronograma seguido, ele já foi explicitado na página de planejamento. A tabela 1 apresenta os participantes dessa verificação.
Tabela 1 - Participantes da Verificação.
| Participante | Papel |
|---|---|
| Arthur de Melo | Avaliador |
| Rafael Ferreira | Revisor |
Fonte: Elaborada por Arthur de Melo, 2023.
Sumário Dos Dados
A Tabela 2 apresenta a checklist com os dados obtidos a partir da verificação.
Tabela 2 - Checklist de Verificação.
| ID | Descrição | Avaliação | Observações |
|---|---|---|---|
| 1 | O artefato possui introdução? | Sim | |
| 2 | O artefato possui uma bibliografia/referência bibliográfica? | Sim | |
| 3 | O artefato possui um histórico de versões com o id e descrição das versões, data, autores e revisores? | Sim | No entanto, os ID's do versionamento estão com números repetidos e errados. |
| 4 | Todas as tabelas e imagens são chamadas no texto, possuem legendas e fontes? | Sim | |
| 5 | Todos os textos estão na norma padrão? | Sim | |
| 6 | Os gráficos SIG foram validados por Fontes Externas?1 | Incompleto | SIG de Usabilidade |
| 7 | Cada SIG possui sua respectiva propagação de Impacto?1 | Sim | |
| 8 | Os softgoals se refinam até um nível de especificação bem definido?1 | Incompleto | Os SIG's de Eficiência e de Desempenho |
| 9 | Os cartões de especificação representam requisitos não-funcionais verificáveis? | Sim | |
| 10 | Os cartões de especificação possuem: Identificador, Classificação, Descrição, Justificativa, Origem, Critério de Ajuste, Dependências, Prioridade, Conflitos e História?1 | Sim | |
| 11 | Os Softgoals NFR estão representados apropriadamente dada a sua definição?1 | Sim | |
| 12 | Os Softgoals de Operacionalização estão representados apropriadamente dada a sua definição?1 | Sim | |
| 13 | Os Softgoals de Afirmação estão representados apropriadamente dada a sua definição?1 | Incompleto | Nos SIG's de Eficiência e de Desempenho |
| 14 | Os requisitos não-funcionais apresentados nos cartões foram priorizados com algum método? | Sim |
Fonte: Arthur de Melo, 2023.
Lista de Problemas e Análise
ID 6 - Os gráficos SIG foram validados por Fontes Externas?
Sim, por três fontes. Contudo, o SIG de Usabilidade apresenta um elemento não validado pelas fontes externas utilizadas, que é o de "Disponibilidade", o qual pode ser trocado sem maiores entraves por "Acessibilidade". Essa alteração, inclusive, é validada pelas fontes já utilizadas e não altera o curso do SIG.
ID 8 - Os softgoals se refinam até um nível de especificação bem definido?
Por exemplo, nos SIG's de Eficiência e de Desempenho, os softgoals de claim não apresentam limitações específicas. Dentro do SIG referido, podemos citar um: "Processar rapidamente". Esse requisito não é verificável, dado que para um requisito ser verificável, vale da seguinte definição: "Um requisito é verificável se existir um processo finito, com custo compensador, que possa ser executado por uma pessoa ou máquina, e que mostre a conformidade do produto final com o requisito"2.
ID 13 - Os Softgoals de Afirmação estão representados apropriadamente dada a sua definição?
Os softgoals de afirmação são fatores delimitantes dentro de um domínio, ou seja, servem como um filtro para as características4. No entanto, nos dois SIG's citados acima, os softgoals de claim não apresentam soluções testáveis, somente são especificadas no cartão de especificação, mas já deveria ser identificável nos claims.
Sugestões de Correções
- Especificar os softgoals de afirmação nos SIG's de Eficiência e de Desempenho.
- Alterar o tópico de "Disponibilidade" por "Acessibilidade" no SIG de Usabilidade.
- Arrumar o histórico de versão.
Acompanhamento
A figura 1 apresenta um gráfico com o percentual de respostas sim, não ou incompleto, obtidas através da checklist de verificação.
Figura 1 - Gráfico do resultado da verificação.
Fonte: Arthur de Melo, 2023.
Retrabalho
Como proposto por Fagan, para o retrabalho os autores do artefato verificado serão responsáveis em um primeiro momento por corrigir os problemas apresentados seguindo a lista de sugestão de correção apresentada anteriormente, porém há a possibilidade de outros integrantes do grupo realizarem as correções propostas. O responsável por essa verificação fará uma revisão das correções feitas, checando se as correções são suficientes e se foi introduzido novos erros ou não. A tabela 3 a seguir apresenta o cronograma de correções.
Tabela 3 - Cronograma de Correções.
| Data de Correção | Descrição | Responsável(eis) | Revisor(es) | Status |
|---|---|---|---|---|
| 01/07/2023 | Correção SIG usabilidade. | Arthur de Melo | Matheus Henrique | |
| 01/07/2023 | Correção dos softgoals de claim e histórico de versão. | Arthur de Melo | Matheus Henrique |
Fonte: Elaborado por Arthur de Melo, 2023.
Info
O cronograma apresentado na tabela 3 pode ser alterado.
Referências Bibliográficas
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: 10/06/2023.
2. MESQUITA, Renato Cardoso. Engenharia dos requisitos de software. Departamento de Eng. Elétrica da UFMG, Belo Horizonte, 2019. Disponível em: https://www.cin.ufpe.br/~joa/menu_options/school/cursos/engsoft/aulas/requisitos-conceitos.pdf. Acesso em: 10/06/2023.
3. MAIRIZA, D.; ZOWGHI, D.; NURMULIANI, N. An investigation into the notion of non-functional requirements. In: Proceedings of the 2010 ACM Symposium on Applied Computing. ACM: [s.n.], 2010. p. 311–317.
4.CHUNG, L., NIXON, B. A., YU, E., MYLOPOULOS, J. Non-functional requirementsin software engineering. Springer Science & Business Media: [S.l.], 2000. v. 5.
Histórico de Versões
| Versão | Data | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
1.0 |
21/06/2023 | Criação da página. | Arthur de Melo | Gabriel Campello |
1.1 |
01/07/2023 | Retrabalho. | Arthur de Melo | Matheus Henrique |