Boa noite Hingridi, você poderia explicar melhor quando diz que as regras de negócio mudam de projeto para projeto ou dar um exemplo mais específico para tentar te ajudar?

Geralmente cada projeto possui suas regras e as especificações pertencem à aquele projeto. Numeração ajuda para fazer rastreabilidade e identificar uma regra quando precisa citá-la. Em um projeto, mesmo que a regra mude constantemente, a numeração não precisa mudar. A RN001 vai ser RN001 sempre.

Ela pode mudar o descritivo. Agora se a RN001 deixar de existir, você não precisa obrigatoriamente renumerar todas as outras regras para ter uma nova RN001. Exceto, se no seu projeto ou cliente tiver tal necessidade por algum motivo.

Se tudo é feito via word ou excel, sem apoio de ferramentas o trabalho de manter essa documentação é muito pior. Outro motivo para não ficar renumerando sempre. Só em casos extremos.

Exemplo da facilidade da numeração. É mais fácil falar que a RN001 está com problema do que falar do que a RN xpto está com problema. Troque xpto pelo nome que você deu. Se for um nome grande complica mais ainda. Se for RN's com nomes similares isso pode confundir.

Outra coisa a ser verificada, é se você coloca na RN coisas que não são da RN. Isso pode aumentar a chance de mudar o tempo todo. Exemplo é definir comportamentos de navegação ou tipos de campos em RN's. Isso geralmente fica em caso de uso. RN's deveriam mudar, quando as regras do negócio mudam. Seu negócio é tão dinâmico que as regras mudem o tempo todo?

Agora se você está falando de um produto customizável ou parametrizável, onde tenha um projeto de implantação no cliente A e um projeto de implantação no cliente B, onde cada projeto possua as "regras" o problema pode ser outro.

Suponha que o valor de um pedido é igual ao valor do serviço x quantidade. Contudo seu sistema permite que o cliente crie pessoas diferentes para o mesmo serviço conforme porte do cliente (VIP, Basico e etc)

Sua regra poderia ser algo no seguinte sentido: "Regra para calcular valor do pedido: 1º Verificar o porte do cliente do pedido (VIP ou Base) 2º Verificar serviço incluído do pedido 3º Verificar qual o preço do serviço obtido no passo 2. O preço obtido deve ser o valor definido para cliente com o mesmo porte obtido no passo 1. 4º Multiplicar a quantidade de serviço no pedido pelo valor obtido no passo 3. 5º O valor calculado no passo 4 é o valor exibido em tela como valor do pedido"

As rerga acima precisa de umas melhorias na descrição, mas o foco aqui é que não importa como cada cliente configure os valores de preço do serviço. Essa regra será sempre verdadeira.

Outro cenário que já vi, são sistemas que o nível de customização ou parametrização é tão grande, que é praticamente cada projeto um sitema novo. Nesse caso, existe uma documentação de Requisitso e RN's do core, que não muda. Em cada projeto, você cria os requisitos e rn's que adaptou naquele projeto daquele cliente. Exemplo a RN002 do do core é essa. No cliente A a RN002 é da forma xxx. No cliente B a RN002 é da forma zzz.

A vantagem é que se mudar algo na RN002 do seu core, fica mais fácil saber em quais cliente isso pode impactar.

Espero que tenha ajudado. Se sim, marque essa resposta como solução. Se não coloque algum exemplo para ficar mais fácil entender.