a) descrever os requisitos funcionais, os não funcionais e as regras do negócio do sistema através de um modelo de caso de uso. (ERRADO: as regras de negócio do sistema não são descritas nos casos de uso)
b) organizar a arquitetura do sistema de software de acordo com cinco visões (views), que são: requisitos, análise, projeto, testes e implantação. (ERRADO: não são visões, mas disciplinas)
c) planejar em detalhes, na fase de iniciação, cada iteração das demais fases do desenvolvimento do sistema, o que envolve alocar recursos para cada uma dessas iterações. (ERRADO: o planejamento em detalhes se dá na fase de elaboração)
d) verificar, de forma contínua, a qualidade do software em desenvolvimento, desde a fase de iniciação até a fase de transição. (CORRETO: apesar de eu não gostar do termo iniciação, mas concepção)
e) tratar os requisitos mais arriscados mais tarde no desenvolvimento do projeto de modo a evitar a volatilidade dos mesmos. (ERRADO: tratar os requisitos mais arriscados antes)
Complementando o excelente comentário do colega Ash:
1) Casos de uso tratam apenas requisitos funcionais (funcionalidades que são visíveis aos usuários).
2) Com relação à letra B, temos que: Existem opiniões diferentes sobre para que as visões são neccessárias. Kruchten (1995), em seu bem conhecido modelo de visão 4 + 1 de arquitetura de software, sugere que deve haver quatro visões fundamentais de arquitetura, relacionadas usando-se casos de uso ou cenários. As visões que ele sugere são:
- visão lógica: abstrações fundamentais do sistema como objetos ou classes de objetos
- visão de processo: mostra como, no tempo de execução, o sistema é composto de processos interativos
- visão de desenvolvimento: mostra como o software é decomposto para o desenvolvimento
- visão física: mostra o hardware do sistema e como os componentes de software são distribuídos entre os processadores
Hofmeister el al. (2000) sugerem o uso de visões semelhantes, mas acrescentam a noção de uma visão conceitual. Essa é uma visão abstrata do sistema que pode ser a base para decomposição de requisitos de alto nível em especificações mais detalhadas, ajuda os engenheiros a tomarem decisões sobre os componentes que podem ser reusados e representa uma linha de produtos ao invés de um único sistema.
Fonte: Sommerville, 9ª Edição, Capítulo 6.
Bons estudos!