-
Um dos erros é
Requisitos funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, pois os requisitos funcionais estão ligados às funcionalidades e comportamentos do sistema. Restrição está mais voltada para o Requisito NÃO FUNCIONAL.
-
Requisitios funcionais: declarações de serviços que um sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve (ou não) se comportar em situações particulares.
Requisitios não funcionais: são restrições nos serviços ou funções.
Requisitos de domínio: são requisitos derivador do domínio da aplicação e refletem características de sua área de negócio.
-
Assertiva ERRADA.
"Reagir a entradas" = casos de uso = requisitos funcionais.
Já quando você adjetiva o software (fácil de usar, rápido, intuitivo, compatível com windows 3.1), estamos falando dos requisitos não-funcionais.
Por fim, quando os requisitos derivam do negócio ou da área de aplicação, temos os requisitos de domínio, que podem ser funcionais ou não-funcionais.
-
A questão falou em requisitos funcionais, mas com definições de requisitos não funcionais que são os que restringem sobre os requisitos funcionais. Requisitos de domínio são naturais do tipo de negócio a que se propõe a aplicação. Nada melhor que exemplos lkkkk:
Requisitos não funcionais: Os dados do usuário devem ser criptografados, a senha deve ser por meios biométricos, o sistema deve responder a um tempo limite de 4 segundos a cada requisição.
Requisitos de domínio: o cálculo para esse projeto espacial deve ser: xª{2%6(*2ªºª)}. Observe que isso é próprio da aplicação.
-
Os requisitos de domínio são derivados do domínio da aplicação do sistema que podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes ou estabelecer como devem ser executados cálculos específicos. Muitas vezes esses requisitos refletem fundamentos do domínio da aplicação (SOMMERVILLE, 2008). Sem uma compreensão satisfatória desses requisitos pode ser impossível fazer o sistema operar de forma satisfatória (PRESSMAN, 2006).
Esses requisitos são expressos com o uso de uma linguagem específica do domínio da aplicação e, geralmente, de difícil compreensão para os engenheiros de software. Os especialistas do domínio podem, por julgarem óbvio, deixarem de fornecer informações importantes e como resultado o requisito pode não ser implementado de forma satisfatória (SOMMERVILLE, 2008).
http://www.semeru.com.br/blog/category/requisitos-de-dominio/