O gerenciamento de mudanças de requisitos de software se propõe a garantir o escopo de um sistema a partir da formalização de procedimentos entre os envolvidos no desenvolvimento para a solicitação, a avaliação, a aprovação e a garantia da implementação das mudanças nos requisitos.

O arquivo de interface externa, que armazena dados referenciados, é um tipo de função de dados lidos e mantidos pela aplicação.

A aplicação da análise por pontos de função para a mensuração de funcionalidades de software depende da tecnologia utilizada na construção do software, uma vez que esforço e tempo despendidos dependem da forma como o produto é construído.

No RUP (Rational Unified Process), a qualidade de software é um quesito contemplado somente nas seguintes fases do ciclo de desenvolvimento: implementação, teste e entrega.

Assim como no modelo em cascata, no RUP (Rational Unified Process) as fases de concepção, elaboração, construção e transição coincidem com as atividades técnicas do processo de desenvolvimento de software.

A NESMA — manual de contagem de pontos de função embasado no CPM — facilita a estimativa do tamanho do produto e tem como referência as funções de dados e transações, sem que haja detalhamento de cada elemento da função.

A norma ISO 15504 apresenta um framework de avaliação tanto do processo de negócio quanto da engenharia de software e da organização. Nesse framework, os processos são identificados em seis níveis específicos: incompleto, executado, gerenciado, estabelecido, previsível e otimizado.

Para transformar os requisitos em um sistema funcional, os projetistas devem criar um projeto conceitual, que descreva o sistema para o cliente em uma linguagem que este possa entender, para depois transformá-lo em um projeto com uma abordagem técnica para os construtores do sistema.

A engenharia reversa se propõe a gerar uma nova especificação ou um novo projeto de um sistema existente, aplicando-se os conceitos de reengenharia, para, depois, se aplicar a engenharia direta e gerar um novo sistema.

Uma das desvantagens de se utilizar a mesma equipe de desenvolvimento para a realização de testes é a tendência à informalidade na sua execução, o que pode provocar a não identificação de determinados defeitos do projeto.