Especificação e diagramas de requisitos de software

Para mim, o objetivo fundamental da SRS é informar ao time de software o que o software deve fazer . Esta é uma alternativa para apenas fazer as coisas à medida que você avança (aka "ágil").

Se você está indo orientado a objeto, então você precisa ter uma abordagem de análise e design orientada a objeto. Muito provavelmente, o primeiro passo é identificar os atores na SRS e identificar os objetos (pode haver apenas um neste nível).

Depois, você pode desenvolver casos de uso. Provavelmente são vários diagramas de casos de uso, a menos que você queira um diagrama monstruosamente grande.

Mais tarde, você dividiria os objetos em pacotes e depois em classes.

A consistência é feita pela rastreabilidade, até o fim. Todo requisito de software deve ser tratado por algo abaixo dele em seu design (geralmente um caso de uso, mas nem sempre). Uma "matriz de requisitos" geralmente é a melhor maneira de documentar isso.

Em casos extremos (como segurança crítica), você pode ter que ir tão longe com sua rastreabilidade de requisitos que se alguém apontar para uma linha em seu código e perguntar "o que é isso?", você pode rastrear todo o caminho faça backup para responder exatamente qual (is) requisito (s) está ajudando a satisfazer.

Não torne as coisas mais complicadas do que elas são. O SRS é simplesmente um documento que descreve o que o software deve fazer, mas não como ele será feito. Pode ser texto simples, mas geralmente faz sentido incluir diagramas. Geralmente, é uma boa ideia usar diagramas UML padronizados, como Caso de Uso ou Atividade. Mas isso não é de forma alguma necessário.

Uma Especificação de Requisitos de Software (SRS) é uma ferramenta para auxiliar na comunicação entre as partes interessadas. Não se destina a minimizar o tempo e o esforço ou a reduzir custos, além de ajudar a facilitar as comunicações. Os documentos SRS descrevem o escopo, fornecem um ponto de partida para a construção de casos de teste e dão uma ideia tangível para revisar e discutir.

Padrão IEEE 29148-2011 - Norma Internacional ISO / IEC / IEEE - Sistemas e engenharia de software - Vida Processos cíclicos - Engenharia de requisitos é o padrão atual para estrutura e conteúdo de uma SRS. Embora grande parte da discussão esteja relacionada a requisitos textuais, a norma reconhece outros métodos de captura de requisitos, incluindo modelos visuais. UML (e linguagens ou técnicas similares) seriam incluídas como modelos visuais. O padrão até menciona fluxo de dados, fluxo de controle, modelos de estado, modelos de objetos "e muitos outros".

Definir métodos e abordagens para modelos visuais para requisitos de software é algo que você pode obter um livro inteiro .

Pessoalmente, alguns modelos se prestam melhor à engenharia de requisitos do que outros. Na UML, descubro que os diagramas de Atividade, Estado, Implantação e Caso de Uso tendem a se adequar melhor à engenharia de requisitos (embora eu recomende evitar diagramas de Casos de Uso na maioria dos casos). Isso não impede o uso de outros modelos (diagramas de classes, diagramas de seqüência), mas eles provavelmente estarão com baixa fidelidade. Considere também os modos UML , especialmente UML as Sketch , bem como as técnicas de Modelagem Ágil .