É muito comum que existam dúvidas na hora de classificar requisitos em funcionais e não funcionais durante a elicitação de requisitos de software . Essa classificação torna-se ainda mais desafiadora quando além de funcionalidades e restrições, são também identificadas regras de negócio junto aos interessados pelo produto; isso porque, regras de negócio, assim como requisitos não funcionais, também são vistos como restrições para as funcionalidades do software .
Observe o quadro a seguir:
1) Requisito Funcional
A) O sistema escolar deve possuir integração com o portal do MEC para captura e exibição de notícias atualizadas sobre a educação básica do país, incluindo datas de inscrições em programas do Governo.
2) Requisito Não Funcional
B) Como aluno, quero poder visualizar minhas notas de provas realizadas para acompanhar meu desempenho em cada disciplina cursada.
3) Regra de Negócio
C) Um aluno poderá se inscrever em até 6 disciplinas por semestre desde que seus horários de aula não coincidam.
4) Não Requisito de Software
D) O coordenador de cada curso deverá participar de todas as reuniões de requisitos para apoiar o levantamento de funcionalidades, características de qualidade e regras de negócio para o sistema em desenvolvimento.
Assinale a alternativa com a correta correspondência entre classificação e exemplo.
1-B; 2-A; 3-C e 4-D.
1-D; 2-C; 3-B e 4-A.
1-B; 2-C; 3-A e 4-D.
1-A; 2-B; 3-C e 4-D.
1-D; 2-C; 3-A e 4-B.
Respostas
Resposta:
1-B; 2-C; 3-A e 4-D.
Explicação:
Resposta:
1-B; 2-A; 3-C e 4-D.
Explicação:
O exemplo (A) não pode ser considerado um requisito funcional, pois explicita uma característica de qualidade de software referente à integração do software
com outros sistemas (interoperabilidade), além disso, apesar de ser considerada uma restrição ao sistema, não pode ser visto como uma restrição ao negócio como um todo, já que a integração é mais técnica que de negócio em si.
O exemplo (B), por sua vez, não representa nenhuma restrição de negócio e nem uma característica de qualidade de software para ser classificado como uma regra de negócio ou como um requisito não funcional.
O exemplo (C), embora descrever uma restrição clara para funcionalidades, é visto como algo puramente de negócio, não representando uma característica de qualidade de software para representar um requisito não funcional.
O exemplo (D) diz respeito a um requisito de projeto de desenvolvimento de software, já que não há relação dele com qualquer capacidade ou característica que o software a ser construído deva implementar.