| << Chapter < Page | Chapter >> Page > |
Apesar da classificação dos requisitos de software em requisitosfuncionais e não-funcionais ser bem aceita, devemos observar que na práticaessa divisão pode não ser tão clara. Isso ocorre devido ao nível de detalhescontido em sua descrição ou mesmo devido ao tipo de sistema desenvolvido.
Podemos ilustrar o caso em que o nível de detalhes faza diferença com o seguinte exemplo:
Se considerarmos um requisito de segurança de confidencialidade(e normalmente considerado não-funcional):
Uma vez que não especifica nenhuma funcionalidade,esse pode ser considerado um requisito não-funcional. Por outro lado,poderíamos deixar essa evidente característica de requisito não-funcionalum pouco mais turva se adicionarmos um pouco mais de detalhes a ele:
Agora, esse requisito seria melhor classificado comofuncional, uma vez que especifica uma função do sistema, apesar doatributo de qualidade exibido pelo software ao final do desenvolvimentoserá o mesmo: segurança, mais especificamente confidencialidade das mensagensenviadas.
Já quando mencionamos que o tipo do sistema pode influenciarem como classificamos um requisito, basta apenas lembrarmos dos sistemasde tempo-real. Neles, a corretude do comportamento do sistema não dependesó do resultado lógico da função, mas também quando esse resultado é obtido. Portanto, uma resposta cedo ou tarde demais podeestar tão incorreta quanto uma resposta logicamente errada.
Em um sistema de informação, consideramos o requisitonão-funcional:
Já em um sistema de controle de voo fly-by-wire , devemos considerar o requisitoa seguir como funcional, uma vez que respostas que não respeitamo intervalo de tempo especificado são tão inúteis quanto a faltade resposta dos sensores (podem causar a queda do avião):
Notification Switch
Would you like to follow the 'Arquitetura de software' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|