A gestão de requisitos é um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos somente no início do projeto. Durante o projeto não se recomenda a alteração dos requisitos anteriormente levantados.

A validação de requisitos examina a especificação para garantir que todos os requisitos do sistema tenham sido declarados de modo não-ambíguo. O principal mecanismo de validação de requisitos é o diagrama de classes definido pela UML.

Problemas como de escopo, em que o sistema é mal definido ou o cliente/usuário especifica detalhes técnicos desnecessários que podem confundir em vez de esclarecer, fazem do levantamento dos requisitos uma atividade de extrema importância.

O modelo de desenvolvimento fundamentado em componentes incorpora muitas das características do modelo incremental. A atividade de engenharia começa com a identificação dos métodos, demandando assim uma atividade interativa.

O modelo de processo concorrente é freqüentemente usado como paradigma para o desenvolvimento de aplicações cliente/servidor. Esse modelo define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades de engenharia de software.

O modelo em espiral ganha-ganha define um conjunto de atividades de negociação no começo de cada passagem em torno da espiral. Além disso, define pontos marcos que ajudam a estabelecer quando um ciclo começa em torno da espiral.

Um modelo espiral é dividido em um certo número de atividades que formam uma estrutura denominada regiões de tarefas. As regiões mais comuns são: comunicação com o cliente; planejamento; análise de riscos; engenharia; construção e liberação; avaliação pelo cliente.

Quando um modelo incremental é usado, o primeiro incremento é freqüentemente denominado núcleo do produto. Nesse caso, os requisitos básicos são satisfeitos, mas muitas características suplementares deixam de ser elaboradas.

Em um sistema orientado a objetos, podem ser usados mecanismos como a herança e a composição. Usando-se composição, um padrão de projeto existente torna-se um gabarito para uma nova subclasse. Por sua vez, a herança permite que um objeto complexo seja decomposto em objetos menos complexos.

O aspecto dinâmico do modelo objeto-comportamento fornece uma indicação da concorrência entre classes. Se classes não são ativadas ao mesmo tempo, não há necessidade de processamento concorrente. Quando subsistemas são concorrentes, a única alternativa é alocar cada subsistema a um processador independente.