Como rotular os requisitos de software?

Qual é uma boa estratégia para rotular os requisitos de software em um SRS?

Normalmente, a numeração de estrutura de tópicos é empregada nos cabeçalhos - mas eles serão numerados se um novo cabeçalho for inserido no documento. Para mim, parece uma boa idéia buscar uma designação mais estável para cada requisito de software. Isso deve facilitar a referência a um requisito específico, mesmo em face de um SRS atualizado.

Quais são suas experiências nisso?

Uma estratégia:

1. Considere o ID do SRS como apenas um número e não implica uma noção forte de ordem consecutiva (o número do seguro social é um exemplo razoável).
2. Não recicle números. Quando um ID em uma sequência é excluído, marque-o como "Excluído", "Descontinuado" etc. Eu prefiro manter o texto do requisito no item excluído para que eu tenha um registro contínuo da evolução do requisito. Se você optar por fazer isso, marque o texto excluído obviamente, por exemplo, uma fonte riscada.
3. # 2 implica que novas adições de requisitos nunca ocorrerão "no local"; em vez disso, eles sempre são anexados ao documento.
4. Essa estratégia pode se tornar difícil de organizar ou agrupar hierarquicamente à medida que as alterações se acumulam, portanto, marque cada ID do SRS com um rótulo significativo para pesquisa, por exemplo, [GUI], [DB] etc.

Existem outras estratégias, como o uso de casas decimais pontilhadas para requisitos de cluster, por exemplo:

• 1.0 GUI
• 2.0 DB
• 3.0 Processamento

Como você pode imaginar, os respectivos requisitos devem ser solicitados com o número de nível superior de acordo: 1.1, 1.2 ... para GUI, 2.1, 2.3, 2.4 para DB, etc. Observe que essa estratégia precisará de alguma forma de método controlado para gerenciamento de exclusões e adições.

A principal coisa a ser imposta em um documento de requisitos: uma vez que um ID tenha sido usado para um requisito, ele não poderá ser novamente utilizado. Em outras palavras, se o SRS 1234 foi usado e excluído, ele não poderá ressurgir posteriormente. (Permitir que isso acarrete estragos absolutos na rastreabilidade de requisitos ao longo de um projeto em evolução.)

Observe que praticamente qualquer organização / estrutura do SRS terá deficiências. Escolha aquele que se adapte ao seu ambiente de desenvolvimento e às suas necessidades de aplicativos. (Por exemplo, as estratégias acima funcionam razoavelmente bem em ambientes de desenvolvimento altamente controlados, como os monitorados pelo FDA ou por outros órgãos governamentais.)

Por fim, considere usar uma ferramenta de gerenciamento de requisitos. Existem bons por aí (de código aberto para $$$$$) que cuidam de tudo isso para você.

O melhor pensamento conceitual é que os Requisitos são itens distintos, relacionados entre si de várias maneiras e, portanto, devem ser armazenados em um Banco de Dados. Usar um processador de texto para armazenar requisitos é o caminho errado e leva a muitos problemas, pois gera o pensamento conceitual de que "os requisitos são um documento" - daí a questão. Se você precisar usar um processador de texto, mantenha cada requisito separado, como faria se usasse o Word para armazenar contatos.

Portanto, usar a numeração de estrutura de tópicos para manter os requisitos causará problemas. Imagine tentar fazer o teste de referência cruzada, o SRS e os requisitos do cliente se você alterar os números? Imagine discutir "Requisito 10.2.3.1" apenas para descobrir que no documento de ontem você enviou ao cliente que era "10.2.2.1"

Os requisitos são um rótulo e devem transmitir pouco significado. Você pode ter um ou alguns prefixos curtos de 2 a 5 letras para identificar o escopo ou a unidade, mas quando tiver vários milhares, qualquer significado implícito deverá ser limitado. por exemplo, em um carro, você pode ter o EM-FUEL-1234 (Gerenciamento do motor, sistema de controle de combustível, requisito 1234).

Os requisitos devem poder ser reutilizados nos projetos.

Os requisitos devem ser exclusivos, em todo o escopo e vida útil do projeto. Como guia, alterar um requisito para esclarecer é o mesmo número, mas para alterá-lo significativamente, exclua o antigo e substitua-o. O uso de um esquema de versão (Anexar_1, _2 etc) pode ser útil.

Se você deve usar o Word para armazenar esse banco de dados, uma boa maneira é usar tokens de início e de fim para identificar requisitos. Se você usar um estilo de fonte exclusivo para numeração de requisitos, fica fácil destacar, pesquisar e extraí-los usando macros (talvez em um banco de dados). Exemplo pode ser

#Req 1234 #

Blá blá blá blá

# ReqEnd #

#Req 1234a #

Bla bla bla bla e mais bla

# ReqEnd #