O particionamento de equivalência e a análise de valor limite são técnicas estruturais de teste. O particionamento de equivalência visa minimizar a quantidade de casos de teste ao selecionar um caso de teste em cada classe de equivalência. Por sua vez, a análise de valor limite complementa o particionamento de equivalência, pois requer casos de teste nos limites de cada classe de equivalência. O uso da análise de valor limite tipicamente produz uma menor quantidade de casos de teste do que o mero uso do particionamento de equivalência.

O teste de software, uma atividade de validação e verificação, consiste em executar o produto para verificar a presença de defeitos e aumentar a confiança que o produto está correto. Na fase dedicada aos testes de unidade, procura-se identificar erros de lógica e de implementação nas unidades que compõem o sistema de software. Além disso, nessa fase, as unidades são integradas visando-se descobrir erros nas interfaces entre unidades.

Se a chave de uma relação for MATRICULA, então, uma relação que respeite as seguintes dependências funcionais na tabela a seguir, encontra-se na terceira forma normal (3FN).

Se a chave de uma relação for composta por CODIGO e CEP, então uma relação que respeite as dependências funcionais na tabela a seguir encontra-se na segunda forma normal (2FN).

Considerando que o projeto de um banco de dados relacional para modelo seja composto pelas relações PEDIDO, ITEM, CLIENTE e ENDERECO, é correto afirmar que, na relação PEDIDO, tem-se as colunas CODIGO, DATA e PRECO; na relação ITEM, tem-se apenas as colunas NUMERO, VALOR e QUANTIDADE; e MATRICULA é chave estrangeira na relação ENDERECO.

No RUP, é recomendado: desenvolver o sistema de software iterativamente; construir modelos usando a UML para representar tanto a visão estática, quanto a dinâmica; estruturar a arquitetura do sistema de software usando componentes modulares e avaliar o nível de qualidade dos artefatos em diversos momentos do ciclo de vida.

No rational unified process (RUP), o ciclo de vida de cada software é decomposto em quatro fases seqüenciais. Em um ciclo de vida, cada fase pode ser dividida em iterações; em cada interação podem ser realizadas atividades de variadas disciplinas, por exemplo, das disciplinas de implementação e de teste. A fase final em um ciclo está relacionada à transferência do sistema da comunidade de desenvolvimento para a de usuários.

O projeto de um software procura dividir o software em componentes que executem funções específicas e levar a interfaces que minimizem a complexidade de conexões entre os módulos. No projeto preliminar, procura-se transformar os requisitos em uma arquitetura de dados e software. No projeto detalhado, os componentes individuais podem ser refinados até o nível de interfaces, classes ou componentes preexistentes.

A análise de requisitos envolve atividades como: reconhecimento do problema; avaliação e síntese; modelagem; especificação e revisão. Durante a análise de requisitos, podem ser criados modelos, os quais se concentram naquilo que o sistema deve fazer, não em como ele o faz. Os modelos construídos quando da análise servem de base para o projeto. Quando da elaboração de modelos no projeto, serão considerados aspectos relacionados ao contexto de implementação.

Um documento WSDL descreve formalmente a interface do ponto de contato (endpoint) de um provedor de serviço e a localização física do serviço. Na porção concreta de uma definição WSDL, tem-se descrições de requisitos para que conexões sejam estabelecidas com o serviço. As estruturas de mensagens SOAP não podem ser definidas com WSDL, uma vez que tais mensagens têm as estruturas das mensagens usadas nos protocolos RPC (remote procedure call).