Para mim, o objetivo fundamental da SRS é informar ao time de software o que o software deve fazer . Esta é uma alternativa para apenas fazer as coisas à medida que você avança (aka "ágil").
Se você está indo orientado a objeto, então você precisa ter uma abordagem de análise e design orientada a objeto. Muito provavelmente, o primeiro passo é identificar os atores na SRS e identificar os objetos (pode haver apenas um neste nível).
Depois, você pode desenvolver casos de uso. Provavelmente são vários diagramas de casos de uso, a menos que você queira um diagrama monstruosamente grande.
Mais tarde, você dividiria os objetos em pacotes e depois em classes.
A consistência é feita pela rastreabilidade, até o fim. Todo requisito de software deve ser tratado por algo abaixo dele em seu design (geralmente um caso de uso, mas nem sempre). Uma "matriz de requisitos" geralmente é a melhor maneira de documentar isso.
Em casos extremos (como segurança crítica), você pode ter que ir tão longe com sua rastreabilidade de requisitos que se alguém apontar para uma linha em seu código e perguntar "o que é isso?", você pode rastrear todo o caminho faça backup para responder exatamente qual (is) requisito (s) está ajudando a satisfazer.