Um dos princípios fundamentais de análise é a partição. No projeto de sistemas orientado a objetos, parte-se o modelo de análise para definir coleções de classes, relacionamentos e comportamentos coesivos.

Um projeto orientado a objetos possui quatro camadas: camada de subsistema, camada de classes e objetos, camada de mensagens e camada de responsabilidade. Nessa última camada, estão as estruturas de dados e o projeto algorítmico de todos os atributos e operações de cada objeto.

A representação gráfica de um diagrama de fluxo de dados (DFD) é a seguinte: um retângulo para representar uma entidade externa, um círculo para representar um processo, uma seta para representar itens de dados e linhas duplas para representar depósitos de dados.

O dicionário de dados é uma forma de organizar os elementos de dados em entidades e depósitos. As entradas e saídas devem ser descritas no diagrama de fluxos de dados.

O diagrama entidade/relacionamento permite especificar os objetos de dados que são entradas e saídas de um sistema, os atributos que definem as propriedades desses objetos e suas relações.

O processo de análise orientada a objetos começa com a preocupação com os objetos e depois com a forma pela qual o sistema vai ser usado. Depois de definido o cenário de uso, começa a modelagem do software.

A UML usa uma combinação de diagramas de estado, diagramas de seqüência, diagramas de colaboração e diagramas de atividade para representar o comportamento estático dos objetos e classes que tiverem sido identificados como parte do modelo de análise.

A análise orientada a objetos de sistemas pode ocorrer em muitos níveis de abstração diferentes. No nível de negócio ou de empresa, as técnicas associadas com a orientação a objetos podem ser combinadas com uma abordagem de engenharia de processos de negócios para definir classes, objetos, relacionamentos e comportamentos que modelem todo o negócio.

No nível de maturidade 2 do modelo CMM, o processo de desenvolvimento, tanto para atividades de gerência quanto de engenharia de software, encontra-se documentado, padronizado e integrado em um processo de desenvolvimento de software válido para toda a organização.

No método de análise CPM, uma atividade crítica é definida como uma atividade que leva à construção de um módulo de software imprescindível para o funcionamento de um sistema, independentemente do impacto que tal atividade tenha na duração ou na seqüência de atividades do projeto.