Especificação e diagramas de requisitos de software

5

Sou um estudante de ciência da computação em alguma faculdade, mas estou um pouco confuso com o uso do SRS e vários diagramas, como diagrama de atividades ou diagrama de casos de uso. Sei que o objetivo do SRS é minimizar o tempo e o esforço requeridos pelos desenvolvedores para atingir metas específicas e reduzir o custo de desenvolvimento, bem como a interação do sistema.

Posso perguntar se é apropriado alguém usar essas informações de SRS, por exemplo, como o sistema funciona e desenvolver um diagrama de casos de uso ou qualquer outro diagrama?

Estou um pouco confuso com a forma como o SRS, o diagrama de casos de uso, o diagrama de atividades, etc., interagem de fato.

Eu entendo que certas funções que estão em um diagrama específico devem ser refletidas em um diagrama específico para garantir a consistência.

Mas não consigo decifrar exatamente o que deveria ser o mesmo para garantir a consistência.

    
por Teo Chuen Wei Bryan 16.02.2017 / 12:58
fonte

3 respostas

4

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.

    
por 16.02.2017 / 18:33
fonte
1

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.

    
por 16.02.2017 / 20:52
fonte
1

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 .

    
por 16.02.2017 / 21:18
fonte

Tags