Um objeto apresenta três características básicas, o estado, a identidade e o comportamento. A parte de dados de um objeto é definida por um conjunto de mensagens, e a porção funcional, por um conjunto de atributos.

Classes são constituídas por interfaces e nelas definidas. O nome de uma classe deve ser único e tem escopo dentro da interface na qual é declarado.

Se os requisitos forem organizados de acordo com os diversos pontos de vista relativos a grupos de usuários do sistema, é possível identificar aqueles comuns a todos ou à maioria dos pontos de vista. Esses requisitos comuns podem estar relacionados a assuntos separados, implementados como extensões da funcionalidade central.

Em sistemas de grande porte, um único requisito pode ser implementado por diversos componentes; cada componente, por sua vez, pode incluir elementos de vários requisitos, o que facilita o seu reúso, pois os componentes implementam, normalmente, uma única abstração do sistema.

Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, e podem ser, também, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações.

Nos testes de caixa branca, o código-fonte do programa é usado para identificar testes de defeitos potenciais, particularmente no processo de validação, o qual demonstra se um programa atende a sua especificação.

Considerando-se o programa final como caixa preta, a validação dinâmica, ou teste, pode ser utilizada para identificar a ocorrência de defeitos no programa ou para confirmar se ele atende aos requisitos estabelecidos.

Para a verificação de resultados de um protótipo de sistema, podem-se utilizar testes back-to-back, nos quais os mesmos casos de teste são submetidos ao protótipo e ao sistema em teste a fim de se produzir um relatório de diferenças.

Na extreme programming, os requisitos são expressos como cenários e implementados diretamente como uma série de tarefas. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.

No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um software. Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento, desde que os itens alterados não estejam na sprint backlog. Isso significa que product backlog e sprint backlog são estruturas similares.