Na literatura clássica de Engenharia de Software (especialmente em Ian Sommerville e Roger Pressman), a Engenharia de Requisitos não é um bloco único, mas sim um conjunto de tarefas sequenciais (e muitas vezes iterativas).

A fase de Análise de Requisitos (frequentemente chamada de Análise e Negociação) é o "filtro" do processo. É neste exato momento que a equipe pega a informação bruta coletada, identifica os problemas como os motoristas querendo rastreamento por paradas e os gerentes exigindo tempo real e senta com os stakeholders para negociar, priorizar e resolver esses conflitos. O objetivo final da Análise é gerar um modelo coerente e sem contradições antes de escrever o documento final.

letra d)

A elicitação e análise de requisitos podem envolver diversos tipos de pessoas em uma organização.  As atividades do processo são:

1. Descoberta de requisitos. Essa é a atividade de interação com os stakeholders do sistema para descobrir seus requisitos. Os requisitos de domínio dos stakeholders e da documentação também são descobertos durante essa atividade. Existem várias técnicas complementares que podem ser usadas para descoberta de requisitos, que discuto mais adiante.

2. Classificação e organização de requisitos. Essa atividade toma a coleção de requisitos não estruturados, agrupa requisitos relacionados e os organiza em grupos coerentes. A forma mais comum de agrupar os requisitos é o uso de um modelo de arquitetura do sistema para identificar subsistemas e associar requisitos a cada subsistema. Na prática, a engenharia de requisitos e projeto da arquitetura não podem ser atividades completamente separadas.

3. Priorização e negociação de requisitos. Inevitavelmente, quando os vários stakeholders estão envolvidos, os requisitos entram em conflito. Essa atividade está relacionada com a priorização de requisitos e em encontrar e resolver os conflitos por meio da negociação de requisitos. Normalmente, os stakeholders precisam se encontrar para resolver as diferenças e chegar a um acordo sobre os requisitos.

4. Especificação de requisitos. Os requisitos são documentados e inseridos no próximo ciclo da espiral.

Fonte: Engenharia de Software -  Ian Sommerville - nona edição