Para se chegar ao produto, a primeira ação que se deve fazer é definir o escopo do projeto. Para tal, é necessário realizar um levantamento inicial de requisitos, decompondo-se o problema segundo a abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em submódulos ou funções, até que se obtenha uma visão geral das funcionalidades a serem tratadas no projeto.

Um processo de elicitação e análise de requisitos envolve as seguintes atividades: obtenção de requisitos, em que são coletados os requisitos e os requisitos de domínio; classificação e organização de requisitos, que agrupa e organiza os requisitos relacionados; priorização e negociação de requisitos, em que, com a participação dos stakeholders, são resolvidos os conflitos de requisitos; e documentação de requisitos, para a produção dos documentos de requisitos formais ou informais.

Requisitos não funcionais são declarações dos serviços a serem fornecidos pelo sistema, enquanto requisitos funcionais restringem tanto o sistema quanto o processo de desenvolvimento que deve ser usado. Os requisitos funcionais podem ser de produto, organizacionais ou externos.

São consideradas técnicas de validação de requisitos: revisões de requisitos, prototipação e geração de casos de teste.

Considerando os aspectos de linguagem de programação, julgue o item subsequente.


A validação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a verificação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

Visando a maior efetividade no processo de desenvolvimento, os requisitos de software são, em geral, desenvolvidos antes dos requisitos de sistema.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

A área de atividade de requisitos de software apresenta maior interface com a engenharia de sistemas quando comparada à área de análise e projeto de software.

O documento de requisitos de software estabelece formalmente o que os desenvolvedores de sistema devem implementar e incluir a especificação resumida dos requisitos do sistema e a visão detalhada da arquitetura do sistema.

A descrição dos cenários de uso com informações acerca da utilização do sistema sob diversos pontos de vista e formas de operação deve fazer parte do levantamento dos requisitos.

O questionamento acerca da consistência, das omissões e das ambigüidades dos requisitos obtidos faz parte da função de validação dos requisitos.

A entrevista é uma técnica de elicitação de requisitos simples, eficiente e direta e, por esses motivos, pode ser usada como fonte exclusiva de informação acerca dos requisitos do sistema.

Visando a maior efetividade no processo de desenvolvimento, os requisitos de software são, em geral, desenvolvidos antes dos requisitos de sistema.

A área de atividade de requisitos de software apresenta maior interface com a engenharia de sistemas quando comparada à área de análise e projeto de software.